Archiwum kategorii: dev

development: programowanie, webmasterstwo itp.

Riddle napisał ostatnio o tzw. “spoiler space” przy użyciu pseudoklasy :focus. Dla niezorientowanych: “spoiler space” (w polskim slangu grup usenetowych czasem także “spojler”) to fragment tekstu, którego nie chciałbyś przeczytać przed obejrzeniem filmu czy przeczytaniem książki, bo np. zdradza zakończenie albo istotne szczegóły fabuły.

W metodzie Riddle’a “spojlery” wyświetla się, ustawiając fokus na linku, który zawiera treść “spojlera”. Rozwiązanie to ma tę zaletę, że działa w IE, a wady to: niedziałanie w Operze i niemożność zawarcia w treści spojlera innych odnośników. Innym problemem - dla maniaków standardów, rzecz jasna - jest niesemantyczność takiego rozwiązania: używamy do czegoś, co nie jest odnośnikiem.

Istnieje inne rozwiązanie: selektor :target z CSS 3. Ukrywanemu przez nas tekstowi nadajemy jakiś identyfikator (np. “spoiler”), a w CSS tworzymy dwie regułki:

#spoiler { visibility: hidden; }
#spoiler:target { visibility: visible; }

Zamiast ustawiać “visibilty” na “hidden” i “visible”, możemy użyć oczywiście “display”, odpowiednio “none” i “block”. Możemy też, podobnie jak Riddle, zmieniać po prostu kolory tekstu danych elementów.

Zapis “#id_elementu:target” oznacza: “element o id=’id_elementu’ gdy jest on elementem docelowym”, co jest równoważne z tym, że adres URL w przeglądarce kończy się na “#id_elementu”. Tak więc, jeśli użytkownik otworzy naszą stronę “normalnie”, nie zobaczy ukrytego tekstu, a kiedy przejdzie do kotwicy (”#id_elementu”) - element ten zostanie wyświetlony.

Rozwiązujemy w ten sposób problemy semantyczności (nasz “spoiler” nie musi być linkiem) oraz zawartości (nie ma żadnych ograniczeń co do “spoilerowej” zawartości, może to być tekst z linkami, tabelka, formularz, aplet, animacja Flash itd.), ale pojawia się problem nowy: jedynym silnikiem, który obsługuje selektor “:target” jest Gecko, tak więc nasz “spoiler” stworzy problemy użytkownikom Opery, IE i przeglądarek opartych na KHTML. Chyba że ich twórcy w końcu dodadzą obsługę selektorów CSS 3.

Przykłady (niezbyt ładne wizualnie, za to bardzo proste w zrozumieniu):

Brendan Eich na swoim blogu pisze o planach rozwoju JavaScriptu 2.0. Rzeczy, których się można było spodziewać (silne typy, “normalne” klasy), jak i użyteczne niespodzianki (np. operatory is, as, to). Ogólnie idzie to w ciekawym kierunku, ale niektórym może się nie spodobać, że najwyraźniej JavaScript 2.0 nie będzie mozillową kopią JScript.NET (czego niektórzy się spodziewali po lekturze poprzedniej propozycji JS2).

Na mozilla.org jest też (powerpointowa) prezentacja Brendana “Dziesięć lat JavaScriptu”, składająca się z kilkunastu slajdów o historii i jednego o przyszłości tego języka.