Do tej pory byłem przekonany, że Google nie radzi sobie (albo po prostu nie robi tego z wyboru) z elementami Java Script na stronie. Jakież było dziś moje zdziwienie kiedy chciałem znaleźć coś u siebie na blogu za pomocą Google - oto co ujrzałem:

"Ale o co Ci chodzi" - mógłby zapytać ktoś, "przecież masz dokładnie* taki tytuł strony:"

No właśnie nie bardzo - w wynikach Google pojawiło się dodatkowe "null" w tytule. Dodatkowo, z uwagi na sposób, w jaki pociąłem sobie szablon Joggera, tytuł podstrony muszę generować w nieco inny sposób:

Czyli jak widać, strona ma zupełnie inny tytuł nadany w HTML, który następnie w głębi kodu zostaje zmodyfikowany przy pomocy Java Script.

Na początku uznałem, że może być to przyczyna odkrycia linków do strony prowadzących np. z głównej strony Joggera czy innych blogów. Nie może to być jednak wyjaśnienie sytuacji, ponieważ tytuły linków z Joggera wyglądają zgoła inaczej - nie ma w nich głównego sloganu witryny. RSS? Również ma inne tytuły artykułów ...

Zostaje mi tylko jeden wniosek - Google (w jakimś tam stopniu) jest w stanie wywołać skrypty JS i pobrać dane ze zmodyfikowanej strony. Czy ktoś spotkał się może już z tym zjawiskiem i może wskazać jakąś publikację mówiącą o tym w jakim stopniu Google bierze pod uwagę takie - wygenerowane przez JS - treści?

HTML5 w jednym ze swoich udogodnień wprowadza bardzo przyjazne rozwiązanie pozwalające na przechowywanie informacji o dowolnym tagu. W celu szybszego zrozumienia o co chodzi, posłużmy się przykładem kodu HTML formularza wraz z walidacją danych:

<input type="text" id="email" name="email" class="text required requiredEmail" />

Istnieje wiele bibliotek JavaScript, służących do walidacji formularza po stronie przeglądarki, które w ten właśnie sposób odnajdują pola, które powinny być wypełnione (posiadają klasę required) i sprawdzają, jaką zawartość powinny posiadać (requiredEmail). Rozwiązanie to oczywiście działało, ale powstawały zbędne, nic nie znaczące klasy CSS.

Jak już wspomniałem, HTML5 pomoże nam i w takim przypadku. A to dzięki możliwości stosowania własnych atrybutów z rodziny data-*. Zamysł jest prosty - autor strony może osadzić dowolną informację używając nowego atrybutu - dane te nie są nigdzie wyświetlane, są one dostępne dla JavaScript oraz CSS (za pomocą funkcji attr()).

Jako autorzy strony posiadamy praktycznie pełną dowolność w wyborze nazwy atrybutu - specyfikacja narzuca jedynie, by nie zawierał on dużych liter. Poprawny przykład:

<input type="text" id="email" name="email" data-validate="true" data-validate-type="email" />

Zgodnie ze specyfikacją, wartości powinny być teraz dostępne jako część zbioru dataset z użyciem notacji CamelCase (znanej także jako Notacja Wielbłądzia):

document.getElementById('email').dataset.validate;
document.getElementById('email').dataset.validateType;

Niestety, do czasu implementacji tego rozwiązania przez przeglądarki dane te nie są dostępne i musimy dostać się do nich w inny sposób:

document.getElementById('email').getAttribute('data-validate');
document.getElementById('email').getAttribute('data-validate-type');

Na szczęście powyższe "obejście" problemu działa bez problemu na wszystkich liczących się przeglądarkach.

Poza oczywistym przykładem przechowywania danych na potrzeby walidacji nowy atrybut umożliwia np. sortowanie zestawów danych (tabel) po danych nie widocznych, lub wyświetlanych dla użytkownika w sposób trudny do zrozumienia dla skryptów, np:

<li data-date="2010-07-07T07:58:12"><a href="#">Spis wydarzeń w dniu 7 lipca, roku 2010</a></li>

Przy okazji porządków na serwerze znalazłem kolekcję swoich starych skryptów i innych dokumentów publikowanych jeszcze na starym blogu. Ponieważ wiem, że niektóre z nich jeszcze mogą się komuś przydać postanowiłem pomóc Google, które linkuje niemiłosiernie do nie istniejących już adresów i wrzucić skrypty do sieci.

Chciałbym przypomnieć, że skrypty te mogą być nie aktualne, mogą nie odzwierciedlać aktualnie stosowanych metod, nie działać czy też być proste do odtworzenia w totalnie lepszy sposób - jest to do przewidzenia, zważywszy, że większość z nich ma ponad dwa lata.

Poniżej lista z krótkimi opisami:

• Animowane menu - jak stworzyć menu graficzne z innymi wyglądami po najechaniu na element
• Dodaj do ulubionych i uwstaw jako stronę startową - chyba nie trzeba tłumaczyć, skrypt wykrywa przeglądarki, które tego nie obsługują i wyświetla stosowny komunikat
• Własna wyszukiwarka w Firefox - czyli jak zdefiniować wyszukiwarkę dla swojej strony i umożliwić użytkownikowi dodanie jej do swojej przeglądarki
• Stronicowanie - HTML i CSS - HTML i CSS dla ostylowania podziału na strony podobnie jak na Digg.com
• Stronicowanie - PHP - tym razem kawałek PHP odpowiedzialny za podział elementów na strony
• Przeźroczyste opisy - rozwiązanie CSS pozwalające na dodanie przeźroczystej warstwy z tekstem np. nad obrazkiem
• Rozwijane menu - rozwijane menu (dropdown) w CSS i HTML, (prawie) bez JS
• Zakładki - przykład wykonania boksu z kilkoma zakładkami, z zaznaczeniem aktywnej.

Jeszcze raz - to są stare skrypt, które mogą być już nie aktualne - proszę o nie wytykanie błędów ;-)

Smokescreen to nowy startup, który mylnie określany jest jako sposób na konwersję Flash do technologii, które wprowadza HTML5. Tak na prawdę, Smokescreen to plugin Flash napisany w JavaScript, który dodatkowo korzysta z technologii dostępnych w HTML5 np. tag ) jednak w większości korzysta on z dużo starszego rozwiązania - SVG.

Jak można się domyślić, powodem powstania pluginu Flash w wersji JS jest oczywiście brak wsparcia technologii Adobe na wielu platformach np. Apple iPad, które z kolei posiadają przeglądarki umożliwiające znośne wykonywanie kodu JS. Co prawda twórcom chodziło głównie o odtwarzanie reklam Flashowych na takich urządzeniach, co nie jest może najbardziej chwytliwym rozwiązaniem, ale jak widać udało się odpalić trochę bardziej skomplikowane flashe.

Jak dokładnie działa SmokeScreen? Jak już wspomniałem - nie jest to żaden konwerter, ale plugin, który powstał dzięki upublicznieniu specyfikacji. Plugin pozwala na uruchomienie aplikacji Flash wprost z pliku SWF i nie wymaga żadnej wcześniejszej modyfikacji. Niestety, jak to bywa z wersjami rozwojowymi (wersja 0.1.2 została opublikowana 27 maja 2010) bywa, plugin nie jest jeszcze w 100% kompatybilny i nie wszystkie Flashe udaje się w nim uruchomić.

Poniżej znajdziecie wideo-prezentację SmokeScreen na iPadzie:

Osobiście przyznam, że Smokescreen wydaje się ciekawym rozwiązaniem - ale chyba tylko dla posiadaczy produktów Apple i innych, nie posiadających oficjalnej wersji pluginu Flash. Należy pamiętać, że jest to implementacja w języku, który nie słynie z najlepszej wydajności - jednak może dzięki zastosowaniu JIT (WebKit zdaje się posiadać własny mechanizm kompilacji JS do kodu maszynowego) umożliwi on wyświetlanie wspomnianych reklam i mniej wymagających aplikacji Flash na urządzeniach mobilnych.

Aplikacja tworzona jest na zasadach Wolnego Oprogramowania i kod już niebawem powinien pojawić się na GitHub.com. Niecierpliwi mogą pobrać aktualną wersję prosto ze strony SmokeScreen.us