Przy okazji tworzenia tylkoteatr.com musiałem szybko dowiedzieć się dużo o wideo w sieci. Im więcej się dowiadywałem tym bardziej zdawałem sobie sprawę, że jeszcze długa droga zanim będzie można zapomnieć o Flashu.

Na początku toczyła się walka o „wolność” w sieci, czyli używanie kodeka, który byłby całkowicie darmowy i niechroniony żadnymi patentami. Nie chciano, żeby w pewnym momencie pojawiła się korporacja żądająca pieniędzy za dostęp do kodeków.

I tak po dwóch stronach barykady stanęły OGG Theora i H.264. Ten pierwszy reprezentował darmowe i wolne oprogramowanie, natomiast ten drugi objęty jest wieloma patentami i nie do końca darmowy (darmowy dla końcowego użytkownika, ale płatny dla developerów chcących go używać np. jako kodeka w swoich kamerach). Po stronie Theory stały Google, Mozilla i Opera. H.264 wspierało właściwie tylko Apple.

Wspomniałem, że Google było za tym, żeby Theorę uznać za oficjalny kodek wideo w HTML5, ale samo tylko dużo mówiło, robiąc niewiele w tym kierunku. W tym czasie całe YouTube opierało się o konkurencyjny H.264 właśnie. A Chrome długi czas obsługiwało i Theorę i H.264. Widać, że Google nie potrafiło twardo postawić sprawy.

Moim zdaniem słusznie. Oponowanie za Theorą było z jednej strony bronieniem wolnego oprogramowania, ale z drugiej wspieraniem przestarzałego i technicznie słabszego kodeka. Kodowanie filmów do H.264 jest banalne i szybkie, a końcowy efekt to bardzo dobra jakość obrazu. Natomiast Theora przy tej samej wielkości pliku produkuje niezbyt wyraźny (rozmazany) obraz, a sam proces zajmował czasami nawet dwa razy więcej czasu.

Duży błąd moim zdaniem popełniło w tym czasie W3C ogłaszając, że nie będzie oficjalnego kodeka i niech rynek zadecyduje. Z jednej strony mądrze, jednak z drugiej zabrakło odważnej decyzji, przez co przed dwa długie lata musiałem kodować zarówno dla H.264 jak i OGG Theora. To dwa (a czasem i trzy) razy więcej czasu na kodowanie i dwa razy więcej danych do przechowywania. Czyli dwa razy więcej kosztów. Można niby powiedzieć, że nie trzeba się pchać w technologię, która dopiero raczkuje. Tyle, że ja głęboko wierzyłem, że HTML5 będzie lepszy od Flasha i chciałem wspomóc ideę.

Widać było, że Theora się nie nadaje. Format otwarty, ale to jego jedyna zaleta. Google postanawia więc stworzyć nowy kodek, specjalnie dla sieci. WebM powstaje pod koniec 2010 roku i robi trochę zamieszania. Jest nowocześniejszy od Theory, ciągle rozwijany i „wolny”. Przynajmniej tak utrzymuje Google, bo za WebM też stoi mnóstwo patentów. Można by pomyśleć, że sprawa przesądzona. Google przeniesie wszystkie nagrania z YouTube na swój format, ograniczy Chrome tylko do WebM i rynek zdobyty. Nie było to jednak takie proste. Przede wszystkim każdy kodek wymaga wsparcia od strony hardware. H.264 miał go praktycznie wszędzie, WebM (ani Theora) nie. W praktyce oznacza to, że WebM i Theora były wolne w renderowaniu. Do dziś na moim sprzęcie skalowanie nagrania w OGG Theora na pełny ekran powoduje, że obraz skacze. Można tu też niby trochę winić twórców przeglądarek, że nie postarali się o lepsze wykorzystanie kart graficznych, ale efekt jest taki, że tylko H.264 można odtwarzać płynnie i praktycznie na każdym urządzeniu.

WebM też szybko został zapomniany. Nie zainteresowali się nim nawet twórcy aplikacji do konwersji nagrań na różne formaty. Owszem, powoli i leniwie był wprowadzany do niektórych, ale w praktyce wychodziło na to, że żeby faktycznie móc skorzystać z WebM trzeba było się nagimnastykować. Google ma talent do tworzenia rzeczy, o których wszyscy szybko zapominamy.

Zostaliśmy więc z mało popularnym (też bardzo wolnym przy kompresji) WebM, cieniem Theory i H.264, który ciągle zdobywał popularność. Wydawałoby się, że nie ma na co czekać i trzeba się w końcu rzucić na świetny (to jest naprawdę bardzo dobry kodek) H.264, ale Mozilla i Opera dalej obstawały przy wolności w sieci. Jestem za, ale nie za taką cenę. Póki co nie ma nic lepszego niż H.264 i trzeba się z tym pogodzić. Na szczęście Mozilla ogłosiła, że się poddaje. Robi najmądrzejszą rzecz jaką tylko może – będzie korzystać z kodeków zainstalowanych w systemie. Czyli jeśli w systemie będzie H.264, to bez problemu odtworzymy w nim nagranie. W praktyce użytkownik Windows XP będzie musiał sobie go doinstalować, ale już na Windows 7 wszystko będzie działało out of the box.

Warto było przez te kilka ostatnich lat upierać się i bronić gorszej technologii? Idea niby szczytna, ale IMO spowolniło to rozwój <video> na prawie cztery lata. Na szczęście rynek wymusił na Mozilli słuszną decyzję. Nikt poza pasjonatami nie wspierał jednocześnie dwóch formatów. Choćby Vimeo, które HTML5 wspiera, ale tylko w H.264.

Podsumowując. Długo to trwało, ale w końcu możemy powiedzieć, że w w sieci używa się H.264.

Przez długość wiersza rozumiem liczbę znaków w jednej linii tekstu. Przyjmuje się, że najwygodniejszy do czytania jest wiersz między 45 a 75 znaków, a za idealną liczbę uznaje się 66 znaków w wierszu (biorąc pod uwagę zarówno litery jak i znaki dodatkowe czy spacje). Wartość ta zmienia się odrobinę jeśli mówimy o layoutach wykorzystujących kilka kolumn. Wtedy wystarczy 40 do 50 znaków.

Dlaczego nie więcej? Dochodząc do końca linii tekstu musimy zapamiętać gdzie skończyliśmy, żeby móc znaleźć początek kolejnego wiersza. Jeśli początek od końca wiersza będzie dzielić zbyt długa droga, nasz wzrok pogubi się na kolejnych literach. Chyba każdy wie jak irytujące potrafi być uczucie kiedy zgubiliśmy linijkę tekstu, albo kiedy musimy palcem jeździć po książce, żeby wiedzieć co czytamy.

Mimo wszystko, z tą wartością można śmiało eksperymentować. Czytelnicy na pewno postrzegają tekst w różny sposób, a część z nich nie zgodziłaby się z proponowanymi przez typografów wartościami.

Dlaczego nie mniej chyba nie trzeba nawet mówić. Każdy zdaje sobie sprawę jak źle czytałoby się dwa lub trzy wyrazy w wierszu. I nie mówimy tu po poezji.

W CSS widzę trzy możliwości ustalenia długości wiersza. Najprościej oczywiście nadając odpowiednią długość kontenerowi, w którym zamykamy tekst.

p.kolumna1 { width: 465px; }

p.kolumna2 { width: 40%; }

p.kolumna3 { width: 33em; }

W druku ten element jest dość prosty. Twórca ustala sztywno wielkość tekstu i może dopasować do tego długość linii. Projektując dla urządzeń elektronicznych trzeba jednak mieć na uwadze to, że użytkownik sam może zmienić wielkość czcionki (a czasami zrobi to za niego urządzenie, na którym stronę przegląda).

W pierwszym przypadku długość wiersza będzie miała dokładnie 465 pikseli, co odpowiada mniej-więcej 66 znakom dla tekstu wielkości 14 pikseli. Oczywiście, w praktyce wszystko zależy od używanego fonta, więc trzeba do tego podchodzić indywidualnie i za każdym razem policzyć znaki. Co ważne – jeśli czytelnik zmieni tę wartość do 16 pikseli, zmniejszy się również ilość znaków w wierszu.

Logiczne wydaje się w takim razie zastosowanie wartości relatywnych. Używając procentów tak na prawdę oddajemy decyzję o długości wiersza w ręce użytkownika. Jeśli będzie chciał go zwiększyć, może zmaksymalizować okno przeglądarki. Jeśli uzna, że wolałby krótszy wers, może okno zmniejszyć. Krótka chwila na zastanowienie i dochodzimy do wniosku, że nikomu z nas nie chce się manipulować oknem przeglądarki dla pojedynczej strony, a użytkownicy urządzeń mobilnych nie mogą zmienić wielkości okna.

Wcześniej wspominałem już, że wielkości dotyczące tekstu najkorzystniej ustawiać z pomocą em. W trzecim przykładzie długość linii wynosi 33 em, czyli 462 piksele dla tekstu wielkości 14 pikseli, ale jeśli użytkownik zwiększy tę wielkość do np. 16 pikseli, długość linii również się zwiększy i będzie wynosić już 480 pikseli. Dzięki temu w wierszu ilość znaków zawsze pozostanie taka sama, niezależnie od ustawionej przez użytkownika wielkości tekstu.

No dobra, ale co z naszym layoutem, który przecież ma określone wymiary i w którym długi wiersz się nie zmieści? Idealny layout to taki, w którym taka sytuacja nie zajdzie, bo wszystkie wartości dostosowują się zarówno do wielkości tekstu jak i ekranu, na którym wyświetlana jest strona. W praktyce rzadko udaje się taki ideał osiągnąć, więc możemy po prostu ograniczyć maksymalną długość linii. Nie w każdym designie taka sztuczka się sprawdzi, bo nie w każdym jest miejsce na większą długość linii. W praktyce więc, najczęściej na sztywno ustala się długość linii, choć – jeśli tylko jest taka możliwość – powinniśmy używać rozwiązań dających większe możliwości adaptacji.

p.kolumna3 { width: 33em; max-width: 600px; }

W CSS do dyspozycji dostajemy kilkanaście różnych jednostek wielkości. Użycie części z nich wydaje się być dość oczywiste, jednak koderzy często nie są świadomi, że za każdą z nich kryje się swojego rodzaju „drugie dno”. Poza tym wydawało mi się, że warto wspomnieć o takich podstawach, żeby nie wyjaśniać wszystkiego później.

Jednostki absolutne

Jednostki absolutne to takie, które w założeniu mają stały wymiar niezależnie od miejsca ich użycia. Oczywistym przykładem będą cale, centymetry czy milimetry. Nie są to raczej popularnie stosowane wielkości, głównie ze względu na brak skalowalności. Być może chcemy, żeby tekst na ekranie komputera miał 3 centymetry wysokości, ale pomyślmy jak duże te trzy centymetry wydają się kiedy otworzymy tę samą stronę na telefonie komórkowym. Jednostki tego typu sprawdzać się mogą na przykład w osobnej wersji strony internetowej przygotowanej specjalnie do druku (za pomocą media queries).

Osobną kwestią są piksele. Zaliczane były przez długi czas do jednostek absolutnych, ale to nie do końca prawda. Pamiętajmy, że jeden piksel też może mieć różne wymiary fizyczne. Na przykład piksel na moim monitorze ma około 0,257 milimetra, ale już piksel na telewizorze w pokoju obok to 0,639 milimetra, a w iPhone 4 ma zaledwie 0,077 milimetra. Mam nadzieję, że widać tu już wyraźnie główną wadę piksela – nigdy nie mamy pewności na jakim urządzeniu wyświetlona zostanie strona, więc nie możemy założyć, że tekst wielkości 12 px nie będzie np. za mały na telewizorze.

Oczywiście większość software radzi sobie z tym bez większego problemu, przeskalowując tekst dla odpowiedniej widoczności. Podobnie bez większych problemów przeglądarki internetowe potrafią zoomować stronę internetową powiększając tekst razem z resztą elementów. Zdania na temat używania bądź nie używania pikseli do określania wielkości związanych z tekstem są podzielone, ale mówi się raczej, że lepszym wyjściem jest używanie jednostek relatywnych.

• in – cal (2,54 centymetra)
• cm – centymetr
• mm – milimetr
• pt – punkt (0,03528 centymetra)
• pc – pica (0.423 centymetra)

Jednostki relatywne

Jednostki relatywne to te, które w jakiś sposób zależą od innej wartości. Idealnie nadają się do operowania na rozmiarach związanych z tekstem, ponieważ bezproblemowo skalują się z jednego medium do drugiego (np. z monitora na ekran smartphone’a).

Podstawową i jedną z najczęściej wykorzystywanych jednostek relatywnych jest em. Nazywa się tak, ponieważ wielkość jednostki jest w założeniu zbliżona do szerokości wielkiej litery M. Jest to jednak wielkość relatywna w stosunku do font-size. Jak to działa w praktyce?

<p>Lorem ipsum <span>dolor</span> sit amet, consectetur adipiscing elit.</p>

p { font-size: 16px; }
span { font-size: 1.5em; }

Nadajemy elementowi <p> wielkość czcionki 16px. Element <span> dziedziczy tę wielkość, jednak zmieniliśmy ją na 1.5em. W praktyce oznacza to, że powiększamy wielkość tekstu o 50% w stosunku do elementu nadrzędnego (więc będzie równa 24px). Warto pamiętać, że em zawsze będzie odwoływać się do wielkości tekstu, nawet jeśli użyjemy go np. w width.

Em technicznie jest bardzo fajnym narzędziem, ponieważ pozwala manipulować wielkościami w zależności od tego, co na stronie najważniejsze, czyli treści. Nie są jednak zbyt wygodne w użyciu, ponieważ wymagają liczenia i sprawdzania jaką wartość ma element nadrzędny. Łatwo sobie wyobrazić, że przy kilkunastu zagnieżdżonych elementach można się zgubić. Z pomocą przychodzą nam różne narzędzia, które pomogą policzyć odpowiednie wartości jak np. Em Calculator.

Oprócz tego, wraz z pojawieniem się CSS3 do dyspozycji oddano nam ciekawą alternatywę dla em, która jest o wiele wygodniejsza w użyciu. Jest nią rem. Od swojego poprzednika różni się tym, że jest relatywna tylko w stosunku do głównego elementu strony (czyli najczęściej <body>). Nie musimy dzięki temu każdorazowo obliczać wielkości w stosunku do kolejnych elementów. Niestety jest to jednostka nowa i minie trochę czasu zanim będzie wspierana przez większość używanych przeglądarek.

Warto pamiętać również o procentach, które od czasu do czasu przydają się również w manipulowaniu wartościami związanymi z tekstem.

• em – wartość relatywna do font-size rodzica
• ex – tak zwany x-height (wysokość małej litery x) używanego fonta
• ch – długość cyfry 0 w używanym foncie
• % – wartość relatywna do wartości nadrzędnej