Книги html5 – Книги и учебники по веб-дизайну и веб-программированию. Скачать бесплатно, читать онлайн. Язык разметки HTML. CSS

Бесплатная книга «HTML5. Руководство разработчика» / Издательский дом «Питер» corporate blog / Habr

ХО-ХО-ХО! Праздник к нам приходит! Всегда coca-co… HTML5!
Выпал снежок и как-то незаметно пришло праздничное, предновогоднее настроение. Чтобы как-то поддержать праздничный дух, мы решили сделать небольшой сюрприз от издательства и порадовать наших читателей бесплатной электронной книгой Марка Пилгрима «HTML5. Руководство разработчика» (DIVE INTO HTML5). Оригинал книги также есть в бесплатном варианте в Интернете.

Прежде чем скачать книгу целиком, предлагаем вам познакомиться с первой главой:

Приступим

Недавно я прочел высказывание одного разработчика для платформы 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 уже включены заголовки-запросы для переговоров о содержимом, то есть то самое «может быть, когда-нибудь» наступило довольно скоро.

Тони так заканчивает свое письмо:

Я рассматривал и следующую альтернативу:

<A HREF="..." INCLUDE>См. фотографию

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

Через несколько часов после сообщения Тони ему и Марку ответил Тим Бернерс-Ли (Tim Berners-Lee):

Я полагал, что картинки можно представлять в виде Картинка. Значение ссылочных отношений таково:

EMBED — встроить содержимое в данное место документа для отображения;
PRESENT — отображать содержимое, если исходный документ доступен.

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

Это предложение не было реализовано, но атрибут rel существует до сих пор (см. раздел «Элемент HEAD» главы 3).
Джим Дэвис (Jim Davis) прибавил:

Хорошо бы еще иметь возможность указывать тип содержимого, например, так:

Однако я, конечно, надеюсь дожить до того времени, когда тип содержимого будет строго определяться по расширению файла.

Это предложение тоже не было реализовано, хотя позднее Netscape стал поддерживать встраивание произвольных мультимедийных объектов с помощью тега .

Джей Вебер (Jay C. Weber) написал следующее:

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

Марк Андрессен ответил:

Это не альтернатива предстоящему использованию MIME-типов как стандартного механизма обработки документов . Это простая реализация функциональности, которая нужна независимо от MIME .

Джей Вебер возразил:

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

Опыт свидетельствует, что беспокойство Джея было вполне обоснованным. Прошло, правда, больше недели, но в HTML5 появились теги </code>и <code><audio></code>. В ответ на первое письмо Джея Дейв Рэггет (Dave Raggett) написал: <blockquote> Совершенно правильно! Собираюсь рассмотреть множество графических и псевдографических типов в связи с механизмом переговоров о формате . Замечание Тима о поддержке активных областей на картинках тоже учту . </blockquote> В том же 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 году Марк ответил Дейву так: <blockquote> Может быть, стоило бы действительно задуматься о графическом процедурном языке общего назначения, возможности которого позволили бы присоединять произвольные гиперссылки к значкам, картинкам, тексту и т . д .? Не известно ли кому-нибудь из подписчиков, как с этим обстоит дело в проекте Intermedia? </blockquote> Intermedia — это гипертекстовый проект Брауновского университета. Работа над ним велась в 1985–1991 годах. Рабочей средой для Intermedia была операционная система A/UX — UNIX-подобная среда, функционирующая на компьютерах Macintosh первых поколений. Мысль о «графическом процедурном языке общего назначения» впоследствии прижилась. Современные браузеры поддерживают как SVG-графику (декларативную разметку со встроенной возможностью разработки сценариев), так и <code><canvas></code> (процедурный интерфейс непосредственного программирования графики). Правда, исторически <code><canvas></code> был проприетарным расширением для браузера и рабочая группа WHAT внесла его в спецификацию постфактум. Билл Дженсен (Bill Janssen) сообщил: <blockquote> Функциональность, о которой вы говорите, действительно очень ценна . Кроме Intermedia, есть другие системы, в которых она реализована: Andrew и Slate . В основе Andrew лежит система вставок . Каждой вставке присвоен определенный тип: текст, растровое изображение, векторное изображение, анимация, электронное письмо, таблица и др . Реализовано рекурсивное вложение произвольной глубины, то есть вставка любого типа может быть вложена во вставку любого из типов, поддерживающих вложение. Так, например, можно поместить вставку в тексте после любого символа (если мы работаем с текстовым окном), в любой прямоугольной области (если мы работаем с графикой), в любой ячейке (если мы имеем дело с таблицей). </blockquote> Andrew — сокращенное название системы пользовательского интерфейса Andrew. Ее в те годы все называли Andrew Project. Тем временем Томас Файн (Thomas Fine) выдвинул альтернативное предложение: <blockquote> Я думаю так . Работу с изображениями в Сети лучше всего построить на системе MIME-типов. А формат Postscript, для которого наверняка уже существует особый тип, как раз позволяет совмещать текстовую и графическую информацию с большим удобством . «Но в нем ведь не будут работать гипертекстовые ссылки», — скажете вы . Да, это так . Однако мне кажется, что проблему решает технология Display Postscript . Если и нет, то дополнить до этого стандартный Postscript — легкая задача . Определим команду-якорь, которая бы содержала URL и интерпретировала текущий контур как замкнутую область-кнопку . Поскольку в Postscript предусмотрена прорисовка контуров, это позволяет легко делать кнопки произвольной формы . </blockquote> Display PostScript — технология экранной прорисовки, совместно разработанная Adobe и NeXT. Это предложение не было реализовано. До сих пор, впрочем, время от времени озвучивается мысль о том, что для улучшения языка HTML надо его просто чем-нибудь заменить. 2 марта 1993 года Тим Бернерс-Ли оставил такой комментарий: <blockquote> В HTTP2 документам разрешено нести любой MIME-тип, понимаемый клиентской программой, а не только какой-либо один из зарегистрированных . Это оставляет пространство для экспериментов . Думаю, Postscript с поддержкой гипертекста мог бы стать предметом таких экспериментов . Не знаю, достаточно ли функциональности у Display Postscript, но мне известно, что компания Adobe сейчас активно продвигает свой формат PDF на основе Postscript . В документах этого формата будут работать гиперссылки, но просматривать такие документы можно будет только в проприетарных программах Adobe. Я полагал, что обобщенный язык якорей (на основе HyTime?) позволит гипертекстовым и мультимедийным (графика/видео) стандартам развиваться независимо, что пойдет на пользу и тем и другим. Пусть лучше будет тег не IMG, а INCLUDE, который бы ссылался на документы произвольного типа . Или EMBED, если INCLUDE звучит как директива C++ и будут ошибочно думать, что нужен исходный SGML-код, который браузер будет разбирать (мы имеем в виду не это) . </blockquote> HyTime — это одна из ранних гипертекстовых систем документов, основанная на разметке SGML. В обсуждениях стандартов HTML и затем XML в 1990-е годы о ней часто вспоминали. Предложенный Тимом тег <INCLUDE> так никогда и не появился, хотя отголоски этой идеи можно наблюдать в тегах <code><object></code>, <code><embed></code> и <code><iframe></code>. Наконец 12 марта 1993 года Марк Андрессен написал в той же ветви дискуссии: <blockquote> Вернусь к теме встроенных изображений . Приближается выпуск Mosaic v0 .10, в котором будет оговоренная ранее поддержка растровых изображений форматов GIF и XBM в тексте. Поддерживать теги INCLUDE/EMBED мы в настоящее время пока не готовы. Вероятно, сейчас придется остановиться на <code><IMG SRC=" url" > </code>(а не ICON, потому что не всякое изображение, вставленное в текст, можно назвать значком). Пока что встроенные изображения не типизируются явным образом; мы намерены начать поддержку графических типов впоследствии, когда речь зайдет о реализации системы MIME-типов в целом . Используемые нами сейчас алгоритмы чтения изображений определяют формат на лету, так что даже расширение файла не играет никакой роли. </blockquote>

Учебник HTML5

333 260

Web-программирование — Учебник HTML5

С первого взгляда можно предположить, что HTML5 — это пятая версия языка HTML для создания веб-страниц. Но в действительности все не так просто.

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

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

Разобраться в HTML5 — задача не из легких. Самой большой проблемой является то обстоятельство, что термин «HTML5» используется для обозначения свыше дюжины отдельных стандартов. (Как мы узнаем, эта ситуация является результатом эволюции HTML5, который начинался как единый стандарт, но впоследствии был разделен на более управляемые части.)

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

Теоретический материал:

• 1. Введение в HTML5

• 2. Веб-формы

• 3. Аудио и видео

• 4. Canvas

• 5. Web Storage API и File API

• 6. Автономные приложения

• 7. Взаимодействие с веб-сервером

• 8. Geolocation API, Web Workers и другие средства

HTML5 и CSS3

1. Краткая история разметки 6
От IETF до W3C: путь к HTML 4 7
XHTML 1 : HTML по правилам XML 8
XHTML 2: терпению пришел конец 9
Раскол: WHATWG TF? 10
От веб-приложений 1.0 к HTML5 11
Объединение 12
XHTML умер: да здравствует синтаксис XHTML 13
Развитие HTML5 14

2. Устройство HTML5 15
Принципы устройства 16
Ближе к реальности 17
Обработка ошибок 18
Доктайп, скажите честно, я буду жить? 19
Будем проще 20
Синтаксис: размечайте, как хотите 21
Мы так не разговариваем 23
Было приятно познакомиться, чао 23
Перемен, мы ждем перемен! 25
Анонимная цитата 25
Элемент а на стероидах 26
Новые игрушки! API JavaScript 27

3. Мультимедиа 28
Canvas 29
Танец вокруг архитектуры: как рисовать с помощью кода 30
Canvas. Ага! И для чего он нужен? 31
Доступ запрещен 31
Умный Canvas 32
Audio 34
Вырваться из-под контроля 35
Буферизация 36
Его вам сразу включат, а может быть, включат 36
Запасной вариант 37
Доступ на все уровни 38
Video 39
Нативный режим 40

4. Веб-формы 2.0 42
Placeholder 43
Autofocus 44
Required 45
Autocomplete 46
Datalist 47
Типы полей ввода 49
Поиск 49
Контакты 49
Ползунки 50
Проверка 51
Счетчики 51
Дата и время 52
Выбор цвета 53
Сделай сам 54
В ожидании будущего 55

5. Семантика 56
Расширяемость 57
Микроформаты 57
Вскипятить океан 57
Новые элементы 59
mark 59
time 59
meter 60
progress 60
Структура 61
section 61
header 61
footer 62
aside 62
nav 63
article 63
Лекарство от избытка дивов? 64
Модели содержимого 66
Содержимое, разбивающее на секции 66
Алгоритм содержания 67
hgroup 68
Корневые элементы разделов 69
Переносимость 69
Локальные стили 70

6. Использование HTML5 сейчас 71
Стили 72
Заголовки 72
Aria 74
Валидация 75
Тестирование функций 76
Выберите собственную стратегию 77
Ресурсы 77
Включайтесь! 78
Будущее 79
Об авторе 80

Книга «HTML5 и CSS3. Веб-разработка по стандартам нового поколения»

Добавить

• Читаю
• Хочу прочитать
• Прочитал

Брайан П. Хоган

Жанр: Интернет

ISBN: 978-5-496-00979-9, 978-1937785598

Год издания: 2013

Издательство: «Питер»

Фрагмент книги

Оцените книгу

Скачать книгу

1287 скачиваний

Читать онлайн

1 планируeт прочитать

О книге «HTML5 и CSS3. Веб-разработка по стандартам нового поколения»

HTML5 и CSS3 – будущее веб-разработки, но не обязательно ждать будущего, чтобы начать применять эти стандарты уже сегодня. Хотя спецификации этих языков еще находятся в разработке, большинство современных браузеров и мобильных устройств поддерживают HTML5 и CSS3. Эта книга поможет вам использовать HTML5 и CSS3 прямо сейчас, применяя все богатые возможности, появившиеся в новых веб-стандартах. Вы научитесь применять новую разметку HTML5, разрабатывать улучшенные интерфейсы для форм ввода данных, узнаете, как добавлять аудио, видео и векторную графику на веб-страницы без использования Flash. Вы увидите, как хранение данных на стороне клиента в автономном режиме кэширования может кардинально улучшить скорость загрузки веб-страниц и как в этом помогают простые решения, доступные в CSS3. Каждый раздел книги сопровождается многочисленными примерами, а для каждой описанной функции читателю предстоит создать небольшой учебный пример. Второе издание содержит обновленную информацию по использованию HTML5 и CSS3; здесь представлена более подробная информация о средствах доступности HTML5 и описан ряд новых подходов, обходных решений и рецептов.

На нашем сайте вы можете скачать книгу «HTML5 и CSS3. Веб-разработка по стандартам нового поколения» Брайан П. Хоган бесплатно и без регистрации в формате fb2, rtf, epub, pdf, txt, читать книгу онлайн или купить книгу в интернет-магазине.

Отзывы читателей

Подборки книг

Похожие книги

Информация обновлена: 16.05.2019

Читать онлайн «HTML5 для веб-дизайнеров» автора Джереми Кит — RuLit

Когда мы с Мэнди Браун и Джейсоном Санта-Мария организовали издательство A Book Apart, мы считали особенно животрепещущей одну конкретную тему, и был только один автор, который мог бы с ней справиться.

Ни одна другая тема, ни «полноценные шрифты», ни CSS3, не волнуют сообщество разработчиков, работающих по стандартам, больше, чем неминуемое появление HTML5. Эта новая вариация общего языка веба, зародившаяся из-за неудовлетворенности медленным темпом развития и консервативной политикой W3C, задуманная для Сети, состоящей из приложений (а не только документов), – в равной мере воодушевляет, злит и запутывает сообщество веб-разработчиков.

У Джереми Кита есть уникальная способность разъяснять HTML5 и писать сразу о том, что имеет значение для дизайнеров/разработчиков, стремящихся делать доступный для технологий специальных возможностей и основанный на стандартах дизайн. Джереми уже предельно доступно описал DOM и JavaScript и делает то же самое в этой книге, в которой ровно столько слов и иллюстраций, сколько необходимо.

О HTML5 есть другие книги, а будет их гораздо больше. Появятся написанные техническим языком пятисотстраничные книги для разработчиков приложений, потребности которых во многом стимулировали развитие HTML5. Будут и еще более объемные книги – для разработчиков браузеров, в которых будут даваться решения технических проблем, о которых – хвала небесам! – нам с вами никогда не придется думать.

Но эта книга для вас – человека, который создает контент для веба, который делает осмысленную, семантическую разметку веб-страниц, который разрабатывает доступные для технологий специальных возможностей интерфейсы. Можно назвать эту книгу инструкцией по использованию HTML5. Ее цель – как и всех книг, которые выходят в каталоге A Book Apart, – пролить ясный свет на запутанный предмет, и сделать это быстро, чтобы вы могли сразу вернуться к работе.

Джеффри Зельдман

1. Краткая история разметки

HTML – связующий язык Всемирной паутины. С помощью простых тегов, которые содержит этот язык, род человеческий сумел создать ошеломительно разнообразную сеть документов, связанных между собой гиперссылками – от Amazon, eBay и Wikipedia до личных блогов и страничек, посвященных котикам, похожим на Гитлера.

HTML5 – последняя на данный момент итерация этого лингва-франка, и хотя это и самое амбициозное изменение в нашем Всеобщем Наречии, но обновляется HTML не впервые. Язык начал развиваться с самого начала.

Как и собственно веб, гипертекстовый язык разметки (HyperText Markup Language, HTML) был детищем сэра Тима Бернерса-Ли, который в 1991 году составил документ под названием HTML Tags, предложив в нем около 20 элементов, которые можно было использовать для написания веб-страниц.

Не сэр Тим придумал использовать теги, состоящие из слов в угловых скобках; такие теги уже существовали в формате SGML (Standard Generalized Markup Language, стандартный обобщенный язык разметки). Вместо того чтобы изобретать новый стандарт, сэр Тим увидел все преимущества того, чтобы разрабатывать язык как надстройку к уже существующему стандарту, – эта тенденция заметна и сейчас, в разработке HTML5.

От IETF до W3C: путь к HTML 4

Такой вещи, как HTML 1, никогда не было. Первой официальной стала спецификация HTML 2.0, опубликованная IETF (Инженерный совет Интернета, Internet Engineering Task Force). Многие из пунктов появились в этой спецификации потому, что они уже существовали на практике. Например, лидировавший на рынке веб-браузер Mosaic уже в 1994 году позволял авторам веб-страниц вставлять в документы картинки с помощью тега <img>. Впоследствии элемент img появился в спецификации HTML 2.0.

На смену IETF пришел W3C, Консорциум Всемирной паутины (World Wide Web Consortium), который публиковал последующие обновления стандарта HTML на сайте http://www.w3.org. Во второй половине девяностых появился целый шквал исправлений в спецификации, пока в 1999 году не была наконец опубликована спецификация HTML 4.01.

В этот момент HTML подошел к своей первой развилке.

XHTML 1: HTML по правилам XML

Следующая после HTML 4.01 версия языка называлась XHTML 1.0. «X» означало «экстремальный», и каждый веб-разработчик, когда начинал произносить название языка, был строго обязан скрещивать руки в форме буквы «Х».

Ладно, на самом деле нет. «X» значило eXtensible, «расширяемый», а скрещивать руки, в общем, было необязательно.

Содержимое спецификации XHTML 1.0 было совершенно идентично спецификации HTML 4.01. Не было добавлено никаких новых элементов и атрибутов. Единственная разница заключалась в синтаксисе языка. Если HTML давал авторам большую свободу в том, как писать элементы и атрибуты, то XHTML требовал следовать правилам XML, гораздо более строгого языка разметки, на основе которого W3C строил большинство своих технологий.