Webkafeen

[Bolson]

Hvilken betydning i praksis (og hvordan er praksisen) har det at man ikke knytter <label> til spesifikke felt i et skjema med å bruke 'id'?

Blant oss dødelige spiller det vel liten rolle, men med mer avanserte hjelpemidler så spiller det vel muligens en større (og ikke minst viktig) rolle i mange sammenhenger?

 

Eks;

<label for="hest"> ... <input type=text" id="hest">

kontra

<label> ... <input type="text">

9586307[/snapback]

 

Har aldri sett at det har hatt praktisk betydning for vanlige brukere, men anbefalingene er å konsekvent bruke for og id (altså ditt første eksempel). Muligens at det har større betydning dersom <label> brukes etter <input>

 

I alle fall feiler alle mer avanserte WAI/WCAG tester på første nivå om man lar være. Derfor prøver i alle fall jeg å være konsekvent med å bruke for

[Marvil]

Mavva: Las ein artikkel om dette her om dagen (hugsar ikkje lenkja akkurat no), og konklusjonen var at ein skal halde seg unna input inne i label. Bruk for-attributten.

9586379[/snapback]

Ser nå at eksempelet mitt bidro til en del misforståelser, så her kommer det litt mer utfylt;

<label for="hest">Hestenavn</label>

<input type=text" id="hest">

 

kontra

 

<label>Hestenavn</label>

<input type="text">

Stemmer sikkert som du sier, at det bør holdes utenfor, men lurte egentlig på hvilke forskjeller man opplever i praksis ved å droppe for-attributten..

 

 

For oss vanlige dødelige er det vel også kjekt å bli brakt rett til feltet ved klikk på labelen. Dette kan enten oppnås ved å ha inputfeltet inni selve labelen eller ved bruk av lik id og for. Edit: Oja, var det eksempelet ditt var ment som ja, for/id vs. wrappende label, trodde du mente uten bruk av for/id vs. for/id.

 

Kan tenke meg at nettlesere for svaksynte / blinde drar fordeler av ordentlig markup her med 'relasjoner' mellom label og input, men vet ikke om det er nødvendig. Som regel vil elementene komme i en viss rekkefølge.

 

Jada, bare synsing herfra. Det er du som jobber i Norge.no.

9586397[/snapback]

Mente 'uten for/id' vs 'for/id', bare jeg som skulle spare tid og skrev litt klumsete.

Det er det jeg også tenker, at spesielt i de situasjonene vil dette kunne spille en viktig rolle, og derfor sett noen eksempler på hvordan forskjeller kan oppleves..

 

Har aldri sett at det har hatt praktisk betydning for vanlige brukere, men anbefalingene er å konsekvent bruke for og id (altså ditt første eksempel). Muligens at det har større betydning dersom <label> brukes etter <input>

 

I alle fall feiler alle mer avanserte WAI/WCAG tester på første nivå om man lar være. Derfor prøver i alle fall jeg å være konsekvent med å bruke for

9586679[/snapback]

Om label kommer etterpå har det mer å si som du nevner, på lik linje med at forklaringer/instruksjoner på skjemainnfylling gjerne bør komme FØR selve skjemaet. Endret 27. september 2007 av Marvil

[Steinmann]

Marve: Bruker du ikke for kommer jeg å tar deg

 

Det skal være relasjon mellom label og inputelement.

[Garreth]

Tillogmed validatoren liker ikke at du ikke har for i label-en, sist jeg sjekket.

[Marvil]

Jeg har ingen planer om å droppe dem (ikke at jeg har spesielt mange steder å droppe det men), men ser at praksisen rundt om ikke helt er på for-nivå, så lurte litt på hvordan dette spilte inn på de som trenger dem..

[PT]

Siden vi først er inne på label og input og sånt. Hva vil den beste måten å knytte en hjelpetekst til et bestemt input-element være?

[Cucum(r)]

Siden vi først er inne på label og input og sånt. Hva vil den beste måten å knytte en hjelpetekst til et bestemt input-element være?

9587096[/snapback]

Godt spørsmål. Om vi går etter HTML5-spesifikasjonen kan kanskje SMALL inne i LABEL være det beste alternativet (small print).

[Lovskogen]

Halla. Fant meg kafé med wireless to hundre meter unna hotellet - hvem er med på morgenbad 0700 timar imorra?

 

*Dra tilbake til hotellet med 40 tabs*

[Abruzzi]

Haraldson: Så du skrev du ikke hadde fått Sonans regningen ennå. En kamerat av meg går der og har fått den for noen uker siden så du bør ringe dem og høre..

[Haraldson]

Har jo vært i skranken og hørt, de sa den var på vei.

[Kiman™]

Vil det være hinsides all fornuft å lage nettsiden til Vestre Toten Kommune i 960px bredde? Har spurt om de har noen statistikker over antall 800x600 brukere, men det hadde de ikke. I Norge er andelen 1024x768+ brukere mange, men er allikevel litt usikker på hva slags maskinvare offentlige instanser og lignende sitter med? Det er så mye innhold som skal på forsiden at 960px sånn sett er den eneste riktige oppløsningen, men veldig synd hvis 30-40% får horisontal scroll. Og nei, på grunn av innholdet kan jeg ikke bruke fluid layout.

 

Håper noen kan hjelpe, eller har synspunkter på saken

[Vindstille]

Ville vel tro det er under 1 % så det burde gå greit, men unngå for all del en tekstbredde på over 750 px. Det er da det virkelig begynner å bli plagsomt med for liten oppløsning. Stor tekstbredde er dessuten heller ikke noe bra for lesbarheten med mindre man har meget stor fontstørrelse (>30 pt))

Endret 27. september 2007 av JonT

[Kiman™]

Takk

Da går jeg for 1024x768, og tekstbredden skal holdes langt under 750px.

[Haraldson]

750px er da langt i overkant av anbefalt linjelengde. Du skal langt opp i tekststørrelse for å forsvare det.

[Cucum(r)]

400px max, etter mitt syn.

[Vindstille]

750px er da langt i overkant av anbefalt linjelengde. Du skal langt opp i tekststørrelse for å forsvare det.

9588064[/snapback]

Virket da i hvert falls om Kiman forsto det fint.

 

70 tegn er vel tommelfingerregelen, så kan man eksprementere litt grid og passende bredde utifra det.

[Haraldson]

45-75 tegn. 60/12-regelen er vel mest kjent/utbredt, for de som bryr seg om sånt.

[Vindstille]

Noen som vet om noen Django/Python-blogger jeg bør følge med på?

[Magnus Holm]

Nei, du får legge de til i signaturen din hvis du finner noen

[Vindstille]

Nei, du får legge de til i signaturen din hvis du finner noen

9588322[/snapback]

Railshumor sucks

 

Neida, hadde vært morsomt å lært Rails også. Men tror jeg konser på å lære Django skikkelig først.