Niquelao » Archiwum bloga » Ja też to widziałem…

» Archiwum bloga » Ja też to widziałem… Niquelao - CSS Ja też to widziałem… 11 listopada 2006 przez Rumoroso Ten artykuł zacznę od końca. Nie chodzi o to, że zamierzam go napisać na opak, ale zacznę od zacytowania (blockquote-owania) rady, którą go zakończę: O ile nie jesteśmy oryginalni i nie chcemy pokazać tego prostokąta wygenerowanego przez ukryte pole („prawie ukryte”), rozwiązanie jest proste.

Stosujemy „ display: none ” i załatwione. Moja rada jest taka, żeby nie próbować oznaczać ukrytych pól klasą, a potem stosować właściwość, którą właśnie napisałem. Zamiast tego można wykorzystać to, że Firefox rozumie i interpretuje selektory atrybutów : [css]input[type=hidden] { display: none; }[/css] Do rzeczy… Nie, ten artykuł nie dotyczy tego, jak zakodować to, co teoretycznie powinno być ukryte (pole typu hidden ), i mówię „teoretycznie”, bo okazuje się, że w przeglądarce Firefox , gdy mamy aktywny CSS i zadeklarujemy określone wartości właściwości „ display ” dla pól formularza, ukryte pola przestają być ukryte i zaczynają być renderowane przez przeglądarkę (co można zobaczyć, jeśli obejrzy się przykład w przeglądarce Firefox lub, jeśli nam zaufasz i uwierzysz w to, co mówimy, na poniższych zrzutach ekranu).

W tym momencie mogą pojawić się pytania: dlaczego stosować display na polu „ hidden “?; jeśli celem ukrytego pola jest przekazywanie informacji bez pokazywania się, to po co miałoby się je chcieć pokazywać?;… Odpowiedź jest łatwa i być może lepiej zrozumieć ją na przykładzie: Mamy następujący formularz: [html] [/html]…do którego stosujemy podstawowe style: [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] Zastosowaliśmy display: block do pól formularza, aby powodowały przejście do nowej linii, pozwalając, by tekst, który je opisuje, znalazł się powyżej.

Umieszczenie etykiet bezpośrednio nad polami tekstowymi sprzyja temu, że anonimowe pole tekstowe, które generują, ma większą powierzchnię styku z polem, dzięki czemu wizualnie lepiej i szybciej przekazuje skojarzenie między oboma (poza tym to sposób, w jaki lubię to robić, i kropka). Być może lepiej będzie to widać na obrazku: Na poprzednim obrazku pokazano trzy sposoby zakodowania tego samego formularza. W pierwszym tekst etykiety label znajduje się nad polem, dzięki czemu jego powierzchnia styku jest większa.

W pozostałych dwóch można zauważyć, jak zmniejsza się ta powierzchnia, jeśli tekst znajduje się obok pola, które opisuje. Ponadto trzeci pokazuje problem z chęcią wyrównania pól względem siebie.

Poza tym w ten sposób można by wyrównać do lewej wszystkie pola tekstowe, co w wielu przypadkach może być pożądane i co może tworzyć konflikty, gdy etykieta poprzedza pole (ponieważ zwykle nie mają one tej samej długości). Rzecz w tym, że nadając tę właściwość „ input “, w Firefoksie, i wyłącznie w Firefoksie, renderowane jest ukryte pole, robiąc to jako pusty blok. Czy to poprawne zachowanie, czy bug? Jeśli przyjrzymy się zachowaniu IE, zauważymy, że to nie występuje.

Related: UserWay — Widget de accesibilidad con plan gratuito para empezar hoy mismo.

Na tym etapie przeciwnicy IE powiedzą już, że Firefox robi to poprawnie, bo w castingach zwykle wybiera się go do roli tego dobrego. W tym przypadku niech każdy wyciągnie własne wnioski, ale najpierw stawiając kilka rzeczy (no dobrze, cztery, „kilka” to sposób mówienia): Czy jakiś programista chce pokazywać pole utworzone przez ukryte pole?

Czy projektant zamierza ignorować to, co robi programista, i chce to pokazać na własną rękę? Czyż specyfikacja nie mówi: 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 .

( hidden control )? Jaki cel może mieć pokazywanie pustego pola utworzonego przez ukryte pole? Rozwiązanie O ile nie jesteśmy oryginalni i nie chcemy pokazać tego prostokąta wygenerowanego przez ukryte pole (albo lepiej „prawie ukryte”), rozwiązanie jest proste.

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

Stosujemy „display: none” i załatwione. Moja rada jest taka, żeby nie próbować oznaczać ukrytych pól klasą, a potem stosować właściwość, którą właśnie napisałem. Zamiast tego można wykorzystać to, że Firefox rozumie i interpretuje selektory atrybutów : [css]input[type=hidden] { display: none; }[/css] …i refleksja Czy twórcy Firefoksa zastanawiali się nad próbą pokazywania innych ukrytych rzeczy, takich jak aura, dusza, duchy,…?

Czy poczekam, aż im się to uda, zanim wyślę ten artykuł do Ikera Jiméneza ? Kategoria: CSS —> Możesz śledzić komentarze dzięki kanałowi RSS 2.0 . Możesz też zostawić komentarz , albo wysłać trackback ze swojej strony.

Poprzedni artykuł: Ale będzie mądrala!! Następny artykuł: Skoro nie ma polędwicy, to każde „nie” jak! Zostaw swój komentarz Pola Nazwa i Email są obowiązkowe Dodaj nas do… Tagi, które ogólnie wyróżniamy dostępność bert bos blockquote bug cañas cytaty cite zachowanie wiedza CSS escuas standardy fieldset Firefox format formularz źródła hidden ie IE 7 informacja javascript legend lista niquelando obowiązkowe opera playa q squash wakacje w3c WCAG xhtml Ta praca jest objęta licencją Creative Commons .

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