> Nie zrozumiałem ciebię - myślałem, że mówisz o wyglądzie, a nie
> implementacji.
>
> Tworzenie zupełnie nowego typu kontrolki to IMHO inna rzecz, niż
> upiększanie wyglądu istniejących i temat wykraczający poza tę dyskusję.

Jedno i drugie może mieć ścisły związek i w przypadku tego wątku ma go. Ten
sam chceckbox raz może stanowić element ankiety i wtedy ewentualna zmiana
jego grafiki oznaczałaby upiekszanie formularza. Innym razem ten sam
chcecbox może być włącznikiem jakiegoś narzędzia. Funkcjonalnie (od strony
przeglądarki) to ten sam chceckbox. Jak go aplikacjia WWW obsłuży to już
kwastia jej twórcy.

> Bo z punktu widzenia użytkownika (patrzącego na ekran, a nie w źródło
> strony) przestanie być standardowym elementem.

Brawo! Czyli cel osiągnięty! Czyli przykładowo: autor aplikacji WWW robi
narzędzie gumki do mazania po rysunku i udostępnia STANDARDOWY chceckbox z
NIESTANDARDOWYM wyglądem przedstawiającym gumkę. Użytkownik patrząc na taki
STANDARDOWY chceckbox nie wie nawet, że to chceckbox bo do czego mu ta
wiedza byłaby potrzebna? On chce wybrać narzędzie gumki (technicznie:
uaktywnić chceckbox w kształcie gumki) i posługiwać się nią. Tak robią
miliony osób w Photoshopie i innych programach. Czemu w aplikacjach WWW to
musi być taki problem?

> Jeśli zmienia to przeznaczenie elementu, to tak. Na przykład CSS daje ci
> możliwość używania <p> zamiast <h1> (p {font-size:bigger;
> font-weight:bold}), ale to by było niewłaściwym użyciem elementu i
> uniemożliwiało automatyczne zrobienie spisu treści dokumentu.

Zgadza się. Jednakże nikt nie będzie robił spisu treści itp. z narzędzi
udostępnionych przez aplikację WWW. Trudno więc nadużyć chceck i
radiobuttony. A nawet jeśli byłoby to jakoś możliwe to tak jak w Twoim
przykładzie - nie zmusisz nikogo do bycia purystą. Jeśli ktoś chce sknocić
stronę WWW to zrobi to bo ma do tego gigantyczne pole do popisu. Znacznie
mniejsze mają programiści aplikacji WWW bo nawet toolsów nie mogą łatwo
udostępniać.

> Zastąpić element samym obrazkiem jest łatwo. Zastąpić wygląd, ale zachować
> działanie jest bardziej skomplikowane (szczególnie 15 lat temu, kiedy to
> było projektowane).

Dlaczego tak sądzisz? W tej chwili np. chceckbox ma 2 reprezentacje
graficzne: pusty kwadracik i z parafką. Gdyby oba te stany zastąpić buzią
uśmiechniętą i smutną to przecież działanie jego zupełnie nie zmienia się.
Zmienia się tylko reprezentacja wizualna obu tych stanów a same stany są
takie same jak były 15 lat temu.

> H1 nie jest interaktywny, nie ma systemowego odpowiednika i nie
> przedstawia wizualnie aż tyle informacji, co przeciętny input. Elementy
> nie są równe pod tym względem.

Tu przyznaję Ci rację jednakże nie widzę związku interaktywności elementu z
ograniczaniem jego reprezentacji graficznej. Mówię o prymitywnych inputach
przynajmniej - nad innymi nie zastanawiam się w tym wątku. Nie masz
narzędzia do pokolorowania inputów innego niż CSS. Obrazki na stronie możesz
zmienić w Photoshopie. Applety w jakimś narzędziu do Javy. A inputy w czym?
Tekstowy już daje się zmieniać, a reszta jest gorsza?

>> No widzisz... czyli nawet systemy operacyjne pozwalają między sobą na
>> zróżnicowany wygląd kontrolek.
>
> Nie rozumiem jak ta wypowiedź ma się do mojego argumentu, więc powtórzę:

Cytujesz fragment akapitu. Całość stanowi dopiero sens. Chodzi o to, że
system operacyjny nie powinien zmieniać wyglądu strony. W tym momencie
grafik czy programista nie wie czy jego strona nie rozleci się gdy jakiś
system operacyjny wstawi sobie armatę w miejsce inputa bo tak np. pola
tekstowe domyślnie renderuje.

> Na OS X pola z zaokrąglonymi rogami służą do wyszukiwania. (...)

Tak tak, to zrozumiałem doskonale choć tak jak napisałem wyżej - to niezbyt
dobry pomysł pozwalać systemowi renderować pola bo nikt nie zapanuje nad
layoutem serwisu WWW.
BTW - otrzymałem projekt formularza WWW od studia graficznego pracującego
wyłącznie na Mac'ach. Pola tekstowe to prostokąty o okrągłych krawędziach
bocznych. Niekoniecznie więc okrągłość boków jest rezerwowana dla pól
wyszukiwania nawet przez tą grupę osób :-)

> 1. U użytkownika systemu B właściwy wygląd to wygląd B. Temu użytkownikowi
> wygląd A będzie przeszkadzał tak samo, jak twórcy wygląd B.
> 2. Strona nie jest dla twórcy.

No to może zdefiniujmy pod czyim kontem należy tworzyć strony: użytkowników
systemu A czy B? Czy należy zawsze rezerwować tyle miejsca w layoucie aby
system C rysujący armaty w miejscu kontrolek mógł je tam wpasować? A co się
stanie gdy powstanie system D, który dorysuje przy tej armacie jeszcze
obsługę działa oraz ich rodziny? Dlatego uważam, że nikt inny tylko twórca
powinien decydować o wyglądzie wszystkich elementów strony WWW bo strona nie
moze uwzględniać wszystkich systemów operacyjnych z powodów czysto
logicznych. Zawsze może powstać kolejny system i co wtedy? Powstaje absurd
gdyż twórca musi być posiadaczem wszystkich systemów operacyjnych by móc
zbadać czy jego dzieło wygląda ok.

> To coś jak z formatem daty. Jak będziesz mieć datę zapisaną wszędzie tak
> samo, to dla części świata będzie to dziwne. Jak zrobisz to tak, jak
> należy, to głupi klient będzie narzekał, że u amerykanów jest brzydka data
> w formacie, którego nie chce.

Morał z tego może być taki: nigdy wszystkim nie dogodzisz więc niech strona
WWW ZAWSZE wygląda tak samo. Niech CSS/HTML określa bardzo precyzyjnie każdy
z elementów strony WWW nie pozwalając na dowolność interpretacji przez
systemy. W tej chwili 99% znaczników na stronie poddaje się tej zasadzie.
Czemu bronić więc tego jednego procenta? Czy to coś na zasadzie niektórych
hipermarketów, w których słowo "witamy" pisze się w 2 językach aby
podtrzymywać lokalny folklor?

> Ujednolicanie brzmi fajnie póki ujednolicasz wzór, który tobie pasuje.

Mówimy o ulednolicaniu narzędzi sterujących layoutem a nie layoutów, które
nigdy nie powinny zależeć od systemu operacyjnego.

> Jeśli zrobiłeś radio button z rozsądkiem i przy testach z użytkownikami
> nie był problemem, to ok (nikt z badanych nie używał systemu z
> kwadratowymi radio buttonami i okrągłymi checkboksami ;)
>
> Niestety mało kto robi testy, mało kto bierze pod uwagę inne platformy i
> przeglądarki, a udziwnione style inputów o wiele łatwiej mogą być mylące,
> niż udziwnione style <h1>, dlatego wolałbym, żeby twórcy stron trzymali
> się od inputów z daleka (a <h1> stylowali z umiarem).

Tak, tu masz rację oczywiście - rozsądek musi być zachowany. Tyle tylko, że
jego narzucanie poprzez utrudnianie robienia toolbarów dla aplikacji WWW
wydaje się być wylewaniem dziecka z kąpielą. Tak czy owak programiści
zawzięli się i toną kodu obeszli ograniczenie. To chyba powinno dać do
myślenia twórcom CSS.