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ę. :-)

Advertisements

Mozilla Hacks: Interfejs FormData wkrótce w Firefoksie

W dzisiejszym odcinku tłumaczeń z Mozilla Hacks notka Paula Rogeta, jednego z głównych europejskich „ewangelizatorów” Mozilli, poświęcona interfejsowi FormData. 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.

Interfejs FormData wkrótce w Firefoksie

Implementacja tego interfejsu pojawiła się w Mozilla Central (trunku) i dostępna jest aktualnie tylko w conocnych kompilacjach Firefoksa.

Specyfikacja XMLHttpRequest Level 2 (obecnie w wersji roboczej) dodaje nowy interfejs – FormData. Obiekty FormData umożliwiają tworzenie par klucz-wartość, reprezentujących pola formularzy i ich wartości, które można następnie łatwo przesłać w formacie “multipart/form-data” wykorzystując metodę send() obiektu XMLHttpRequest.

Dlaczego FormData?

W celu przesłania złożonych danych ze strony WWW do serwera (pliki, treści inne niż ASCII) konieczne jest stosowanie typu zawartości multipart/form-data. Zazwyczaj aby utworzyć formularz z takim typem, stosuje się kod jak poniżej:

<form method="post" 
    enctype="multipart/form-data" action="http://foo.bar/upload.php">
<input type="file" name="media"/>
<input name="nickname"/>
<input name="website"/>
<input type="submit" value="upload"/>
</form>

W ten sposób zwykle przesyła się pliki.

Firefox 3.6 umożliwił manipulację plikami z poziomu JavaScriptu (zob. File API [w jęz. angielskim – przyp. tłum.]), ale nie było dotąd prostego sposobu na przesłanie plików przez XMLHttpRequest. Odtworzenie funkcjonalności powyższego formularza z poziomu JavaScriptu było trudne, bo wymagało zakodowania treści do postaci multipart/form-data przez kod skryptu (np. ten kod, napisany przeze mnie [przez Paula Rogeta – przyp. tłum.] jakiś czas temu, implementuje kodowanie multipart/form-data: jest powolny i niezbyt elegancki).

Tutaj właśnie przydaje się FormData: do odtworzenia funkcjonalności przesyłania formularzy z poziomu JavaScriptu.

Obiekt FormData

Obiekt FormData pozwala ułożyć zbiór par klucz-wartość do przesłania przez XMLHttpRequest. Obiekt ten posiada tylko jedną metodę:

append(key, value);

Argument key to nazwa klucza dla przesłanej wartości, a wartość ta – value – może być ciągiem znaków lub plikiem.

Można utworzyć obiekt FormData, dołączyć do niego wartości i przesłać go z wykorzystaniem XMLHttpRequest. Aby zasymulować powyższy formularz, wystarczy:

// aFile może być plikiem z inputa z atrybutem type="file"
// albo plikiem przeciągniętym metodą drag&drop
var formdata = new FormData();
formdata.append("nickname", "Foooobar"); 
formdata.append("website", "http://hacks.mozilla.org");
formdata.append("media", aFile);
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://foo.bar/upload.php");  
xhr.send(formdata);

FormData i element <form>

Firefox (czy raczej silnik Gecko – przyp. tłum.) nieco rozszerza element <form> języka HTML o metodę getFormData(), która pozwala na pobranie danych formularza w postaci obiektu FormData. Nie jest to obecnie część standardu HTML, ale spodziewamy się, że pojawi się w niej w przyszłości (możliwe, że pod inną nazwą):

var formElement = document.getElementById("myFormElement");
var xhr = new XMLHttpRequest();
xhr.open("POST", "submitform.php");
xhr.send(formElement.getFormData());

Można także dodać dane do obiektu FormData pomiędzy pobraniem go z formularza a przesłaniem, jak poniżej:

var formElement = document.getElementById("myFormElement");
formData = formElement.getFormData();
formData.append("serialnumber", serialNumber++);
xhr.send(formData);

Pozwala to na modyfikację danych formularze przed przesłaniem, na przykład rozszerzając je o dodatkowe informacje, które nie są przeznaczone do edycji przez użytkownika w formularzu.

Zasoby (w jęz. angielskim):

Mozilla Hacks: Firefox 4 – nowy parser HTML5

W ramach serii tłumaczeń artykułów z bloga Mozilla Hacks, przedstawiam dzisiaj tłumaczenie artykułu Firefox 4: the HTML5 parser – inline SVG, speed and more. Oryginalny artykuł i jego tłumaczenie dostępne są na warunkach licencji Creative Commons Attribution 3.0 USA.


Autorem wersji oryginalnej tej notki jest Henri Sivonen, zajmujący się nowym parserem HTML5 Firefoksa. Parser HTML jest jednym z najbardziej skomplikowanych i wrażliwych elementów przeglądarki. Steruje procesem przetwarzania kodu źródłowego HTML do stron WWW, dlatego też zmiany w nim wprowadzane są rzadko i muszą być dobrze przetestowane. Podczas gdy większa część silnika Gecko została przebudowana od czasów jego powstania w późnych latach 90., parser był jedną z rzeczy, które pozostały od samego początku niezmienne. Teraz kod ten został zastąpiony nowym, który jest szybszy, zgodny z nowym standardem HTML5 i daje sporo nowych możliwości.

Od jakiegoś czasu prowadziliśmy prace nad zastąpieniem starego parsera HTML w silniku Gecko. Nowy parser został ostatnio domyślnie włączony w trunku, tak więc wystarczy po prostu pobrać conocną kompilację przeglądarki, by wypróbować nowy parser bez potrzeby przełączania żadnych opcji konfiguracyjnych.

Cztery najważniejsze rzeczy, które są związane z nowym parserem HTML5:

  • można korzystać z kodu SVG i MathML bezpośrednio (inline) na stronach HTML5, bez przestrzeni nazw XML
  • przetwarzanie odbywa się poza głównym wątkiem interfejsu użytkownika Firefoksa, zwiększając całkowitą responsywność przeglądarki
  • szybkość zapisu własności innerHTML jest o około 20% większa
  • nowy parser naprawia dziesiątki starych błędów dotyczących przetwarzania.

Obejrzyj democonocnej kompilacji Firefoksa lub innej przeglądarce obsługującej HTML5. Powinno to wyglądać tak:

Co to jest?

Parser HTML5 w Gecko zamienia strumień bajtów w drzewo DOM, zgodnie z algorytmem przetwarzania HTML5.

HTML5 to pierwsza specyfikacja, która szczegółowo określa sposób parsowania HTML. Dotychczasowe specyfikacje nie opisywały, jak przekształcić strumień bajtów w drzewo DOM. Teoretycznie HTML przed HTML5 był określony jako aplikacja SGML. Pociągało to za sobą określony związek między kodem
źródłowym poprawnych dokumentów HTML i drzewem DOM. Jednakże przetwarzanie niepoprawnych dokumentów nie było dobrze określone (a strony WWW w większości składają się z niepoprawnego kodu HTML4), a jednocześnie istnieją konstrukcje SGML, które teoretycznie były częścią HTML, ale nie były implementowane w rzeczywistości przez popularne przeglądarki.

Brak właściwej specyfikacji sprawił, że twórcy przeglądarek musieli samemu dojść do tego, jak traktować nieprawidłowe dokumenty, w razie wątpliwości badając działanie innych przeglądarek o największym udziale w rynku (najpierw Mosaic, potem Netscape, potem IE). Powstało w ten sposób wiele niepisanych reguł, ale także wiele różnic w zachowaniu przeglądarek.

Algorytm przetwarzania HTML5 standaryzuje zachowanie, do którego zbiegają się przeglądarki i inne aplikacje konsumujące HTML. Zgodnie z projektem, algorytm przetwarzania HTML5 jest właściwy do przetwarzania istniejących treści HTML, tak więc aplikacje nie muszą dalej wspierać swoich starych parserów, aby móc wyświetlić stare treści. W conocnych kompilacjach Firefoksa parser HTML5 używany jest dla wszystkich treści typu text/html.

Jak inny jest nowy parser?

Algorytm przetwarzania HTML5 ma dwie główne części: tokenizację i budowanie drzewa. Tokenizacja jest procesem rozdzielania strumienia źródłowego do znaczników, tekstu, komentarzy i atrybutów wewnątrz znaczników. Faza budowania drzewa na bazie znaczników i tekstu pomiędzy nimi buduje drzewo DOM. Algorytm tokenizacji w parserze HTML5 bliższy jest temu, co robi Internet Explorer, niż temu, co robiły dotychczasowe wersje Gecko. IE miał przez długi czas dominację na rynku, przez co witryny były głównie testowane pod kątem prawidłowego działania z tokenizerem IE. Proces budowy drzewa natomiast jest zbliżony do dotychczasowego działania silnika WebKit. Spośród głównych silników przeglądarek przed HTML5, WebKit posiadał najbardziej rozsądne rozwiązanie problemu budowania drzewa.

Ponadto, nowy parser przetwarza strumienie poza głównym wątkiem. Tradycyjnie przeglądarki wykonywały większość zadań w głównym wątku. Radykalne zmiany, takie jak przeniesienie przetwarzania poza główny wątek, uprościły kod parsera HTML5 w porównaniu do starego parsera HTML Gecko.

Co nowego dla twórców witryn?

Zmiany omówione powyżej są interesujące głównie dla programistów przeglądarek. Kluczową cechą parsera HTML5 jest to, że właściwie nie widać, żeby cokolwiek się zmieniło.

Jest jednak jedna duża zmiana istotna dla twórców witryn: kod MathML i SVG bezpośrednio w dokumentach HTML5. Nowy sposób przetwarzania HTML5 uwalnia MathML i SVG od XML-a i udostępnia je w głównym formacie sieci WWW.

Oznacza to, że można osadzać złożone typograficznie wyrażenia matematyczne w dokumentach HTML, bez potrzeby przepisywania całego dokumentu do XHTML, jak też, co ważniejsze, bez potrzeby modyfikacji oprogramowania budującego witrynę do zwracania prawidłowo sformowanego kodu XHTML. Na przykład, aby osadzić w kodzie HTML wzór na rozwiązanie równania kwadratowego, wystarczy tylko poniższy kod:

<math>
  <mi>x</mi>
 
  <mo>=</mo>
  <mfrac>
    <mrow>
      <mo>&minus;</mo>
      <mi>b</mi>
      <mo>&PlusMinus;</mo>
      <msqrt>
        <msup>
 
          <mi>b</mi>
          <mn>2</mn>
        </msup>
        <mo>&minus;</mo>
        <mn>4</mn>
        <mo>&InvisibleTimes;</mo>
        <mi>a</mi>
 
        <mo>&InvisibleTimes;</mo>
        <mi>c</mi>
      </msqrt>
    </mrow>
    <mrow>
      <mn>2</mn>
      <mo>&InvisibleTimes;</mo>
      <mi>a</mi>
 
    </mrow>
  </mfrac>
</math>

W podobny sposób można osadzić skalowalną grafikę SVG – bez przepisywania HTML-a do XHTML-a. Podczas gdy rozmiary ekranów i rozdzielczości stają się coraz bardziej zróżnicowane, coraz większą wagę przywiązuje się do jakości grafiki przy różnych stopniach powiększenia. Wprawdzie dotychczas można było używać grafiki SVG w dokumentach HTML przez referencję (używając elementu object), wstawianie SVG bezpośrednio jest w niektórych przypadkach wygodniejsze. Na przykład ikona ostrzeżenia może być teraz osadzona bezpośrednio, a nie ładowana z zewnętrznego pliku.

<svg height=86 width=90 viewBox='5 9 90 86' style='float: right;'>
  <path stroke=#F53F0C stroke-width=10 fill=#F5C60C stroke-linejoin=round d='M 10,90 L 90,90 L 50,14 Z'/>
  <line stroke=black stroke-width=10 stroke-linecap=round x1=50 x2=50 y1=45 y2=75 />
</svg>

Wystarczy utworzyć stronę zaczynającą się od <!DOCTYPE html> i wstawić do niej dwa powyższe fragmenty, a będzie to działać w nowych nocnych kompilacjach Firefoksa.

Ogólnie, jeśli mamy kod MathML czy SVG jako XML, wystarczy po prostu wkleić kod XML bezpośrednio do HTML-a (pomijając, jeśli istnieją, deklarację XML oraz doctype). Dwa zastrzeżenia: kod nie może stosować przedrostków przestrzeni nazw dla elementów (tak więc żadnych svg:svg ani math:math), a przedrostkiem przestrzeni nazw XLink musi być xlink.

W powyższych fragmentach MathML i SVG uważna osoba dostrzeże, że bezpośrednio osadzane fragmenty MathML i SVG są bardziej podobne do HTML i prostsze niż po prostu wklekony w to miejsce XML. Nie ma deklaracji przestrzeni nazw, a niepotrzebne cudzysłowy wokół wartości atrybutów zostały pominięte. Działa to, ponieważ znaczniki są tokenizowane przez tokenizer HTML5, a nie przez tokenizer XML. Pomijanie deklaracji przestrzeni nazw działa, ponieważ proces budowania drzewa nie używa atrybutów wyglądających jak deklaracje przestrzeni nazw do przypisania elementom “MathML-owatości” czy “SVG-owatości”. Zamiast tego <svg> rozpoczyna zasięg elementów, którym przypisana będzie przestrzeń nazw SVG w DOM, a <math> rozpoczyna zasięg elementów, którym w DOM przypisana będzie przestrzeń nazw MathML. W przykładzie MathML widać także, że stosowane są odwołania do encji nazwanych, które wcześniej nie były obsługiwane w HTML.

Poniżej krótkie podsumowanie przetwarzania MathML i SVG bezpośrednio w dokumentach HTML dla twórców witryn:

  • <svg></svg> przypisany jest do przestrzeni nazw SVG w DOM.
  • <math></math> przypisany jest do przestrzeni nazw MathML w DOM.
  • foreignObject oraz annotation-xml (na różnych mniej istotnych elementach) rozpoczyna zagnieżdżony zasięg HTML, tak więc można zagnieżdżać SVG, MathML i HTML w sposób, jakiego można oczekiwać.
  • Parser poprawia wielkość znaków w znakowaniu, tak więc <SVG VIEWBOX=’0 0 10 10′> działa w kodzie HTML.
  • Metody DOM i selektory CSS rozróżniają wielkość znaków, należy więc pisać wywołania DOM oraz selektory CSS z użyciem kanonicznej wielkości znaków, czyli tzw. camelCase w przypadku różnych części SVG, takich jak viewBox.
  • Składnia <foo/> otwiera i natychmiast zamyka element foo, jeśli jest to element MathML lub SVG (ale nie element HTML).
  • Tokenizacja atrybutów przebiega w taki sam sposób, jak w HTML, tak więc można pomijać cudzysłowy w sytuacjach, w których można byłoby je pominąć w HTML (tj. kiedy wartość atrybutu nie jest pusta oraz nie zawiera białych znaków, ", ', `, <, = ani >).
  • Uwaga: dwie powyższe cechy nie współgrają ze sobą dobrze z przyczyn zachowania zgodności z tokenizacją starego HTML-a. Jeśli cudzysłowy zostaną pominięte przy wartości ostatniego atrybutu, konieczne jest wstawienie spacji przed zamykającym ukośnikiem. Tak więc prawidłowy jest kod: <circle fill=green />, ale nieprawidłowy jest: <circle fill=red/>.
  • Atrybuty zaczynające się od xmlns nie mają absolutnie żadnych skutków, nie wpływają na obecność elementów ani atrybutów w danej przestrzeni nazw, tak więc nie ma potrzeby ich stosowania.
  • Atrybuty w przestrzeni nazw XLink muszą stosować przedrostek xlink (np. xlink:href).
  • Nazwy elementów nie mogą zawierać przedrostków ani dwukropków.
  • Zawartość elementów script w SVG tokenizowana jest tak, jak w XML – nie jak zawartość elementów script w HTML.
  • Kiedy element SVG lub MathML jest otwarty, sekcje <![CDATA[]]> działają tak, jak w XML. Można to wykorzystać do ukrycia treści tekstowych przed starszymi przeglądarkami nie obsługującymi SVG ani MathML w text/html.
  • Encje nazwane MathML dostępne są w całym dokumencie (także w treści HTML).
  • Aby zapewnić działanie stron, na których autorzy umieścili fragmenty SVG w HTML (nie wiadomo, po co) lub użyli znacznika <math> do celów niezwiązanych z MathML, próby zagnieżdżenia różnych popularnych elementów HTML jako elementów potomnych SVG (bez użycia foreignObject) spowodują natychmiastowe wyjście z kontekstu SVG lub MathML. Może to sprawić, że literówki będą miały zaskakujące efekty.

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.

HTML 5: przesyłanie wielu plików jednocześnie

Dotychczas, chcąc umożliwić użytkownikowi przesłanie wielu plików przy pomocy formularza HTML, webmasterzy musieli posiłkować się albo apletami Flasha (takimi jak SWFUpload czy Uploadify), albo wstawić wiele elementów input. To drugie rozwiązanie było niewygodne dla użytkownika, ponieważ musiał on każdy plik wybrać w osobnym oknie wyboru pliku. Tak robiło się to do tej pory w HTML 4.01:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Upload plików - pojedynczy</title>
<form method="post" enctype="multipart/form-data" action="upload.php">
  <fieldset>
    <legend>Prześlij pliki</legend>
      <label>Dodaj plik 1: 
        <input type="file" name="files[]">
      </label><br>
      <label>Dodaj plik 2: 
        <input type="file" name="files[]">
      </label><br>
      <label>Dodaj plik 3: 
        <input type="file" name="files[]">
      </label><br>
      <label>Dodaj plik 4: 
        <input type="file" name="files[]">
      </label><br>
      <!-- itd... -->
      <input type="submit">
    </fieldset>
</form>

Niezbyt to wygodne, jeśli chcemy załadować np. kilka zdjęć z naszej ostatniej wycieczki w góry…

Gecko 1.9.2 (dostępne m. in. w nadchodzącym Firefoksie 3.6) oraz nowsze wersje przeglądarek opartych na silniku WebKit obsługują atrybut multiple elementu <input> z atrybutem type="file". Atrybut ten pozwala do jednego inputa wstawić wiele plików. Powyższy kod upraszcza się więc w HTML 5 do takiej postaci:

<!DOCTYPE html>
<meta charset="UTF-8">
<title>Upload wielu plików</title>
<form method="post" enctype="multipart/form-data" action="upload.php">
  <fieldset>
    <legend>Prześlij pliki</legend>
    <label>Dodaj pliki:
      <input type="file" multiple name="files[]">
    </label><br>
    <input type="submit">
  </fieldset>
</form>

Po kliknięciu “Przeglądaj” użytkownikowi wyświetli się systemowa wybieraczka plików, pozwalająca zaznaczyć wiele plików (z wciśniętym klawiszem Ctrl, Shift, lub poprzez odpowiednie zaznaczenie myszą). Po stronie serwera nic się nie zmienia, przesłane pliki traktowane są tak samo, jakby były przesłane z kilku osobnych, a nie jednego wspólnego inputa.

Tak więc np. kod w PHP operujący na tablicy $_FILES w ogóle nie musi być modyfikowany po przejściu na input z atrybutem multiple (jeśli korzystaliśmy do tej pory z wielu inputów o tej samej “tablicowej” nazwie).

HTML 5 po raz kolejny rozwiązuje problem, który irytował webmasterów od niepamiętnych czasów. Teraz czekamy już tylko na Operę i Microsoft… :)

PS. Na razie aplety w rodzaju SWFUpload pozostają niezastąpione, jeśli chcemy użytkownikowi np. pokazywać pasek postępu podczas przesyłania plików. Wkrótce jednak flashowe protezy zupełnie stracą rację bytu – W3C pracuje nad specyfikacją FileUpload, która umożliwi przesyłanie plików poprzez XMLHttpRequest.

MDN

Better JavaScript docs for a better Web on MDN

Archiwum