On Sun, 21 Jun 2009 12:02:34 +0100, Marek <m...@s...interia.pl>
wrote:

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

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

> Mówimy tylko o tylko check i radio oczywiście. Dlaczego element
> standardowy nie może nim nadal pozostać lecz wyglądać niestandardowo?

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

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

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.

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

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

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

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.

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

Bo jesteś osobą widzącą i nie potrzebujesz nawigować po stronie za pomocą
nagłówków.

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

Nie rozumiem jak ta wypowiedź ma się do mojego argumentu, więc powtórzę:

Na OS X pola z zaokrąglonymi rogami służą do wyszukiwania. Kanciaste pola
są do wpisywania danych. System pozwala ci zaokrąglić rogi, ale powinieneś
korzystać z tego tylko wtedy, gdy pole będzie przeznaczone do wyszukiwania.

Pod innymi systemami zaokrąglone rogi nic nie znaczą, więc użytkownik
Windows/Linux projektując stronę może zechcieć zrobić ładne pola,
zaokrąglić im rogi i ujednolicić wygląd na wszystkich platformach (bo nie
widzi nic zdrożnego w takiej idei). Wtedy niewinne upiększenie w
kontekście Windows będzie dziwaczną pomyłką z perspektywy OS X.

Nawet CSS dziś pozwala zaokrąglić rogi dowolnego inputa, ale z ww. powodu
nie powinno się wykorzystywać tej możliwości. Żeby rogi były zaokrąglone
tam, gdzie trzeba w HTML 5 jest <input type=search>.

> Czyli strona WWW na systemie A będzie wygladała inaczej niż na systemie
> B z czego twórca strony nie będzie zadowolony.

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.

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.

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

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

> Podobnie jest z każdym innym stylem. H1 też można zepsuć używając np.
> białej czcionki na białym tle.

H1 nie musi przedstawiać tego, czy jest disabled, read-only, ma auto-fill,
placeholder. Nie ma odpowiednika we wszystkich aplikacjach i nie ma
konwencji specyficznych dla różnych systemów operacyjnych, dlatego masz
większą swobodę w jego stylowaniu.

> Czy w związku z tym nie powinno zlikwidować się CSS?

Nie. CSS ma swoje zastosowania, a poza tym nie sposób zabronić ludziom
strzelania sobie w stopę. Można jednak odradzać stosowanie CSS tam, gdzie
to może mieć negatywne skutki. To, że możesz nie oznacza, że od razu
musisz czy powinieneś.

Możesz zrobić nagłówek, który jest niewidoczny dla użytkowników screen
readerów, możesz zrobić obrazkowy radio button, który będzie
rozpikselowany pod iPhone i wyglądał jak krowi placek przy kontrolkach
Cocoa, możesz robić biały tekst na białym tle, ale nie powinieneś.

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

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