Обновляем сайт до HTML 5. Часть 2.

^{2011-03-21

JavaScript

HTML

Internet Explorer

Internet Explorer 8

outcoldman.ru

Html 5

Internet Explorer 9

modified: 2011-03-21

reading: 9 minutes}

Продолжу тему обновления верстки сайта до HTML 5. С первой частью статьи можно ознакомиться здесь Обновляем сайт до HTML 5. Часть 1. Как я и говорил – это можно назвать рефератом на книгу DIVE INTO HTML5, большинство примеров взяты оттуда.

Video

Затея очень классная, по идеи без лишних плагинов (Flash или Silverlight) можно сразу же смотреть видео в интернете. Для разработчиков тоже хлопот мало, по минимуму можно просто выложить видео и все будет работать, примерно так:

<video src="pr6.webm" width="320" height="240" controls></video>

А на практике мы получаем нечто другое. Разработчики браузеров не могут договориться насчет кодеков, приходится поддерживать старые браузеры, а потому от Flash/Silverlight все равно не отказаться, в итоге вместо приведенного выше примера получаем нечто, вроде:

<video id="movie" width="320" height="240" preload controls>
  <source src="pr6.webm" type='video/webm; codecs="vp8, vorbis"' />
  <source src="pr6.ogv" type='video/ogg; codecs="theora, vorbis"' />
  <source src="pr6.mp4" />
  <object width="320" height="240" type="application/x-shockwave-flash"
    data="flowplayer-3.2.1.swf"> 
    <param name="movie" value="flowplayer-3.2.1.swf" /> 
    <param name="allowfullscreen" value="true" /> 
    <param name="flashvars" 
        value='config={"clip": {"url": "http://wearehugh.com/dih5/pr6.mp4", "autoPlay":false, "autoBuffering":true}}' /> 
    <p>Download video as <a href="pr6.mp4">MP4</a>, <a href="pr6.webm">WebM</a>, or <a href="pr6.ogv">Ogg</a>.</p> 
  </object>
</video>
<script>  var v = document.getElementById("movie");
  v.onclick = function() {    if (v.paused) {
      v.play();    } else {
      v.pause();
    }
  };
</script>

Все дело в том, что нет ни одной пары кодека с контейнером, который поддерживался бы всеми браузерами (можно посмотреть, например, страничку HTML5 video на wikipedia). Итого, если вы раньше отображали видео при помощи flash, то, если захотите переходить на HTML5 тег video, то вам все равно придется конвертировать видео для флеш, и поддерживать этот плеер, чтобы поддерживались старые браузеры. К тому же, при использовании тега video, не обойтись конвертацией видео в один формат, нужно использовать несколько, чтобы поддерживать все браузеры.

Итого, если вы владеете видео сервисом, то нужно настроить автоматизацию по конвертированию видео в несколько форматов (да еще, наверное, с разными размерами), поддерживать два плеера: flash (or Silverlight) и Html 5. Но профит будет, хотя бы для пользователей устройств iPad, так как эти устройства не поддерживают ни flash, ни Silverlight (если не ошибаюсь, если ошибаюсь, то можно привести и другое устройство в пример).

В общем-то, особо я даже и не знаю, что рассказывать про этот тег. Будем только надеяться на светлое будущее.

Geolocation

Вещь, конечно, требующая специфичных задач. Один из примеров, где используется геолокация – это twitter (по крайней мере, я раньше это видел, сейчас почему-то не смог включить ее). Там вы можете добавлять к своим твиттам еще и информацию о том, где вы находитесь. Да, идея геолокации – это определение вашего местоположения (и не только, например, еще и скорость, и высоту). Понятное дело, что в случае использования ноутбука (подключенного к домашнему wifi роутеру) или стационарного компьютера точность определения будет очень низкой (хорошо, если город правильно определит), так как определить ваше местоположение можно только по IP адресу. В принципе, ничем не будет отличаться от использования базы масок IP адресов (Geo IP) – старого проверенного способа. Другое дело, если это мобильное устройство, подключенное, например, через GSM сети, то по ближайшим вышкам точность определения уже будет значительно выше (хорошо, если квартал правильно определит), а вот если устройство даст доступ к GPS (если имеется), то это будет другое дело, можно будет даже определять скорость передвижения (чтобы предупредить, что твитты писать во время движения плохо, ибо можно встретиться со столбом).

Политика у всех браузеров сейчас одинаковая, не давать доступ к методам определения положения, пока пользователь не даст на это добро. Потому, если вы у себя на сайте внедрите эти методы, не факт что они будут работать, пользователь может не разрешить их использование. Вопрос пользователю будет в немодальном диалоге, поэтому браузер не будет блокировать возможность дальше работать с сайтом. В связи с этим запросы являются асинхронными:

function get_location() {
  navigator.geolocation.getCurrentPosition(show_map);
}
 function show_map(position) {
  var latitude = position.coords.latitude;
  var longitude = position.coords.longitude;
  // let's show a map or do something interesting!
}

Из переменной position так же можно получить множество других данных (какие именно можно посмотреть в спецификации).

И давайте определимся, GeoIP (база масок IP адресов) остается нашим главным инструментом для сайтов, когда мы хотим помочь пользователю в регистрации, перенаправлении на магазин, который специфичен для его местоположения. А вот geolocation будем использовать только для сайтов-сервисов, где местоположение является одной из опор уникальности (ну или просто идеи) вашего сервиса, и для сайтов, где у нас большой процент возвращений пользователей (чтобы это было хоть оправдано).

Local Storage

Считаю одной из самых лучших фич в HTML5. Сколько раз я натыкался на проблемы, когда где-то заполняю информацию, потом нажимаю Save, а у меня интернет отвалился (или хуже что-то на сервере отвалилось, как раньше с gotdotnet бывало). Или сидишь, скорчившись в аэропорту, заполняешь что-то, и вот тянешься к другой вкладке или избранному, чтобы открыть какое-то окно, откуда хочется что-то вставить в форму. И для этого всего используешь супер удобный трекпад, и вот в какой-то момент случайно нажимаешь на закрыть браузер или закрыть таб со страницей, где было что-то заполнено и не сохранено. Сколько злости у меня в этот момент копится. В общем, думаю, проблема понятна, а так же понятно как можно это применить. Я так же у себя на сайте добавил эту фичу. Чтобы просто сохранялся комментарий, пока его не отправили на сервер. То есть вы можете теперь без проблем начать писать комментарий, потом закрыть вкладку, вернуться и продолжить допиливать свой комментарий. Делается это уж очень легко, у меня примерно так (используется jQuery):

$(document).ready(function () {
    try {
        if (Modernizr.localstorage) {
            var savedComment = localStorage[document.URL + "_commentBody"];
            if (savedComment != null) {
                $("#commentBody")[0].value = saved;
            }            $("#commentBody").bind('keyup', function () {
                localStorage[document.URL + "_commentBody] = this.value;
            });
        }
       
    }    catch(e) {}
}

Ну и не забываем после добавления комментария удалить из local Storage:

if (Modernizr.localstorage) {
    localStorage.removeItem(document.URL + "_commentBody");
}

В local Storage все хранится как строки, потому будьте с этим очень аккуратны. Так, например, если выполнить этот код:

localStorage["key"] = null;
var storedValue = localStorage["key"];

В переменной storedValue после выполнения кода будет храниться строковое значение “null”.

Понятное дело, что localStorage ограничен по размеру, но можно просить у пользователя больше под нужды. Можно еще подписываться на изменения localStorage, следить за тем были ли изменения. Это удобно, например, для того чтобы в случае открытия пользователем несколько окон следить за тем заполнена ли корзина (если интернет магазин), чтобы отображать актуальную информацию на каждой странице.

Кроме localStorage, есть еще и sessionStorage (это, наверное, больше подходит для корзины).

Offline

Еще одна интересная возможность – это возможность работы с сайтом в offline режиме. Для этого нужно создать файл манифест и указать его на странице следующим образом:

<!DOCTYPE HTML><html manifest="/cache.manifest">
<body>
...
</body>
</html>

Сам файл cache.manifest может выглядеть следующим образом:

CACHE MANIFEST
NETWORK:
/tracking.cgi
CACHE:
/clock.css
/clock.js
/clock-face.jpg

Этот манифест говорит о том, что совместно с самой страницей, которую мы только что открыли, будут закешированы файлы из секции CACHE, а вот файлы по URL, описанных в NETWORK, кешировать не нужно. В следующий раз, когда мы захотим открыть эту страницу, а интернет соединения не будет, мы увидим закешированную страницу.

Есть еще один специальный пример, который везде рассматривают:

CACHE MANIFEST
CACHE:
/clock.css
/clock.js
/clock-face.jpg
FALLBACK:
/ /offline.html
NETWORK:
*

Тут на самом деле описаны не пути уже в секциях, а паттерны (имею ввиду в секциях FALLBACK и NETWORK). В секции FALLBACK описано, что для URL, удовлетворяющих URL паттерну “/”, если страницы не закешированы, должна отобразится страница offline.html (ранее закешированная). Так же в секции NETWORK просто описано, что все ресурсы, которые не указаны в секции CACHE, должны грузиться в онлайн режиме. То есть при заходе на страницы у нас они будут кешироваться, когда у нас не будет интернет соединения, мы сможем без проблем открыть эти страницы. Если мы будем заходить на другие страницы сайта, на которых мы не были в онлайн режиме, то нам отобразится страница offline.html.

Так же есть небольшой API, при помощи которого можно следить за состоянием, когда кеш начинает загружаться, когда заканчивает. Так же можно узнать находится ли страница в online или offline режиме.

Давайте теперь попробуем подумать, когда нам хорошо это было бы применять. Первая мысль, я могу так же закинуть этот кеш на каждую страницу со статьей, то есть, если пользователь потом откроет мой сайт, когда будет offline, то сможет посмотреть статью. Вроде плюс. С другой стороны, есть куча пользователей, которым мы просто забьем кеш нашей страницей, на которую он может больше никогда и не зайдет. Предположим, что 50% сайтов сделают у себя такие offline режимы, как же замучается браузер записывать все это по кешам, и как же будут пользователи не довольны, что мы будем забивать кеш всякой фигней (конечно браузер будет сам чистить из кеша страницы, которые там залежались и не используются, но все же). Нет, мне все-таки кажется, что следует использовать эту фичу только в том случае, когда она действительно нужна, и пользователь знает, что она существует. В паре с localStorage они нам могут дать полноценное offline приложение, которым можно пользоваться, например, в самолете. Одно время в Google Reader было такое, можно было загружать ленты и работать потом в offline режиме с ним (правда, реализовано там было не через фичу HTML5, а через Google Gears). По моему мнению, использовать это нужно только для enterprise порталов и сервисов, которым это действительно нужно. Ну и мне кажется, что замучаются программисты это все сопровождать и отлаживать, но кто знает, может быть на деле все немного проще, чем кажется.

Формы

Тут просто пойду по списку. В общем-то, Internet Explorer 9 обломал нас, в нем ничего, вроде, не поддерживается, потому пока про эти новые элементы можно позабыть.

Placeholder – текст, который отображается на форме ввода, когда ничего еще не введено. Это то самое, что делается при помощи JavaScript, теперь можно реализовать при помощи простого атрибута:

<input type="text" placeholder="Input Name" />

Autofocus. Можно указать какой-нибудь форме этот атрибут, чтобы после загрузки туда установился фокус. Не поддерживается большинством браузеров, проще написать JavaScript на onload:

$get("inputForm").focus();

вместо

<input type="text" autofocus />

Появились новые типы для input полей, такие как color, search, email, url, number, range. Последние 4 очень полезны для мобильных устройств, чтобы отобразить нужную клавиатуру, так iPhone, вроде, поддерживает уже их все, и отображает специальные клавиатуры для каждого из них. Для search еще нужно подумать, зачем его стоит использовать (может интеграция сразу же с полем для поиска у самого браузера). Еще несколько типов для дат, такие как date, month, week, time, datetime, datetime-local. Из всех браузеров только у Opera есть поддержка, вроде.

Еще появилась в стандарте валидация форм. Есть атрибут required, который можно установить для input элементов. Так же браузеры будут сами валидировать, что в поле email, url и т.п. установлены верные значения (это не избавляет нас от проверки на сервере).

Новые типы можно использовать уже сейчас без проблем, так как тот же Internet Explorer при непонимании, что такое type=”email” просто выставит тип в text, ошибок не будет.

Microdata

О Микроданных на русском можно почитать, например, на странице справки гугла О микроданных для веб-разработчиков. Примеры смотрим там, типы сущностей смотрим тут http://www.data-vocabulary.org/. Идея очень простая – пометить на странице как-то объекты реального мира, такие как человек, мероприятие, адрес и т.п. Понятное дело, что список скорее всего будет со временем пополняться. И никто вас не ограничивает сделать свой тип сущностей. Зачем это? Ну как же, плагины будут без проблем находить на страницу информацию о мероприятии и, например, уметь импортировать их в Outlook.

Ну и под конец делаем две вещи:

а) выставляем на сайт значок HTML5 http://www.w3.org/html/logo/
б) кидаем в избранное ссылку справочник HTML5 Peeks, Pokes and Pointers

@outcoldman