On Sat, 20 Jun 2009 21:37:39 +0100, Marek <m...@s...interia.pl>
wrote:

>> To jest absurd.
>
> Nie rozumiem, dlaczego absurd?

Sugerujesz, że zastąpienie pasków narzędzi rzędami checkboxów to nie
absurd?

>> Nie, paleta narzędzi jest paletą narzędzi. Przerabiasz argument na
>> "straw man" (http://pl.wikipedia.org/wiki/Sofizmat_rozszerzenia)
.
>
> Oj, chyba przesadzasz. Niczego takiego nie robię. Ok, dostosuję
> nazewnictwo: nazwijmy więc na potrzeby niniejszej dyskusji zastosowanie
> w/w kontrolek paletą narzędzi. Czy istnieje jakakolwiek przesłanka,
> która zabrania utworzenia ze 2 styli zmieniających wygląd kontrolek w
> celu utworzenia palety narzędzi w HTMLu? Co za problem byłoby ją zrobić
> za pomocą check/radiobuttonów z odpowiednim CSS?

Jeśli potrzebujesz paletę narzędzi, to co innego, niż ostylowanie
checkboksa po swojemu, tylko dlatego, że standardowy checkbox jest brzydki.

HTML nie ma elementu odpowiedniego do palety narzędzi, więc nie masz
innego wyboru, niż kombinowanie i hackowanie.

Natomiast HTML ma element właściwy do checkboksów, więc masz możliwość
użycia standardowego zamiast kombinować i hackować.

> Ok, to może inaczej ujmę to co powiedziałem bo widzę, że kręcimy się w
> kółko. Zadanie: zrobić ikonkę dwustanową przełączaną myszą z
> zastosowaniem wyłącznie HTML i CSS, której stan będzie słany GETem lub
> POSTem na serwer.

Różnie, zależnie od tego czy ta ikona ma reprezentować checkbox, radio,
pushbutton, paletę, ikonę pliku. Pierwsze 2-3 z tych standardowymi
elementami. Do reszty niezbędne będą kombinacje ze stylami, ARIA,
tabindex=0 i JavaScript.

> Co stoi na przeszkodzie aby utworzyć możliwość nadawania stylów
> istniejącym kontrolkom w celu uzyskania efektu? Dlaczego nie wolno
> zmieniać Twoim zdaniem kształtu istniejących kontrolek aby osiągnąć w/w
> cel?

Jak już wcześniej wspomniałem, są techniczne problemy w implementacjach
CSS/formularzy. Gdyby CSS potrafił lepiej stylować wszystkie kontrolki, to
bym mniej narzekał.

Mimo tego IMHO standardowe elementy interfejsu użytkownika powinny być
standardowe - pod względem wyglądu i zachowania. Są wtedy natychmiastowo
rozpoznawalne i intuicyjne.

Na przykład na OS X zaokrąglone rogi pól tekstowych oznaczają pole do
wyszukiwania. To jest konsekwentnie używane we wszystkich aplikacjach, ale
nieświadomi tego projektanci mogą zrobić zaokrąglone rogi tylko dla bajeru.

Może się komuś nie podobać zbyt duży kontrast pól na czarnym tle i zrobi
je szare lub półprzezroczyste. Niestety mój system w dokładnie taki sposób
oznacza nieaktywne pola. Podobnie upiększone obramowanie pola może
sprawiać wrażenie pola tylko do odczytu albo pola automatycznie
uzupełnianego.

Nawet jak się domyślę, że zielone kółko to radio button (a nie
nieinteraktywna lampka oznaczająca, że coś jest włączone), to w
użyteczności jest ważna zasada: Don't make me think.

Ogólnie rzecz biorąc upiększone kontrolki mogą być mylące/nieintuicyjne.
Ponieważ łatwiej je zepsuć, niż ulepszyć, IMHO powinno się unikać
kombinowania z nimi.

--
http://pornel.net
this.author = new Geek("porneL");