HTML

Atrybut Title w Internet Explorer – jak usunąć?

Ostatnio napotkałem na dość dziwny problem w przeglądarce Internet Explorer (a jakże) z atrybutem title. Miałem za zadanie stworzyć własny system wyświetlający podpowiedzi do danego wiersza w zestawie pól formularza. Naturalnym rozwiązaniem dla mnie było użycie atrybutu “title” Algorytm sprowadził się do tego, że na zdarzeniu :hover pobierałem atrybut title przekazywałem do mojego systemu a z tego usuwałem. Wszystko to wykonane było za pomocą jQuery

$('.row').hover(function() {
    var title = $(this).attr('title');
    $(this).removeAttr('title');
});

Wydawałoby się, że to dosyć proste i banalne, jednakże Internet Explorer zupełnie nie rozumie o co chodzi. Usunięcie atrybutu title zwyczajnie nie przynosi rezultatów. Chmurka od przeglądarki nadal się pojawia. Rozwiązanie jakie udało mi się wynaleźć to ustawienie title na wartość pustą

$('.row').hover(function() {
    var title = $(this).attr('title');
    $(this).attr('title', '');
});

I voila! Teraz Internet Explorer jak i inne przeglądarki nie mają problemu. Chmurka przestaje się pojawiać. Co ciekawe… jeśli jednak dodatkowo potem jeszcze usunę ten atrybut w ten sposób:

$('.row').hover(function() {
    var title = $(this).attr('title');
    $(this).attr('title', '');
    $(this).removeAttr('title');
});

to chmurka znowu się pojawia z oryginalnym tekstem. Wygląda na to, że ustawienie samodzielne title jakoby podmienia zawartość kontenera zatem usunięcie tego co sami zrobimy “odsłania” wartość pierwotną. Dziwne?

Optymalny kod HMTL / Hack IE

W dobie nowoczesnych przeglądarek internetowych oraz wchodzącego coraz większymi krokami HTML5 mało sensowne wydaje się zajmowanie problemami które powodują przeglądarki starsze. Jednak warto w związku z tą fazą “przejścia” do Internetu “nowej jakości” zastosować pewne sztuczki które w przyszłości pozwolą gładko przejść w tą erę.

Chciałbym także zaprezentować współczesne rozwiązywanie problemów niekompatybilności starszych przeglądarek oraz problemów jakie sprawiają – tak, żeby strona była nowoczesna, ale jednocześnie działała jeszcze na starszych przeglądarkach.

Nie będę w tej chwili poruszał kwestii HTML5 (ale o tym niedługo 🙂 ) za to chciałbym oprzeć się na obecnych popularnych technologiach i przyjrzeć się technologii odseparowania kodu który uznajemy za poprawny od kodu który musi się znaleźć aby strona działała i wyświetlała się na przeglądarkach które normalnie sobie z tym nie radzą. Postaram się także poddać subiektywnej ocenie każdą z metod. Zaczynamy:

Hacki nadmiarowe

Hacki nadmiarowe – czyli technika, która jest całkowitym zaprzeczeniem poruszanego tematu. Zakłada ona w uproszczeniu, że np w kodzie CSS tworzymy standardowy kod w postaci:

div {
    color:red;
}

Często okazuje się, że jakaś przeglądarka inaczej dziedziczy klasy CSS lub występuje jakiś inny problem (np na jednej przeglądarce linki są czerwone a na innej zielone i nie wiadomo dlaczego. Można wtedy zastosować Hacki dla przeglądarek – czyli tak zapisać kod aby tylko dana przeglądarka potrafiła go zinterpretować. Np dla przeglądarki Internet Explorer wyglądałoby to tak:

div {
    color:red;
}
div\ {
    color:green;
}
}

Tego drugiego “div’a” zinterpretuje tylko IE. Więc we wszystkich przeglądarkach div będzie miał czerwony tekst, a na IE zielony. Jest jeszcze mnóstwo technik które pozwalają uzyskać te różnice na przeglądarkach, ale ja tej metody nie polecam więc nie będę ich wypisywał. Dlaczego nie polecam tej metody?

wady:

  1. Nadmiarowość kodu współdzielona przez wszystkie przeglądarki
  2. W 99% przypadków nie jest to potrzebne ponieważ różnica wynika z błędu programisty lub niewłaściwego zaprojektowania zależności
  3. Hacki to tak naprawdę celowe zapisanie czegoś “źle” żeby wykorzystać błąd przeglądarki – w efekcie 2 minusy dalą plus

zalety:

  1. Można zrealizować bardzo prosto pewne różnice.

Hacki warunkowe

Hacki warunkowe to technika zdecydowanie bardziej odpowiednia. Pozwala ona oddzielić pewne fragmenty kodu tylko dla specyficznej wersji danej przeglądarki – np Internet Explorer w wersji 6. Dzięki temu możemy napisać stronę pod najnowsze przeglądarki i a pewne różnice skorygować za pomocą odrębnych zasad. Kod taki nie jest wtedy mieszany z prawidłowym kodem i nie jest interpretowany przez przeglądarki które działają poprawnie. Warunki zapisuje się w prosty sposób:

Można także precyzyjnie dobrać przeglądarkę:

Można także zaprzeczać wersji przegladarki

Lub jedne z najczęściej spotykanych (dla wszystkich wersji IE mniejszych niż 7)

Efektywny kod w sekcji HEAD mógłby wyglądać tak:

	
	

Zamiast tworzyć udziwnienia i mieszać kod możemy wszystkie różnice i reguły przenieść do kodu specyficznego dla danej wersji przeglądarki. Co nad to daje? W momencie gdy zostanie podjęta decyzja o zaprzestaniu wsparcia dla  danej przeglądarki wystarczy usunąć zapis warunkowy ze swojego kodu i już. Nie trzeba potem odkręcać nic więcej.

wady:

  1. Trzeba stworzyć osobny plik i jest to nadal pewna nadmiarowość, ale już tylko w obrębie przeglądarki która jest “pokrzywdzona” – najczęściej jednak na niej właśnie najmniej nam zależy i się na to godzimy<

zalety:

  1. Kod jest odseparowany. Nie tworzą się nieprawidłowości.
  2. W dowolnym momencie można dany warunek usunąć, zmienić lub dodać nowy bez wpływania na to co już działa poprawnie.
  3. W momencie decyzji i zaprzestaniu wspierania danej przeglądarki dany warunek wystarczy usunąć z kodu.

Emulacja funkcjonalności

Różnice w zasadzie działania to jedno, ale co gdy dana przeglądarka zwyczajnie nie ma danej funkcji, nie potrafi czegoś zrobić lub robi to źle? Najczęstsze problemy z przeglądarką Internet Explorer poniżej 7 to:

  1. Brak wsparcia przezroczystości plików PNG
  2. Zastosowanie elementów hover tylko na znacznikach typu a

Paradoksalnie nawet bardzo stare przeglądarki Internet Explorer mają różne ciekawe funkcje których nie mają współcześnie najnowsze przeglądarki. Te funkcje to m.in:

  1. Filters
  2. Behaviors

Filtry – IE posiada zestaw filtrów różnego typu które wprowadzają zmiany w elementach strony. Jednym z najczęściej używanych filtrów jest “gray”. Dany selektor konwertowany jest do postaci czarnobiałeł. Można w ten sposób na elemencie body stworzyć całą stronę na czarno-biały. Przydatne gdy chcemy włączyć “żałobę”. Co ciekawe żadna współczesna przeglądarka nie posiada takiej funkcji.

Behaviors – W uproszczeniu są to pewne reguły napisane za pomocą skryptu. Dzięki temu można je wykorzystać do zasymulowania pewnych zachowań których standardowo przeglądarka nie potrafi.

Rozwiązanie problemu HOVER

W tym celu można utworzyć plik HTC. Polecam plik ze strony http://www.xs4all.nl/~peterned/htc/csshover3.htc – zestaw bardzo fajnych reguł do hoverowania elementów.

Załączyć do IE można go tak

body {
	behavior:url("../htc/csshover3.htc");
}

Oczywiście korzystamy w tym celu a jakże z Hacku warunkowego, żeby nie śmiecić innym przeglądarkom. (Uwaga na ścieżkę do pliku htc bo można się naciąć – oprócz tego jeśli uruchamiasz stronę pod Apache to plik ten musi być przez niego rozumiany)

Rozwiązanie problemu PNG

To nie prawda, że IE6 nie potrafi obsłużyć przezroczystości dla plików PNG. Potrafi – ale robi to źle 🙂 Można zatem naprostować ją i użyć. Można w sieci znaleźć wiele technik do poradzenia sobie z tym problemem – np również pliki HTC z odpowiednimi funkcjami symulującymi “włączenie przezroczystości”, różne nakładki i skrypty konwertujące. Ogólnie sprowadza się to do wywołania pewnej wariancji mniej lub bardziej skomplikowanej następującej funkcji:

#logo {
	background:transparent url(/gfx/logo.png) no-repeat scroll left top;
	height:10px;
	width:10px;
}
* html #logo {
	/* Alpha transparencies hack for IE */
	background-image:none;
	filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='/gfx/logo.png', sizingMethod='crop');
}

Oczywiście zastosowano tutaj brzydki Hack dla IE (na początku napisane jest * html ” co rozumie tylko IE. Zostawiłem tak celowo żeby porównać z tym co mówiłem na początku. Oczywiście idealna wersja powinna wyglądać tak, że zostanie to przeniesione do osobnego pliku css dla danej wersji IE.

Podsumowanie

Na ten temat można dużo pisać. W sieci jest niesamowita ilość informacji i rozwiązań problemów. Nie jest to miejsce by opisać je wszystkie i nie taki jest cel tego posta. Chciałbym tylko przybliżyć, że istnieją takie metody i rozwiązania i że warto z nich korzystać aby tworzyć fajny, czytelny i wydajny kod – jeśli potrzeba by strona musiała mimo wszystko działać jeszcze na starszych przeglądarkach to wyżej wspomniane techniki pozwolą na osiągnięcie tego stanu rzeczy bez modyfikowania już gotowego wydajnego kodu. Należy jednak pamiętać aby nie korzystać z tego nagminnie i najpierw samemu upewnić się, że wszystko co zostało zrobione jest poprawne (np częsty problem w różnicy wyświetlania to błąd polegający na tym, że stworzony został kontener rodzic o mniejszej szerokości niż jego element potomny – IE wtedy świetnie nadaje się to znajdowania tego typu problemów gdyż rozszerza kontenery o najszerszą długość jaką znajdzie)

Polecam także korzystanie z walidatora kodu W3C w standardzie SGML i Tidy oraz walidatora CSS. Dopiero potem czas na uzupełnianie różnic.

Pozdrawiam.

Sposób na AJAX’a

Podam Wam teraz 3 znane przeze mnie metody obsługi ajaxa i powiem co wg mnie jest dobrym a co złym rozwiązaniem.

Sposób 1

W większości opisów i przykładów używanie ajaxa “kończy się” “osobnym bytem” w postaci pliku *.php znajdującego się gdzieś w katalogu publicznym:

/public
—/images
—/scripts
—/ajax
——/ajax_show_subcategories.php
——/ajax_check_email.php

Jest to najprostsze rozwiązanie ale jednocześnie najmniej efektywne. Po pierwsze każdy ajax to osobny plik który jakby “odcina” się od naszego systemu – czasami jest to pożądane ale w większości przypadków skrypt w ajaxie stanowi pewną funkcjonalność naszego systemu. Każdy z tych plików musi includować ręcznie jakieś pliki związane np z obsługą bazy danych, przetwarzać pliki konfiguracyjne itd itd. Jest to na pewno mało efektywne rozwiązanie ale na początek – zwłaszcza dla osób, które chcą się ajaxa dopiero nauczyć – rozwiązanie całkowicie wystarczające.

Zalety:
– prosty do zrobienia
– łatwy do przyswojenia

Wady
– mało wydajny
– nieefektywny
– nieelegancki
– sztucznie oddziela ajax’y od reszty systemu (tak jakby był w innym języku pisany)
– upublicznia kod (bo musi znajdować się w katalogu public)

Sposób 2

Ciekawszym i bardziej złożonym rozwiązaniem jest użycie tzw “ajax handlera”. Nie ma w tym nic rewolucyjnego. Cała idea polega na stworzeniu małego skryptu o dostępie publicznym który byłby pośrednikiem między odwołaniami do ajaxa a samymi skryptami ajaxowymi. Mówiąc prościej nie odwołujemy się bezpośrednio do skryptów ajaxowych tylko “prosimy” nasz ajax_handler aby dla nas jakis skrypt uruchomił. Przy czym skrypty ajaxowe mamy gdzieś schowane poza katalog publiczny – tak, że tylko ajax handler może je uruchomić. Ponadto do ajax_handlera możemy dodać od razu procedury które potrzebuje nasz program (np obsługa bazy danych) bez potrzeby dodawania ich do każdego skryptu oddzielnie.

/public
—/images
—/scripts
—/ajax_handler.php
/ajax
—/ajax_show_subcategories.php
—/ajax_check_email.php

Przykład: /ajax_handler?odpal_skrypt=ajax_show_subcategories.php

Rozwiązanie jest bardzo fajne ale… nie różni się ono ideowo od sposobu pierwszego. Jest to swego rodzaju “oszukaństwo” – po prostu zautomatyzowanie pewnych czynności i rozwiązanie kilku wyżej wymienionych wad – lecz nadal skrypty te stanowią odrębny byt i wymagają specjalnego traktowania. Podsumujmy.

Zalety
– Całkiem wydajny
– Ukrycie ajaxów z katalogu publicznego
– Dosyć elegancki (mydlenie oczu)

Wady
– Nieefektywny
– Sztucznie oddziela ajaxy od reszty systemu
– Wymaga stworzenia dodatkowego systemu (ajax_handler)
– Wywoływanie skryptów odbywa się w nienaturalny sposób

Sposób 3 – jak to zrobić w GRAD?

W frameworku GRAD proponuje podejść do problemu w zupełnie inny sposób. Metodą tę można zastosować także w innych aplikacjach ale wyjaśnię najpierw o co chodzi.

Odpowiedzmy sobie na pytanie: Czym jest program wywoływany w ajaxie?
Odpowiedź: Zwyczajnym skryptem PHP

Odpowiedzmy sobie na drugie pytanie: Czym jest program wywoływany w request?
Odpowiedź: Zwyczajnym skryptem PHP

Wniosek? Uruchamiajmy ajaxa po prostu jako zwyczajny request.

Jeżeli GRAD dzieli aplikację na kontrolery i akcję to nie ma znaczenia czy uruchomisz akcję wpisując w przeglądarce:

http://localhost/category/show

czy też uruchamiając w ajaxie (np z wykorzystaniem jQuery – albo twojej innej ulubionej metody uruchamiania ajaxów):

$.ajax({
url: “/category/show“,
dataType: “xml”,
success: function(xml) {
}
});

I już! To jaką metodę wybierzesz do uruchamiana ajaxów to juz jest Twoja wola. Różnica w całym podejściu polega na tym, żeby nie rozróżniać ajaxów na osobne pliki a traktować je jako naszą integralną część systemu. W ten sposób możemy wymazać pojecią “skrypty ajaxowe” bo każdy z twoich skryptów może być wywołany metodą ajaxową i każdy normalną metodą request w przeglądarce. Myślę, że na tym polega profesjonalne podejście do programowania dynamicznych, ciekawych i przede wszystkim spójnych stron w prosty i najbardziej naturalny sposób.

Zalety
– kod to kod, po co go rozróżniać?
– wybierasz metodę do skryptu a nie skrypt do metody
– eleganckie
– przejrzyste
– wydajne
– spójne

Wady
– Musisz zmienić sposób myślenia 🙂

To wszystko w tym artykule. Zachęcam gorąco do zabawy z moim frameworkiem – uważam, że naprawdę warto jeśli chcesz szybko i wydajnie skonstruować dynamiczną i wydajną stronę internetową.

Zobacz framework GRAD

Zachęcam gorąco do komentarzy na temat tego artykułu.

Pozdrawiam serdecznie.

Go to Top