Hoppa till huvudinnehåll
Niquelao Webbtillgänglighet och frontend-utveckling på spanska: WCAG-standarder, tillgängliga widgets och tillägg för Firefox, förklarat med riktig kod.

Vissa länkar på den här sidan är affiliatelänkar: om du köper via dem kan vi tjäna en provision utan extra kostnad för dig. Detta påverkar aldrig vad vi rekommenderar. Se vår affiliate-upplysning för mer information. Ansvarsfriskrivning för affiliate.

Niquelao » Webblogsarkiv » Jag har också sett det...

» Arkiv för webloggen » Jag har också sett det… Niquelao - CSS Jag har också sett det… 11 november 2006 av Rumoroso Den här artikeln kommer jag att inleda bakifrån. Det är inte så att jag tänker skriva den med ryggen vänd, utan jag börjar med att citera (blockcitera) det råd som jag avslutar med: Om vi inte vill vara originella och visa den ruta som genereras av det dolda fältet (“nästan dolt”), är lösningen enkel.

Vi tillämpar display: none så är saken klar. Mitt råd är att man inte försöker markera de dolda fälten med en klass för att sedan tillämpa egenskapen jag nyss nämnde. Istället kan man dra nytta av att Firefox förstår och tolkar attributselektorer: [css]input[type=hidden] { display: none; }[/css] Till sakens kärna… Nej, den här artikeln handlar inte om hur man layoutar något som teoretiskt sett borde vara dolt (ett fält av typen hidden). Jag säger teoretiskt eftersom det i webbläsaren Firefox, när CSS är aktiverat och vi anger vissa värden för egenskapen display på formulärfält, sker att de dolda fälten slutar vara dolda och istället renderas av webbläsaren (såsom syns om man tittar på exemplet i Firefox, eller om du litar på oss och tror på vad vi säger, på skärmdumparna nedan).

Vid det här laget kan frågor uppstå: Varför tillämpa display på ett “hidden”-fält? Om syftet med ett dolt fält är att skicka information utan att visa det, varför skulle någon vilja visa det? Svaret är enkelt och kanske lättare att förstå med ett exempel: Vi har följande formulär: [html] [/html]…där vi tillämpar några grundläggande stilar: [css]form { border: 2px outset; background-color: #CCCCCC; } fieldset { margin: 20px auto; width: 500px; border: 1px solid; padding: 10px; } legend { font-size: 1.5em; color: #000; } label { font-weight: bold; font-size: 1.1em; } fieldset input { display: block; width: 90%; height: 1.3em; line-height: 1.3em; margin-left: 5%; font-size: 1em; } p { text-align: center; margin: 1em 0; } fieldset p { text-align: left }[/css] Vi har tillämpat display: block på formulärfälten för att framkalla ett radbryt, vilket gör att texten som etiketterar dem hamnar ovanför.

Placeringen av etiketterna direkt ovanför textfälten gör att den anonyma textruta de genererar får en större kontaktyta mot själva fältets ruta. Detta förmedlar visuellt bättre och snabbare kopplingen mellan de två (dessutom är det så jag gillar att göra det, punkt slut). Kanske blir det tydligare visuellt: I bilden ovan visas tre sätt att layouta samma formulär.

I det första placeras etikettens text ovanför fältet, vilket ger en större kontaktyta. I de andra två kan man se hur denna yta minskar om texten placeras bredvid fältet den etiketterar.

Dessutom illustrerar den tredje metoden problemet med att försöka justera fälten i förhållande till varandra. På detta sätt skulle man dessutom kunna vänsterjustera alla textfält, vilket kan vara önskvärt i många situationer men som kan skapa konflikter när etiketten föregår fältet (eftersom dessa sällan har samma längd). Poängen är att när vi ger denna egenskap till input-elementen, renderas det dolda fältet i Firefox, och endast i Firefox, som ett tomt block. Korrekt beteende eller bugg?

Related: con plan gratuito para empezar hoy mismo.

Om vi observerar beteendet i IE ser vi att detta inte inträffar. Vid det här laget kommer IE-kritikerna säkert att hävda att Firefox gör rätt, eftersom de vid rollbesättningar ofta väljs ut för rollen som den gode.

I det här fallet får varje och en dra sina egna slutsatser, men inte innan vi tar upp ett par saker (eller egentligen fyra, “ett par” är bara ett talesätt): Finns det någon utvecklare som verkligen vill visa rutan som skapas av ett dolt fält? Tänker designern ignorera vad utvecklaren gjort och istället visa det på eget bevåg? Säger inte specifikationen: “hidden controls: Authors may create controls that are not rendered but whose values are submitted with a form. Authors generally use this control type to store information between client/server exchanges that would otherwise be lost due to the stateless nature of HTTP.

The INPUT element is used to create a hidden control.” (dolt kontroll-element)? Vilket syfte kan det ha att visa den tomma rutan som skapas av ett dolt fält? En lösning Om vi inte vill vara originella och visa den ruta som genereras av det dolda fältet (eller bättre sagt “nästan dolt”), är lösningen enkel.

Worth a look: — Accesibilidad gestionada: automatización combinada con revisión humana.

Vi tillämpar display: none så är saken klar. Mitt råd är att man inte försöker markera de dolda fälten med en klass för att sedan tillämpa egenskapen jag nyss nämnde. Istället kan man dra nytta av att Firefox förstår och tolkar attributselektorer: [css]input[type=hidden] { display: none; }[/css] …och en reflektion Har utvecklarna bakom Firefox övervägt att försöka visa andra dolda ting såsom aura, själ, spöken…?

Ska jag vänta tills de lyckas med det innan jag skickar denna artikel till Iker Jiménez? Kategori: CSS —> Du kan följa kommentarerna via RSS 2.0-flödet . Du kan också lämna en kommentar , eller skicka en trackback från din webbplats.

Föregående artikel: Men, så smart!! Nästa artikel: När det inte finns någon filé, får man säga “nej” till allt! Lämna din kommentar Fälten Namn och E-post är obligatoriska Lägg till oss i… Taggar som vi lyfter fram i allmänhet tillgänglighet bert bos blockquote bugg cañas citat cite beteende kunskap CSS escuas standarder fieldset Firefox format formulär typsnitt hidden ie IE 7 information javascript legend lista niquelando obligatorisk opera strand q squash semester w3c WCAG xhtml Detta verk är licensierat under en Creative Commons-licens .

P.S. A few readers have asked which superposición de accesibilidad (overlay) we actually reach for — it's accessiBe; if you want the current details.


¿Cumplir WCAG sin tocar el código?

Superposición de IA que promete cumplimiento WCAG en 48 horas