[CSS] Zmiana obramowania po wskazaniu myszką

MoLo · Post autor: **MoLo** » wt lut 21, 2006 6:44 pm

W jaki sposób zrobić coś takiego, żeby np. obramowanie tabelki, po najechaniu na nia myszka zmienilo kolor i grubosc ?

MoLo · Post autor: **MoLo** » wt lut 21, 2006 7:36 pm

Umiesz liczyć? LIcz na siebie !

<HEAD>
   BODY{
   p.klasa{ 
	   border-style: solid; 
	   border-color: #a9a9a9; 
	   border-width: 2px 
	}
	p.klasa1{
	   border-style: solid; 
	   border-color: #a9a9a9; 
	   border-width: 0px
   }
   }
</HEAD>
<BODY>
    <P onmouseover="this.className='klasa'" onmouseout="this.className='klasa1'"><IMG ....>
</P>
</BODY>

Stig · Post autor: **Stig** » wt lut 21, 2006 8:22 pm

Przedstawione przez MoLo rozwiązanie, ze względu głównie na nieodpowiednie rozdzielenie wartstw, nie jest niestety do końca poprawne. Ten problem można rozwiązać szybciej, prościej, lepiej za pomocą pseudoklasy :hover. Arkusz stylów powinien wyglądać następująco:

Kod: Zaznacz cały

table {
border: 1px #FF0000 solid;
}
table:hover {
border: 3px #00FF00 dotted;
}

Ze względu na wrodzoną ułomność badzIEwia, która przejawia się m. in. obsługą pseudoklas tylko dla elementu a, dla produktu Micro$oft należy wykorzystać pewną sztuczkę.

MoLo · Post autor: **MoLo** » wt lut 21, 2006 9:05 pm

Może się nie znam, ale na nic nie zda się zmiana stylów dla stołu (tabel). Porponuje zamiast tego wpisać table.

Stig · Post autor: **Stig** » wt lut 21, 2006 9:16 pm

MoLo pisze:Może się nie znam, ale na nic nie zda się zmiana stylów dla stołu (tabel). Porponuje zamiast tego wpisać table.

Po pierwsze: wcale nie stwierdziłem, iż jakoby się nie znasz. Po drugie: dziękuję za zwrócenie uwagi na literówkę.

viraptor · Post autor: **viraptor** » wt lut 21, 2006 9:39 pm

Stig pisze:Ze względu na wrodzoną ułomność badzIEwia, [blablabla...]

Wiem, że lubimy kląć na badzIEwie, ale niektóre rzeczy lepiej sprawdzić przed krytyką - cytat stąd:

na temat :hover, :active, ... w3c pisze:CSS doesn't define which elements may be in the above states, or how the states are entered and left. Scripting may change whether elements react to user events or not, and different devices and UAs may have different ways of pointing to, or activating elements.

IE zachowuje się tutaj zgodnie z CSS2. Może tego nie robić nawet dla linków i dalej będzie prawdopodobnie zgodnie (chyba, że gdzieś przy samych linkach odwołują się do :hover). Szczególnie, że w tym rozdziale mowa o "interactive media" (tak, wiem, że w troche innym kontekście), a tabele do części interaktywnej ciężko zaliczyć.

Stig · Post autor: **Stig** » wt lut 21, 2006 10:03 pm

Fakt faktem, specyfikacja nie określa dla jakich elementów ta pseudoklasa powinna być dostępna, jednakże, patrząc na to, że inne, nowoczesne przeglądarki interpretują tę pseudoklasę dla każdego elementu, nie widzę racjonalnego wytłumaczenia dlaczego tak samo sprawa nie mogłaby wyglądać w przypadku IE. Choć nie może być to interpretowane jako niezgodność ze specyfikacją, to, chyba się ze mną zgodzisz, brak obsługi tej pseudklasy dla innych elementów niż hiperłącza ogranicza w znacznym stopniu twórczość autorów stron i zmusza ich do wykorzystywania gorszych, niezgodnych ze standardami rozwiązań. Sam fakt, że można nie martwić się niczym stosując dowolnie pseudoklase :hover w przypadku nowoczesnych przeglądarek, które to w innych aspektach wyprzedzają znacząco zgodność ze specyfikacjami W3C w porównaniu z IE, a to, że w przypadku IE należy szukać innych rozwiązań, może w pewnym stopniu oznaczać ułomość tej przeglądarki. Natomiast w pełni można ją dostrzec patrząc na poziom implementacji innych składników CSS (jak chociażby box-model).

viraptor · Post autor: **viraptor** » wt lut 21, 2006 11:03 pm

1. To dalej jest naciągane. IE nie musi tego robić, więc nikt nie ma jakichkolwiek podstaw do krytykowania ich za nierobienie tego. Można to ew. zgłosić jako prośba o ulepszenie. Nie jako błąd. To nie jest absolutnie ułomność tej przeglądarki, ani też jedna z większych jej niedogodności.
2. Można to obejść zgodnie ze standardami (js i onMouse* są zgodne z DOM i innymi)

Ułomność to gilotyna w IE, brak display:inline-block; w mozilli, i stado błędów związanych z DOM i javascriptem w operze.

Niezrobienie czegoś, jeśli można tego nie zrobić nie jest żadnym błędem. Ostatnio tutaj latają bardzo dziwne poglądy (tabelek nie można pod żadnym pozorem do layów stosować, ramki zawsze są be i inne... nomen omen - zwykle od tych samych osób). Wyluzujcie. Niektórych rzeczy nie da się zrobić inaczej. A radykalizm zw. z tym, że tak można w mojej przeglądarce zakrawa na podejście ms.

I nie zrozumcie mnie źle, bo niektóre fragmenty z rekomendacji w3c znam prawie na pamięć, pisze generalnie w xhtml+css, ale nie narzekam (zwykle) na takie małe sprawy. Jak nie jest coś zgodne z w3c, to owszem - bug raport zawsze idzie. Ale nie przesadzajmy.
Jak ktoś jest tak bardzo zakochany w standardach w3 i beztabelkowcach, to mogę mu podać troche przykładów, gdzie takie podejście nie jest możliwe, albo po prostu się nie sprawdza. Pamiętajcie, że czasem nawet standardy trzeba "obchodzić" sztucznie.
Tak samo :hover. Nie ma go dla innych elementów? To napisz to inaczej. Zawsze można mz i innym podawać :hover, a dla IE podhaczyć w onMouseOver odpowiednią funkcję.

Stig · Post autor: **Stig** » wt lut 21, 2006 11:27 pm

viraptor pisze:1. To dalej jest naciągane. IE nie musi tego robić, więc nikt nie ma jakichkolwiek podstaw do krytykowania ich za nierobienie tego. Można to ew. zgłosić jako prośba o ulepszenie. Nie jako błąd. To nie jest absolutnie ułomność tej przeglądarki, ani też jedna z większych jej niedogodności.

Faktycznie, nie musi, ale może. I dalej nie widzę rozsądnego uzasadnienia dlaczego tego nie robi.

viraptor pisze:2. Można to obejść zgodnie ze standardami (js i onMouse* są zgodne z DOM i innymi)

Mój osobisty stosunek do atrybutów zdarzeń, wykorzystywanych przynajmniej w ten sposób, jest negatywny, ale nie zaprzeczam, że takie rozwiązanie jest zgodne ze standardami. Tylko czemu nie skorzystać z rozwiązania lepszego?

viraptor pisze:Niezrobienie czegoś, jeśli można tego nie zrobić nie jest żadnym błędem. Ostatnio tutaj latają bardzo dziwne poglądy (tabelek nie można pod żadnym pozorem do layów stosować, ramki zawsze są be i inne... nomen omen - zwykle od tych samych osób). Wyluzujcie. Niektórych rzeczy nie da się zrobić inaczej. A radykalizm zw. z tym, że tak można w mojej przeglądarce zakrawa na podejście ms.

Tabele w poprawny sposób można stosować tylko do przekazywania danych tabelarycznych - inne zastosowanie łamie zasady semantyki (także dostępności). Ramki prawie zawsze są "be". Jeżeli niektórych rzeczy nie da się zrobić inaczej (czytaj: poprawnie, w miarę dostępnej technologi) to niestety trzeba z nich zrezygnować.

viraptor pisze:Pamiętajcie, że czasem nawet standardy trzeba "obchodzić" sztucznie.

IMHO standardy powstały i są rozwijane także dlatego, aby nie trzeba było ich "obchodzić".

viraptor pisze:Tak samo :hover. Nie ma go dla innych elementów? To napisz to inaczej. Zawsze można mz i innym podawać :hover, a dla IE podhaczyć w onMouseOver odpowiednią funkcję.

Zastosowanie onMouseOver wymaga ingerencji w strukturę, a co za tym idzie serwowania różnych markup'ów różnym przeglądarkach (wysyłanie onMouseOver nowoczesnym przeglądarkom IMHO nie wchodzi w grę, bo po co mam przekazywać coś, co jest w tym przypadku zbędne). Dlatego też, przedstawione przeze mnie wcześniej rozwiązanie whatever:hover, wydaje mi się lepsze...

viraptor · Post autor: **viraptor** » śr lut 22, 2006 12:03 am

Stig pisze:Faktycznie, nie musi, ale może. I dalej nie widzę rozsądnego uzasadnienia dlaczego tego nie robi.

Dlatego, dlaczego mozilla nie stosuje -moz-bgsound, choć w IE bgsound jest. Przecież standard pozwala.

Stig pisze:Mój osobisty stosunek do atrybutów zdarzeń onmouse jest negatywny, ale nie zaprzeczam, że generalnie rzecz ujmując takie rozwiązanie jest zgodne ze standardami. Tylko czemu nie skorzystać z rozwiązania lepszego?

Lepszego pod względem...? Ja widzę tylko różnicę ilości użytych znaków. Chociaż nie jestem pewien - nie liczyłem.

Stig pisze:Tabele w poprawny sposób można stosować tylko do przekazywania danych tabelarycznych - inne zastosowanie łamie zasady semantyki (także dostępności).

W takim razie co bardziej cię razi:
- użycie tabeli do formatowania,
- użycie sztucznego niewidzialnego elementu z clear: both; czy
- użycie javascriptowego onLoad()
żeby uzyskać wysokość div'a zawierającego float'a, przynajmniej taką jak wysokość zawartości + 2 marginesy? Bo standardy nas tu nie zawodzą, ale standardy+dostępność+semantyka już tak.

Stig pisze:IMHO standardy powstały i są rozwijane także dlatego, aby nie trzeba było ich "obchodzić".

W xhtml akurat pod tym względem nie zrobili wielu testów. Idea dobra, ale wykonanie nie bardzo. (patrz -> kolejność renderowania, floaty, pojawiający się wszędzie zwrot "rozmiar bloku zawierającego" i moment jego przeliczania)

Stig pisze:Zastosowanie onMouseOver wymaga ingerencji w strukturę, a co za tym idzie serwowania różnych markup'ów różnym przeglądarkach (wysyłanie onMouseOver nowoczesnym przeglądarkom IMHO nie wchodzi w grę, bo po co mam przekazywać coś, co jest w tym przypadku zbędne). Dlatego też, przedstawione przeze mnie wcześniej rozwiązanie whatever:hover, wydaje mi się lepsze...

Można to załatwić przez:
1. kontrole przez <---[!IE] , czy jak to się tam pisało
2. w onLoad() sprawdzenie przeglądarki, a potem w razie IE podpięcie handlera.

PS. dawno tu dobrego rantu nie widziałem

Stig · Post autor: **Stig** » śr lut 22, 2006 5:03 pm

viraptor pisze:Dlatego, dlaczego mozilla nie stosuje -moz-bgsound, choć w IE bgsound jest. Przecież standard pozwala.

Nie wiem jak to jest w sprawie Mozilli, ale mogę powiedzieć Ci jak w moim odczuciu wygląda to w przypadku IE. Podchodząc do tego z racjonalnego punktu widzenia, gdybym był ważnym notablem w Micro$ofcie i zajmował się rozwojem IE, to patrząc na negatywne opinie nt. braku implementacji psedoklas dla wszystkich elementów, co zaś realizuje konkurencja, powszechnie uważana za lepszą, to chcąc ją dogonić wydałbym polecenie realizacji tego zadania. Nie znam się na technikach implementacji CSS'a w przeglądarkach, ale wydaje mi się, że skoro możliwe jest użycie tych pseudoklas dla hiperłącza, i skoro inni twórcy przeglądarek wprowadzili taką możliwość (chyba) bez większych problemów dla wszystkich elementów, to IMHO jest to możliwe do osiągnięcia niedużym kosztem. W takim wypadku należy się zapytać dlaczego IE tego nie robi? Ale co my mamy od nich wymagać, skoro oni nawet nie poprawiają krytycznych luk bezpieczeństwa w swoim oprogramowaniu.

Ironicznie i dosadnie można tę sytuację skomentować prawdopodobnymi słowami jakiejś szychy w Micro$ofcie: "Co? Webmastarzy chcą pseudklas obsługiwanych dla wszytkich elementów? Nasza konkurencja już dawno to ma? Nigdy! Nie pójdziemy na to! Niech się cieszą, że wprowadziliśmy obsługę dla hiperłączy! To z NASZEGO produktu korzysta 80% internautów. To MY rozdajemy karty - nie oni!". Mam wrażenie, że Micro$oft zachowuje się w tym przypadku jak taki pięciolatek, który faktycznie posłucha mamy (internautów, W3C) i posprząta zabawki (choć nie wszystkie), ale już sam z własnej woli nie zrobi nic, aby dodatkowo pomóc mamie.

Jeśli chodzi o przykład z Mozillą, który przytoczyłeś, to nie znam sprawy - muszę się trochę rozejrzeć. Póki co mogę wysnuwać wnioski, że może Mozilla stara się uchronić internautów przed muzyką odgrywaną na stronach WWW...

viraptor pisze:Lepszego pod względem...? Ja widzę tylko różnicę ilości użytych znaków. Chociaż nie jestem pewien - nie liczyłem.

Chociażby pod względem semantyki i rozdzielenia warstw. Bez wątpienia atrybuty zdarzeń odnoszą się do warstwy zachowania. Nie znam się za bardzo na językach skryptowych wykonywanych po stronie klienta, ale jestem przekanany, że dostęp do możliwości oferowanych przez te atrybuty powinien odbywać się, w miarę możliwości, w osobnej płaszczyźnie. Jeżeli nie jest to możliwe, to IMHO taka sposobność powinna być jak najszybciej wprowadzona.

viraptor pisze:W takim razie co bardziej cię razi:
- użycie tabeli do formatowania,
- użycie sztucznego niewidzialnego elementu z clear: both; czy
- użycie javascriptowego onLoad()
żeby uzyskać wysokość div'a zawierającego float'a, przynajmniej taką jak wysokość zawartości + 2 marginesy? Bo standardy nas tu nie zawodzą, ale standardy+dostępność+semantyka już tak.

Użycie w tym wypadku tabel i jakichkolwiek rozwiązań JavaScriptu, z jasnych przyczyn jest najgorsze. Clear:both jest tu rozwiązaneim najlepszym (jedynym?) i nie ma obowiązku stosowania go dla niewidzialnego, sztucznego elementu. Można próbować zawrzeć ten atrybut w logicznie użytym znaczniku lub, gdy to jest niemożliwe, w sprytny sposób umieścić go w elemenecie hr, rozdzielającego logiczne fragmenty dokumentu strony internetowej - i taki sposób rozwiązania jest IMHO najlepszy.

viraptor pisze:W xhtml akurat pod tym względem nie zrobili wielu testów. Idea dobra, ale wykonanie nie bardzo. (patrz -> kolejność renderowania, floaty, pojawiający się wszędzie zwrot "rozmiar bloku zawierającego" i moment jego przeliczania)

Także nie jest do końca zadowolony z poziomu aktualnych specyfikacji W3C tyczących się XHTML'a i CSS'a. Na pewno jest wiele istotnych funkcji do dodania/usunięcia/poprawienia. Jednakże wychodzę z założenia, że "jak się nie ma co się lubi, to się lubi co się ma" i w pełnym stopniu staram się trzymać obecnych specyfikacji, jednocześnie z wielkim zniecierpliwieniem oczekując XHTML 2.0 i CSS 3, w których pokładam duże nadzieje.

viraptor pisze:1. kontrole przez <---[!IE] , czy jak to się tam pisało
2. w onLoad() sprawdzenie przeglądarki, a potem w razie IE podpięcie handlera.

Co do komentarzy warunkowych to nie jestem pewien, czy IE zinterpretuje je w ramach jakiegoś elementu. Czy mimo wszystko nie uważasz rozwiązania whatever:hover w tym przypadku za najlepsze?

viraptor · Post autor: **viraptor** » śr lut 22, 2006 7:12 pm

Stig pisze:...skoro inni twórcy przeglądarek wprowadzili taką możliwość (chyba) bez większych problemów dla wszystkich elementów, to IMHO jest to możliwe do osiągnięcia niedużym kosztem.

Prawdopodobnie ze względu na to, że nie muszą się martwić co zrobić w przypadku najechania myszą na a:hover, który znajduje się w table:hover. Ale to takie spekulacje

Stig pisze:Ironicznie i dosadnie można tę sytuację skomentować prawdopodobnymi słowami... [cut]

W MS pracują inteligentni ludzie. Nie muszą nikomu na złość robić (przynajmniej nie na polu html i nie teraz). Jeśli tego nie wprowadzili to prawdopodobnie miało to związek z ogólnym celem / finansami. Przecież nowa wersja przeglądarek wychodzi z nowym systemem - jaki mają zysk z dodawania funkcjonalności do IE, który ktoś już kupił? IE6 jest w fazie eksploatacji, wejdzie w wymieranie po publikacji IE7 / visty. Do takich programów komercyjnych nie dodaje się już funkcjonalności.

Stig pisze:Jeśli chodzi o przykład z Mozillą, który przytoczyłeś, to nie znam sprawy - muszę się trochę rozejrzeć. Póki co mogę wysnuwać wnioski, że może Mozilla stara się uchronić internautów przed muzyką odgrywaną na stronach WWW...

Po prostu nie muszą, jest do dla nich wygodniejsze ze względu na ważniejsze cele, etc. Inny motyw -> ta sama reakcja - nie muszą, więc nie robią

Stig pisze:Chociażby pod względem semantyki i rozdzielenia warstw. Bez wątpienia atrybuty zdarzeń odnoszą się do warstwy zachowania. Nie znam się za bardzo na językach skryptowych wykonywanych po stronie klienta, ale jestem przekanany, że dostęp do możliwości oferowanych przez te atrybuty powinien odbywać się, w miarę możliwości, w osobnej płaszczyźnie. Jeżeli nie jest to możliwe, to IMHO taka sposobność powinna być jak najszybciej wprowadzona.

Rozdzielenia wartstw w js nie uświadczysz. Można to ew. wydzielić do innego modułu - takie MVC dla ubogich w możliwości (model - html, view - css, controller - server i client-side sktypty). Js jest bardzo zintegrowany z modelem DOM, czyli (x)html, jak i ma przez to dostęp do styli - element.style.*. Nie zostanie to rozdzielone, bo do tego właśnie ma służyć - do zmian w obu warstwach.

Stig pisze:Clear:both jest tu rozwiązaneim najlepszym (jedynym?) i nie ma obowiązku stosowania go dla niewidzialnego, sztucznego elementu.

Ale znacznik nowego bloku, który wstawiamy to czymś tylko po to, żeby zakończył wizualną prezentację bloku poprzedniego zawsze będzie sztuczny. Jeśli nie potrzebujemy wstawić tam żadnej treści, to jest niepotrzebny, więc czemu mamy go tam wstawiać?

Stig pisze:Jednakże wychodzę z założenia, że "jak się nie ma co się lubi, to się lubi co się ma" i w pełnym stopniu staram się trzymać obecnych specyfikacji, jednocześnie z wielkim zniecierpliwieniem oczekując XHTML 2.0 i CSS 3, w których pokładam duże nadzieje.

Także oczekuję... ale z tego co widzę w draftach css3 to jest dokładnie to, co jest tak strasznie obgadywane w html

http://www.w3.org/TR/2005/WD-css3-multicol-20051215/
http://www.w3.org/TR/2005/WD-css3-layout-20051215/
Multicolumn layout i advanced positioning, to przecież dokładnie tabelki z html'a, tylko przeniesione do css'a. I teraz tłumacz komuś w czym jest lepsze <table>...</table> od <div> i css'a. Styl pozycjonowania ten sam, algorytmy te same, semantyka wychodzi na poziomie koncepcji podziału tylko, bo każdemu div i td można nadać tak samo id, a po wycięciu wszystkich tagów treść zostaje ta sama.
Umarły tabelki, niech żyją tabelki!

Stig pisze:Co do komentarzy warunkowych to nie jestem pewien, czy IE zinterpretuje je w ramach jakiegoś elementu. Czy mimo wszystko nie uważasz rozwiązania whatever:hover w tym przypadku za najlepsze?

Warunki mogą być w dowolnym miejscu poza wnętrzem tagów, więc przejdą. Rozwiązanie whatever:hover jest tak samo dobre / troche gorsze jak onMouseOver. whatever:hover też miesza w stylach, ale robi to:
1. w sposób nieudokumentowany (nieusuwanie :hover ustawionego przez js, ale ignorowanie go w css, to błąd, który przypadkiem działa na twoją korzyść)
2. nieprzenośny (jesteś pewny, że to nie zepsuje zachowania przelądarki X, która z czym innym będzie miała problem?)
3. nie wiesz w jaki sposób IE zmieni interpretacje tego w przyszłości - mogą albo usunąć każde :hover poza <a>, albo dodać go do css'a - tak, czy tak będą mieli jakąś rację
Jeśli zrobisz to przez onMouseOver, będzie to sposób przenośny na wszystkie przeglądarki, które obsługują JS i nie dostaniesz żadnych niespodzianek np. po wejściu IE7.

Stig · Post autor: **Stig** » śr lut 22, 2006 8:44 pm

viraptor pisze:W MS pracują inteligentni ludzie. Nie muszą nikomu na złość robić (przynajmniej nie na polu html i nie teraz). Jeśli tego nie wprowadzili to prawdopodobnie miało to związek z ogólnym celem / finansami. Przecież nowa wersja przeglądarek wychodzi z nowym systemem - jaki mają zysk z dodawania funkcjonalności do IE, który ktoś już kupił? IE6 jest w fazie eksploatacji, wejdzie w wymieranie po publikacji IE7 / visty. Do takich programów komercyjnych nie dodaje się już funkcjonalności.

Tu wkraczamy w kwestię podejścia Micro$oftu do rozwoju swojej przeglądarki. Powiem tyle, że IMHO MS popełnia strategiczny błąd publikując nowe wersje swojej przeglądarki wraz z nowym systemem - o takim sposobie działania traktuje jeden z głównych postulatów przeciw korzystaniu z IE.

viraptor pisze:Rozdzielenia wartstw w js nie uświadczysz. Można to ew. wydzielić do innego modułu - takie MVC dla ubogich w możliwości (model - html, view - css, controller - server i client-side sktypty). Js jest bardzo zintegrowany z modelem DOM, czyli (x)html, jak i ma przez to dostęp do styli - element.style.*. Nie zostanie to rozdzielone, bo do tego właśnie ma służyć - do zmian w obu warstwach.

OK, ale wracając do samych atrybutów zdarzeń, jako nieświadomy w tej kwestii mam następujące pytanie: skoro można "dobrać się" z zewnętrznej warstwy zachowania do dowolnego elementu struktury przy pomocy DOM, to czy nie można w ten sposób zastąpić owych atrybutów?

viraptor pisze:Ale znacznik nowego bloku, który wstawiamy to czymś tylko po to, żeby zakończył wizualną prezentację bloku poprzedniego zawsze będzie sztuczny. Jeśli nie potrzebujemy wstawić tam żadnej treści, to jest niepotrzebny, więc czemu mamy go tam wstawiać?

Jeżeli mamy umieścić pusty element, który z założenia ma przekazywać jakąś treść, aby czyścił wizualną prezentację bloku poprzedniego to oczywiście jest to działanie błędne. Ale właśnie dlatego przytoczyłem informacje nt. możliwości wykorzystania do tego celu elementu hr, którego takie działanie, połączone z odzielaniem logicznych fragmentów strony, jest jak najbardziej poprawne.

viraptor pisze:Multicolumn layout i advanced positioning, to przecież dokładnie tabelki z html'a, tylko przeniesione do css'a. I teraz tłumacz komuś w czym jest lepsze <table>...</table> od <div> i css'a. Styl pozycjonowania ten sam, algorytmy te same, semantyka wychodzi na poziomie koncepcji podziału tylko, bo każdemu div i td można nadać tak samo id, a po wycięciu wszystkich tagów treść zostaje ta sama.
Umarły tabelki, niech żyją tabelki!

Chyba mimo wszystko takie rozwiązanie będzie lepsze niż tabelki. Ale szczegółowo wypowiem się jak CSS 3 wejdzie w życie i będę miał okazję w pełni spróbować tego sposobu.

viraptor pisze:Warunki mogą być w dowolnym miejscu poza wnętrzem tagów, więc przejdą.

Tak, ale z tego co mówisz, i z tego co ja wiem wynika, że następujące rozwiązanie działać nie będzie:

Kod: Zaznacz cały

<p <!--[if IE]>onmouseover="this.className='klasa'" onmouseout="this.className='klasa1'"<![endif]-->>akapit</p>

A więc w jaki sposób, wykorzystując to rozwiązanie sprawić, żeby atrybuty onmouseover i onmouseout były interpretowane tylko przez IE?

viraptor pisze:1. w sposób nieudokumentowany (nieusuwanie :hover ustawionego przez js, ale ignorowanie go w css, to błąd, który przypadkiem działa na twoją korzyść)

Nauczyłem się, że błędy i ograniczenia IE w większości przypadków można poprawić tylko świadomie robiąc błąd.

viraptor pisze:2. nieprzenośny (jesteś pewny, że to nie zepsuje zachowania przelądarki X, która z czym innym będzie miała problem?)

W związku ze stosunkowo dużą popularnością tego rozwiązanie mogę być tego w miarę pewien.

viraptor pisze:3. nie wiesz w jaki sposób IE zmieni interpretacje tego w przyszłości - mogą albo usunąć każde :hover poza <a>, albo dodać go do css'a - tak, czy tak będą mieli jakąś rację

Zmiany w IE są rzeczą rzadką, więc jeśli tylko Micro$oft wprowadziłby jakiekolwiek poprawki napewno przystosowałbym w odpowiedni sposób swój kod.

viraptor pisze:Jeśli zrobisz to przez onMouseOver, będzie to sposób przenośny na wszystkie przeglądarki, które obsługują JS i nie dostaniesz żadnych niespodzianek np. po wejściu IE7.

Staram się nie korzystać z języków skryptowych wykonywanych po stronie klienta wszędzie tam gdzie jest to możliwe (nie ukrywam, że duży wpływ na to ma filozofia osiołków.net).

viraptor · Post autor: **viraptor** » śr lut 22, 2006 10:14 pm

Stig pisze:Powiem tyle, że IMHO MS popełnia strategiczny błąd publikując nowe wersje swojej przeglądarki wraz z nowym systemem - o takim sposobie działania traktuje jeden z głównych postulatów przeciw korzystaniu z IE.

I za mozillą, więc nie robią tak źle

Stig pisze:OK, ale wracając do samych atrybutów zdarzeń, jako nieświadomy w tej kwestii mam następujące pytanie: skoro można "dobrać się" z zewnętrznej warstwy zachowania do dowolnego elementu struktury przy pomocy DOM, to czy nie można w ten sposób zastąpić owych atrybutów?

Zastąpić atrybutów, tzn.?
Jak masz element <a> na stronie, to javascriptem możesz podmienić mu href, czy dowolny inny atrybut. DOM z założenia przekazuje do js całą stronę, jako xml. (ładnie to widać w mozilli w dodatku DOM Inspector - w prawej stronie można włączyć widok znacznika jako "javascript object"). Jeśli chodziło ci o "wymuszenie stanu" :hover, to w mozilli na pewno jest to możliwe (ze względu na język w którym jest napisana

- nie zdziwiłbym się, jakby ":hover" było przez onMouseOver właśnie zaimplementowane), ale jak się ma do tego specyfikacja js, to nie wiem... dobre pytanie - sprawdzę.

Stig pisze:Ale właśnie dlatego przytoczyłem informacje nt. możliwości wykorzystania do tego celu elementu hr, którego takie działanie, połączone z odzielaniem logicznych fragmentów strony, jest jak najbardziej poprawne.

Ano fakt...

Stig pisze:Chyba mimo wszystko takie rozwiązanie będzie lepsze niż tabelki. Ale szczegółowo wypowiem się jak CSS 3 wejdzie w życie i będę miał okazję w pełni spróbować tego sposobu.

Jak narazie myślę, że gorsze (po przeczytaniu specyfikacji). Proponują formatowanie następujące: w display dajesz tablicę znaków, która określa "rozkład" danych elementów, a następnie odpowiednie elementy wybierają position: x;, gdzie x, to litera z nadrzędnego display. Czyli grail wygląda tak:

Kod: Zaznacz cały

body { display: "aaa"
                  "bcd" }

No i jeszcze ujdzie, ale horror zaczyna się, kiedy znak @ oznacza rezerwację miejsca - nic tam nie będzie się znajdowało. Przykład:

Kod: Zaznacz cały

body { display: "a@@"
                "@@@"
                "@@b"
                "@@@"
                "c@@"
                "@@@"
                "@@d" }

Czyli nic tylko OMG,WTF,BBQ?

Stig pisze:Tak, ale z tego co mówisz, i z tego co ja wiem wynika, że następujące rozwiązanie działać nie będzie: [cut]

Myślałem nie o wcinaniu się w środek znacznika, ale o wydzieleniu jednej linijki includującej js z zewnątrz tylko w IE. Praktycznie nie ma wtedy over-head'a dla innych przeglądarek, nie dostają tego skryptu, a IE sam sobie znajdzie dzięki niemu odpowiednie elementy (np. poszuka wszystkich <table> klasy "x" i doda im handlery onMouse*).

Stig pisze:Nauczyłem się, że błędy i ograniczenia IE w większości przypadków można poprawić tylko świadomie robiąc błąd.

To teraz wyższa szkoła jazdy - spróbuj to zrobić tak, żeby błędu nie robić

Stig pisze:W związku ze stosunkowo dużą popularnością tego rozwiązanie mogę być tego w miarę pewien.

Ja w tym kodzie nie widziałem kontroli, czy element wogóle zawiera odpowiednie funkcje i czy operacje się udają. Jeśli jakaś przeglądarka tego nie implementuje, to zatrzyma wszystkie skrypty na tej stronie prawdopodobnie.

Stig pisze:Zmiany w IE są rzeczą rzadką, więc jeśli tylko Micro$oft wprowadziłby jakiekolwiek poprawki napewno przystosowałbym w odpowiedni sposób swój kod.

Jeszcze raz wyższa szkoła jazdy - czemu zakładasz, że później będziesz musiał z nim cokolwiek robić? Jedno zabezpieczenie więcej i nie musisz się nim przejmować. To samo dotyczy też innych sytuacji, innych przeglądarek, ... Ew. błędy zawsze należy sprawdzać w czasie wykonania.

Stig pisze:Staram się nie korzystać z języków skryptowych wykonywanych po stronie klienta wszędzie tam gdzie jest to możliwe (nie ukrywam, że duży wpływ na to ma filozofia osiołków.net).

No fakt... z jednej strony ja też unikam, a z drugiej myślę, że można spokojnie zignorować wszystkich, którzy wyłączyli js - albo wiedzieli co robią i znają konsekwencje, albo nie powinni mieć dostępu do wyłączenia tego typu opcji

Stig · Post autor: **Stig** » śr lut 22, 2006 10:51 pm

viraptor pisze:Zastąpić atrybutów, tzn.?

Mam na myśli takie rozwiązanie, w którym w markup'ie wszystkie atrybuty zdarzeń (on*) nie znajdowywałyby się, lecz wywoływane (nadawane, symulowane) byłyby przez zewnętrzny skrypt. O ile dobrze się rozumiemy to taki sposób przytoczyłeś w późniejszej części swojego posta :]

viraptor pisze:Jak narazie myślę, że gorsze (po przeczytaniu specyfikacji). [cut]

Faktycznie, dość skomplikowana sprawa. Ale przynajmniej markup będzie w miarę czysty

viraptor pisze:Myślałem nie o wcinaniu się w środek znacznika, ale o wydzieleniu jednej linijki includującej js z zewnątrz tylko w IE. Praktycznie nie ma wtedy over-head'a dla innych przeglądarek, nie dostają tego skryptu, a IE sam sobie znajdzie dzięki niemu odpowiednie elementy (np. poszuka wszystkich <table> klasy "x" i doda im handlery onMouse*).

Czyli możliwe jest np. zdalne nadanie poszczególnym elementom atrybutów zdarzeń, tak, aby te nie znajdowały się bezpośrodnio w źródle - innymi słowy - zamiast mnie napisze je skrypt (a w miarę możliwości użytkownik/validator ich nie zobaczy)?

viraptor pisze:To teraz wyższa szkoła jazdy - spróbuj to zrobić tak, żeby błędu nie robić

Czasami to bardzo utrudnione, a wręcz niemożliwe

viraptor pisze:Jeszcze raz wyższa szkoła jazdy - czemu zakładasz, że później będziesz musiał z nim cokolwiek robić? Jedno zabezpieczenie więcej i nie musisz się nim przejmować. To samo dotyczy też innych sytuacji, innych przeglądarek, ... Ew. błędy zawsze należy sprawdzać w czasie wykonania.

Nie zakładam - przypuszczam :]. Gdyby w IE pojawiły się poprawki, przez które skrypt mógłby nie działać, zawsze mógłbym go poprawić. Ale równie dobrze skrypt może działać bez problemu

viraptor pisze:No fakt... z jednej strony ja też unikam, a z drugiej myślę, że można spokojnie zignorować wszystkich, którzy wyłączyli js - albo wiedzieli co robią i znają konsekwencje, albo nie powinni mieć dostępu do wyłączenia tego typu opcji

Ja wychodzę z założenia, aby nie stosować JS tam, gdzie nie jest to konieczne. W praktyce na moich stronach (prawie) zawsze takich skryptów nie ma

[CSS] Zmiana obramowania po wskazaniu myszką

[CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką

Re: [CSS] Zmiana obramowania po wskazaniu myszką