Mozilla Hacks: Eliptyczne obramowania w Firefoksie 3.5

W ramach serii tłumaczeń artykułów z bloga Mozilla Hacks, przedstawiam dzisiaj tłumaczenie artykułu Elliptical Borders in Firefox 3.5, którego autorem jest Lim Chee Aun (web developer z Malezji, autor ikon i motywu Phoenity). Oryginalny artykuł i jego tłumaczenie dostępne są na warunkach licencji Creative Commons Attribution 3.0 USA.

Własność border-radius jest prawdopodobnie jedną z bardziej interesujących części specyfikacji CSS 3, umożliwiającą tworzenie zaokrąglonych rogów elementów dokumentu. Na przykład:

div {

  border-radius: 10px;
  -moz-border-radius: 10px;
  -webkit-border-radius: 10px;

}

W Firefoksie 3.5 własność -moz-border-radius jest obecnie zgodna z najnowszą wersją (roboczą – przyp. tłum.) specyfikacji CSS 3. Dzięki temu można tworzyć także eliptyczne obramowania.

Co to więc znaczy? Według specyfikacji składnia jest następująca:

-moz-border-radius: <border-radius>{1,4} [ / <border-radius>{1,4}]?

Mamy tutaj zbiór wartości tej własności rozdzielonych ukośnikiem. Tutaj leży cała magia. Jeśli dwa zbiory wartości rozdzielone są ukośnikiem, wartości z lewej strony określają półoś poziomą, a wartości z prawej – półoś pionową.

Oferuje to ciekawe możliwości. Poniższe demo pokazuje kilka eksperymentów z różnymi kształtami, które można w ten sposób uzyskać.

W przykładzie tym eksperymentujemy nie tylko z grubością i promieniem/półosiami obramowania, ale także i jego stylem – o wartościach ridge, double i groove. Obecnie wartości dotted i dashed nie działają, wyświetlane są jak solid. Więcej informacji na ten temat znaleźć można w zgłoszeniu błędu Mozilli nr 431176 .

Mozilla Hacks: Przechodzenie po drzewie DOM w Firefoksie 3.5

W ramach serii tłumaczeń artykułów z bloga Mozilla Hacks, przedstawiam dzisiaj tłumaczenie artykułu DOM Traversal in Firefox 3.5 autorstwa Johna Resiga (znanego m. in. jako twórca biblioteki jQuery). Oryginalny artykuł i jego tłumaczenie dostępne są na warunkach licencji Creative Commons Attribution 3.0 USA.

Przechodzenie po drzewie DOM w Firefoksie 3.5

Firefox 3.5 obsługuje dwie nowe specyfikacje W3C dotyczące przechodzenia po drzewie DOM. Pierwsza z nich – Element Traversal API – ułatwia przechodzenie pomiędzy kolejnymi elementami, a druga – interfejs NodeIterator – sprawia, że odnajdywanie węzłów wszystkich typów staje się prostsze.

Element Traversal API

Zadaniem Element Traversal API (API przechodzenia po elementach) jest ułatwienie przechodzenia po elementach w drzewie DOM z pominięciem pośrednich węzłów tekstowych, węzłów komentarzy itp. Rozwiązuje to istniejący od dawna problem irytujący programistów; w szczególności problematyczne były przypadki, w których document.documentElement.firstChild miało różną wartość w zależności od występowania białych spacji w dokumencie.

Element Traversal API wprowadza kilka nowych własności węzłów DOM, znacznie ułatwiających przechodzenie drzewa.

Poniżej zestawienie istniejących dotychczas własności DOM i ich nowych odpowiedników:

Cel Wszystkie węzły DOM Tylko elementy DOM
Pierwszy .firstChild .firstElementChild
Ostatni .lastChild .lastElementChild
Poprzedni .previousSibling .previousElementSibling
Następny .nextSibling .nextElementSibling
Długość .childNodes.length .childElementCount

Własności te są dość prostym rozszerzeniem specyfikacji DOM (szczerze mówiąc, powinny się w niej znajdować od początku).

Jednej własności jednakże brakuje: .childElements (jako odpowiednika .childNodes). Własność ta (zawierająca dynamiczną kolekcję typu NodeSet elementów potomnych danego elementu DOM) znajdowała się w poprzednich iteracjach tej specyfikacji, ale w międzyczasie została z niej usunięta.

Ale nie wszystko stracone. Obecnie Internet Explorer, Opera i Safari obsługują własność .children, oferującą nadzbiór funkcjonalności, która miała być udostępniana przez .childElements. Kiedy obsługa Element Traversal API została włączona do Firefoksa 3.5, zaimplementowana wraz z nią została także kolekcja .children. Oznacza to, że obecnie każda z głównych przeglądarek obsługuje tę własność (wyprzedza ona pod tym względem właściwą specyfikację Element Traversal).

Oto kilka przykładów wykorzystania Element Traversal API (i kolekcji .children):

Wyświetl następny element po kliknięciu:

someElement.addEventListener("click", function(){
    this.nextSiblingElement.style.display = "block";
}, false);

Ustaw klasę dla wszystkich elementów bezpośrednio podrzędnych:

for ( var i = 0; i < someElement.children.length; i++ ) {
    someElement.children[ i ].className = "active";
}

NodeIterator API

NodeIterator to dość stare API, które nie było dotąd szeroko stosowane, a obecnie zostało zaimplementowane w Firefoksie 3.5. NodeIterator API ma na celu ułatwienie przechodzenie po wszystkich węzłach dokumentu DOM (w tym węzłów tekstowych, komentarzy itd.).

Samo API jest dość zawiłe (zawiera sporo funkcji, które nie są specjalnie istotne dla większości programistów), ale w prostych zastosowaniach jest dość łatwe w użyciu.

Zasada działania jest następująca: tworzymy instancję NodeIterator (za pomocą document.createNodeIterator) i przekazujemy jej zbiór filtrów. NodeIterator potrafi zwrócić wszystkie węzły w dokumencie (czy w kontekście danego węzła), dlatego zwykle chcemy odfiltrować wyniki, by dostać tylko pożądane węzły. Oto prosty przykład:

Utwórzmy instancję NodeIterator, by przeiterować po wszystkich węzłach komentarzy w dokumencie.

var nodeIterator = document.createNodeIterator(
    document,
    NodeFilter.SHOW_COMMENT,
    null,
    false
);

var node;

while ( (node = nodeIterator.nextNode()) ) {
    node.parentNode.removeChild( node );
}

Po utworzeniu NodeIterator jest dwukierunkowy (można przechodzić w dowolnym kierunku, przy pomocy własności previousNode i nextNode).

Prawdopodobnie najsensowniejszym zastosowaniem tego API jest przechodzenie po często używanych (ale w inny sposób trudnych do przejścia) węzłach, takich jak komentarze i węzły tekstowe. Jako że istnieje już kilka innych API do przechodzenia po elementach DOM (jak np. getElementsByTagName), omówione tu API jest kolejną przydatną alternatywą dla innych sposobów na przechodzenie węzłów dokumentu.

W uzupełnieniu powyższego artykułu Johna – dwa zdania ode mnie na ten temat. W swoim blogu autor powyższego artykułu jest bardziej krytyczny co do NodeIteratora. Zgadzam się z nim tutaj w pełni – osobiście mam wrażenie, że gdyby nie test ACID 3, którego NodeIterator jest częścią, nie zobaczylibyśmy implementacji tego API w Gecko. Omówione w pierwszej części artykułu Element Traversal API jest natomiast zdecydowanie bardziej przydatne w codziennej pracy web developera.

Mozilla Hacks: Synchroniczne żądania XHR w Firefoksie 3.5

W ramach serii tłumaczeń artykułów z bloga Mozilla Hacks, przedstawiam dzisiaj tłumaczenie artykułu Synchronous XHR requests in Firefox 3.5 autorstwa Douga Turnera. Doug pracuje w Mozilli nad projektem Mobile. Oryginalny artykuł i jego tłumaczenie dostępne są na warunkach licencji Creative Commons Attribution 3.0 USA.

Synchroniczne żądania XHR w Firefoksie 3.5

Żądania XMLHttpRequest (XHR) mogą być zarówno synchroniczne, jak i asynchroniczne. Chociaż w większości przypadków korzysta się z żądań asynchronicznych, zdarza się, że możemy potrzebować żądania synchronicznego (np. w wątkach roboczych – przyp. tłum.), czyli wstrzymać dalsze wykonywanie kodu JavaScript aż do ukończenia obsługi żądania XMLHttpRequest. W Firefoksie 3 i starszych przeglądarka odpalała zdarzenia czasowe i reagowała na wprowadzanie danych podczas synchronicznego żądania XHR. W Firefoksie 3.5 i nowszych zdarzenia wprowadzania danych, takie jak ruchy myszą, oraz zdarzenia czasowe są wstrzymywane do chwili ukończenia żądania synchronicznego. Dzięki temu żądania synchroniczne są żądaniami blokującymi.

Na przykład:

function hello() {
     alert(“hello”);
}

 
setTimeout(hello, 20);
 
var req = new XMLHttpRequest();

req.open('GET', 'http://www.mozilla.org/', false);
req.send(null);

Przed Firefoksem 3.5 nie można było określić, czy funkcja „hello” wywołana zostanie przed czy po żądaniu XHR. Powodowało to różne problemy czasowe w aplikacjach WWW korzystających z synchronicznych żądań XHR.

Rozwiązaniem tego problemu jest wstrzymanie zdarzeń wprowadzania danych i zdarzeń czasowych do momentu powrotu z req.send.

Więcej informacji na ten temat można znaleźć w zgłoszeniach błędów nr 340345 i 333198 dotyczących tego problemu

Mozilla Hacks: API selektorów w DOM w Firefoksie 3.5

W ramach serii tłumaczeń artykułów z bloga Mozilla Hacks, przedstawiam dzisiaj tłumaczenie artykułu DOM Selectors API in Firefox 3.5 autorstwa Johna Resiga. Oryginalny artykuł i jego tłumaczenie dostępne są na warunkach licencji Creative Commons Attribution 3.0 USA.

API selektorów w DOM w Firefoksie 3.5

Specyfikacja Selectors API, rekomendacja W3C, to nowe rozwiązanie pozwalające programistom JavaScriptu odnajdywać elementy drzewa DOM strony przy użyciu selektorów CSS. To pojedyncze API pozwala na przeszukiwanie drzewa DOM i odnajdywanie jego elementów przy użyciu prostego, ujednoliconego interfejsu.

API selektorów jest jednym z lepiej obsługiwanych przez wszystkie przeglądarki nowych standardów: można z niego korzystać już dziś w Internet Explorerze 8, Chrome, Safari, Firefoksie 3.5 i wkrótce w Operze 10.

Korzystanie z querySelectorAll

Selectors API zawiera dwie metody dostępne na wszystkich dokumentach, elementach i fragmentach DOM: querySelector i querySelectorAll. Metody te działają prawie identycznie – obie przyjmują jako argument selektor CSS i zwracają pasujące do niego elementy DOM (z tą różnica, że querySelector zwraca tylko pierwszy pasujący element).

Na przykład, mając dany poniższy fragment kodu HTML:

<div id="id" class="class">
    <p>Pierwszy akapit.</p>

    <p>Drugi akapit.</p>
</div>

możemy wykorzystać querySelectorAll do ustawienia czerwonego koloru tła wszystkich akapitów leżących wewnątrz diva o ID równym „id”:

var p = document.querySelectorAll("#id p");

for ( var i = 0; i < p.length; i++ ) {

    p[i].style.backgroundColor = "red";
}

Możemy też odnaleźć pierwszy akapit diva o klasie „class” i ustawić jego nazwę klasy na „first”.

document.querySelector("div.class > p:first-child")
    .className = "first";

Dotychczas, bez użycia Selectors API, tego rodzaju przeszukiwanie wymagałoby napisania długiego kodu JavaScript/DOM, złożonego z wielu linii i wielu zapytań.

O ile metody Selectors API są relatywnie proste w użyciu (pobierają tylko jeden argument), o tyle bardziej problematyczną sprawą jest dobór selektorów CSS. API selektorów korzysta z selektorów CSS natywnie obsługiwanych przez przeglądarkę do stylowania elementów przy użyciu CSS. W większości przeglądarek (Firefoksa, Safari, Chrome i Opery) oznacza to, że możemy w pełni korzystać z selektorów CSS 3. Internet Explorer 8 obsługuje bardziej ograniczony podzbiór selektorów, włączając w to selektory CSS 2 (które i tak są bardzo przydatne).

Największym wyzwaniem dla nowych użytkowników API selektorów jest więc określenie, które selektory CSS są odpowiednie do odnalezienia pożądanych elementów – szczególnie, że większość programistów piszących kod działający w wielu przeglądarkach ma doświadczenie głównie z ograniczonym podzbiorem w pełni działających selektorów CSS 1.

Dobrze jest zacząć od specyfikacji selektorów CSS 2 i CSS 3, ale warto też przejrzeć poniższe artykuły, by dowiedzieć się więcej (w języku angielskim – przyp. tłum.):

Implementacje w bibliotekach

Najciekawszy przypadek użycia API selektorów to nie tyle ich bezpośrednie stosowanie przez programistów WWW, ale ich wykorzystanie w bibliotekach, które już teraz dostarczają funkcjonalność selektorów CSS w DOM. Istotnym dziś problemem w szerszym stosowaniu API selektorów jest fakt, że nie są one dostępne we wszystkich przeglądarkach, dla których tworzy się obecnie strony (w tym IE 6, IE 7 i Firefox 3). Dlatego też, dopóki starsze przeglądarki są w użyciu, musimy korzystać z narzędzia pośredniczącego, aby odtworzyć zachowanie selektorów CSS w DOM.

Na szczęście w wielu istniejących bibliotekach jest dostępne API zgodne z Selectors API (w rzeczywistości Selectors API zostało w dużej mierze zainspirowane przez istniejące biblioteki). Co więcej, wiele z tych implementacji używa wewnętrznie właśnie Selectors API. Oznacza to, że można stosować selektory CSS w DOM w wielu przeglądarkach już teraz, zapewniając większą wydajność w nowych przeglądarkach obsługujących Selectors API, bez nadmiernego wysiłku.

Oto niektóre z istniejących implementacji, które korzystają z Selectors API, o ile to możliwe:

Warto jeszcze raz podkreślić duży skok w wydajności, jaki powoduje korzystanie z nowego API (w porównaniu z tradycyną mieszanką DOM i JabaScriptu, stosowaną do tej pory). Różnicę tę widać na przykład we wzroście wydajności bibliotek javascriptowych, odkąd zaimplementowały one Selectors API.

Ostatnio wykonane testy przyniosły następujące wyniki:

Widać tu dramatyczny wzrost wydajności po zaimplementowaniu natywnego API selektorów w bibliotekach – całkiem możliwe, że podobny wzrost wydajności zobaczysz także w swoich aplikacjach.

Zestaw testów

Razem ze specyfikacją Selectors API przygotowany został zbiór testów Selectors API, jego autorem jest John Resig z Mozilli. Ten zbiór testów pozwala określić jakość implementacji API selektorów w głównych przeglądarkach.

Aktualne wyniki (w momencie pisania oryginalnego artykułu – przyp. tłum.) dla przeglądarek obsługujących nowe API:

  • Firefox 3.5: 99.3%
  • Safari 4: 99.3%
  • Chrome 2: 99.3%
  • Opera 10b1: 97.5%
  • Internet Explorer 8: 47.4%

Internet Explorer 8, jak wspomniano wcześniej, nie obsługuje większości selektorów CSS 3, dlatego nie przechodzi większości powiązanych testów.

Selectors API pozwala na proste i szybkie odnajdywanie elementów DOM strony. Już teraz przynosi ono pożytek osobom korzystającym z bibliotek javascriptowych zapewniających podobną funkcjonalność, dlatego też zachęcamy do wypróbowania nowego API już teraz.

Mozilla Hacks: Nieprzezroczystość w Firefoksie 3.5

W ramach serii tłumaczeń artykułów z bloga Mozilla Hacks, przedstawiam dzisiaj tłumaczenie (króciutkiego) artykułu Opacity in Firefox 3.5, autorstwa Chrisa Blizzarda. Oryginalny artykuł i jego tłumaczenie dostępne są na warunkach licencji Creative Commons Attribution 3.0 USA.

Nieprzezroczystość w Firefoksie 3.5

To będzie bardzo krótka notka, ale warta opublikowania, bo pokazuje, jak możliwości przeglądarek rozwijają się, począwszy od własnej implementacji producenta po w pełni wspierany standard.

Firefox 3.5 nie obsługuje już specyficznej dla Mozilli własności CSS -moz-opacity. Programiści chcący określić stopień nieprzezroczystości elementu powinni stosować standardową własność opacity.

Własność opacity pojawiła się już w Firefoksie 0.9, a -moz-opacity została oznaczona jako przestarzała. W Firefoksie 3.5 została ostatecznie usunięta.

Trwało to długo, jak na prostą własność, ale warto o tym wspomnieć, by pokazać perspektywę czasową dla tego rodzaju funkcji i ich związku ze standardami.