[Semantiek] Formulieren

[Victor]

In navolging van het door mij gestartte topic Semantische HTML, CSS en jij, hier het eerste draadje, en wel over formulieren.

Formulieren zijn eigenlijk altijd al een gevalletje table klussen geweest. De INPUT velden zijn net wat groter dan een beschrijvende tekst en vaak lijnt het allemaal niet zo mooit uit. Een tabel bestaande uit twee kolommen met in de linker een beschrijving van het veld en in de rechter het veld zelf zal ons niet vreemd zijn. Maar hoe moet het dan wel?

Helaas is hier zoals met veel van deze problemen geen eenduidig antwoord op te geven. Sommige formulieren hebben daadwerkelijk iets weg van een tabel, bestaande uit een aantal kolommen met een aantal rijen die door de user te bewerken zijn. Ik zal uitgaan van het klassieke contactformulier om een eerste mogelijke oplossing aan te dragen.

Om maar meteen met de deur in huis te vallen:

HTML:

<form action="#">
    <fieldset>
        <legend>Semantic Form</legend>
        <label for="firstname">First name:</label>
        <input type="text" id="firstname" /><br />
        <label for="lastname">Last name:</label>
        <input type="text" id="lastname" /><br />
        <label for="email">E-mail address:</label>
        <input type="text" id="email" /><br />
        <label for="homepage">Homepage URL:</label>
        <input type="text" id="homepage" /><br />
    </fieldset>
</form>

En de CSS om het netjes neer te zetten:

Cascading Stylesheet:

label
{
    float: left;
}

input
{
    margin-left: 120px;
    display: block;
    font: small Verdana, Tahoma, Arial, Sans-Serif;
}

br
{
    display: none;
}

En even wat toelichting: allereerst natuurlijk een FIELDSET om het netjes te groeperen en een LEGEND om het beestje een naam te geven. Maar dan waar het allemaal om draait: het netjes tegenover elkaar uitlijnen van de LABELs en INPUTs. Hiervoor heb ik constructies gezien met SPANs, DIV's en DL's. SPANs en DIV's zijn hier sowieso overbodig, maar de DL is nog een interessant discussiepunt. De DT's en DD's zijn natuurlijk prima te gebruiken om respectievelijk de label en het veld te herbergen, maar zijn in mijn ogen dubbel op. Een label is al een beschrijving van een veld, dat hoeft niet nog eens in een DT.
Maar goed, genoeg over hoe ik het niet heb gedaan.
Allereerst heb ik simpelweg alles in paren naast elkaar gezet, LABEL voor het veld en een BR voor de volgende twee. Op deze manier staat alles zonder CSS netjes geordend en is het prima bruikbaar. Maar we willen met CSS dat de INPUT velden even ver van de kant af staan, dus zonder het inspringen van de verschillende lengtes van de LABELs. Dit los ik op door de LABEL een float te geven, waardoor de margin van de INPUT zich tegen de container zal positioneren.
Maar de margin van de INPUT werkt nog niet, eerst zullen we deze een display: block moeten geven. Doordat de INPUT zich nu gedraagd als een blockelement komt alles daarna op een volgende regel te staan, maar dat deed onze BR ook al. Omdat we de BR wel nodig hebben (zodat het ook bruikbaar is zonder CSS) schakelen we deze uit met een display: none. En voila, een net opgemaakt formulier. Uiteraard valt dit alles met de nodige margin's volledig naar wens op te maken.

Uiteraard ziet niet ieder formulier er zo uit, en is deze oplossing dan ook alleen toepasbaar in deze situatie (hoewel er natuurlijk wel verder op gebouwd kan worden). Er zijn ook formulieren bestaand uit meerdere kolommen van velden, formulieren voor het bewerken van datagrids, etc.

Graag jullie mening over deze oplossing en toepassingen van CSS op andere typen formulieren.

Zie ook: Semantische HTML, CSS en jij

[Verwijderd]

Je oplossing met <br /> vind ik vrij bizar, de rest zou ik precies hetzelfde doen. Een ander punt is of je wel een fieldset zou willen gebruiken?

Wat mij betreft komen de label+input samen in een p element. Als je niet hoeft te groeperen kun je dan de fieldset weglaten.

[crisp]

Even los van het feit dat gebruik maken van labels sowieso een good practice is gebruik ik voor dergelijke formulieren toch vaak nog gewoon een table, en semantisch gezien vind ik dat niet eens incorrect

Een definition list is vaak ook wel een goede optie naar mijn mening, maar lastig(er) te stylen...

[Verwijderd]

crisp schreef op maandag 23 januari 2006 @ 23:42:
Even los van het feit dat gebruik maken van labels sowieso een good practice is gebruik ik voor dergelijke formulieren toch vaak nog gewoon een table, en semantisch gezien vind ik dat niet eens incorrect

Een definition list is vaak ook wel een goede optie naar mijn mening, maar lastig(er) te stylen...

Met tables is niets mis, zolang je ze niet zo gebruikt:

Label1	Label2
Input1	Input2

[Sappie]

Ik doe het over het algemeen op dezelfde wijze als de TS en kan me hier dus wel in vinden

[ Voor 14% gewijzigd door Sappie op 23-01-2006 23:51 ]

[Verwijderd]

King_Louie schreef op maandag 23 januari 2006 @ 23:19:

Formulieren zijn eigenlijk altijd al een gevalletje table klussen geweest. De INPUT velden zijn net wat groter dan een beschrijvende tekst en vaak lijnt het allemaal niet zo mooit uit. Een tabel bestaande uit twee kolommen met in de linker een beschrijving van het veld en in de rechter het veld zelf zal ons niet vreemd zijn. Maar hoe moet het dan wel?

Vaak is een tabel prima te verantwoorden. Alleen moet je dus niet tabellen in tabellen gaan zetten om het maar juist gepositioneerd te krijgen. Simpele invulformulieren bestaan vaak uit een kolom met labels, een kolom met velden, en elke rij bevat een label en 1 of meerdere velden. Niets mis mee als je het op de juiste manier gebruikt.

Ik zou zelf liever een soort property list element zien, dat zich min of meer zo gedraagt als de bekende properties vensters uit bijvoorbeeld Visual Studio .NET 2003/2005, maar dat is er (nog) niet.

Helaas is hier zoals met veel van deze problemen geen eenduidig antwoord op te geven. Sommige formulieren hebben daadwerkelijk iets weg van een tabel, bestaande uit een aantal kolommen met een aantal rijen die door de user te bewerken zijn. Ik zal uitgaan van het klassieke contactformulier om een eerste mogelijke oplossing aan te dragen.

Om maar meteen met de deur in huis te vallen:

HTML:

<form action="#">
    <fieldset>
        <legend>Semantic Form</legend>
        <label for="firstname">First name:</label>
        <input type="text" id="firstname" /><br />
        <label for="lastname">Last name:</label>
        <input type="text" id="lastname" /><br />
        <label for="email">E-mail address:</label>
        <input type="text" id="email" /><br />
        <label for="homepage">Homepage URL:</label>
        <input type="text" id="homepage" /><br />
    </fieldset>
</form>

Dit is gewoon waardeloos. Je legt echt nergens een relatie tussen een label en een invoer element (los van de for/id attributen).

En de CSS om het netjes neer te zetten:

Cascading Stylesheet:

label
{
    float: left;
}

input
{
    margin-left: 120px;
    display: block;
    font: small Verdana, Tahoma, Arial, Sans-Serif;
}

br
{
    display: none;
}

En even wat toelichting: allereerst natuurlijk een FIELDSET om het netjes te groeperen en een LEGEND om het beestje een naam te geven. Maar dan waar het allemaal om draait: het netjes tegenover elkaar uitlijnen van de LABELs en INPUTs. Hiervoor heb ik constructies gezien met SPANs, DIV's en DL's. SPANs en DIV's zijn hier sowieso overbodig, maar de DL is nog een interessant discussiepunt. De DT's en DD's zijn natuurlijk prima te gebruiken om respectievelijk de label en het veld te herbergen, maar zijn in mijn ogen dubbel op. Een label is al een beschrijving van een veld, dat hoeft niet nog eens in een DT.

Ware het niet dat een machine dan nog niet zal herkennen wat iets precies voorstelt. En dáár gaat het vaak om. Vaak vinden we iets onterecht overbodig of juist onnodig. Maar heb je elk element wel zo duidelijk mogelijk beschreven?

Maar goed, genoeg over hoe ik het niet heb gedaan.
Allereerst heb ik simpelweg alles in paren naast elkaar gezet, LABEL voor het veld en een BR voor de volgende twee. Op deze manier staat alles zonder CSS netjes geordend en is het prima bruikbaar.

Het staat zonder CSS wel enigszins netjes, maar het is niet duidelijk voor een machine. Die heeft alleen informatie over hoe iets weergegeven moet worden. Het br element moet je hiervoor niet misbruiken. Die is er alleen om in een tekst een nieuwe regel af te dwingen om de tekst te verduidelijken.

Maar we willen met CSS dat de INPUT velden even ver van de kant af staan, dus zonder het inspringen van de verschillende lengtes van de LABELs. Dit los ik op door de LABEL een float te geven, waardoor de margin van de INPUT zich tegen de container zal positioneren.
Maar de margin van de INPUT werkt nog niet, eerst zullen we deze een display: block moeten geven. Doordat de INPUT zich nu gedraagd als een blockelement komt alles daarna op een volgende regel te staan, maar dat deed onze BR ook al. Omdat we de BR wel nodig hebben (zodat het ook bruikbaar is zonder CSS) schakelen we deze uit met een display: none. En voila, een net opgemaakt formulier. Uiteraard valt dit alles met de nodige margin's volledig naar wens op te maken.

Altijd uitkijken met zaken als display: block; op invoerelementen. Hoewel meestal gewoon gebeurt wat je wilt, kun je discussieren over de vraag of de huidige user agents het wel helemaal goed aanpakken. Want waarom zou display: block; niet betekenen dat een veld op een nieuwe regel komt met 100% breedte? Ik zou een element rond het invoer element verwachten.

Uiteraard ziet niet ieder formulier er zo uit, en is deze oplossing dan ook alleen toepasbaar in deze situatie (hoewel er natuurlijk wel verder op gebouwd kan worden). Er zijn ook formulieren bestaand uit meerdere kolommen van velden, formulieren voor het bewerken van datagrids, etc.

Tabel, tabel.

Graag jullie mening over deze oplossing en toepassingen van CSS op andere typen formulieren.

Heel simpel. Gebruik de HTML die zo goed mogelijk beschrijft wat de elementen zijn en/of bevatten. Dat een pagina er zonder CSS ook leesbaar uitziet is slechts een indicatie, nooit een garantie dat je markup in orde is.

[DJ Buzzz]

Op http://www.aplus.co.yu/css/styling-form-fields/ staan wel een aantal suggesties over hoe je hetzelfde formulier op verschillende manieren kunt opmaken (dus verschillende flow in het formulier).

[Zoefff]

crisp schreef op maandag 23 januari 2006 @ 23:42:
Even los van het feit dat gebruik maken van labels sowieso een good practice is gebruik ik voor dergelijke formulieren toch vaak nog gewoon een table, en semantisch gezien vind ik dat niet eens incorrect

Een definition list is vaak ook wel een goede optie naar mijn mening, maar lastig(er) te stylen...

In sommige gevallen is een tabel semantisch misschien te verantwoorden, maar over het algemeen vind ik een defenitionlist beter passen. De tweede gebruik ik dus ook vrijwel altijd voor m'n formulieren, ik heb nooit zo'n problemen met het stylen ervan eigenlijk?

Mijn formulier ziet er vaak ongeveer zo uit:

HTML:

<form id="reply" action="">
    <fieldset>
        <legend>Reply</legend>
        <dl>
            <dt><label for="name">Naam:</label></dt>
            <dd><input id="name" type="text"></dd>

            <dt><label for="email">Email:</label></dt>
            <dd><input id="email" type="text"></dd>

            <dt><label for="message">Bericht:</label></dt>
            <dd><textarea id="message"></textarea></dd>
        </dl>
    </fieldset>
</form>

Cascading Stylesheet:

fieldset {
    border:0;
}
fieldset legend {
    display:none;
}
#reply dt {
    float:left;
    width: .. ;
}
#reply dd {
    margin-left: .. ;
}

Eventueel gedonder met floats kan vaak opgevangen worden door de dt en dd een hoogte mee te geven, maar of dat persé nodig is weet ik even niet uit m'n hoofd. Als je het goed doet met margins en paddings niet volgens mij

[crisp]

Ik heb ook geen probleem met het stylen van definition lists

[Zoefff]

Point made

[Victor]

Verwijderd schreef op dinsdag 24 januari 2006 @ 00:02:
[...]

Vaak is een tabel prima te verantwoorden. Alleen moet je dus niet tabellen in tabellen gaan zetten om het maar juist gepositioneerd te krijgen. Simpele invulformulieren bestaan vaak uit een kolom met labels, een kolom met velden, en elke rij bevat een label en 1 of meerdere velden. Niets mis mee als je het op de juiste manier gebruikt.

Eens, maar dat gaat voor alles op.

Dit is gewoon waardeloos. Je legt echt nergens een relatie tussen een label en een invoer element (los van de for/id attributen).

Optisch is de relatie er doordat het op dezelfde regel staat, en voor de machine... waar denk je dat het for attribuut voor bedoeld is?

quote: http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1

The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control.

The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one LABEL may be associated with the same control by creating multiple references via the for attribute.

Het staat zonder CSS wel enigszins netjes, maar het is niet duidelijk voor een machine. Die heeft alleen informatie over hoe iets weergegeven moet worden. Het br element moet je hiervoor niet misbruiken. Die is er alleen om in een tekst een nieuwe regel af te dwingen om de tekst te verduidelijken.

Zie stukje over label hierboven.

Altijd uitkijken met zaken als display: block; op invoerelementen. Hoewel meestal gewoon gebeurt wat je wilt, kun je discussieren over de vraag of de huidige user agents het wel helemaal goed aanpakken. Want waarom zou display: block; niet betekenen dat een veld op een nieuwe regel komt met 100% breedte? Ik zou een element rond het invoer element verwachten.

Het komt niet op een nieuwe regel omdat de label float. 100% breedte is eventueel af te vangen met een gespecificeerde breedte.

Tabel, tabel.

Eens

Heel simpel. Gebruik de HTML die zo goed mogelijk beschrijft wat de elementen zijn en/of bevatten. Dat een pagina er zonder CSS ook leesbaar uitziet is slechts een indicatie, nooit een garantie dat je markup in orde is.

In dit geval kan ik geen enkele reden bedenken waarom mijn oplossing niet goed zou zijn, aangezien het rechtstreeks te valideren valt tegen de W3C specificaties.

[ Voor 9% gewijzigd door Victor op 24-01-2006 09:28 ]

[Sappie]

Verwijderd schreef op dinsdag 24 januari 2006 @ 00:02:
[...]

Dit is gewoon waardeloos. Je legt echt nergens een relatie tussen een label en een invoer element (los van de for/id attributen).

Daar is het for attribuut juist voor; om expliciet aan te geven dat er een verband is tussen een label en controls (in dit geval dus input elementen). Ik kan me best vinden in het gebruik van een tabel voor de layout van een form (want daar wordt het dan dus eigenlijk voor gebruikt), maar het is imho onzin om te zeggen dat dit voorbeeld waardeloos is.

_{zie ook hier: http://www.w3.org/TR/html4/interact/forms.html#h-17.9}

edit:
Had King Louie's post nog niet gelezen dus is deze post wellicht wat overbodig.

[ Voor 8% gewijzigd door Sappie op 24-01-2006 10:39 ]

[Verwijderd]

Sappie schreef op dinsdag 24 januari 2006 @ 10:33:

Daar is het for attribuut juist voor; om expliciet aan te geven dat er een verband is tussen een label en controls (in dit geval dus input elementen).

Dat doet hij in zijn voorbeeld al niet. En zelfs áls hij dat wel gedaan zou hebben, heeft hij nog steeds niet de bij elkaar horende labels en invoerelementen gegroepeerd. Een label mag namelijk gerust helemaal ergens anders in het document voorkomen, en dan verwijzen naar een element. Het enige dat bekend is, is dat er een label en een invoer element op dezelfde regel staan. Zie het verschil:

HTML:

<label for="streetfield">Straat</label> <input id="streetfield" .../> <label for="numberfield">nummer</label> <input id="numberfield" .../><br />

HTML:

<tr>
   <td scope="row">
      <label for="streetfield">Straat</label>/<label for="numberfield">nummer</label>
   </td>
   <td>
      <input id="streetfield" .../>
      <input id="numberfield" .../>
   </td>
</tr>

Ik wens je dan nog veel succes met floatende labels.
Vaak is het een kwestie van gekke varianten bedenken om erachter te komen wat de beste methode is. Het is een voordeel om labels en invoer velden binnen een of ander element te zetten die ze groepeert. Ik hoop dat in het 2e stuk HTML duidelijker is wat de functie is van die tabelcellen. En op zo'n manier zie je ook dat bijvoorbeeld een <label> binnen een <dt> helemaal niet dubbel is. Je vertelt er verschillende dingen mee.

Ik kan me best vinden in het gebruik van een tabel voor de layout van een form (want daar wordt het dan dus eigenlijk voor gebruikt), maar het is imho onzin om te zeggen dat dit voorbeeld waardeloos is.

Ik praktijk kun je er gewoon niet veel mee. Dan vind ik het toch vrij waardeloos.

[ Voor 9% gewijzigd door Verwijderd op 24-01-2006 12:04 ]

[Sappie]

Verwijderd schreef op dinsdag 24 januari 2006 @ 12:03:
Dat doet hij in zijn voorbeeld al niet. En zelfs áls hij dat wel gedaan zou hebben, heeft hij nog steeds niet de bij elkaar horende labels en invoerelementen gegroepeerd.

Misschien begrijp ik je verkeerd, maar daarvoor dient het fieldset element dan toch weer.

Zie het verschil:

HTML:

<label for="streetfield">Straat</label> <input id="streetfield" .../> <label for="numberfield">nummer</label> <input id="numberfield" .../><br />

HTML:

<tr>
   <td scope="row">
      <label for="streetfield">Straat</label>/<label for="numberfield">nummer</label>
   </td>
   <td>
      <input id="streetfield" .../>
      <input id="numberfield" .../>
   </td>
</tr>

Ik wens je dan nog veel succes met floatende labels.

hier volg ik je niet helemaal. De markup voor je form bepaal je toch altijd nog zelf. Ook zie ik niet zo in wat nou het voordeel is van de tabel oplossing boven de oplossing zonder de tabel met betrekking tot het juist kunnen opmaken van het form.

En wat betreft het gebruik van een definition list; ik vind niet echt dat een form binnen zo'n list past (term -> descriptie). Toch is er wel wat voor te zeggen, maar ben ik niet van mening dat het (vanuit semantisch oogpunt) wat toevoegt.

[ Voor 37% gewijzigd door Sappie op 24-01-2006 12:26 ]

[Victor]

Verwijderd schreef op dinsdag 24 januari 2006 @ 12:03:
[...]

Ik zie aan de hand van je voorbeeld met een straat/nummer pas eigenlijk wat je bedoelt. Ik dacht dat je het over de relatie tussen de LABEL en het INPUT element had, maar het gaat hier dus om het groeperen van aan elkaar gerelateerde velden (met bijbhorende labels). Hiervoor biedt HTML echter het FIELDSET element, en zie ik nog steeds de noodzaak van een tabel in zo'n eenvoudig formulier niet.

[-FoX-]

Allemaal goed en wel als je met simpele formulieren werkt met alleen input tekst boxjes. Maar wat als je ook nog een radiogroup nodig hebt waar de gender gespecifieerd kan worden. Een aantal checkboxen en eventueel een paar textarea's samen met een paar comboboxen. Dat zijn toch wel de meest voorkomende types van input controls voor html.

[OzBoz]

Even een interessant linkje voor het nageslacht: http://jroller.com/page/m...hy_you_should_right_align

Gaat over het rechts uitlijnen van de omschrijvende tekst voor formulieren. Leuk om te lezen, maar imo een vrij kansloos onderzoek. Mijn officiële statement is op aanvraag verkrijgbaar. Maar vond het linkje wel even een goeie voor in deze draad.

[Blaise]

Even een interessant linkje voor het nageslacht: http://jroller.com/page/m...hy_you_should_right_align

Wauw! Zo bespaar je je bezoekers een hele seconde! Bij zulke onbenulligheden kies ik gewoon wat er het beste uitziet.

[ZeilDude]

Ik heb ook wat zitten stoeien, omdat ik nog altijd op zoek ben naar een goede manier om mijn formulieren in elkaar te zetten.

Grofweg zijn er 4 manieren:

1. alleen HTML-elementen en hooguit een regeleinde- of een paragraafelement;
2. met een tabel;
3. met <div>-elementen en andere 'lege' elementen;
4. met definitielijsten.

Ik probeer even kort wat voor-en nadelen op te sommen, gebaseerd op mijn praktijkervaring en diverse bestudeerde voorbeelden.

@1 - voordelen:

• symantisch zeer correct, omdat je gebruik kunt maken van alle benodigde elementen, zonder concessies te hoeven doen;
• compacte code;
• goed toegankelijk voor alternatieve browsers zoals Lynx.

@1 - nadelen:

• beperkte mogelijkheden voor opmaak, met name fieldsets en legends zijn een ramp om cross-browser te stylen.

@2 - voordelen:

• goede cross-browser ondersteuning;
• goede mogelijkheden om te stylen;
• werkt zeer goed met 'liquid' design.

@2 - nadelen:

• symantisch discutabel: is een formulier tabulaire data?;
• veel code, lastiger in onderhoud;
• niet alle formulierelementen kunnen altijd een logisch plekje in de tabel krijgen.

@3 - voordelen:

• goede cross-browser ondersteuning;
• goede mogelijkheden om te stylen.

@3 - nadelen:

• symantisch discutabel: probeer je vaak niet gewoon een tabel te maken met andere elementen?;
• veel code, lastiger in onderhoud;
• onoverzichtelijke stylsheets door veelvuldig gebruik van floats en clears.

@4 - voordelen:

• goede cross-browser ondersteuning;
• goede mogelijkheden om te stylen;
• compacte, logische HTML-code;

@4 - nadelen:

• symantisch discutabel: mag je een definitielijst hiervoor toepassen?;
• kleine problemen met IE 3-pixel bug.

Dit is geen uitputtende lijst, maar een opsomming van problemen die me het meest zijn bijgebleven.

Wanneer je de vele voorbeelden op Internet bestudeerd, valt me op dat bijna alle voorbeelden zeer eenvoudig zijn. Meestal 2 kolommetjes met eerst een label en daarachter een text-input. Tsja, die zijn inderdaad niet zo heel erg moeilijk. Om die te stylen kom je met alle 4 de manieren simpel weg.
De praktijk leert dat formulieren vaak net even wat gecompliceerder zijn. Ok, je kunt natuurlijk overdrijven en moet je formulieren ook weer niet té ingewikkeld maken, maar toch...
Grofweg kan een formulieronderdeel op twee manieren in het formulier staan:

1. een label met daarachter een invoerelement zoals een tekstinvoervak of een keuze lijst;
2. een invoerelement zoals een radiobutton of een selectievakje, met daarachter het label.

Laat het probleem nu vaak juist in deze tweede zitten.

De laatste tijd heb ik me vooral verdiept in toegankelijkheid van sites, juist ook door mensen die beperkt zijn in hun lichamelijke vermogens. Ook bij formulieren is dit niet onbelangrijk. Je bent echt verkeerd bezig als je formulieren maakt zonder labels.
Maar ok, welke van de 4 manieren wordt het nu? Ik heb eigenlijk niet een hele duidelijke 'winnaar' gevonden. Zowel optie 2 (tabellen) als 4(definitielijsten) zijn redelijk geschikt. Ik snap het heel goed als mensen nog altijd tabellen gebruiken voor hun formulieren om eerder genoemde voordelen. Symantisch denk ik dat het gebruik van definitielijsten de voorkeur geniet boven tabellen. Daarom ben ik aan de slag gegaan met de laatste.
Uitgangspunt was het volgende formulier: voorbeeld 1. Belangrijk vond ik heldere, logische code die ook goed werkt bij 'liquid' ontwerpen. Ik moest kiezen hoe formulierelementen met een label áchter het invoerelement een plekje moest geven in een definitielijst. Symantisch lijkt mij dit de beste optie:

HTML:

<fieldset>
    <legend>Invoer groep 2</legend>
    <dl>
        <dt>
            Choose a color:
        </dt>
        <dd>
            <input id="blue" type="checkbox" name="checkbox" 
                value="checkbox" />
            <label for="blue">Blue</label>
        </dd>
        <dd>
            <input id="green" type="checkbox" name="checkbox2" 
                value="checkbox" />
            <label for="green">Green</label>
        </dd>
        <dd>
            <input id="yellow" type="checkbox" name="checkbox3" 
                value="checkbox" />
            <label for="yellow">Yellow</label>
        </dd>
        <dt>
            Choose a car:</dt>
        <dd>
            <input id="pt" type="radio" name="radio" value="ptcruiser" />
            <label for="pt">Chrysler PT Cruiser</label>
        </dd>

    -knip-


    </dl>
</fieldset>

Dit ziet er als volgt uit: voorbeeld 2. De kleurtjes zijn om duidelijk aan te geven waar de elementen zitten en hoe groot ze zijn. Voor de volledigheid heb ik een plekje gezocht om foutmeldingen in het formulier aan te geven na het valideren van het formulier.
Helaas zit er een klein foutje in IE, de zogenaamde IE 3px-bug. In IE staat het eerste keuzerondje/optievakje niet uitgelijnd. Dit heb ik opgelost met een conditioneel commentaar, wat alleen in IE werkt, maar daar zit ook allen de fout. Dit opgelost hebbende, ziet de pagina er zo uit: voorbeeld 3.

Tot slot heb ik alle kleurtjes even weggehaald en laat ik zien hoe de pagina in het 'echie' gebruikt zou kunnen worden: voorbeeld 4.

Ik ben zelf best tevreden met dit tussenresultaat. Niet alleen de manier waarop de HTML-code op een logische en beknopte manier in elkaar zit, maar ook de manier waarop het formulier te stylen is. Verder ziet het formulier er erg netjes uit wanneer de stylesheets zijn uitgeschakeld, evenals in Lynx. Het lquid design lijkt zeer goed cross-browser te werken. Helaas geeft FF een tekstvak en een tekstarea een verschillende breedte wanneer je deze baseert op ems. Dit gebeurt niet bij pixels.

Dus... kijk er naar, schiet erop en kom met suggesties voor verbetering.

[ Voor 10% gewijzigd door ZeilDude op 25-01-2006 07:27 ]