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

Rozumiem pojęcie elementu obcego. Jednakże z inputem nie do końca zgodziłbym
się. O tym niżej (przy borderze inputa).

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

Tylko dlatego gdyż w tym wątku zastanawiam się nad radio i checkboxami.
Gdybym się zastanowił ogólnie nad wszystkimi tagami to pewnie więcej
napisałbym.

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

A no widzisz. Dodam, że background też. Odpowiedź tu zdaje się być
oczywista: ponieważ autorzy pomysłu obcości inputów doszli do wniosku, że
chyba zapędzili się w usztywnianiu definicji. Inputa nie da się narysować w
programie zewnętrznym tak jak można narysować obrazek czy oprogramować
appleta, czego efekt tego zobaczy każdy kto odwiedzi stronę. Dlatego jedynym
"edytorem" gdzie mozna coś pokolorować jest CSS. Pewnie za jakiś czas ktoś
wpadnie na pomysł, że input "text" nie jest leszy wcale od input "checkbox"
i wprowadzi postulowaną przeze mnie zmianę do CSS.

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

Tak się domyślałem... lecz dlaczego pielęgnować sirmiężność zamiast dodać
banalne 2 style i udostępnić nową funkcjonalność niskim kosztem? Szczególnie
tego aspektu nie mogę pojąć. Istnienie aplikacji WWWod dawna stało się
faktem. Większość aplikacji wymaga istnienia narzędzi. Skąd więc upór w
zrobieniu tego małego kroku wymagającego niewielkiej ingerencji w celu
umozliwienia przeglądarkom obsługi nowych 2 styli?

> I bez grafiki nie masz kontrolek.

Dlaczego nie? W takim przypadku ich wygląd mógłby być przywrócony do
standardowego jaki obecnie mamy.
Jest jeszcze innej natury argument sugerujący absurdalność wyłączania
grafiki dla aplikacji WWW. Gdybyś mógł wyłączyć w Photoshopie wszelkie
obrazki to niewiele byś w nim zdziałał. Podobna konsekwencja mogłaby
dotyczyć aplikacji WWW. Aplikacji WWW nie czyta się lecz pracuje się w nich.
Wyłączanie grafiki jest bezcelowe.

do góry

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

Tylko w jaki sposób spowodować aby takiego samego "thema" w zakresie
inputów mieli wszyscy odwiedzający stronę WWW jeśli nie CSSem? Jak napisałem
Tobie nieco wcześniej - inputy tekstowe można już ostylować. Pozostałe póki
co są typami gorszymi i dopóki nie znajdzie się kolejny Martin Luter King
walczący o równouprawnienie, to będziemy używać armat na wróble obchodząc
niedostatki HTMLa i CSSa.

do góry

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

Gdyby dało się je publikować jako element strony WWW to pewnie tak
zrobiłbym. Tymczasem muszę wiązać buta dżdżownicą bo sznurowadeł nie
produkuje się.

do góry

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

do góry

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

No dobrze - ale jeśli coś ma się zachowywać dokładnie jak chceckbox a tylko
wyglądać inaczej to po co tworzyć nowy tag w HTMLu skoro można przypisać
styl do już istniejącego? (zauważyłem, że niżej poruszasz ten wątek i tam
będę go kontynuował)

> 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, ale w tym momencie ograniczasz rolę tych kontrolek do elementów ankiety.
Czy w Photoshopie masz problemy z poruszaniem się po pasku narzędzi?
Wyjaśnię, że mam tu na myśli wykorzystanie tego typu przycisków jako
przełączników narzędzi a nie wyłącznie jako elementów ankiety.

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

Hmmm... to mnie trochę przekonuje do tego, że toolbar może mieć (choć nie
musi) szerszą funkcjonalność niż istniejące kontrolki. W takim przypadku
tylko nwy tag rozwiązuje temat. Ograniczmy więc radio i checkboxy do
zastosowania w ankietach. Istnieje problem kontrolek na np. czarnym tle. Pod
IE8/FF wyglądają one paskudnie. Osobiście nie widzę przesłanek, dla których
nie mógłbym mieć możliwości narysowania sobie własnego kształtu kontrolki.
Jeśli chcę coś spierniczyć to i tak to zrobię już teraz, bez postulowanej
funkcjonalności więc argumentacja z k...wowaniem powinna dotyczyć jedynie
wyczucia ergonomii u twórcy strony WWW a nie dawania kolejnego mechanizmu,
który mógłby być nadużyty.

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

hahahhaha
Uśmiałem się....:-) Mam własnie taki problem z czarnym tłem. Kontrolki na
nim wygladają jak hot piksele matrycy monitora a ja wolałbym żeby wygladały
jak kontrolki. Czy wobec tego należy unikać czerni w tle? Wydaje mi się to
być dość drastycznym obejściem braku styli dla kontrolek.

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

Tak, po zainstalowaniu Adobe InContext Editing udaje się :-)

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

Twórca stron powinien mieć w biurze wszystkie systemy operacyjne świata aby
móc skontrolować poprawność wyglądu strony. Gdyby było mozna narzucić wygląd
strony WWW wszystkim elementom HTML a nie prawie wszystkim jak jest to
obecnie - to takiego problemu nie byłoby. Inputa tekstowego juz tak mozna
ostylować. A co z paroma niedobitkami?

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

To, że nie rozwalą mu layoutu strony tak jak dzieje się to obecnie z czarnym
tłem. Ponadto zauważ, że osoba całe życie pracująca na Mac'u poradzi sobie z
wypełnieniem formularza WWW wyświetlonego pod Windowsem i vice versa. Żaden
system nie narysuje pola tekstowego w postaci szympansa a radiobuttonów w
formie pcheł z tego szympansa :-D
Dlatego nie czyń analfabetami uzytkowników pracujących pod innym systemem
niż ulubiony. Dadzą sobie radę bo różnice nie są aż tak drastyczne jak
sugerujesz.

> Jak tak bardzo chcesz mieć kontrolki pasujące do wyglądu strony, to
> sobie zmień skórkę w systemie.

Nie sobie lecz oglądaczom danego projektu. Niestety jeszcze nie dali w HTMLu
takiego obejścia braku 2 styli. :-) Z pewnością wtedy zmieniłbym czarne
radiobuttony na czarnym tle na dostrzegalne, np. zielone.

do góry

Dnia Mon, 22 Jun 2009 23:43:09 +0200, Marek napisał(a):

>> To może jednak wróć do projektowania aplikacji windowsowych?
>
> Gdyby dało się je publikować jako element strony WWW to pewnie tak
> zrobiłbym.

Po pierwsze: nie usuwaj kontekstu.
Po drugie: da się. Słyszałeś o XUL-u?

> Tymczasem muszę wiązać buta dżdżownicą bo sznurowadeł nie
> produkuje się.

To kup buty na rzepy.

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

do góry

Marek pisze:
> 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.

HTML nie jest językiem pisania aplikacji, jest formatem zapisu
dokumentu. Przynajmniej pod takim kątem został zaprojektowany i takie
jest jego podstawowe zastosowanie. Jeśli chcesz pisać aplikacje z
rozbudowanym interfejsem (RIA), to masz do tego celu inne środki (Java,
Flash, Silverlight, Rebol, Curl itd). Nie miej więc pretensji do twórców
standardów HTML i CSS, tylko do siebie, że używasz niewłaściwych narzędzi.

Pozdrawiam,

artur

do góry

Marek pisze:
>> Jeśli istnieje szansa zaserwowania go większości "oglądaczy" - czasem
>> pewnie warto.
>
> Mniej więcej połowy więc czekam na jakąś stymulację :-)
>
>> Na stronie z sygnaturki mam pewien efekt który zobaczą (ściślej: usłyszą)
>> tylko nieliczni - warunkiem jest Firefox i któraś z najnowszych wersji
>> screenreadera. Uważasz że nie warto było tego tam umieszczać?
>
> Jestem otwarty na nowinki techniczne. Możesz jakiś link podesłać?
>
>> A poza tym - zawsze to jakiś argument na nIE :)
>
> Tak na marginesie ... czemu zawsze IE musi być z tyłu? Masz na to jakąś
> teorię? Nie sądzę aby było to ambicją jego twórców. Dlatego zupełnie nie
> rozumiem polityki M$.

Proste: im więcej będą potrafiły przeglądarki internetowe, tym większa
szansa, że aplikacje webowe staną się konkurencją dla aplikacji
systemowych. A tego M$ by nie chciało. Wyobrażam sobie, że przy braku
"hamowania" technologii internetowych przez M$ już dawno mielibyśmy w
100% funkcjonalne pakiety biurowe on-line.

Pozostaje tylko czekać, aż jedyną funkcją systemu operacyjnego będzie
uruchomienie przeglądarki internetowej ;) i to też nie wróży dobrze M$owi.

To tak moim skromnym zdaniem...

--
Radek N.

do góry

> Po pierwsze: nie usuwaj kontekstu.

Trochę dużo się go nam zrobiło...

> Po drugie: da się. Słyszałeś o XUL-u?

Nie, nie słyszałem. Bardzo ciekawa koncepcja. Jak tylko będzie publicznie
dostępna to zainteresuję się nią. Obawiam się jednak, że będzie to kolejna,
początkowo bardzo zależna od platformy funkcjonalność. Tymczasem wolę skupić
się na teraźniejszości.

> To kup buty na rzepy.

Tak robię rzeźbiąc za pomocą kodu JS :-)

do góry

> HTML nie jest językiem pisania aplikacji, jest formatem zapisu dokumentu.
> Przynajmniej pod takim kątem został zaprojektowany i takie jest jego
> podstawowe zastosowanie. Jeśli chcesz pisać aplikacje z rozbudowanym
> interfejsem (RIA), to masz do tego celu inne środki (Java, Flash,
> Silverlight, Rebol, Curl itd). Nie miej więc pretensji do twórców
> standardów HTML i CSS, tylko do siebie, że używasz niewłaściwych narzędzi.

Hej,

1. Nie mam pretensji - nigdzie ich nie zgłaszałem. Pewnie nie śledziłeś
dyskusji więc przypomnę, że pytałem o mozliwość podstawienia grafiki do
reprezentowania stanów 2 typów kontrolek.

2. Całkowicie nie zgadzam się z pierwszym zdaniem. W początkach internetu
było ono prawdą lecz nie od czasu wprowadzenia formularzy do HTMLa. Nie
wyobrażam sobie zrobienia sklepu internetowego wyłącznie we Flashu czy w
Javie - jak sugerujesz. To kompletne nieporozumienie.Od czasu stworzenia
formularzy powstało mnóstwo aplikacji internetowych pracujących z
wykorzystaniem HTML. Mnóstwo CSMów korzysta właśnie z HTML'a jako języka ich
interfejsów. Zwróć też uwagę, że aplikacje WWW istniały zanim powstał
Silverlight, Flash i Java (dla stron WWW).

do góry