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

do góry

>Problem sprowadza się do tego, że niektóre elementy formularza w
>każdym browserze wyglądają inaczej.
>Ostylowanie ich w CSS wymagałoby przede wszystkim ujednolicenia ich
>wyglądu (zwłaszcza biorąc pod uwagę różnice pomiędzy systemami, nie
>tylko przeglądarkami) - stąd jest to raczej odległa przyszłość.

Hmm... wydaje mi się, że nie jest to konieczne. Zwróć uwagę, że ostylowania
wymagają tylko dwa stany: aktywny i nieaktywny. Nie ważne jak one wygladają
w Safari a jak w IE. Jeśli dało by się podpiąć rysunek do każdego z tych 2
stanów to byłoby po sprawie - niezależnie od tego jak przeglądarka to
renderuje w chwili obecnej.

do góry

Marek pisze:
> Hmm... wydaje mi się, że nie jest to konieczne. Zwróć uwagę, że
> ostylowania wymagają tylko dwa stany: aktywny i nieaktywny. Nie ważne
> jak one wygladają w Safari a jak w IE. Jeśli dało by się podpiąć rysunek
> do każdego z tych 2 stanów to byłoby po sprawie - niezależnie od tego
> jak przeglądarka to renderuje w chwili obecnej.

Pierwszy krok zrobiono - element button. Na tym jednak stanęło.
Widocznie nie takie to proste i oczywiste, jak się z pozoru wydaje.
Ujednolicenie wyglądu i sposobu działania kontrolek to jedne z
ważniejszych cech ergonomicznego GUI. Wycofać się z tego, to jakby
wrócić do epoki sprzed 20 lat. Wraz ze wzrostem możliwości technicznych
przyszła moda na stylowanie systemowych elementów graficznych, ale to
jest robione "z głową", nie jakimś prymitywnym zastąpieniem przycisku
obrazkiem.

artur

do góry

On Wed, 17 Jun 2009 10:37:05 +0100, wrote:

> Połowa rzeczy z CSS2.1 i 3 nie zadziała w badzIEwiu, co znaczy tylko
> tyle że IE jest do dupy, a nie że się nie da w CSSie zrobić. No i IE w
> Polsce to grubo poniżej 70%, zaktualizuj sobie dane.

Bardzo grubo poniżej. Wg ranking.pl wszystkie MSIE razem wzięte mają 42%
(choć to ciągle o 40% za dużo :)

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

do góry

ethanak pisze:
> Zwróć uwagę może uprzejmie na chronologię - o tym "lekkim makijażu"
> dowiedziałem się już _po_ napisaniu swojego posta.

no za to to faktycznie przepraszam


> Chwalisz się? Wydaje mi się że na tej grupie jest parę osób dla których
> napisanie czegoś takiego pod _wszystkie_znane_ przeglądarki (z netfrontem
> włącznie) nie stanowi żadnego problemu. Nie chodziło mi jednak o
> umiejętnośc napisania jakiegoś kodu a o celowość.
aha


>>> Widziałem ostatnio arcydzieło w którym komuś się ramki naokoło inputów
>>> tekstowych nie podobały więc je kunsztownie usunął - a jako że
>>> istnienie takich elementów jak label pewnie w zakres edukacji owego
>>> geniusza nie wchodziło hgw gdzie trzeba było klikać...
>> znam label i co... to nie znaczy że jestem madrzejszy
>
> Jeśli znasz i stosujesz to owszem, jesteś. Jeśli nie zrozumiałeś tego co
> napisałem to przeczytaj jeszcze raz.

aha, a mi się wydawało że trochę bardziej oczytany człowiek jest i tyle.



>>> a dowodem kunsztu
>>> grafika byłoby stworzenie projektu, w którym standardowy wygląd owych
>>> kontrolek współgrał z resztą strony...
>> może kolega oświeci jaki jest standardowy wygląd kontrolek??
>
> A kolega to przepraszam nie wie? Standardowy to jest taki który oferuje
> mi moja przeglądarka.

nadal czekam o opis. Tworzę stronę agencji reklamowej w określonym
stylu, kolorach. Proszę niech kolega mnie oświeci jak wygląda
standardowa kontrolka, bo chciałbym do niej przypasować strone

To co piszesz to bzdura i utopia:
1. nie ma standardowych kontrolek już od dawna : są themey, sam windows,
KDE itd. ma pare styli nazwanych default to albo tamto

2. oprócz kilku nowych przeglądarek reszta trochę bardziej
skomplikowanego poprawnego CSS rozwala i trzeba stosować myki.
gdzie widzisz standard.


>>> z faktem że ktoś (np. Bardzo Ważny Klient Z Wielce Wypasionom Komurkom)
>>> nie będzie mógl owego formularza wypełnić?
>> przeczytaj to jeszcze raz co napisałeś
>
> Nie, to Ty przeczytaj co ja napisałem. Jakoś wątkotwórcy nie sprawiło
> trudności zrozumienie...

zwykle "Bardzo Ważny Klient Z Wielce Wypasionom Komurkom" nie istnieje,
a większość z nich nie potrafi w ten sposób używać komórki, poza tym
jeśli "Bardzo Ważny Klient Z Wielce Wypasionom Komurkom" nie przewiduje
go w grupie docelowej to nie pisze strony pod komórkę i tyle

Tworzenie na wyrost dla każdego to bzdura którą i sam uprawiałem, w
latach '90 przy bumie Delphi.


>>
>> podstawowy błąd:
>> reklama / strona ma schemat swojego odbiorcę już z góry zwykle
>> ustalonego przez odpowiednich ludzi grafik, projektant ma wgląd do
>> takich wytycznych (nie tylko z kwestii wyglądu np. dla SEO) i tyle, bez
>> jakiegoś gdybania. Klienci, które nie dają takich wytycznych
>> i chcą żeby strona działał wszędzie tak jak piszesz "nie są warte"
>> pracy.
>
> Że co? Przetłumacz na polski.
bez komentarza


--
pozdrawiam,

Krzysztof Warunek

*In specialibus generalia quaerimus*

do góry

> Pierwszy krok zrobiono - element button. Na tym jednak stanęło. Widocznie
> nie takie to proste i oczywiste, jak się z pozoru wydaje.
> Ujednolicenie wyglądu i sposobu działania kontrolek to jedne z
> ważniejszych cech ergonomicznego GUI. Wycofać się z tego, to jakby wrócić
> do epoki sprzed 20 lat.

Z tym raczej nie zgodziłbym się, że to krok wstecz. Istnieją 2 metody
ujednolicenia wyglądu kontrolek:
1) programiści wszystkich przegladarek zawiązują klub i ustalają globalnie
jedyny słuszny ich wygląd
2) powstaja mechanizmy stylowania i każdy twórca stron decyduje lokalnie jak
w jego projekcie kontrolki mają wyglądać lub zostawia to przeglądarce

Wydaje mi się, że trzeciej metody nie ma. Jeśli założymy istnienie tylko
tych 2 metod, to pkt. 1 jest nierealny z dwóch powodów:
a) trudno zmusić programistów konkurujących firm do współpracy lub choćby
nawet argumentować dlaczego dany wyglad jest lepszy od innego
b) trudno zmusić web-designerów i ich klientów do zaakceptowania narzucenia
im jednygo słusznego wyglądu kontrolek

Jeśli towyższe jest prawdą, czyli panuje powszechna wola nadawania
kontrolkom wyglądu to po co ją ograniczać na siłę szczególnie, że i tak
punkt a) stanie temu i tak na przeszkodzie?

> Wraz ze wzrostem możliwości technicznych przyszła moda na stylowanie
> systemowych elementów graficznych, ale to jest robione "z głową", nie
> jakimś prymitywnym zastąpieniem przycisku obrazkiem.

Hmm... szczerze mówiąc nie widzę potrzeby komplikowania zagadnienia. Przez
tyle lat kontrolki typu radio i checkbox miały tylko dwa stany i nadal tak
może być. Ich działanie jest powszechnie rozumiane. Pewnie więc nie miałeś
na myśli główkowania nad rozwojem ich funkcjonalności. Pozostaje więc
główkowanie nad ich wyglądem - i pewnie to miałeś na myśli. Jeśli tak, to
moim zdaniem najbardziej swobodnym sposobem kształtowania wyglądu tych dwóch
typów kontrolek jest pozwolenie na zastępowanie ich obu stanów grafiką (ew.
stanów typu hover - wtedy powstają 4 kombinacje). Co w tym złego lub
niezrozumiałego? Czy hipotetycznie choćby istnieje lepszy sposób na pełną
graficzną elastyczność interfesów?

do góry

Marek pisze:
> Z tym raczej nie zgodziłbym się, że to krok wstecz. Istnieją 2 metody
> ujednolicenia wyglądu kontrolek:
> 1) programiści wszystkich przegladarek zawiązują klub i ustalają
> globalnie jedyny słuszny ich wygląd
> 2) powstaja mechanizmy stylowania i każdy twórca stron decyduje lokalnie
> jak w jego projekcie kontrolki mają wyglądać lub zostawia to przeglądarce

Żaden z powyższych sposobów nie daje jednolitych kontrolek z punktu
widzenia końcowego użytkownika. A ten obecnie ma jednolite, bo w
programach i na stronach wyglądają tak samo, więc jak się nauczy w
jednym miejscu z nich korzystać to już jest masta i żaden formularz mu
nie straszny.

> b) trudno zmusić web-designerów i ich klientów do zaakceptowania
> narzucenia im jednygo słusznego wyglądu kontrolek

Bo to takie straszne mieć radiobutona wyglądającego jak radiobuton.
Normalnie na szczycie ONZ/G8/WC powinni tę sprawę czym prędzej
rozwiązać, bo się nam zaraz szefowie i graficy pochlastają z rozpaczy ;)


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

do góry

Marek pisze:
> Z tym raczej nie zgodziłbym się, że to krok wstecz. Istnieją 2 metody
> ujednolicenia wyglądu kontrolek:
> 1) programiści wszystkich przegladarek zawiązują klub i ustalają
> globalnie jedyny słuszny ich wygląd

Nie programiści przeglądarek, tylko programiści systemu operacyjnego.
Każdy system ma mniej lub bardziej formalne wytyczne dotyczące
projektowania interfejsów, które takie rzeczy porządkują. Dlatego ten
sam ładny program pod Linuxem jest brzydki pod Windowsem, ładny pod
Windowsem jest ochydny pod OSX, a programy w Javie są często paskudne na
wszystkim.

> 2) powstaja mechanizmy stylowania i każdy twórca stron decyduje lokalnie
> jak w jego projekcie kontrolki mają wyglądać lub zostawia to przeglądarce

Powstają mechanizmy, ale często wcale nie są mile widziane przez
użytkowników. Jak pisałem, nowoczesne mechanizmy są skomplikowane, żeby
stylowanie nie psuło standardowego zachowania przycisku, a i tak należy
je wykorzystywać z umiarem. Do czego prowadzi obłędne stylowanie, to
(przynajmniej w mojej opinii) widać na przykładzie WinAMP-a.

> b) trudno zmusić web-designerów i ich klientów do zaakceptowania
> narzucenia im jednygo słusznego wyglądu kontrolek

Nie pokażę ci wyników badań, ale uwierz mi, te wysiłki większość
użytkowników ma kompletnie w tylnej części ciała.

> Hmm... szczerze mówiąc nie widzę potrzeby komplikowania zagadnienia.
> Przez tyle lat kontrolki typu radio i checkbox miały tylko dwa stany i
> nadal tak może być. Ich działanie jest powszechnie rozumiane.

Uwziąłeś się na te checkboxy i zaciemnia ci to obraz. Jak sobie
poczytasz dokumentację standardu HTML, to zobaczysz, że projektanci
pozostawili swobodę w sposobie realizacji, właśnie dlatego, że w różnych
środowiskach są różne niuanse. Chodzi o sposób przedstawienia fokusu,
graficzne oznaczanie naciśnięcia, zachowanie przy mouseover, wygląd
przycisku nieaktywnego, sposób prezentacji listy rozwijanej, kształt
obwódek, kolorystykę itd. Przy twoim podejściu (obrazek) masz sporą
szansę na to, że kontrolka przestaje przypominać i działać jak inne
kontrolki w systemie.

PS: Koledzy ci podpowiedzieli różne możliwości, więc zrobisz jak sobie
zechcesz. Ostylowanych javascriptem checkboxów masz na pęczki, możesz
sobie użyć. Ja cię od tego nie będę odwodził.

artur

do góry

> Nie programiści przeglądarek, tylko programiści systemu operacyjnego.

O ile programiści zdecydują się użyć standardowych bibliotek :-) Nie
chciałem zakładać, że wszystkie przegladarki pod Windows korzystają z
kontrolek Windows bo nie znam wszystkich przeglądarek. Ale i tak rozumiemy
co miałem na myśli :)

> Każdy system ma mniej lub bardziej formalne wytyczne dotyczące
> projektowania interfejsów, które takie rzeczy porządkują. Dlatego ten sam
> ładny program pod Linuxem jest brzydki pod Windowsem, ładny pod Windowsem
> jest ochydny pod OSX, a programy w Javie są często paskudne na wszystkim.

hahaha - podzielam Twoje zdanie. Sun chyba zatrudnia programistów z
niezaleczonym ADHD do tworzenia interfejsów :)

> Powstają mechanizmy, ale często wcale nie są mile widziane przez
> użytkowników.

Nie dogodzisz wszystkim. Owszem, bezpiecznie jest bazować na standardowych
bibliotekach. Ponadto mój klient to nie klient mojego klienta. On dyktuje
warunki. Ja tylko mogę sugerować.Jednakże w przypadku organizacji
artystycznych pojecie standaryzacji nie istnieje.

> Jak pisałem, nowoczesne mechanizmy są skomplikowane, żeby stylowanie nie
> psuło standardowego zachowania przycisku, a i tak należy je wykorzystywać
> z umiarem.

Nie mówimy o zmianie zachowania lecz wyglądu.

> Do czego prowadzi obłędne stylowanie, to (przynajmniej w mojej opinii)
> widać na przykładzie WinAMP-a.

Istnieją przykłady w drugą stronę. W3C na swojej stronie wprowadziło nowy
layout. No i fajnie! Znajdą się tacy, którzy stwierdzą, że to ohyda.
Jednakże nic z tego nie wynika.

> Nie pokażę ci wyników badań, ale uwierz mi, te wysiłki większość
> użytkowników ma kompletnie w tylnej części ciała.

Chodzi o oglądaczy stron czy zleceniodawców stron WWW? Jeśli o tych
pierwszych to wierzę. Jednakże w drugim przypadku bywa bardzo
różnie.Statystyk nie robiłem lecz jedynie własne życiowe obserwacje
przytaczam.

> Uwziąłeś się na te checkboxy i zaciemnia ci to obraz.

Bo o nic innego mi nie chodzi. Mój inicjalny post wyraźnie mówi o tych dwóch
typach.

>Jak sobie poczytasz dokumentację standardu HTML, to zobaczysz, że
>projektanci pozostawili swobodę w sposobie realizacji, właśnie dlatego, że
>w różnych środowiskach są różne niuanse. Chodzi o sposób przedstawienia
>fokusu, graficzne oznaczanie naciśnięcia, zachowanie przy mouseover, wygląd
>przycisku nieaktywnego, sposób prezentacji listy rozwijanej, kształt
>obwódek, kolorystykę itd. Przy twoim podejściu (obrazek) masz sporą szansę
>na to, że kontrolka przestaje przypominać i działać jak inne kontrolki w
>systemie.

Wcale nie! To problem twórcy layoutu. Jeśli layout będzie spójny w całym
projekcie, to ok. To reguluje i powinien regulować CSS. Któryś z kolegów
przejaskrawił sytuację i podał przykład zastąpienia kontroli rysunkiem
słonia, który podnosi trąbę w aktywnym stanie kontrolki. Może to przegięcie
ale gdy się zastanowić nad tym, to czy w specyficznym zastosowaniu nie
stanowiłoby to jakiegoś fikuśnego urozmaicenia? Jeśli ktoś ma taką fantazję
to czemu na siłę mu tego zabraniać? Nie zawsze przecież chcemy trzymać
oficjalną formę formularzy. Zauważ, że teraz nawet Adobe forsuje ideę
stosowania pól tekstowych wielkości połowy monitora z tłem nie-białym, a
łamie dotychczasowe kanony. Zmiana wyglądu pól tekstowych dała się ostylować
i nie wywołała fali zamieszek na całym świecie. :-) Czemu nie pójść za
coisem więc?

> PS: Koledzy ci podpowiedzieli różne możliwości, więc zrobisz jak sobie
> zechcesz. Ostylowanych javascriptem checkboxów masz na pęczki, możesz
> sobie użyć. Ja cię od tego nie będę odwodził.

Do P.S.
Nie jestem zwolennikiem stosowania JS. Gdy już inaczej nie można to tak
robię. Angażowanie JS do rysowania kontrolek to już w/g mnie przerost kodu
nad treścią :-)

do góry

> Żaden z powyższych sposobów nie daje jednolitych kontrolek z punktu
> widzenia końcowego użytkownika. A ten obecnie ma jednolite, bo w
> programach i na stronach wyglądają tak samo, więc jak się nauczy w
> jednym miejscu z nich korzystać to już jest masta i żaden formularz mu
> nie straszny.

Argumentację rozumiem i akceptuję lecz jest to ograniczone postrzeganie do 1
punktu widzenia, moim zdaniem. Klienci zlecający realizacje projektów mają
różne wizje w końcu. Po drugie, zauważ, że kiedyś nie było CSS i każdy
nagłówek <h1> stron wyglądał tak samo. Mogłoby się wydawać, ze panował wtedy
super-standard, super-porządek, super-ergonomia. Potem pozwolono na jego
modyfikacje, kolorowanie, wybór czcionki itp. A dlaczego tak, skoro
standaryzacja wyglądu sprzyjała ergonomii? Przyznasz rację, że obecnie nie
słyszy się opinii krytycznych odnośnie wprowadzenia możliwości manipulowania
wyglądem poszczególnych elementów. Czemu więc dzielić elementy HTML na
lepsze i gorsze: poddające się modyfikacji wyglądu nie pozwalające na to?

> Bo to takie straszne mieć radiobutona wyglądającego jak radiobuton.

Podobnie jak kiedyś <h1> wyglądał jak porządne <h1> a nie jak wyfisiowane
niewiadomo co obecnie :-)

(tarktuj to jako żart i prowokację a nie dogryzanie)

do góry