Mozilla Hacks: Firefox, YouTube i WebM

W dzisiejszym odcinku tłumaczeń z Mozilla Hacks notka Chrisa Blizzarda, jednego z głównych „ewangelizatorów” Mozilli, na temat formatu WebM. Wprawdzie sam napisałem o tym formacie w poprzedniej notce, ale myślę, że warto posłuchać oficjalnego głosu Mozilli. Jak większość treści z MozHacks, zarówno oryginalny artykuł, jak i poniższe tłumaczenie dostępne są na warunkach licencji Creative Commons Attribution 3.0 USA.

Dzisiaj pięć ważnych rzeczy:

1. Google wyda VP8 jako open-source i bez żadnych opłat (royalty-free). VP8 to wysokiej jakości kodek, w którego posiadanie Google weszło po zakupie firmy On2. Kodek VP8 jest znacznie lepszy pod względem stosunku jakości do liczby bitów niż Theora, a sama jego jakość porównywalna jest z H.264.

2. Kodek VP8 zostanie połączony z kodekiem audio Vorbis i podzbiorem formatu kontenera Matroška w jeden nowy standard otwartego wideo dla WWW – zwany WebM. Więcej na ten temat można znaleźć na w nowej witrynie projektu: http://www.webmproject.org/.

3. Dodamy obsługę WebM do Firefoksa. Już teraz można pobrać bardzo wczesne kompilacje Firefoksa z obsługą WebM. WebM będzie również obsługiwany przez Google Chrome i Operę.

4. Wszystkie filmy na YouTube zostaną przekodowane do WebM. Dziś w tym formacie YouTube udostępnia około 1,2 miliona filmów, a w najbliższym czasie Google zajmie się przekodowaniem archiwum. Obiecują wspierać wszystko.

5. Nowy format jest wspierany przez wielu partnerów – a nie tylko Google i paru innych. Dostawcy treści – jak Brightcove – zadeklarowali wsparcie WebM jako część kompletnego rozwiązania wideo HTML5. Na liście wspierających WebM firm są producenci sprzętu, dostawcy enkoderów i innych elementów stosu technik związanych z wideo. Także Adobe będzie wspierać WebM we Flashu. Firefox, dzięki swemu udziałowi w rynku i dzięki wartościom, które za nim stoją, oraz YouTube, z największym zasięgiem wśród dostawców wideo, to najważniejsi partnerzy w tym przedsięwzięciu, ale jesteśmy tylko drobną częścią większego ekosystemu wideo.

Cieszymy się niezmiernie widząc, jak Google dołącza do nas, by wspierać Otwarte Wideo. Udostępniają technologię na warunkach spójnych z ideą Otwartego WWW i zasad licencyjnych Royalty-Free W3C. Co najważniejsze, Google zapewnia o całkowitym wsparciu pełnego stosu technologii Otwartego Wideo na największej witrynie z wideo na świecie. Ten ruch całkowicie zmienia krajobraz internetowego wideo, określając nowe podstawy, które inne witryny muszą spełniać, żeby dotrzymać kroku YouTube’owi i nowościom technicznym. Ważne też jest wsparcie ze strony przeglądarek o rosnącym udziale w rynku i popychających naprzód technologię w sieci WWW.

Mozilla zawsze chciała, by wideo na WWW rozwijało się tak szybko, jak reszta WWW. Potrzebna była więc podstawa oparta na otwartej technologii, na której można budować nowe rzeczy. Theora była dobrym pierwszym krokiem, VP8 jest znacznie lepsze. Spodziewajcie się od nas mocnego nacisku na dalsze innowacje związane z wideo. Będziemy rozwijać nowe technologie tak, jak rozwija się WWW, przesuwając się z krańców do środka, dzięki dziesiątkom małych rewolucji, które po połączeniu stają się czymś więcej niż tylko sumą elementów. VP8 to jeden z tych elementów, HTML5 to następny. Jeśli zaglądacie na ten blog (lub moje jego tłumaczenia – przyp. tłum.), zauważycie, jak pojawiają się kolejne kawałki. Sieć WWW pełna jest coraz to nowych technologii, a Firefox jest tutaj liderem. Zamierzamy w dalszym ciągu być w awangardzie rozwoju sieci WWW ponad HTML5, do następnego miejsca, w którym powinna być.

Dziś jest dzień wielkiej zmiany. Jutro będzie kolejny.

WebM – nowy format wideo dla HTML5

Dzisiaj Google we współpracy z Mozillą i Operą udostępniło WebM – nowy format wideo, oparty na:

Wsparcie dla nowego formatu powinno pojawić się w najnowszych conocnych kompilacjach Chromium (testowe wydania Chrome pozbawione części niebędących wolnym oprogramowaniem) i Firefoksa, a wkrótce także w oficjalnych paczkach z Google Chrome z kanału developerskiego i testowym wydaniu Opery.

Co ważne – nowy format wspierany jest także przez YouTube – wszystkie filmy o jakości 720p i lepszej wgrane od dziś na YouTube’a dostępne będą w formacie .webm i odtwarzane przez odtwarzacz oparty na HTML5.

Wśród innych organizacji popierających nowy format są także m. in.: Adobe, projekt Android, Skype, AMD, nVidia, Logitech, Texas Instruments, Freescale Semiconductor, Broadcom – mamy więc tu zarówno firmy software’owe jak i zajmujące się sprzętem. WebM jest więc (na razie potencjalnie) pozbawiony największej wady formatu Ogg Theora – braku silnego wsparcia sprzętowego, a ma wszystkie jego zalety.

Czy dni h.264 są policzone? Mam nadzieję. :-)

Ogg Theora czy h.264 – co wybrali użytkownicy w Polsce

Język HTML 5 wprowadził znacznik <video>, służący do osadzania filmów na stronach internetowych. W pierwotnej wersji specyfikacji znalazł się format Ogg z kodekiem Theora, wskutek protestów m. in. Apple aktualna robocza wersja specyfikacji nie określa formatu wideo.

Przeglądarki z silnikiem Gecko (w tym Firefox 3.5+), a także Opera (aktualnie w wersji beta 10.50) i Google Chrome (od wersji 3, także w opensource’owej wersji – Chromium) obsługują Ogg Theora. Format h.264 z kolei obsługuje jedynie Apple Safari (od wersji 3.2) i Google Chrome (od wersji 3, tylko oficjalne wydania komercyjne Google).

Zobaczmy, jak wsparcie dla obu formatów oraz znacznika <video> HTML5 wygląda pośród polskich użytkowników WWW. Poniżej wykorzystałem dane z najnowszej edycji rankingu gemiusTraffic (za tydzień 15-21.02.10). W danych tych pominięto niektóre przeglądarki w wersjach testowych, w szczególności nie zawierają one liczby użytkowników Firefoksa pre-3.7 i Safari 4.x (gdzie x>0), ale wpływ tego ograniczenia na ogólny błąd w tym zestawieniu jest niewielki.

Jak więc to wygląda?

Liczba odsłon Udział % Ogg H.264
Wszystkie odsłony 7382509245 100
Firefox 3.5 2433559952 32,96 T N
Firefox 3.6 545454889 7,39 T N
Opera 10.50 4622237 0,06 T N
Chrome 3 9653886 0,13 T T
Chrome 4 345356590 4,68 T T
Chrome 5 5791210 0,08 T T
Safari 3.2 1314478 0,02 N T
Safari 4.0 29105252 0,39 N T
Obsługa <video> 3374858494 45,71
Wszystkie Ogg 3344438764 45,3
Wszystkie H.264 391221416 5,3

Przeglądarki obsługujące w ogóle znacznik <video> z HTML 5 generują więc już 45,71% odsłon wszystkich serwisów monitorowanych przez Gemius. Przeglądarki obsługujące HTML 5 oraz format h.264 – jedynie 5,3%, natomiast przeglądarki obsługujące HTML 5 i Ogg Theora – 45,3%.

Wraz z migracją użytkowników do nowszych wersji przeglądarek (w szczególności – z Firefoksa 3.0 do 3.6) oraz po wydaniu finalnej Opery 10.50, udział HTML5+Ogg Theora powinien przekroczyć połowę użytkowników – dzisiaj liczba użytkowników brandów (grup) przeglądarek, których najnowsze wersje obsługują otwarte wideo, przekracza 2/3.

Wkrótce więc zdecydowanej większości użytkowników będzie można serwować filmy bez konieczności korzystania z niestabilnych wtyczek (co gwarantuje nam HTML 5) i bez konieczności ponoszenia opłat licencyjnych (co zapewnia otwarte wideo – format Ogg Theora). Użytkownicy przeglądarek internetowych w Polsce wybrali te, które obsługują lub będą wkrótce obsługiwać otwarty format wideo. Każdy, kto poważnie zajmuje się kwestią multimediów w sieci, powinien zwrócić na to uwagę.

Powtórzmy jeszcze raz: już prawie połowie użytkowników w Polsce można serwować wideo bez konieczności instalowania przez nich wtyczek, jednocześnie zapewniając sobie (czy też własnej firmie) niezależność od producentów wtyczek (Adobe Flash) i opłat licencyjnych (h.264). 1

Widownia dla Theory już jest, czas na dostawców treści! :)


1) Użytkownikom pozostałych przeglądarek można serwować te same filmy w formacie Ogg Theora przy użyciu wtyczek (XiphQT, aplet Javy Cortado) lub Video for Everybody.

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 in Poland: EPIC WIN! ;-)

For the first time since the late nineties, Microsoft Internet Explorer is no longer the most popular web browser in Poland. Mozilla Firefox scores the highest marketshare percentage ever, 45.3%, leaving MSIE behind by 0,3 percentage points.

All the Gecko-based browsers amount to 45.5% of the marketshare, Opera is at 8% and growing. WebKit-based browsers like Chrome and Safari grouped with KHTML-based Konqueror are only at 0.3%.

We did it! We broke the Microsoft monopoly! Big thanks to all the people who have supported Mozilla in Poland, starting with Marcin Jagodziński, the first man to translate Mozilla into Polish, Piotr Bartecki and Marek “GmbH” Wawoczny for everything they did at MozillaPL.org, and to all of my friends at Aviary.pl. We would not be here without all your work! I also personally would like to thank the Mozilla Europe team for supporting the Polish team.

To our great community – MozillaPL.org forum members, Polish extension developers,  contributors to the alt.pl.mozilla newsgroup, and to all the Polish web developers who supported web standards and Gecko even in the days of 1% marketshare, to all of you – THANK YOU!!!

History happens!


mozillaepicwin


Po raz pierwszy od lat dziewięćdziesiątych Microsoft Internet Explorer nie jest już liderem rynku przeglądarek internetowych w Polsce. Mozilla Firefox uzyskuje najwyższy wynik w historii – 45,3%, wyprzedzając MSIE o 0,3 pkt proc.

Wszystkie przeglądarki oparte na silniku Gecko mają łącznie 45,5%, a Opera osiągnęła poziom 8% i nie przestaje rosnąć. Przeglądarki oparte na silniku WebKit, takie jak Chrome i Safari, łącznie z opartym na KHTML Konquerorze mają łącznie 0,3%.

Udało się! Przełamaliśmy monopol Microsoftu! W tym miejscu chciałbym podziękować wszystkim, którzy wspierali Mozillę w Polsce, zaczynając od Marcina Jagodzińskiego, który rozpoczął polską lokalizację Mozilli, przez Piotra Barteckiego i Marka “GmbH” Wawocznego (za wszystko, co zrobiliście w MozillaPL.org) po moich przyjaciół z Aviary.pl. Bez Waszego oddania nie byłoby to możliwe. Dziękuję także stowarzyszeniu Mozilla Europe za wsparcie, jakiego udziela polskiemu zespołowi.

Naszej wspaniałej społeczności – użytkownikom forum MozillaPL.org, twórcom polskich rozszerzeń, uczestnikom dyskusji na alt.pl.mozilla, a także tym wszystkim web developerom w Polsce, którzy przestrzegali standardów WWW i wspierali Gecko nawet w najbiedniejszych dniach jednoprocentowego udziału w rynku, Wam wszystkim – WIELKIE DZIĘKI!!!

Tak oto dzieje się historia. :)

PS. Na ten temat po polsku pisze dziś także Hubert.