Marek pisze:
>> Nie. Jeśli podany obrazek mi się nie spodoba, to go mogę zamienić na
>> inny zmieniając tylko src (zakładam te same wymiary, opis w alt,
>> itp.). Jeśli podany checkbox nie podoba mi się, to... nie mogę go ni
>> jak zmienić. No chyba, że nakombinuję się w js
>
> Zastanawiam się nad powodem, dla którego dla nas oczekiwana
> funkcjonalność CSS jest oczywista, a dla Pawła i Pornela zupełnie
> niezrozumiała. Nie mogę pojąć dlaczego zmiana kształtu standardowej
> kontrolki na inny kształt miałaby być niedozwolona. W konsekwencji
> dlaczego nie wolno w HTMLu robić np. przełącznika narzędzi tą techniką?
> Wystarczyłyby dwa style: background-image dla aktywnego i nieaktywnego.

Wg mnie wszystkie elementy HTML-a powinny dać się zmieniać na dowolne
sposoby. I tak obecnie zdecydowana większość elementów da się zmieniać,
poza np. input type file, radio czy checkbox. Podnoszone głosy w stylu
"zostaw mojego scrollbara w spokoju" są moim zdaniem jakimś
nieporozumieniem. Wchodzisz na stronę www i dostajesz jakąś zawartość
określoną przez jej autora. A jeśli nie chcesz czegoś oglądać, to
_zawsze_ można sobie np. taki ustawić tryb, jaki będzie dla
"właściciela" przeglądarki wygodny, ot, choćby w Operze (tryb użytkownika).

Jeśli rozważyć by argument, że część kontrolek musi wyglądać tak, jak
system nam to narzuci, to albo jest to jakieś niedopatrzenie producentów
przeglądarek albo to jakaś idea, którą mało znam.

WWW to nie DTP. Tu wszystko się zmienia jak w kalejdoskopie i każda
witryna będzie wyglądać podobnie, ale nie tak samo, i zawsze będzie
mogła być poddana pewnym manipulacjom przez oglądającego. I to, że nie
można zmienić określonej kontrolki i producentowi przeglądarki wydaje
się, że poczynił cudowny krok w celu zabezpieczenia tego, to się myli,
bo jak wiemy, wszystko da się zrobić. Pytanie tylko po co marnować czas
na to?

--
Peter

do góry

Marek pisze:
> "Czy za pomocą CSS da się w jakiś sposób zmienić formę graficzną
> radiobuttonów i checkboxów? Przykładowo button aktywny miałby być
> reprezentowany przez parafkę a nieaktywny innym rysunkiem.
> Jeśli nie - to czy CSS to planuje wprowadzić?"

Za pomocą samego CSS-a niewiele można zrobić z radiobutton-em i
checkboksem. Co najwyżej border, background-color, width czy font-size
(wszystkich nie próbowałem ;-)).

Osobiście chciałbym, aby to była możliwość wpływania na wygląd tych
kontrolek bez uciekania się do sztuczek z js + css.

--
Peter

do góry

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");

do góry

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

do góry

Peter pisze:
> Paweł Piskorz pisze:
>> Peter pisze:
>>> Ale mogę zamienić jeden obrazek na drugi.
>>
>> CSSem? No w sumie się da, tylko jakoś sensu nie widzę :P
>
> Nie. Jeśli podany obrazek mi się nie spodoba, to go mogę zamienić na
> inny zmieniając tylko src (zakładam te same wymiary, opis w alt, itp.).
> Jeśli podany checkbox nie podoba mi się, to...

Zmieniasz sobie systemowego thema i masz inny. Jak Ci się kolor belki
tytułowej okna nie podoba, robisz to samo, a nie domagasz się możliwości
jej stylowania CSSem.


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

Dnia Sun, 21 Jun 2009 13:02:34 +0200, Marek napisał(a):


> [...] Nie interesuje mnie czy tytuł strony zrobiono na H1 czy na P i
> nie mam wewnętrznej potrzeby intuicyjnego rozpoznawania typów
> znaczników.

To może jednak wróć do projektowania aplikacji windowsowych?

ethanak
--
mailto=window.atob('ZXRoYW5ha0Bwb2xpcC5jb20=');
http://milena.polip.com/ - nie czekam na Ivo!

do góry

Marek pisze:
>> Nie. Jeśli podany obrazek mi się nie spodoba, to go mogę zamienić na
>> inny zmieniając tylko src (zakładam te same wymiary, opis w alt,
>> itp.). Jeśli podany checkbox nie podoba mi się, to... nie mogę go ni
>> jak zmienić. No chyba, że nakombinuję się w js
>
> Zastanawiam się nad powodem, dla którego dla nas oczekiwana
> funkcjonalność CSS jest oczywista, a dla Pawła i Pornela zupełnie
> niezrozumiała.

Bo w przeciwieństwie do Was zdajemy sobie sprawę że input tak samo jak
img czy object są elementami "obcymi" (tzw. replaced elements). Wygląd
obrazków zmieniasz GIMPem/PS, animacje edytujesz AF, aplety Javy w
netBeans, scrolle i inputy zmieniasz ustawieniach systemowych. Wszystkie
te elementy umieszczasz z pomocą elementów HTML (a scrolla włączasz
CSSem), a jakoś tylko inputy chcesz móc edytować w CSSie, dlaczego tak
skromnie?

> Nie mogę pojąć dlaczego zmiana kształtu standardowej
> kontrolki na inny kształt miałaby być niedozwolona.

To już inna kwestia, porneL Ci pisał że wtedy powstaje burdel i
użytkownik musi się od nowa uczyć każdego głupiego formularza.
Mnie bardziej dziwi dlaczego można zmienić border tekstowego inputa, a
radio już nie idzie, taki jakiś brak konsekwencji.

> W konsekwencji
> dlaczego nie wolno w HTMLu robić np. przełącznika narzędzi tą techniką?

Nie tyle nie wolno co po prostu się nie da. HTML był tworzony z myślą o
stronach a nie aplikacjach i nikt czegoś takiego nie przewidział.

> Wystarczyłyby dwa style: background-image dla aktywnego i nieaktywnego.

I bez grafiki nie masz kontrolek.


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

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");

do góry

Marek pisze:
>> Sugerujesz, że zastąpienie pasków narzędzi rzędami checkboxów to nie
>> absurd?
>
> Właśnie nie dostrzegam w tym absurdu.

Hint: semantyka. checkboxy wyglądające jak pasek narzędzi to jednak
dalej checkboxy a nie pasek narzędzi.

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

Nie wiem jak Ty, ale ja np. rodzaj kontrolek odróżniam po ich wyglądzie,
nie patrze w kod. I tak, np. jak mam grupę checkboksów, to wiem że mogę
się po nich poruszać tabem, a spacją zaznaczam które chcę, jak mam grupę
radiobutonów to wybieram tylko jeden kursorem a tab ucieka z grupy.
Jak sobie wymyślisz, że u Ciebie w formularz wybrany radiobuton będzie
miał ptaszka, to nie dość że będę miał problemy z wybraniem właściwego -
tab zamiast przejść do następnego przejdzie do kolejnej grupy - to będę
k...ował dlaczego mogę tylko jedną opcję wybrać, skoro zwykle mogłem
zaptaszyć więcej. A przecież tylko będzie wyglądać inaczej.

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

Bo zabierasz się do tego od d..y strony. Jak potrzebujesz pasek narzędzi
to domagaj się odpowiedniego elementu w HTMLu. Pasek narzędzi, select,
radio to są inne rodzaje kontrolek, pomimo iż efekt ich działania jest
ten sam - jedna wybrana opcja. W select możesz wyszukiwać jakiejś opcji
wpisując jej początek, w radio nie da rady. W pasku narzędzi możesz się
poruszać kursorem również na boki, grupa radiobutonów Ci tego nie
umożliwia. To są zupełnie różne kontrolki nie tylko pod względem
wyglądu. Zmieniając wygląd jednej kontrolki na inną zrobisz tylko ułomną
kontrolkę.

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

Z tego samego powodu dla którego umywalka wygląda jak umywalka a nie jak
muszla klozetowa :P

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

Standardowy wygląd dla nagłówków oznacza, że jest albo pogrubiony albo
innym krojem pisma, oraz im niższy poziom nagłówka tym mniejszy font-size.

> Nie wydaje mi się aby H1 był mniej standardowy od INPUT.

Próbowałeś na niego wejść tabem, albo coś do niego wpisać?

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

Czyli co? Robisz divitis, bo w końcu div może wyglądać praktycznie jak
wszystko inne, więc po co używać pozostałych elementów? :)
Hint: www jest nie tylko dla przeglądarek, a i nie wszystkie
przeglądarki są graficzne i obsługują CSSa. Dlatego właśnie nagłówki
robimy w <hx>, a nie <div class="hx">, do przycisków radio używamy
<input radio>, a do palety haczymy i się modlimy żeby działało ;)

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

Ważne, że w danym systemie jest jednolicie. Ilu systemów na raz używasz,
a ilu stron?

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

No to powinien zmienić fach, jeżeli dopiero się o tym dowiedział. Nie
tylko elementy formularza będą wyglądać inaczej.

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

I znowu patrzysz od d..y strony. Co to da użytkownikowi, że jakiej
przeglądarki by nie użył to inputy na stronie będą takie same, skoro i
tak będą inne niż te które zna?
Jak tak bardzo chcesz mieć kontrolki pasujące do wyglądu strony, to
sobie zmień skórkę w systemie.


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

Generalnie się z Tobą zgadzam że powinno się zostawiać elementy
formularza domyślne ale jednak Marek też ma trochę racji. Stylów
systemowych może być tyle ilu użytkowników a co za tym idzie zostawiając
domyślny wygląd narażamy się na kompletną losowość w wyglądzie co może
doprowadzić do anty-dostępności. Dotyczy to wszystkich elementów na
stronie. Przykładowo gdy nie podamy tła i zrobimy czarne litery a styl
systemowy każe wyświetlić tło ciemne wtedy klops (żeby daleko nie szukać
strona logowania adsense, tylko form jest formatowany, przynajmniej tak
kiedyś było). Niestety aby oszczedzać transfer mam domyślnie wyłączone
pobieranie obrazków i zbyt często mam też okazję oglądać fuszerkę gdy
obrazek tła robi za kolor kontrastowy (albo brak połowy funkcjonalności
- nowe allegro). Chyba jednak czasami lepiej zaryzykować i przynajmniej
spróbować jakoś się przed tym zabezpieczyć.

do góry