Ostatnia duża aktualizacja jQuery miała miejsce pod koniec ubiegłego roku. Od tamtej pory pojawiło się kilka mniejszych poprawek, jednak nie wprowadzały one znaczących zmian do biblioteki. Kilka dni temu światło dzienne ujrzała pierwsza beta jQuery 1.8. Wprowadzonych zmian jest całkiem sporo, a najciekawsze z nich to między innymi:

• modułowość – jQuery doczekało się podziału na moduły, dzięki czemu możemy skorzystać tylko z tych funkcji, które są nam aktualnie potrzebne. W chwili obecnej mamy do dyspozycji takie moduły jak: ajax, css, dimensions, effects oraz offset.
• prefiksy we właściwościach CSS – prefiksy pozwalają na wykorzystanie nowej/eksperymentalnej funkcjonalności CSS, niekoniecznie wspieranej przez wszystkie przeglądarki. Największą ich bolączką jest fakt, że dla każdej przeglądarki musimy użyć innego prefiksu. Tutaj z pomocą przychodzi jQuery, który od wersji 1.8 sam zajmie się tą niewdzięczną robotą.
• Sizzle – na nowo napisany silnik selektorów CSS. Podobno ma być jeszcze lepiej i jeszcze szybciej.
• Ochrona przez XSS – wprowadzenie zabezpieczenia przed wstrzykiwaniem złośliwego kodu pochodzącego z niezaufanego źródła – użytkownika.

Zmian jest znacznie więcej, a ich opis można znaleźć na oficjalnym blogu jQuery.

Podczas realizacji jednego z ostatnich projektów, używałem selektora :contains jak się okazało selektor ten nie jest wrażliwy na wielkość znaków czyli dla niego kot i KOT to to samo niestety nie o to chodziło mojemu klientowi

W internecie natknąłem się na ciekawe rozwiązanie definiujące własny selektor :Contains dzięki czemu mogłem używać standardowego :contains jak i nowego :Contains. Poniżej znalezione rozwiązanie:

jQuery.expr[':'].Contains = function(a,i,m){
    return jQuery(a).text().toUpperCase().indexOf(m[3].toUpperCase())>=0;
};

src: http://http.cdnlayer.com

Ochrona własnego adresu poczty elektronicznej stała się „oczywistą oczywistością”. Niezliczone spam-boty przeczesują Internet w poszukiwaniu adresów email, które później zalewane są falą niechcianej poczty. Niestety często jesteśmy zmuszeni udostępnić swój adres. Wpisany zwykłym tekstem, a tym bardziej dodany do linku z mailto stanie się bardzo szybko łupem spamerów. O ile na formę upublicznienia adresu w obcych serwisach zwykle nie mamy wpływu, o tyle mamy w przypadku własnych. Jako, że potrzeba jest matką wynalazku, postanowiłem stworzyć własne rozwiązanie. Połączenie CSS i JavaScript przyniosło oczekiwany skutek.

Założenia protectEmails

Tworząc założenia starałem się patrzeć na problem możliwie z wielu stron. Najważniejszymi punktami są:

1. Czytelność dla użytkownika końcowego
2. Ochrona przed podstawowymi mechanizmami spam-botów
3. Łatwość modyfikacji wyglądu
4. Prostota w stosowaniu

Czytelność dla użytkownika końcowego

Przede wszystkim chciałem uniknąć rozwiązań typu info [at] example.com, które poza tym, że już dawno nie chronią przed botami, to dodatkowo są męczące dla użytkowników. Wszystkie odmiany tego rozwiązania charakteryzują się tą samą trudnością w pozyskaniu maila przez odwiedzającego stronę – podmiana fragmentów, łatwość pomyłki. Tworząc swoje rozwiązanie, chciałem, aby adres email był widoczny w zwykłej formie, po prostu jako info@example.com.

Dodatkowo, uważam, że ważne jest też zachowanie standardowej funkcjonalności linku, który otwiera domyślny program pocztowy klienta.

Ochrona przed podstawowymi mechanizmami spam-botów

Rozwiązanie musi być w jakiś sposób unikatowe, tak aby standardowe funkcje spamerów nie były w stanie takiego adresu wyłuskać. Oczywiście, nie da się zabezpieczyć w 100%, zawsze znajdzie się ktoś, kto napisze dedykowane rozwiązanie. Jednak dużą część automatów można wyeliminować.

Poszukując gotowych rozwiązań spotkałem się z dużą ilością pseudo-zabezpieczeń. Nie dość, że utrudniają one życie użytkownikom, to dodatkowo wystawiają adresy na pastwę botów, np.:

<a href="mailto:info@example.com">info [ at ] example.com</a>

<a href="mailto:info@example.com">info [ at ] example [dot] com</a>

Lub po prostu utrudniają życie, np.:

<span class="email">info [ at ] example [dot] com</spam>

W przypadku powyższego istnieją rozwiązania oparte na JavaScript, które na podstawie klasy modyfikują znacznik span, przerabiając go na klikalny adres email. Jest to dość dobre rozwiązanie z jednym mankamentem – adres jest czytelny dla botów.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

W serii Linkdump dawno nie podejmowałem już tematyki silnika blogowego, którego sam używam - WordPressa. Naprawiając ten błąd zapraszam Was na kolejną porcję linków z nim związanych.       Fotografia: m.schuckart @ Fotolia. Linkdump #62: WordPress. Dodatkowe pola w formularzu komentarzy WordPress. Jak w tytule. :) Add a jQuery UI Accordion Widget Area to [...]

W poprzednim artykule pokazałam jak w kohana 2 stworzyć formularz za pomocą modułu formo. Nadmieniłam też, że w pewnych sytuacjach przydałoby się wykorzystać javascript, a ściślej mówiąc framework jQuery, żeby część formularza odpowiedzialna za ustalanie daty była bardziej funkcjonalna. Poza tym doszłam do wniosku, ze wykorzystanie jQuery może znacznie poprawić usability. Nie jestem miłośnikiem JavaScript, [...]

Kontynuując naprawianie mojego lenistwa związanego z publikacją wpisów na blogu oddaję w Wasze ręce kolejny Linkdump, tym razem poświęcony najpopularniejszej bibliotece / frameworkowi JavaScriptu - jQuery. Mam nadzieję, że zebrane tu informacje po raz kolejny będą dla Was przydatne i znajdą zastosowanie zarówno w projektach komercyjnych, jak też we własnym domowym "dziubaniu" kodu. Zapraszam do [...]

Dawno, dawno temu opublikowałem Linkdump #19 prezentujący zbiór materiałów dotyczących biblioteki MooTools. Kontynuując tą "krucjatę przeciwko jQuery", zapraszam Was dzisiaj do lektury kolejnej serii linków związanych z tym narzędziem.     Fotografia: jeffisageek, CC-BY. Linkdump #57: MooTools. NPM + MooTools + Ender = <3. Czyli kilka słów o zarządzaniu pakietami związanymi z MooTools. Events with [...]