Perfection or Vanity

Przyznam szczerze, że przyzwyczaiłem się bardzo do idei powiększania tekstu, zamiast całej strony. Wydaje mi się logiczne, że wydając komendę powiększenia zależy nam na tekstowej części dokumentu, a nie na przysunięciu lupy do całości. Gdy myślę o zoomie, widzę od razu potrzebę zakupienia monitora 24", bo nie wiem w jaki sposób strony mogłyby się mieścić na ekranie całe. Skoro często też sam interesujący tekst się nie mieści. Widzę też przeskalowane obrazki oraz niewygodną nawigację po ekranie. Czy mogę mieć rację?

Często stosowanym układem layoutu jest menu o stałej szerokości dostawione z jednej strony układu, tak aby druga kolumna dopasowywała się płynnie do pozostałej szerokości.

Standardowe rozwiązanie jest proste - umieścić w HTML menu (#sidebar) nad treścią (#content), ustawić szerokość oraz float - a temu drugiemu margines równy szerokości menu.

Grafiku! Wyobraź sobie, że projektujesz serwis internetowy. Być może nawet teraz to robisz. Są w nim formularze - jakże by miało ich nie być - pola tekstowe jedno i wielolinijkowe. Pola wyboru jedno i wielokrotnego, rozwijalne listy, pola uploadu plików oraz cała masa przycisków. Masz zestaw wytycznych w postaci wireframes i zabierasz się do ich rysowania w najnowszym Photoshopie / Fireworksie.

Stop.

Rollover, śpieszę z wyjaśnieniem, jest to efekt podmiany obrazka na inny, gdy znajdzie się nad nim kursor myszy. Co to jest CSS rollover i czym się różni od swojego skryptowego przodka już pisałem i jeśli nie słyszeliście o tej metodzie, to możecie zechcieć się z nią teraz zapoznać.

Tyle słowem wstępu. Rollover jaki zaprezentowałem dawniej był całkiem sprytny, nie wymagał czekania na wczytanie drugiego obrazka, ale nie był doskonały. Jego ułomność wynikała z zachłyśnięcia się możliwościami obrazków teł - wciskalibyśmy je wszędzie. Jednak i one stwarzają kłopoty:

Wpis jest komentarzem do, jeśli można to tak nazwać, wzburzenia Elsindela odnośnie skrótów klawiaturowych dla linków oznaczanych atrybutem accesskey.

Przy rejestracjach i dodawaniu komentarzy bardzo często można spotkać tak zwany Captcha czyli obrazek z wygenerowanym fikuśnym tekstem, poprzecinanym liniami, zakropkowanym, kolorowym często. Wszystko po to, aby tylko sprawnie widzący (w przypadku gdy nie ma alternatywy dźwiękowej) człowiek odczytał zawartość obrazka i wpisał to co na nim widzi w formularz. Taka walidacja ma na celu wyeliminowanie spamerskich botów i masowego zakładania kont.

Tym większe było moje, ogromne już i tak, zdziwienie, jak na stronie z bazą wyrażeń regularnych, w polu dodawania komentarza wygenerowano obrazek korzystając z takiego skryptu:

1. http://projectdistributor.net/Captcha.ashx?txt=SWXCR

Nie pomyliłem się. Po znaku równości mamy fragment tekstu. Nie, to nie jest jakiś hash czy xor. On po prostu jest tym co się wyświetli na obrazku. Spróbujmy ze mną:

1. http://projectdistributor.net/Captcha.ashx?txt=RIDDLE

Genialnie. Teraz bot nie musi rozgryzać trudnego obrazeczka, tylko sobie odczyta z kodu źródłowego strony potrzebny ciąg znaków i wpisze go do formularza.

Ja wiem, że zadaniem Captcha nie jest zabezpieczyć coś na amen. Wiem, że zwykle jego algorytmy są znane. Chodzi tylko o utrudnienie życia pająkom (utrudnia się też życie, jak zauważył MiMaS, ludziom z kłopotami ze wzrokiem, jeśli nie ma innego, oprócz graficznego, rozwiązania). Ale umieszczać bezpośrednie odwołanie do skryptu tekstem, który chcemy ukryć? Twórcom pogratulować poczucia humoru.