Книги для верстальщика (HTML5 и CSS3)

05 августа 12:48 2012 by admin

Добрый день друзья, в этой публикации я собрал самые популярные книги на тему веб-разработки, вёрстки и программированию.

Я считаю, что любой дизайнер должен уметь верстать, ведь как он будет создавать макеты и интерфейсы сайтов, если понятия не имеют – как оно всё воплощается в жизнь и что надо, чтобы элементы дизайна правильно отображалось в браузере посетителя.

Я сам помимо дизайна, ещё активно верстаю и программирую (JS/jQery в основном, в php не лезу :)), по крайней мере, постоянно обучаюсь в этом направление.

Вы увидите самые популярные книги по веб-разработке в России, на основе данных интернет магазина Ozone.ru, я кстати себе приобрёл парочку.

Эта книга – хорошее руководство по изучению новых технологий CSS3 – сейчас это самые последние технологии, которые используются в веб-дизайне и вёрстке сайтов.

Из книги вы сможете почерпнуть:

• Работе с шрифтами и изображениями, боксами — закруглённые углы, тень и многие другие интересные эффекты CSS3;
• Многоколоночная верстка;
• Анимации средствами CSS — в третьем поколение каскадных таблиц стилей появилось уже возможность создания анимации;
• Различные способы оформления текста;
• Медиа-запросы.

Книга вышла в 2012 году, весной и она стала одной из самых популярных в магазине Ozone по количеству продаж. Я эту книгу рекомендую вам, потому что сам приобрёл себе и она оказалась очень полезной, я её сейчас использую как справочник по функциям CSS.

Ещё одна хорошая книга с уже комплексной темой — работа с HTML5 и CSS3. Эти стандарты взаимно связаны и лучше всего обучаться языкам разметки вместе — изучать и html5, и каскадные таблицы стилей CSS3.

В книге доступно описаны про такие вещи:

• Новый синтаксис и разметку HTML5;
• Работа с видео и графикой средствами HTML5 — новое поколение HTML5 поддерживает работу с векторной графикой, вы сможете делать сайты на подобие Flash, только на много легче и они будут индексироваться поисковыми системами;
• Комплексная работа HTML5 и CSS3, советы и мелкие хитрости.

Книга Брайана Хогана является одним из лидеров по продажам в России и не зря в сети очень много положительных отзывов, мне эта книга тоже очень понравилось, описывается всё доступно и понятно даже новичку.

Дэн Седерхольм — известный американский публицист и веб-разработчик, он издал несколько популярных книг в помощь веб-разработчикам. Самые популярные из них — CSS ручной работы и «Пуленепробиваемый веб-дизайн». Именно вторая и получила самую большую популярность из-за очень простого слога и большого количества примеров в книге.

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

Книга построена на принципе реализации учебных примеров из книги, вы вместе с автором решаете проблему и успешно выполняете её. Как известно – это один из самых лучших способов научиться чему-то.

Основные вопросы, которые рассматриваются в книге:

• Как подключать новые возможности CCS3 для старых браузеров?
• Как создать красивые дизайны с уникальной типографикой и графическими элементами?
• Как создавать адаптивный веб-дизайн. чтобы он отображался в мобильных устройствах?
• Как использовать CSS3 чтобы повысить юзабилити вашего сайта?

Книга для новичков, которые ещё не знакомы с веб-разработкой или только недавно начали создавать сайты. В книге описаны все возможности HTML и XHTML, проработаны много примеров по оформлению сайта с помощью CSS и многое другое.

Книга в стиле – создание сайта для чайников, сам лично не читал и не просматривал её, но думаю для новичков будет самое то, так как книга Игорь Квинта «Создаем сайты с помощью HTML, XHTML и CSS» довольно популярна и имеет много отзывов.

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

Вообще, книга имеет огромную популярность в США и её советуют, как базовый курс для всех, кто хочет изучить язык разметки HTML5. Новый стандарт рассмотрен с самых азов, до создания сложных элементов сайта. Книга подойдёт всем типам веб-разработчиков, от начинающих до профессионалов.

Я книгу не покупал, но листал в магазине, скорей всего она у меня будет следующая на заказ, очень понравился материал.

Данная книга написана опытными программистами Брюс Лоусон и Реми Шарпом, они давно работают вместе и создали ни один успешный проект в интернете. В своей работе они постоянно используют HTML5 и поэтому их все советы, полностью «пропитаны» практикой создания реальных сайтов и материал воспринимается очень легко.

Эта книга так же пополнила мою коллекцию, я считаю книга стоящая и очень хороший справочник.

Книга Дэвид Мэтью, как и все предыдущие, описывает основные возможности вёрстки на HTML5, даются советы по эффективности написания кода, как оформлять и т.п.

Книга разделена на 5 логически разных разделов, но обучаясь от первого до последнего, вы в итоге создадите полноценный сайт на HTML5, который будет соответствовать всем современным стандартам.

Книга подойдёт как для профессионалов (вы почерпнете тут что-нибудь новое для себя) так и для новичков, я бы даже сказал в первую очередь для новичков, потому что по ходу прочтения, вы будете переходить от самых простых и базовых моделей к более сложным.

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

В частности описано:

• Как профессионалы подходят к работе;
• Самообразование дизайнера и разработчика;
• Использование Ajax для построения сайтов
• Использование современных стандартов разработки при создании сайтов.

В ней рассмотрены основные способы применения Web-стандартов и рассмотрены примеры настоящих профессиональных сайтов, которые построены на современных технологиях.

Марк Пилгрим

Подробное руководство по всем новшествам стандарта HTML5. Показано, как использовать в Web-разработках новые функциональные возможности, открывающиеся при применении HTML5. Представлено множество простых и понятных практических примеров, позволяющих использовать разметку HTML5 для добавления графики, аудио, видео, автономных возможностей и много другого. Для Web-разработчиков.

Все объекты DOM используют общий набор свойств. В браузерах, поддерживающих некоторые функции HTML5, некоторые объекты будут обладать уникальными свойствами. Беглый взгляд на модель DOM позволит вам выяснить, какие из функций HTML5 обеспечены поддержкой. Существует четыре базовых метода, которые позволяют выяснить, поддерживает ли браузер ту или иную функцию HTML5. Если идти по пути “от простого к сложному”, то эти методы формулируются так…

Любой, кто за последние четыре года посещал сайт YouTube.com, знает о том, что в Web-страницы можно встраивать видеоролики. Но до начала работы над стандартом HTML5 стандартного метода достижения этой цели определено не было. Практически все видеоролики, которые вы когда-либо просматривали в Web, “пропускались” через какой-нибудь подключаемый модуль (плагин) от стороннего разработчика— будь то QuickTime, RealPlayer или Flash (YouTube использует Flash.) Эти подключаемые модули интегрируются с вашим браузером настолько хорошо, что вы можете даже не подозревать о том, что пользуетесь ими. По крайней мере, вы можете не подозревать об этом до тех пор, пока не попытаетесь просмотреть видео на платформе, которая не поддерживает этого плагина.

HTML5 определяет стандартный способ встраивания видео в Web-страницу с помощью элемента <video>. Поддержка элемента <video> все еще находится в разработке, и это — просто “политкорректный” метод сказать, что пока что она еще не работает полноценно. По крайней мере, если она и работает, то отнюдь не везде. Но не поддавайтесь отчаянию! Существуют альтернативы, обходные методы, да и вообще — к вашим услугам самый широкий выбор разнообразных опций.

Постоянное локальное хранение информации — это та область, где полноценные клиентские приложения, обладающие встроенной поддержкой локального хранения информации, традиционно имели преимущество перед Web-приложениями. Для полноценных клиентских приложений операционная система, как правило, предоставляет уровень абстракций для хранения и извлечения таких специфичных для приложения данных, как настройки приложения и статус времени выполнения. Эти значения могут храниться в системном реестре (только для Windows), INI-файлах, XML-файлах или других компонентах системы, установленных для конкретной платформы. Если ваш клиент нуждается в локальном хранении других данных, а не только пар “ключ/значение”, вы можете встроить в него собственную базу данных, разработать собственный формат хранения данных или выработать целый ряд других решений.

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

• cookie-файлы включаются в каждый запрос HTTP и, таким образом, замедляют работу вашего Web-приложения бесполезной пересылкой данных туда и обратно;
• cookie-файлы включаются в каждый запрос HTTP, поэтому данные постоянно пересылаются через Интернет в незашифрованном виде (за исключением тех случаев, когда все ваше приложение работает через SSL);
• cookie-файлы имеют ограничение по размеру (до 4 Кбайт для каждого файла). Этого уже достаточно, чтобы существенно замедлить работу вашего приложения, но явно мало для того, чтобы предоставлять реальную пользу.

А теперь давайте посмотрим, что нам требуется в реальности:

• большой объем пространства, чтобы клиентское приложение могло хранить свои данные, которые должны сохраняться между обновлениями страницы;
• возможность сохранения данных без необходимости их передачи на сервер.

До появления HTML5, все попытки добиться этих целей по различным причинам оказывались неудовлетворительными.

Что представляет собой автономное Web-приложение? На первый взгляд, кажется, что это — какое-то терминологическое недоразумение. Во всяком случае, противоречие кажется очевидным. Web-страницы — это то, что мы скачиваем и визуализируем. Скачивание подразумевает наличие сетевого соединения. Как мы можем что-то скачать, если у нас на данный момент нет соединения с Интернетом? Естественно, сделать этого мы не можем. Но при наличии соединения возможность скачивания появляется. Именно по этому принципу и работают автономные приложения HTML5.

В простейшей своей форме автономное Web-приложение представляет собой список URL — файлов HTML, CSS, JavaScript, изображений и ресурсов любого другого типа. Домашняя страница автономного Web-приложения указывает на этот список, который называется файлом манифеста (manifest file), который представляет собой просто текстовый файл, расположенный где-либо на Web-сервере. Web-браузер, который реализует автономные приложения HTML5, прочтет список URL из файла манифеста, загрузит ресурсы, кэширует их локально и будет автоматически сохранять локальные копии по мере их изменения. Когда вы пытаетесь получить доступ к Web-приложению при отсутствии сетевого соединения, ваш Web-браузер автоматически переключается на использование локальных копий.

Начиная с этого момента, большую часть работы должны выполнить вы, как Web-разработчик. В DOM есть флаг, который сообщает вам, в каком режиме вы находитесь в данный момент — онлайн или в автономном. Существуют события, которые срабатывают при изменении вашего статуса соединения (когда вы только что были в автономном режиме, а через минуту переключились в режим онлайн, и наоборот). Но если ваше приложение создает данные или сохраняет свой статус, то локальное сохранение данных при переключении в автономный режим и их синхронизация при подключении к удаленному серверу — это ваша задача. Иными словами, HTML5 позволяет переводить ваши Web-приложения в автономный режим. Что вы будете делать после этого — целиком и полностью зависит от вас.

Зачем нужно вручную управлять адресом в браузере? В конце концов, переход по новому URL можно осуществлять с помощью простой ссылки; таким способом Web работает. И Web продолжит работать таким способом. Данный API не делает попытки “подавить” Web. Как раз наоборот. Web-разработчики нашли новые интересные способы управления Web без какой-либо помощи со стороны появляющихся стандартов. HTML5 history API разрабатывался с тем,
чтобы гарантировать то, что URL останутся полезными даже в приложениях, перегруженных скриптами.

Создание, доработка, продвижение сайтов - Марк Пилгрим HTML5

Обновлено 14.04.2015 | Категория: Мой блог | Просмотров: 2393

Любой специалист не только работает, гребет деньги лопатой и отдыхает на Бали, но еще и учится, систематизирует накопленные знания и опыт. Причем на 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 геолокации
Покажите мне код
Обработка ошибок
Требую выбора!
А что в IE?
На помощь спешит geo.js
Живой пример
Для дальнейшего изучения
Глава 7. Локалькое хранилище: прошлое, настоящее, будущее
Приступим
Краткая история прототипов локального хранилища до HTML5
HTML5-хранилище: вводный курс
Использование HTML5-хранилища
Следим за состоянием HTML5 - хранилища
Ограничения в современных браузерах
HTML5-хранилище в действии
Альтернативы: хранилище без ключей и значений
Для дальнейшего изучения
Глава 8. На волю, в офлайн!
Приступим
Манифест кэша
Раздел NETWORK
Раздел FALLBACK
Поток событий
"Убей меня поскорее!"
Строим оффлайновое приложение
Для дальнейшего изучения
Глава 9. Веб-формы как форма безумия
Приступим
Подсказывающий текст
Поля с автофокусировкой
Адреса электронной почты
Веб-адреса
Числа как счетчики
Числа как ползунки
Выборщики даты
Форма поиска
Выборщики цвета
И еще об одной вещи
Для дальнейшего изучения
Глава 10. Микроданные и другие красивые слова
Приступим
Что такое микроданные?
Структура микроданных
Разметка данных о человеке
Разметка данных об организации
Разметка данных о событии
Разметка клиентских отзывов
Для дальнейшего изучения
Приложение. Универсальный почти алфавитный определитель всего на свете
Элементы
Для дальнейшего изучения

После прочтения книги у меня остались только приятные впечатления, во-первых, радует, что автор фактически начинает книгу, раскрывая основы тестирования HTML5 кода. Кроме того в книге разобрано множество типовых ситуаций, поясняющих особенности работы HTML5 с различными объектами на веб-странице. Книга будет полезна как начинающему web-разработчику, так и более опытному.

Также можно почитать:

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

• Мэтью Мак-Дональд
• Издательство: БХВ-Петербург
• ISBN: 978-5-9775-0805-6
• Год издания: 2012
• Кол.страниц: 480, цв. ил.
• Язык: русский
• Формат: RTF/FB2
• Размер: 13,85 Mb

Доступно и в занимательной форме рассказано, как HTML превратился в HTML 5. Рассмотрены семантические элементы и новые стандарты языка. Описано, как создавать современные веб-страницы, в том числе улучшенные веб формы, поддерживать аудио и видео, рисовать на холсте, совершенствовать оформление веб-страниц с помощью CSS 3.

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

можно по следующим ссылкам:

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

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

Расширенные возможности HTML5 Центр «Специалист» предлагает Вам авторизованный курс Microsoft «М50564A Расширенные возможности HTML5». Язык HTML5 — ответ веб-разработчиков на давно назревшие требования обычных пользователей в международной паутине. Революционным отличием HTML5 от

Погружение в HTML5 Подробное руководство по всем новшествам стандарта HTML5. Показано, как использовать в Web-разработках новые функциональные возможности, открывающиеся при применении HTML5. Представлено множество простых и понятных практических примеров, позволяющих

Бесплатная книга «HTML5

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

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

Недавно я прочел высказывание одного разработчика для платформы Mozilla, где говорится о той напряженности, которая всегда сопутствует разработке стандартов:

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

Пока я буду рассказывать, как появился HTML5, помните эти слова.

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

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

Значение 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. Хорошенько запомните эту информацию, так как она еще пригодится.

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

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

25 февраля 1993 года Марк Андрессен (Marc Andreessen) написал :

Предлагаю новый опциональный HTML-тег:
IMG
При нем должен обязательно указываться аргумент SRC=" url". Тег отсылает к файлу растрового изображения (bitmap или pixmap). Браузер будет запрашивать этот файл в Сети, распознавать как изображение и вставлять в текст сообразно месту
тега в коде страницы.
Пример использования:

<IMG SRC="file://foobar.com/foo/bar/blargh.xbm">
(Закрывающий тег не требуется.)

Как и любое другое содержимое, этот тег может быть вложен внутрь якоря. Тогда изображение станет чувствительным к активизации, как и обычная текстовая ссылка. Следует предоставить браузерам свободу выбора графических форматов, которые будут в них поддерживаться. Удачным выбором мне представляются, например, 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>. Но такое решение было бы удобно для совместимости с браузерами, которые не понимают параметр INCLUDE. Иными словами, если браузер распознает команду INCLUDE, то он заменит текст ссылки («См. фотографию» в данном случае) картинкой, а более старый или более глупый браузер просто проигнорирует INCLUDE.

Это предложение не было реализовано, хотя идея заместительного текста на случай, если изображение отсутствует, очень привлекательна и не упоминается в предложенной Марком конструкции тега <IMG>. Много лет спустя идея была осуществлена в атрибуте <img alt=". " > (после чего все испортил Netscape, который ошибочно отображал текст-заместитель в виде всплывающей подсказки).

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

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

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

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

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

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

Это предложение тоже не было реализовано, хотя позднее Netscape стал поддерживать встраивание произвольных мультимедийных объектов с помощью тега <embed> .
Джей Вебер (Jay C. Weber) написал следующее:

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

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

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

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

Забудем на время о MIME-типах, они отвлекают от сути. Я, собственно, не согласен с вашим подходом к поддержке встроенных изображений, ведь можно ожидать, что на следующей неделе кто-нибудь предложит новый тег <AUD SRC=" file://foobar .com/foo/bar/blargh .snd"> для звуковых файлов. Между тем за использование единого для всех медийных типов способа встраивания пришлось бы платить не такой уж и дорогой монетой.

Опыт свидетельствует, что беспокойство Джея было вполне обоснованным. Прошло, правда, больше недели, но в HTML5 появились теги <video> и <audio> .
В ответ на первое письмо Джея Дейв Рэггет (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-графику (декларативную разметку со встроенной возможностью разработки сценариев), так и <canvas> (процедурный интерфейс непосредственного программирования графики). Правда, исторически <canvas> был проприетарным расширением для браузера и рабочая группа WHAT внесла его в спецификацию постфактум.

Билл Дженсен (Bill Janssen) сообщил:

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

Andrew — сокращенное название системы пользовательского интерфейса Andrew. Ее в те годы все называли 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-е годы о ней часто вспоминали.

Предложенный Тимом тег так никогда и не появился, хотя отголоски этой идеи можно наблюдать в тегах <object>. <embed> и <iframe> .

Наконец 12 марта 1993 года Марк Андрессен написал в той же ветви дискуссии:

Вернусь к теме встроенных изображений. Приближается выпуск Mosaic v0 .10, в котором будет оговоренная ранее поддержка растровых изображений форматов GIF и XBM в тексте.

Поддерживать теги INCLUDE/EMBED мы в настоящее время пока не готовы. Вероятно, сейчас придется остановиться на <IMG SRC=" url" > (а не ICON, потому что не всякое изображение, вставленное в текст, можно назвать значком). Пока что встроенные изображения не типизируются явным образом; мы намерены начать поддержку графических типов впоследствии, когда речь зайдет о реализации системы MIME-типов в целом. Используемые нами сейчас алгоритмы чтения изображений определяют формат на лету, так что даже расширение файла не играет никакой роли.