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

Właśnie nie dostrzegam w tym absurdu. Jeśli chceckbox (albo radio)
odbowiednio ostylowany (co teraz jest to niemożliwe) miałby reprezentację
graficzną inną dla stanu aktywnego i nieaktywnego to zachowuje się on
dokładnie tak jak do tej pory. Nadal przekazuje swój stan GETem lub
POSTem.Co w tym absurdalnego, że wygląda inaczej (np. jest obarazkiem gumki
albo szarej albo kolorowej gdy ma pełnić rolę wyboru narzędzia o nazwie
"gumka") ?

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

Ok, teraz nie mam wyboru i już wiem o tym. Nie potrafię zrozumieć przesłanki
jaką forsujesz, że absurdem jest dołożenie 2 styli do CSS, które w sposób
banalny pozwoliłyby przekonwertować wizualnie i tylko wizualnie istniejące
już elementy HTML, w dodatku już w tej chwili zachowujące się tak jak tego
oczekujemy, na włączniki narzędzi? Czy istnieje jakieś przykazanie, które
mówi "nie będziesz używał włączników narzędzi na stronie WWW" albo inne "nie
będziesz miał INNYCH (graficznie) checkboxów przede mną"?

> 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.

Mówimy tylko o tylko check i radio oczywiście. Dlaczego element standardowy
nie może nim nadal pozostać lecz wyglądać niestandardowo? Czy H1, czy P od
czasu kiedy wymyślono style zmieniające jego standardowy wygląd stał się
elementem niestandardowym? Czy możliwość zmiany wyglądu H1, P zaszkodziła
komuś i powinno się zwalczać mozliwość stosowania do nich CSS?

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

A tego niedoczytałem. Przepraszam. Szczerze mówiąc jako ex-programista m.in.
aplikacji pod Windows nie potrafię sobie wyobrazić takich przeszkód. W
aplikacjach typu desktop nawet nie pomyślałem, że to jest jakikolwiek
problem i bezwiednie podmieniałem wygląd kontrolek na graficzny lub też
pisałem nowe, własne biblioteki rozszerzające możliwości gdy jakieś cuda na
patyku były potrzebne. Podobnie widzę, ze postępują programiści
przeglądarek. Wymyślono w CSS np. styl background-image i nagle stało się
możliwe stosowanie obrazka w tle dla większości tagów. Elementy formularzy
tak czy owak rysują swoją powierzchnię i nie ma problemu aby zamiast rysować
się same programowo mogły w to miejsce bitmapę wrzucić. To nawet jest
uproszczenie a nie rozszerzenie funkcjonalności.

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

No własnie nie do końca. Przytaczany znacznik H1 jest standardowym a mimo to
trudno znaleźć takie 2 serwisy WWW gdzie wygląda identycznie. Nie wydaje mi
się aby H1 był mniej standardowy od INPUT. W szczególności jako widz nie mam
potrzeby rozpoznawania znaczników patrząc na treść strony. Nie interesuje
mnie czy tytuł strony zrobiono na H1 czy na P i nie mam wewnętrznej potrzeby
intuicyjnego rozpoznawania typów znaczników. Mało tego: nie muszę wcale być
świadomy ich istnienia. Jako widz chcę mieć przycisk "gumka" gdy chcę coś
wymazać. I to jest dla widza istotne. Tymczasem jakaś organizacja mówi NIE.
No i programiści męczą się z JS aby banalną kwestię rozwiązać.

> 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.

No widzisz... czyli nawet systemy operacyjne pozwalają między sobą na
zróżnicowany wygląd kontrolek. Czyli strona WWW na systemie A będzie
wygladała inaczej niż na systemie B z czego twórca strony nie będzie
zadowolony. Gdy natomiast miałby wpływ na wygląd to ujednoliciłby go dla
wszystkich przeglądarek. Nie widzę nic zdrożnego w takiej idei. To również
jest argument za CSSem dla radio i checkboxów.

> Może się komuś nie podobać zbyt duży kontrast pól na czarnym tle i zrobi
> je szare lub półprzezroczyste.

Pod IE8/FF i Windows XP kontrast nie jest duży tylko żaden. Czarne kółko
kontrolki zlewa się z czarnym tłem. Widać tylko czarną kropkę wewnątrz
białego koła. Znika pół kontrolki.

> 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.

Tak, z tym się zgadzam. Tak jak wspomniałem: badania dotyczące m.in.
czytelności tych zielonych kółek ponoć w ani jednym przypadku nie wzbudziły
wątpliwości co do ich funkcji.

> Ogólnie rzecz biorąc upiększone kontrolki mogą być mylące/nieintuicyjne.

Mogą ale nie muszą. To nie argument gdyż cała strona może być nieczytelna z
użyciem standardowych elementów również. Wejdź sobie na stronę az.pl i
poszukaj "whois". Wszystko zależy od twórcy strony i jego poczucia ergonomii
i smaku. Może też być odwrotnie: standardowe kontrolki na czarnym tle są
zupełnie nieczytelne.

> Ponieważ łatwiej je zepsuć, niż ulepszyć, IMHO powinno się unikać
> kombinowania z nimi.

Podobnie jest z każdym innym stylem. H1 też można zepsuć używając np. białej
czcionki na białym tle. Czy w związku z tym nie powinno zlikwidować się CSS?