Руководство разработчика by Марк Пилгрим. Кратко описываются новые стандарты HTML5. Популярные за год. HTML5-руководство по новым конструкциям Здесь, в Вебвилле, мы недавно. Цель здесь заключалась в том, чтобы дать вам, опытному разработчику,.

1. Марк Пилгрим Html5. Руководство Разработчика
2. Html5. Руководство Разработчика
3. Html 5. Руководство Разработчика

Марк Пилгрим Html5. Руководство Разработчика

Любой специалист не только работает, гребет деньги лопатой и отдыхает на Бали, но еще и учится, систематизирует накопленные знания и опыт. Причем на 90% процесс обучения - это самообучение через чтение книг, журналов, спецификаций или другой технической литературы, через общение с коллегами, в том числе и на тематических форумах, чтение блогов и RSS-лент. Ну, и, конечно практический опыт, личные наработки.

И тем не менее, чтобы что то изучить системно нужно придерживаться традиций и изучать сначала теорию, а уже затем осваивать практику. В этом лучше всего помогают книги. Недавно, обшаривая интернет с целью найти крупицы полезной информации, я наткнулся на интересную книгу Марка Пилгрима (специалиста по поддержке разработчиков Google) ' HTML5. Руководство разработчика', которая на момент написания статьи доступна для скачивания. Оглавление книги: Глава 1.

Как мы сюда попали? Приступим MIME-типы Большое отступление о том как появляются стандарты Не отрывая карандаша Основные вехи развития HTML в 1997-2004 годах Все, что вы знаете об XHTML, - это ложь Альтернативная точка зрения WHAT? И снова W3C Послесловие Для дальнейшего изучения Глава 2. Тестирование функций HTML5 в браузере Приступим Способы тестирования браузера Modernizr: библиотека для тестирования HTML5-функций Холст Рисование текста Видео Форматы видео Локальное хранилище Фоновые вычисления Офлайновые веб-приложения Геолокация Типы полей ввода Подсказывающий текст Автофокусировка в формах Микроданные Для дальнейшего изучения Глава 3. Что все это значит? Приступим Определение типа документа Корневой элемент Элемент HEAD Кодировка символов Ссылочные отношения Новые семантические элементы HTML5 Большое отступление о том, как браузеры обрабатывают незнакомые элементы Верхние колонтитулы Рубрикация Дата и время Навигация Нижние колонтитулы Для дальнейшего изучения Глава 4.

С чистого листа(холста) Приступим Простые формы Координатная сетка холста Контуры Текст Градиенты Изображения А что в IE? Живой пример Для дальнейшего изучения Глава 5.

Видео в Сети Приступим Видеоконтейнеры Видеокодеки H.264 Theora VP8 Аудиокодеки MPEG-1 Audio Layer 3 Advanced Audio Config Vorbis Что работает в Интернете? Проблемы лицензирования видео H.264 Кодирование Ogg-видео с помощью ffmpeg2theora Кодирование H.264-видео с помощью HandBrake Кодирование WebM-видео с помощью программы ffmpeg.И наконец разметка А что в IE? Живой пример Для дальнейшего изучения Глава 6.

Вот мы вас и нашли! Приступим API геолокации Покажите мне код Обработка ошибок Требую выбора! На помощь спешит geo.js Живой пример Для дальнейшего изучения Глава 7. Локалькое хранилище: прошлое, настоящее, будущее Приступим Краткая история прототипов локального хранилища до HTML5 HTML5-хранилище: вводный курс Использование HTML5-хранилища Следим за состоянием HTML5 - хранилища Ограничения в современных браузерах HTML5-хранилище в действии Альтернативы: хранилище без ключей и значений Для дальнейшего изучения Глава 8.

На волю, в офлайн! Приступим Манифест кэша Раздел NETWORK Раздел FALLBACK Поток событий 'Убей меня поскорее!' Строим оффлайновое приложение Для дальнейшего изучения Глава 9. Веб-формы как форма безумия Приступим Подсказывающий текст Поля с автофокусировкой Адреса электронной почты Веб-адреса Числа как счетчики Числа как ползунки Выборщики даты Форма поиска Выборщики цвета И еще об одной вещи Для дальнейшего изучения Глава 10. Микроданные и другие красивые слова Приступим Что такое микроданные?

Структура микроданных Разметка данных о человеке Разметка данных об организации Разметка данных о событии Разметка клиентских отзывов Для дальнейшего изучения Приложение. Универсальный почти алфавитный определитель всего на свете Элементы Для дальнейшего изучения После прочтения книги у меня остались только приятные впечатления, во-первых, радует, что автор фактически начинает книгу, раскрывая основы тестирования HTML5 кода. Кроме того в книге разобрано множество типовых ситуаций, поясняющих особенности работы HTML5 с различными объектами на веб-странице. Книга будет полезна как начинающему web-разработчику, так и более опытному. Также можно почитать:. К сожалению, у Вас отключен Javascript, включите JavaScript, чтобы испытать комментарии правильно.

Праздник к нам приходит! Всегда coca-co HTML5! Выпал снежок и как-то незаметно пришло праздничное, предновогоднее настроение.

Чтобы как-то поддержать праздничный дух, мы решили сделать небольшой сюрприз от издательства и порадовать наших читателей бесплатной электронной книгой Марка Пилгрима « HTML5. Руководство разработчика» (DIVE INTO HTML5). Также есть в бесплатном варианте в Интернете. Прежде чем книгу целиком, предлагаем вам познакомиться с первой главой: Глава 1. Как мы сюда попали? Приступим Недавно я прочел одного разработчика для платформы Mozilla, где говорится о той напряженности, которая всегда сопутствует разработке стандартов: Спецификация и программная реализация должны пройти путь осторожного совместного развития. Ведь, с одной стороны, не хочется, чтобы реализация появилась раньше, чем выйдет окончательная версия стандарта, иначе разработчики станут принимать во внимание особенности конкретной программы, то есть в дело пойдет лишь фрагмент спецификации.

С другой стороны, не хочется утверждать полный стандарт до выхода хотя бы одной реализации, иначе придется обойтись без обратной связи, в частности, не будут приняты в расчет мнения создателей программ. Противоречие неизбежно. Нам остается решать проблему методом проб и ошибок. Пока я буду рассказывать, как появился HTML5, помните эти слова. MIME-типы Книга, которую вы держите в руках, посвящена HTML5, а не предшествующим версиям стандарта HTML и тем более не XHTML. Но, чтобы ясно проследить историю HTML5 и увидеть причины, предшествующие его появлению, нужно сначала овладеть кое-какими техническими деталями, в частности получить понятие о MIME-типах. Каждый раз, когда ваш браузер пытается загрузить страницу, сервер, прежде чем отослать клиентской программе код самой страницы, отправляет ей ряд заголовков.

Пользователь обычно не видит этих заголовков, хотя в некоторых программах для веб-разработчиков предусматривается возможность их отображения. Заголовки важны постольку, поскольку они сообщают браузеру, как воспринимать код посылаемой вслед за ними страницы. Самый информативный заголовок называется Content-Type и выглядит, например, так: Content-Type: text/html Значение text/html называется типом содержимого, или MIME-типом загружаемой страницы.

Только данный заголовок определяет, каково содержание отдельного ресурса и, следовательно, как этот ресурс должен выводиться на экран. У изображений собственные MIME-типы ( image/jpeg — для картинок в формате JPEG, image/png — для формата PNG и т. Собственными MIME-типами оснащены файлы JavaScript, таблицы стилей CSS и, в общем-то, все, что есть в Сети. На самом деле все чуть сложнее, чем рассказано выше.

Самые ранние веб-серверы, под которыми я понимаю веб-серверы 1993 года и нескольких последующих лет, не отправляли заголовки Content-Type, потому что те были изобретены только в 1994 году. Ради совместимости, во имя которой, кстати, с 1993 года по сей день делалось и делается очень много всего, отдельные популярные браузеры при определенных условиях игнорируют заголовки Content-Type.

Это называется контент-сниффингом. Но общее правило таково, что любой фрагмент содержимого Сети, будь то HTML-страница, изображение, сценарий, видеозапись, PDF-документ или что-то еще под собственным URL-адресом, посылается клиентской программе с предварительным уведомлением о MIME-типе в заголовке Content-Type.

Хорошенько запомните эту информацию, так как она еще пригодится. Большое отступление о том, как появляются стандарты Откуда взялся тег? Не думаю, что вы хоть иногда задавались подобным вопросом. Очевидно, кто-то его создал. Такие вещи не берутся ниоткуда.

Из всех элементов и атрибутов HTML, которыми вы в разное время пользовались, абсолютно каждый был когда-то кем-то создан. Этот кто-то придумал, как должен работать элемент или атрибут, и письменно сформулировал свои мысли. Такого рода люди, бесспорно, умнее нас с вами, но они тоже обычные люди.

Если стандарт разрабатывался открыто, то можно вернуться в прошлое и увидеть, как рождалась идея того или иного пункта спецификации. Обсуждения ведутся в почтовых рассылках, а их архивы обычно имеют интерфейс поиска. Чтобы ответить на вопрос о теге, я решил немного позаниматься «электронной археологией» и погрузился в толщу времен, когда еще не существовало Консорциума Всемирной паутины (W3C), а все веб-серверы мира можно было пересчитать по пальцам. Речь идет о первых днях Интернета.

25 февраля 1993 года Марк Андрессен (Marc Andreessen): Предлагаю новый опциональный HTML-тег: IMG При нем должен обязательно указываться аргумент SRC=' url'. Тег отсылает к файлу растрового изображения (bitmap или pixmap).

Браузер будет запрашивать этот файл в Сети, распознавать как изображение и вставлять в текст сообразно месту тега в коде страницы. Пример использования: (Закрывающий тег не требуется.) Как и любое другое содержимое, этот тег может быть вложен внутрь якоря.

Тогда изображение станет чувствительным к активизации, как и обычная текстовая ссылка. Следует предоставить браузерам свободу выбора графических форматов, которые будут в них поддерживаться.

Удачным выбором мне представляются, например, Xbm и Xpm. Если браузер не умеет отображать данный формат, пусть он делает то, что разработчикам заблагорассудится предусмотреть на этот случай (так, в X Mosaic будет выводиться растровая картинка, замещающая нужное изображение). Данная функциональность будет реализована в X Mosaic. Мы работаем над ней и собираемся использовать по крайней мере внутри команды разработчиков. Разумеется, я буду рад вашим предложениям по поводу того, каким должен быть механизм поддержки изображений в HTML.

Если у вас появится мысль удачнее моей, поделитесь, пожалуйста. Я знаю, что разнообразие графических форматов делает ситуацию чрезвычайно туманной, но альтернативы не вижу.

Можно разве что сказать: «Пусть браузер работает как умеет» — и ждать той поры, когда будет предложено идеальное решение (может быть, когда-нибудь, с помощью MIME-типов). Эту цитату надо пояснить. Xbm и Xpm — популярные графические форматы в UNIX-системах; Mosaic — один из первых браузеров.

Его версия, которая работала в UNIX-системах, называлась X Mosaic. Когда Марк отправлял это письмо на дискуссионный лист в начале 1993 года, он еще не основал компанию Mosaic Communications Corporation, которая впоследствии принесла ему известность, и еще не начал работу над флагманским продуктом будущей компании — браузером Mosaic Netscape (фирма и программа позже были переименованы в Netscape Corporation и Netscape Navigator соответственно). Говоря о MIME-типах «может быть, когда-нибудь», Марк ссылается на предусмотренный в протоколе HTTP механизм переговоров о содержимом». Благодаря этому механизму клиентская программа-браузер сообщает серверу (в данном случае веб-серверу), какие типы ресурсов она умеет обрабатывать (например, image/jpeg), а сервер в ответ может прислать содержимое в удобном для клиента формате. По состоянию на февраль 1993 года программно реализован только самый первый вариант протокола HTTP (1991 год), в котором клиент не мог передать серверу информацию о поддерживаемых типах изображений. Отсюда проблема, с которой столкнулся Марк.

Несколько часов спустя Тони Джонсон (Tony Johnson) ответил: У меня в Midas 2.0 (программа пока находится во внутреннем пользовании SLAC, но уже готова к открытому релизу) применяется похожее решение. Тег иначе назван, и в нем есть еще один аргумент NAME=' name', но функциональность абсолютно та же, что и у предложенного вами тега IMG.

Пример: Смысл параметра NAME в том, чтобы позволить браузеру прибегать к помощи набора «встроенных» картинок. Если имя соответствует изображению, которым браузер уже располагает, то вместо того, чтобы доставать картинку из Сети, программа использует готовый графический файл. Кроме того, имя изображения может подсказывать текстовым браузерам, каким символом заместить картинку. Меня мало волнуют имена тегов и параметров (но если бы мы решили прийти к компромиссу, они приобрели бы большое значение). Столь же маловажен, по-моему, вопрос об аббревиатурах, то есть почему IMG и SRC, а не IMAGE и SOURCE. Мне самому больше по душе ICON — это слово дает понять, что картинка должна быть маленькой, вроде значка.

Готов признать, впрочем, что слово ICON итак уже обременено множеством смыслов. Midas — это еще один ранний браузер, современник X Mosaic.

Он был кросс-платформенным и работал как в UNIX, так и в VMS. Аббревиатура SLAC расшифровывается как Stanford Linear Accelerator Center (Научно-исследовательский центр при Стэнфордском линейном ускорителе (электронов)). Теперь этот центр получил статус национальной лаборатории.

Инженеры SLAC запустили первый веб-сервер в США, который фактически был и первым за пределами Европы. В феврале 1993 года SLAC считался долгожителем Сети (работал год и три месяца!) с пятью веб-страницами на сервере. Вот продолжение письма Тони: Раз уж мы заговорили о новых тегах, то расскажу о другом аналогичном теге, поддержку которого я намерен реализовать в Midas 2.0. Его схема такова: В код документа в месте вхождения этого тега должен быть вставлен другой документ, на который ссылается тег.

Этот документ может быть чем угодно по типу содержания, но основная задача тега — обеспечить вставку изображений произвольного размера в веб-страницы. Когда будет реализован HTTP2, клиент и сервер смогут дополнительно оговаривать формат вставляемого документа.

Под названием HTTP2 здесь фигурирует базовый HTTP в редакции 1992 года. В начале 1993 года значительная его часть не имела программной реализации. Черновой вариант, известный как HTTP2, после некоторой доработки был стандартизован в качестве HTTP 1.0.

В стандарт HTTP 1.0 уже включены заголовки-запросы для переговоров о содержимом, то есть то самое «может быть, когда-нибудь» наступило довольно скоро. Тони так заканчивает свое письмо: Я рассматривал и следующую альтернативу: См. фотографию Не хочется прибавлять новую функциональность тегу. Но такое решение было бы удобно для совместимости с браузерами, которые не понимают параметр INCLUDE. Иными словами, если браузер распознает команду INCLUDE, то он заменит текст ссылки («См. Фотографию» в данном случае) картинкой, а более старый или более глупый браузер просто проигнорирует INCLUDE.

Это предложение не было реализовано, хотя идея заместительного текста на случай, если изображение отсутствует, очень привлекательна и не упоминается в предложенной Марком конструкции тега. Много лет спустя идея была осуществлена в атрибуте (после чего все испортил Netscape, который ошибочно отображал текст-заместитель в виде всплывающей подсказки). Через несколько часов после сообщения Тони ему и Марку ответил Тим Бернерс-Ли (Tim Berners-Lee): Я полагал, что картинки можно представлять в виде Картинка. Значение ссылочных отношений таково: EMBED — встроить содержимое в данное место документа для отображения; PRESENT — отображать содержимое, если исходный документ доступен.

Стоит отметить, что возможны разные сочетания атрибутов. Если браузер не поддерживает какой-то один из них, сбоя не будет. Понятно, что для создания таким способом значков, чувствительных к пользовательскому выбору, нужно вложить один якорь в другой. Но, честно говоря, я не хотел бы вводить особый тег.

Это предложение не было реализовано, но атрибут rel существует до сих пор (см. Раздел «Элемент HEAD» главы 3). Джим Дэвис (Jim Davis) прибавил: Хорошо бы еще иметь возможность указывать тип содержимого, например, так: Однако я, конечно, надеюсь дожить до того времени, когда тип содержимого будет строго определяться по расширению файла. Это предложение тоже не было реализовано, хотя позднее Netscape стал поддерживать встраивание произвольных мультимедийных объектов с помощью тега. Джей Вебер (Jay C. Weber) написал следующее: Отображение графики в браузерах — моя давняя мечта.

Но неужели для каждого вида мультимедийной информации надо создавать персональный тег? Еще недавно все с радостью ожидали появления механизма MIME-типов. Что же случилось теперь? Марк Андрессен ответил: Это не альтернатива предстоящему использованию MIME-типов как стандартного механизма обработки документов. Это простая реализация функциональности, которая нужна независимо от MIME.

Html5. Руководство Разработчика

Джей Вебер возразил: Забудем на время о MIME-типах, они отвлекают от сути. Я, собственно, не согласен с вашим подходом к поддержке встроенных изображений, ведь можно ожидать, что на следующей неделе кто-нибудь предложит новый тег для звуковых файлов. Между тем за использование единого для всех медийных типов способа встраивания пришлось бы платить не такой уж и дорогой монетой. Опыт свидетельствует, что беспокойство Джея было вполне обоснованным.

Прошло, правда, больше недели, но в HTML5 появились теги. В ответ на первое письмо Джея Дейв Рэггет (Dave Raggett) написал: Совершенно правильно! Собираюсь рассмотреть множество графических и псевдографических типов в связи с механизмом переговоров о формате. Замечание Тима о поддержке активных областей на картинках тоже учту. В том же 1993 году, но немного позже Дейв опубликовал стандарт HTML+, задуманный им в качестве замены первоначальному HTML. Стандарт не был реализован; на смену HTML пришел ретроспективный HTML 2.0 — формальное описание того аппарата тегов, который на момент принятия стандарта уже широко использовался: «Эта спецификация сводит воедино, уточняет и формально описывает функции из того набора, который приблизительно соответствует возможностям общеупотребительного HTML по состоянию на июнь 1994 года».

Позже на основе спецификации HTML+ Дейв Рэггет создал стандарт HTML 3.0. Нигде, кроме внутренней (используемой W3C в качестве эталона) программы Arena, стандарт HTML 3.0 не был реализован. На смену ему пришел HTML 3.2 — вновь ретроспектива: «Сохраняя полную обратную совместимость с существующим HTML 2.0, стандарт HTML 3.2 добавляет к нему широко распространенные новые функции: таблицы, приложения и обтекание изображений текстом». Еще позже Дейв выступил в качестве одного из соавторов HTML 4.0, разработал HTML Tidy, принимал участие в подготовке XHTML, XForms, MathML и других современных спецификаций W3C. В далеком 1993 году Марк ответил Дейву так: Может быть, стоило бы действительно задуматься о графическом процедурном языке общего назначения, возможности которого позволили бы присоединять произвольные гиперссылки к значкам, картинкам, тексту и т. Не известно ли кому-нибудь из подписчиков, как с этим обстоит дело в проекте Intermedia?

Intermedia — это гипертекстовый проект Брауновского университета. Работа над ним велась в 1985–1991 годах. Форд транзит для омси. Рабочей средой для Intermedia была операционная система A/UX — UNIX-подобная среда, функционирующая на компьютерах Macintosh первых поколений. Мысль о «графическом процедурном языке общего назначения» впоследствии прижилась. Современные браузеры поддерживают как SVG-графику (декларативную разметку со встроенной возможностью разработки сценариев), так и (процедурный интерфейс непосредственного программирования графики). Правда, исторически был проприетарным расширением для браузера и рабочая группа WHAT внесла его в спецификацию постфактум. Билл Дженсен (Bill Janssen) сообщил: Функциональность, о которой вы говорите, действительно очень ценна.

Кроме Intermedia, есть другие системы, в которых она реализована: Andrew и Slate. В основе Andrew лежит система вставок. Каждой вставке присвоен определенный тип: текст, растровое изображение, векторное изображение, анимация, электронное письмо, таблица и др. Реализовано рекурсивное вложение произвольной глубины, то есть вставка любого типа может быть вложена во вставку любого из типов, поддерживающих вложение. Так, например, можно поместить вставку в тексте после любого символа (если мы работаем с текстовым окном), в любой прямоугольной области (если мы работаем с графикой), в любой ячейке (если мы имеем дело с таблицей). Andrew — сокращенное название системы пользовательского интерфейса Andrew.

Html 5. Руководство Разработчика

Ее в те годы все называли Andrew Project. Тем временем Томас Файн (Thomas Fine) выдвинул альтернативное предложение: Я думаю так. Работу с изображениями в Сети лучше всего построить на системе MIME-типов.

А формат Postscript, для которого наверняка уже существует особый тип, как раз позволяет совмещать текстовую и графическую информацию с большим удобством. «Но в нем ведь не будут работать гипертекстовые ссылки», — скажете вы. Однако мне кажется, что проблему решает технология Display Postscript. Если и нет, то дополнить до этого стандартный Postscript — легкая задача.

Определим команду-якорь, которая бы содержала URL и интерпретировала текущий контур как замкнутую область-кнопку. Поскольку в Postscript предусмотрена прорисовка контуров, это позволяет легко делать кнопки произвольной формы.

Display PostScript — технология экранной прорисовки, совместно разработанная Adobe и NeXT. Это предложение не было реализовано. До сих пор, впрочем, время от времени озвучивается мысль о том, что для улучшения языка HTML надо его просто чем-нибудь заменить. 2 марта 1993 года Тим Бернерс-Ли оставил такой комментарий: В HTTP2 документам разрешено нести любой MIME-тип, понимаемый клиентской программой, а не только какой-либо один из зарегистрированных. Это оставляет пространство для экспериментов. Думаю, Postscript с поддержкой гипертекста мог бы стать предметом таких экспериментов.

Не знаю, достаточно ли функциональности у Display Postscript, но мне известно, что компания Adobe сейчас активно продвигает свой формат PDF на основе Postscript. В документах этого формата будут работать гиперссылки, но просматривать такие документы можно будет только в проприетарных программах Adobe. Я полагал, что обобщенный язык якорей (на основе HyTime?) позволит гипертекстовым и мультимедийным (графика/видео) стандартам развиваться независимо, что пойдет на пользу и тем и другим. Пусть лучше будет тег не IMG, а INCLUDE, который бы ссылался на документы произвольного типа.

Или EMBED, если INCLUDE звучит как директива C и будут ошибочно думать, что нужен исходный SGML-код, который браузер будет разбирать (мы имеем в виду не это). HyTime — это одна из ранних гипертекстовых систем документов, основанная на разметке SGML. В обсуждениях стандартов HTML и затем XML в 1990-е годы о ней часто вспоминали. Предложенный Тимом тег так никогда и не появился, хотя отголоски этой идеи можно наблюдать в тегах,. Наконец 12 марта 1993 года Марк Андрессен написал в той же ветви дискуссии: Вернусь к теме встроенных изображений. Приближается выпуск Mosaic v0.10, в котором будет оговоренная ранее поддержка растровых изображений форматов GIF и XBM в тексте.

Поддерживать теги INCLUDE/EMBED мы в настоящее время пока не готовы. Вероятно, сейчас придется остановиться на (а не ICON, потому что не всякое изображение, вставленное в текст, можно назвать значком).

Пока что встроенные изображения не типизируются явным образом; мы намерены начать поддержку графических типов впоследствии, когда речь зайдет о реализации системы MIME-типов в целом. Используемые нами сейчас алгоритмы чтения изображений определяют формат на лету, так что даже расширение файла не играет никакой роли. Метки:. Добавить метки Пометьте публикацию своими метками Метки необходимо разделять запятой. Например: php, javascript, андронный коллайдер, задача трех тел. Хм система оплаты странно работает. Из хрома вообще не захотела.

Расчехлил IE. Ступил видать, не залогинился предварительно, система спросила емайл. Указал ей его.

Оплатил по кредитке — на последнем этапе скрин ушел в пустую страницу. Думал что ничего не прошло (даже вернулся, повторил оплату). Смотрю емайл пришел что все ОК. Вернулся в хром. Не нашел покупки. Посмотрел в IE. Там есть купленная электронная книга.

Теперь у меня 2 одинаковых аккаунта, у одного только приписка вида.ru Квест пройден.