Содержание: 1. Введение в язык HTML.Введение в язык HTML. 2. История создания HTML.История создания HTML. 3. Основные понятия языка HTMLОсновные понятия языка HTML 4. Структура Web – документа.Структура Web – документа. 5. Вставка комментария Вставка комментария 6. Пример HTML документа.Пример HTML документа. 7. Теги форматирования текста.Теги форматирования текста. 8. Теги управления внешним видом Web-страницы Теги управления внешним видом Web-страницы 9. Тэг Тэг 10. Цвет фона и текста Цвет фона и текста 11. Списки Списки 12.Web-страница с графическими объектами.Web-страница с графическими объектами.
Введение в язык HTML HTML – это язык разметки документов в среде WEB. То, что вы видите при просмотре страницы в Internet, это интерпретация вашим браузером HTML-текста. Чтобы браузер правильно отображал форматирование к примеру текста т.е. разделял его на абзацы, выделял цитаты, заголовки, списки и.т.д. ему надо как-то сообщить, что мол это заголовок, а это – параграф и.т.д. Этим как раз и занимается язык html. Чтобы увидеть HTML-коды страницы в Internet, кликните правой кнопкой мыши по странице, в выпавшем меню выберите пункт - view source (или "просмотр HTML кода"). Содержание
История создания HTML (Hyper Text Markup Language – язык разметки гипертекста) Некоторые даты: 1945 год: 1945 год: американский ученый, научный консультант президента Ванневар Буш (Vannevar Bush) высказывает идею гипертекста год: 1968 год:Дуглас Энджельбарт демонстрирует работу гипертекстовых связей в созданном им текстовом процессоре. Содержание
1960-е годы: 1960-е годы: сотрудники компании IBM создали язык GML (General Markup Language - общий язык разметки), который предназначался для использования на ЭВМ семейства IBM. Язык GML в дальнейшем был расширен, а в 80-х годах прошёл стандартизацию ISO (Международная организация стандартизации). Этот мощный и универсальный режим разметки, названный SGML (Standart General Markup Langugage), использовался военным ведомством США для оформления технической документации е годы: 1980-е годы: учёный-физик Тим Бернерс-Ли, сотрудник CERN (Европейский Центр Ядерных Исследований),в основу разрабатываемого языка положил язык SGML и приёмы работы с гипертекстом, с чем и связано название созданного им языка - HTML. Новый язык использовал основные конструкции SGML для описания документов и гипертекстовых ссылок. Некоторые даты: Содержание
Термин "гипертекст" впервые был введён Тедом Нельсоном в 1969 году. Гипертекст – электронный документ, содержащий в себе ссылки на другие документы. Содержание
Структура Web – документа. …, Всё содержимое файла Интернет-страницы заключается в контейнер …, указывающий браузеру, что данный текст представляет собой HTML-документ и, возможно содержит в себе тэги, которые браузер должен выявить, распознать, интерпретировать. Типичная Интернет-страница (HEAD)(BODY) Типичная Интернет-страница состоит из двух частей: заголовка (HEAD) и тела (BODY). Содержание
Структура Web – документа. начало контейнера HTML-документа начало контейнера заголовка начало контейнера строки – названия страницы …строка названия страницы конец контейнера строки – названия страницы конец контейнера заголовка начало контейнера тела страницы …тело (всё содержимое) страницы конец контейнера тела страницы конец контейнера HTML-документа Эту базовую структуру в простейшем виде можно наглядно показать следующим образом: Содержание
Структура Web – документа. Указанная вами строка-название будет выводиться в заголовке окна браузера, когда данная страничка будет в нём просматриваться, а также (уже после размещения страницы в Интернете) в списках, выдаваемых поисковыми серверами. Содержание
Тэги форматирования текста. отображает текст полужирным шрифтом. отображает текст курсивом отображает текст подчеркнутым шрифтом. и отображают текст, перечеркнутый горизонтальной линией. выводит текст шрифтом большего размера, чем непомеченная часть текста выводит заключенный в него текст шрифтом меньшего размера, по сравнению с остальной частью текста: сдвигает текст ниже уровня строки и выводит его шрифтом меньшего размера. Рекомендуется для печати математических индексов: сдвигает текст выше уровня строки и выводит его шрифтом меньшего размера. Этот тэг можно использовать для задания степеней чисел: Содержание
Тэг Тэг позволяет изменить шрифт, который использует браузер для просмотра Web-страницы. Тэг может иметь следующие параметры: FACE – задает название шрифта, которым будет выводится текст. SIZE – задает размеры шрифта в условных единицах от 1 (самого маленького) до 7 (самого большого). Принято считать, что шрифт нормального размера соответствует значению 3. COLOR – устанавливает цвет шрифта, который может задаваться с помощью стандартных имен или набором шестнадцатеричных цифр. Содержание
Цвет фона и текста Мы уже знаем как менять цвет текста, но для этого нам нужно было заключать его в теги font, а это не всегда удобно. Иногда, лучше задать цвет текста для всего документа. Также, можно задать и фоновое изображение. Вот необходимые атрибуты: BACKGROUND – определяет изображение для "заливки" фона. Значение задается в виде полного URL или имени файла с картинкой в формате GIF или JPG (подробнее об этом будет рассмотрено позже). BGCOLOR – определяет цвет фона документа. TEXT – определяет цвет текста в документе. Все они прописываются для элемента BODY. Значения цветов задаются либо RGB-значением в шестнадцатеричной системе, либо одним из 16 базовых цветов. Содержание
Цвет фона и текста Пример: Этот текст будет красный, потому что мы изменили цвет текста в теге БОДИ и теперь весь текст на странице по умолчанию будет красный В этом абзаце текст будет зеленый, потому что мы заключили его в теги font и придали соответствующий цвет Теперь текст снова будет красный Содержание
Списки Каждый элемент списка начинается тэгом В языке HTML предусмотрен специальный набор тэгов для представления информации в виде списков следующих типов: Маркированный (); Нумерованный (/); список определений (/). Термин. Его определение... Содержание
Web-страница с графическими объектами. Изображения - это неотъемлемая часть любого сайта в сети интернет. Они используются везде, поэтому давайте разберемся что к чему. Есть три типа файлов изображений, которые можно вставить на ваши страницы: GIF (Graphics Interchange Format) JPG / JPEG (Joint Photographic Experts Group) PNG (Portable Network Graphics) Содержание
Web-страница с графическими объектами. Пара слов о форматах: GIF - использует всего 256 цветов и соответственно лучше подходит для рисунков с малым кол-вом оттенков. Этот формат поддерживает прозрачность изображений. JPEG - формат изображений, который использует до миллиона цветов. Обычно используется для фотографий и качественной графики(с огромным количеством оттенков). PNG - сравнительно новый формат. По многим параметрам превосходит JPEG и GIF: миллионы цветов и эффективное сжатие. Также поддерживает прозрачность. В каком формате брать изображения - дело Ваше, однако старайтесь добиться максимального качества при минимальном размере. Содержание
Web-страница с графическими объектами. Для размещения изображений в HTML-документах используется тэг, у которого параметр SRC задает местонахождение файла с изображением. Например: - в HTML-документ будет помещено изображение, находящееся в файле picture.gif; - в HTML-документ будет помещено изображение, находящееся в файле Плитка.bmp, который расположен в папке Images, находящейся в этой же самой папке, что и HTML-документ. Содержание
Web-страница с графическими объектами. При включении графического изображения в документ можно указывать его расположение относительно текста или других элементов страницы. Способ выравнивания изображения задается значением параметра ALIGN тэга. Ниже приведены некоторые возможные значения этого параметра: LEFT Изображение прижимается к левому полю окна. Текст обтекает изображение с правой стороны. RIGHT Изображение прижимается к правому полю окна. Текст обтекает изображение с левой стороны. Содержание
Создание сайта с помощью языка html Что такое html? История создание языка Основные теги Создание сайта с помощью блокнота Создание сайта с помощью редактора html
Что такое html? Hyper. Text Markup Language (в дальнейшем HTML) это язык гипертекстовой разметки документа. В нашем случае этим документом является web страница. Проще говоря, это язык для написания web страниц. Читая код HTML, веббраузер выводит на экран Вашего монитора содержимое web страницы.
История создания языка html Начало было положено Тимом Бернерс-Ли, выпускником Оксфордского университета. В 1989 году он выдвинул предложение о создании «Системы гипертекстовых документов» , которая должна была использоваться внутри CERN. В 1990 году он назвал эту систему World Wide Web (на русский язык это можно перевести как Всемирная Паутина). Одной из составляющих системы был язык разметки гипертекста. Его основы были заложены в 1990 году, когда Бернерс-Ли разрабатывал первый веб-браузер. Наконец, в 1993 году появилась первая версия языка - HTML 1. 0. Но он не был стандартом. И только в 1995 году, когда закончилась разработка языка HTML 2. 0, он стал таковым. К тому времени вторую версию языка HTML полностью поддерживало большинство браузеров. Что же было в этой версии? Во-первых, полностью утвердилась структура документа (она осталась неизменной до настоящего времени). Во-вторых, достаточно широко были представлены элементы разметки текста. Втретьих, появилась возможность добавлять рисунки. Конечно же, можно было вставлять гиперссылки и веб-формы. Как мы видим, очень многое из сегодняшнего языка HTML уже было реализовано в 1995 году в спецификации HTML 2. 0. Именно этот язык стал базисом, который потом усложнялся и дополнялся.
Дальнейшим развитием языка стала версия HTML 3. 0. В ней были реализованы таблицы, обтекание текста вокруг фигур и многие другие идеи. Несмотря на обратную совместимость, отличия между версиями 2. 0 и 3. 0 были огромными, по этой причине браузеры очень медленно и достаточно вяло включали поддержку новых возможностей. Версия 3. 0 так и не стала стандартом. Зато им стала версия HTML 3. 2. Она создавалась с учетом мнений производителей браузеров (Microsoft и Netscape), что естественным образом привело к положительным результатам. Примечателен тот факт, что еще до официального утверждения данного стандарта (это произошло в 1997 году), уже в 1996 году практически все браузеры полностью поддерживали его. Во многом благодаря стандарту HTML 3. 2 веб-дизайн испытал небывалый взлет. Появилась возможность проектировать и отображать на экране сложные композиции, ничем не уступающие журналам, газетам и другим печатным изданиям (это стало возможным благодаря табличной верстке). Но из-за медленных каналов связи приходилось значительно ограничивать применение графики, а многие мониторы отображали не более 256 цветов, так что и богатство красок оставляло желать лучшего.
Несмотря на то, что язык HTML 3. 2 включал в себя многие расширения, внедренные разработчиками браузеров, он все еще оставался достаточно ограниченным, поэтому и новый стандарт не заставил себя долго ждать. Уже в том же 1997 году появилась спецификация HTML 4. 0. В нее включили фреймы, унифицировали процедуру вставки различных объектов в документ, реализовали поддержку каскадных таблиц стилей. Кроме того, были значительно усовершенствованы формы и таблицы, а некоторые элементы помечены как нежелательные для использования. Необходимо отметить, что четвертая версия HTML отличается законченностью и полнотой. Фактически, это предел возможностей данного языка. Последняя версия HTML 4. 01 была стандартизирована 24 декабря 1999 года, после чего разработка этого языка прекратилась.
Основные теги Тэг – это специальное указание того как нужно отображать элемент (текст, картинка и т. д.) на странице сайта. Можно представить его как команду браузеру содержащую название и параметры. Текст, на который должен воздействовать тэг. Большинство тэгов - парные, то есть на каждую открывающую метку вида есть закрывающая метка вида с тем же именем, но с добавлением слэша "/".
Открывающий тег, который объявляет о начале документа. Открывающий тег заголовка или головы документа (кому как удобно) В дальнейшем, если речь будет идти о заголовке документа, будем говорить тег, имя в виду «заголовок» документа. Между открывающим и закрывающим тегом располагается название документа и служебная информация для браузеров и поисковых машин. Открывающий тег названия документа дает браузеру понять, что все что написано сразу за этим тегом и до закрывающего тега является названием документа. Это название выводится браузером на самую верхнюю панель браузера. Наша первая страница - собственно само название документа.
Закрывающий тег названия документа дающий понять браузеру, что на этом действие тега закончилось. Закрывающий тег заголовка или головы документа дающий понять браузеру, что на этом действие тега закончилось. Между открывающим тегом и закрывающим находится все, что выводится браузером на экран. Это таблицы, текст, изображения. Одним словом, все HTML-элементы, отвечающие за отображение документа, управление им и гипертекстовые ссылки. Закрываем тело документа. Сообщаем браузеру, что на этом тело или содержимое (кому как нравиться, мы будем говорить далее «тело») документа закончено. Иными словами в данном месте закончено действие тега.
Закрываем HTML документ. Видя этот тег браузер понимает что действие тега на этом закончено.
Создание сайта с помощью блокнота Сначала создадим отдельную папку для нашего сайта. Назовем ее, например, site. Затем, откроем блокнот. Если Вы не знаете, что это такое и где он находится у вас на компьютере, то идите в панель «ПУСК» , далее «ПРОГРАММЫ» , далее на вкладке «СТАНДАРТНЫЕ» найдите и откройте «БЛОКНОТ» . Теперь пропишите следующие теги, о которых мы вам уже упоминали: Моя страничка Добрый день! Это моя первая страница!
Теперь это все сохраним. Затем вводим название страницы. Обязательно вводим расширение. html и смотрим, чтобы в строке «тип файла» Было выбрано «Все файлы»
Теперь запустим нашу страничку, чтобы посмотреть, что же у нас получилось. Для этого перейдем в папку с нашей страничкой. И запустим созданный файл. Смотрим, что у нас получилось.
Конечно, вы увидели самый простой из возможных вариантов сайтостроения с помощью блокнота, но в дальнейшем, изучая этот язык самостоятельно можно делать куда более сложные сайты.
Создание сайта с помощью редактора html Для начала Вам нужно выбрать редактор. Сyщecтвyeт два типа HTML peдaктopoв: Редакторы типа “WYSIWYG (What-You- See-Is What-You-Get) Что видишь, то и получишь” Пользователь не видит "внутренностей" документа, с которым он работает, точно так же, как при работе с текстовым процессором типа Microsoft Word Редакторы собственно HTML-текстов. В процессе работы пользователь видит внутреннее содержание HTML-файла и может изменять его либо вручную, либо вызывая команды меню для вставки определенных элементов HTML.
Ecли Вы нe имeeтe ни мaлeйшeгo пpeдcтaвлeния o HTML, тo для начала вaм пoдoйдyт peдaктopы пepвoй гpyппы На примере редактора Microsoft Office Front. Page 2003, я хочу показать примерный принцип работы редакторов. Для начала запустим его. Перед собой мы видим вот такое окно как в Word’е.
Теперь вы можете вставлять картинки, делать таблицы, писать текст, все на ваше желание, прямо как в Word. А этот редактор переделает это все в html. Вот небольшой пример моей работы в Front Page:
Нажимаем, и выходит такое вот окно: По умолчанию, сайт сохраняется в каталоге «Мои документы» в папке «Мои веб-узлы»
Src="https://present5.com/presentation/3/50880218_183922291.pdf-img/50880218_183922291.pdf-19.jpg" alt="Теперь запустим нашу сделанную страничку. Для этого заходим Мои документы->Мои веб-узлы->index. html: "> Теперь запустим нашу сделанную страничку. Для этого заходим Мои документы->Мои веб-узлы->index. html:
Перевод: Влад Мержевич
Недавно я наткнулся на цитату разработчиков Mozilla о напряженности, связанной с разработкой стандартов :
Реализации и спецификации должны следовать вместе в изящном танце. Вы не хотите, чтобы реализация происходила до окончания работ над спецификацией, потому что люди начнут зависеть от деталей реализации и это будет сдерживать спецификацию. Однако вы также не желаете, чтобы спецификация была завершена раньше реализации, тогда авторы начнут экспериментировать с реализацией, когда вам нужна обратная связь. Здесь существует неизбежное напряжение, но мы просто должны колебаться в выборе до конца.
Держите эту цитату в глубине сознания и позвольте мне объяснить про становление HTML5.
MIME-типы
Эта книга об HTML5, а не о предыдущих версиях HTML и не о версиях XHTML. Но чтобы понять историю HTML5 и мотивацию, стоящую за ним, вы должны в первую очередь понимать несколько технических моментов. В частности, MIME-типы.
Каждый раз, когда ваш браузер запрашивает страницу, веб-сервер посылает «заголовки» перед отправкой фактического кода страницы. Эти заголовки, как правило, невидимы, хотя есть инструменты веб-разработчика, которые делают их видимыми, если вам интересно. Заголовки важны, потому что они говорят вашему браузеру, как следует интерпретировать разметку страницы. Наиболее важный заголовок называется Content-Type и выглядит так:
Content-Type: text/html
«text/html» называется «тип содержимого» или «MIME-тип» страницы. Этот заголовок определяет только, что это в действительности за ресурс и как его отображать. Изображения имеют свои собственные MIME-типы (image/jpeg для JPEG, image/png для PNG и т.д.). Файлы JavaScript имеют собственный MIME-тип. CSS имеют собственный MIME-тип. Все имеют собственный MIME-тип. Интернет работает на MIME-типах.
Конечно, в реальности все намного сложнее. Первое поколение веб-серверов (я говорю про веб-сервера с 1993 года) не посылало заголовок Content-Type, потому что его не было (он не был изобретен до 1994 года). Из соображений совместимости при возврате даты на 1993 год, некоторые популярные браузеры игнорируют заголовки Content-Type при определенных обстоятельствах (это называется «сниффинг контента»). Но, как правило, все, что вы когда-нибудь просматривали в Сети - HTML-страницы, изображения, скрипты, видео, PDF и др. - отдавалось вам с определенным MIME-типом в заголовке Content-Type.
Пока отложите вашу шляпу. Мы еще вернемся к этому.
Длинное отступление о том, как делаются стандарты
Почему мы используем элемент
? Это не тот вопрос, который вы слышите каждый день. Очевидно, кто-то его создал. Такие вещи не появляются просто ниоткуда. Каждый элемент, каждый атрибут, каждая особенность HTML, которую вы когда-либо использовали - кто-то создал их, решил, как они должны работать и написал все это. Эти люди не боги и они не безупречны. Они обычные люди. Умные люди, уверен. Но просто люди.
Одна из замечательных вещей в стандартах, разработанных «в открытую» это то, что вы можете вернуться назад во времени и ответить на разные вопросы. Обсуждения происходят через список рассылки, которые, как правило, архивируются и публично доступны. Так что я решил немного заняться «почтовой археологией», чтобы попытаться ответить на вопрос, «Почему мы используем элемент
?». Я должен вернуться назад до того, как появилась организация под названием Консорциум Всемирной паутины (World Wide Web Consortium, W3C). Я вернулся в первые дни Сети, когда количество веб-серверов можно было пересчитать по пальцам двух рук и может быть парой пальцев ног.
Есть ряд опечаток в следующих цитатах. Я решил оставить их нетронутыми для исторической точности.
Я хотел бы предложить новый дополнительный тег HTML:
Обязательный аргумент SRC="url"
Это имя растрового или графического файла для браузера, который пытается тянуть их по сети и интерпретируют как изображение, должно быть включено в текст в момент создания тега.
(Здесь нет закрывающего тега, это всего лишь одиночный тег.)
Браузеры должны проявлять гибкость в отношении графических форматов, которые они поддерживают. Xbm и Xpm хорошо поддерживаются, к примеру. Если браузер не может интерпретировать данный формат, он может делать, что хочет (X Mosaic по умолчанию выведет растровое изображение в качестве заполнителя).
Это потребует функциональности для X Mosaic, у нас это работает, и мы, по крайней мере использовали это внутренне. Я, конечно, открыт для предложений, как это должно обрабатываться в HTML, если у вас есть идея получше, чем предложенная, пожалуйста, дайте мне знать. Я понимаю, туманно написал о форматах изображений, но я не вижу альтернативы, чем просто сказать «пусть браузер делает что может» и ждать идеального решения (MIME, когда-нибудь, возможно).
У меня есть нечто похожее в Midas 2.0 (используется здесь в SLAC и должен быть публичный релиз на этой неделе), за исключением, что все имена разные и есть дополнительный аргумент NAME="name". Он почти в точности имеет ту же функциональность, что и предлагаемый вами тег IMG, например.
Идея параметра name позволит браузеру устанавливать «встроенные» изображения. Если name совпадает со «встроенным» изображением, тогда оно используется вместо того, чтобы пойти и получить изображение. name также может выступать в качестве подсказки для «строчного режима» браузеров, чтобы какой-нибудь символ положить в месте изображения.
Я не очень заботился о параметрах или именах тегов, но было бы разумно, если бы использовали те же самые вещи. Я не очень забочусь о сокращениях, так что, почему не IMAGE= и не SOURCE=. Я предпочитаю все же ICON, поскольку он проще, чем IMAGE и должен быть маленьким, но, возможно, ICON перегруженное слово?
Midas другой ранний браузер, современник X Mosaic. Он кроссплатформенный и запускался на Unix и VMS. SLAC относится к Стэнфордскому центру линейного ускорителя , сейчас Национальная ускорительная лаборатория SLAC, в котором запущен первый веб-сервер США (на самом деле первый веб-сервер за пределами Европы). Когда Тони написал это сообщение, SLAC был старейшим в WWW, у которого на веб-сервере размещалось пять страниц колоссальные 441 день.
Тони продолжает:
Пока мы в теме о новых тегах, у меня есть другая идея, несколько похожий тег, который я хотел бы поддержать в Midas 2.0. В принципе так:
Замысел в том, что второй документ вставляется в первый документ в месте, где этот тег встречается. В принципе, указанный документ может быть любым, но главная цель позволить изображениям (в данном случае произвольного размера) встраиваться в документы. Опять замысел такой, что с приходом HTTP2 форматы включаемых документов будут обсуждаться отдельно.
Несколько часов спустя после отправки сообщения Тони, ответил Тим Бернерс-Ли .
Я думал, что иллюстрации будут представлены так:
Иллюстрация
где значения отношений обозначают
EMBED Вставить сюда при наличии
PRESENT Показать, когда исходный документ представленЗаметьте, что вы можете иметь их различные комбинации, и если браузер не поддерживает ни одно, он не ломается.
[Я] вижу использование этого как метод для выбора иконки средствами вложенных ссылок. Хммм. Но я не хотел бы специальный тег.
Это предложение не было реализовано, но атрибут rel еще здесь.
Было бы хорошо, если был способ указать тип содержимого, например.
Но я полностью согласен жить с требованием, что я указываю тип содержимого по расширению файла.
Это предложение не было реализовано, но Netscape позже добавил поддержку для встраивания мультимедийных объектов с элементом
Хотя изображения находятся в верхней части моего списка желаний, посередине типов в WWW браузерах, я не думаю, что мы должны добавлять специальные хуки для медиа по одному за раз. Что случилось с энтузиазмом по использованию механизма MIME?
Это не замена предстоящего использования MIME в качестве механизма стандартного документа; это обеспечение необходимой и простой реализации функциональности, который требуется независимо от MIME.
Давайте временно забудем о MIME, если это эфемерная проблема. Мое возражение было к обсуждению «как мы будем поддерживать встроенные изображения», а не «как мы будем поддерживать встроенные изображения в разных медиа».
В противном случае кто-то через неделю предложит «вставить новый тег
» для аудио. Не должно быть больших расходов при переходе от чего-то обобщенного.
Оглядываясь назад, беспокойства Джея выглядят обоснованными. Потребовалось чуть больше недели, но в HTML5 наконец добавлены новые элементы
Отвечая на исходное сообщение Джея, Дэйв Рэгетт сказал :
Точно! Я хочу рассмотреть весь диапазон возможных изображений/линий художественных типов наряду с обсуждением формата. Тим заметил про поддержку кликабельных областей внутри изображений, это тоже важно.
В действительности, может быть мы должны подумать о процедурном языке графики общего назначения, с которым мы можем вставлять произвольные гиперссылки приатаченные к иконкам, изображениям, тексту или другое. Кто-нибудь еще видел возможности Intermedia относительно этого?
Посмотрите другие системы, которые имеют эти (довольно ценные) понятия, Andrew и Slate. Andrew построен со _вставками_, каждая из них имеет несколько интересных типов, таких как текст, точечный рисунок, графика, анимация, сообщения, электронные таблицы и т.д. Понятие произвольное рекурсивное вложение присутствует, так что вставка любого рода может быть вложена в любой другой вид, который поддерживает вложения. Например, вставка может быть встроена в любом месте текста текстового виджета или в любой прямоугольной области виджета рисования или в любой ячейке электронной таблицы.
Вот мое мнение. Лучший способ сделать изображения в WWW это использование MIME. Я уверен, PostScript уже поддерживает подтипы в MIME, и он делает очень красиво с совмещением текста и графики.
Но это не кликабельно, вы говорите? Да, вы правы. Я подозреваю, что ответ на это уже есть в Display PostScript. Даже если не добавлено в стандартный PostScript, это тривиально. Определите команду ссылке, которая задает URL и использует текущий путь как замкнутую область для кнопки. Поскольку PostScript хорошо имеет дело с путями, создание произвольной кнопки тривиально.
Display PostScript был экранной технологией рендеринга совместно разработанной Adobe и NeXT.
Это предложение не было реализовано, но идея, что лучший способ исправить HTML, это заменить его чем-то совсем другим, еще всплывает время от времени.
HTTP2 позволяет документу содержать любой тип, с которым пользователь сказал, что он может работать, а не только зарегистрированные MIME-типы. Так что можно экспериментировать. Да, я думаю, есть основания для PostScript-а с гипертекстом. Я не знаю, достаточно ли Display PostScript. Я знаю, Adobe пытается создать свой собственный PostScript-ориентированный «PDF», который будет иметь ссылки и быть читаться их проприетарным просмотрщиком.
Я думаю, что общий оверлейный язык для ссылок (на основе Hytime?) позволит гипертексту и графики/видео стандартам развиваться отдельно, что поможет обоим.
Пусть тег IMG включает INCLUDE и пусть он ссылается на произвольный тип документа. Или EMBED, если INCLUDE звучит как инклюд cpp, чтобы люди могли обеспечить исходный код SGML для построчного разбора - не так, как было задумано.
Вернемся к инлайновым изображениям еще раз - я близок к выпуску Mosaic 0.10, который поддерживает изображения GIF и XBM как уже упоминалось ранее...
Мы не готовы поддержать INCLUDE/EMBED в этой точке... Так что мы, вероятно, будем идти с
(не ICON, поскольку не все инлайновые изображения могут обоснованно называться иконками). В настоящее время, инлайновые изображения не будут явно содержать content-type; в будущем, мы планируем сделать поддержку этого (наряду с общей адаптацией MIME). На самом деле процедура чтения изображений, которую мы используем в настоящий момент, выясняет формат на лету, так что расширение файла не так и важно.
Непрерывная линия
Я чрезвычайно увлечен всеми аспектам этого почти 17-летнего разговора, что привел к созданию элемента HTML, который использовался практически на каждой веб-странице когда-либо опубликованной. Примем во внимание:
- HTTP по-прежнему существует. HTTP успешно развивался с 0.9 в 1.0 и позже в 1.1. И еще развивается.
- HTML по-прежнему существует. Это элементарный формат данных - он даже не поддерживает строчные картинки! - успешно развивался в 2.0, 3.2, 4.0. HTML это непрерывная линия. Кривая, узловатая, путаная линия, будьте уверены. Существовало много «мертвых ветвей» в эволюционном дереве, мест, где стандартно мыслящие люди опередили самих себя (и превзошли авторов и исполнителей). Но тем не менее. Мы здесь в 2010 году, а веб-страницы с 1990 года по-прежнему отображаются в современных браузерах. Я только что загрузил одну в браузер моего мобильника на новейшем Андроиде и мне даже не предложили «Пожалуйста, подождите, пока импортируется устаревший формат...».
- HTML всегда был разговором между разработчиками браузеров, авторами, зубрилами стандартов и другими людьми, которые просто пришли и хотят поговорить об угловых скобках. Большинство успешных версий HTML были «ретро-спеками», догоняющими мир и одновременно пытающими подтолкнуть его в правильном направлении. Любой, кто говорит вам, что HTML должен быть «чистым» (вероятно, игнорируя разработчиков браузеров или игнорируя авторов или и тех и других) просто дезинформирует. HTML никогда не была чистым и все попытки очистить его были впечатляющие неудачными и могут только сравниться с попытки заменить его.
- Ни один из браузеров с 1993 года не существует в любом узнаваемом виде. Netscape Navigator был заброшен в 1998 году и переписан с нуля для создания Mozilla Suite, от которого затем отделился Firefox. Internet Explorer начинал как скромный «с чего начать» в «Microsoft Plus! для Windows 95», где он шел в комплекте с некоторыми темами рабочего стола и игрой пинбол.
- Некоторые из операционных систем с 1993 года все еще существуют, но ни одна из них не имеет отношение к современной Сети. Большинство «опытных» людей выходят в Интернет на ПК под управлением Windows 2000 или более поздней версии, на Маках под управлением Mac OS X, ПК под управлением некоторых вкусных Linux или портативных устройствах вроде iPhone. В 1993 году Windows была в версии 3.1 (и конкурирующей с OS/2), Маки управлялись System 7, Linux распространялся через Usenet.
- Некоторые же люди по-прежнему во всем и по-прежнему участвуют в том, что мы теперь просто называем «веб-стандарты». Вот уже почти 20 лет. И некоторые занимались предшественниками HTML, возвращаясь в 1980-е годы и раньше.
- Говоря о предшественниках... С конечной популярностью HTML и веба легко забыть тех, образовавших дизайн современных форматов и систем. Andrew? Intermedia? HyTime? И HyTime был не каким-то допотопным исследовательским проектом, это был стандарт ISO. Он был одобрен для использования в военных целях. Это был Большой Бизнес. И вы можете прочитать об этом сами... .
Но все это не отвечает на исходный вопрос: почему мы используем элемент
? Почему не элемент
? Все очень просто, потому что Марк Андрессен реализовал его и реализованный код победил.
Это не означает, что все реализованные коды победили, в конце концов, Andrew и Intermedia и HyTime тоже были реализованы. Код необходим, но не достаточен для успеха. Я, конечно, не хочу сказать, что реализация кода раньше выпуска стандарта это лучшее решение. Элемент Марка
не определяет основные графические форматы; не устанавливает, как текст должен его обтекать; не поддерживает альтернативный текст или запасной контент для старых браузеров. И 17 лет спустя мы еще боремся со сниффингом контента и он по-прежнему источник сумасшедшей уязвимости безопасности . И вы можете проследить все 17 лет назад, через Великие войны браузеров , назад до 25 февраля 1993 года, когда Марк Андрессен небрежно заметил: «MIME, когда-нибудь, возможно», а затем реализовал свой код, не смотря ни на что.
Хронология развития HTML с 1997 по 2004
В декабре 1997 года, World Wide Web Consortium (W3C) опубликовал HTML 4.0 и оперативно закрыл Рабочую Группу HTML. Менее чем через два месяца, отдельная Рабочая группа W3C опубликовала XML 1.0 . Спустя три месяца после этого, люди, которые управляют W3C, провели семинар под названием «Формируя будущее HTML», чтобы ответить на вопрос: « W3C отказался от HTML?» Это был их ответ:
В ходе обсуждения было решено, что дальнейшее расширение HTML 4.0 будет затруднено, как бы преобразуем 4.0 до XML-приложений. Предлагаемый путь освободит от ограничений, чтобы начать новую жизнь со следующего поколения HTML на основе набора XML-тегов.
W3C перезапустил Рабочую Группу HTML на создание этого «набора XML-тегов». Их первый шаг в декабре 1998 года был проект временной спецификации, которая просто переделывала HTML в XML без добавления каких-либо новых элементов и атрибутов. Эта спецификация позже стала известна как «XHTML 1.0 ». Она определила новый MIME-тип для документов XHTML - application/xhtml+xml . Однако для облегчения миграции существующих страниц HTML4, она также включила приложение C , которое «суммирует рекомендации по проектированию для авторов, желающих, чтобы их XHTML-документы отображались на существующих пользовательских агентах HTML». Приложение C говорит вам, что позволяет автору так называемых «XHTML» страниц, по-прежнему передавать их с MIME-типом text/html .
Следующая цель была веб-формы. В августе 1999 года та же Рабочая Группа HTML опубликовала первый проект XHTML Extended Forms . Она установила ожидания в первом абзаце:
После тщательного рассмотрения, Рабочая Группа HTML постановила, что цели следующего поколения форм не совпадают с сохранением обратной совместимости с браузерами, предназначенных для ранних версий HTML. Нашей целью является обеспечение чистоты новой модели форм (XHTML Extended Forms) на основе набора четко определенных требований. Эти требования описаны в данном документе и основаны на опыте с широким спектром приложений форм.
Несколько месяцев спустя «XHTML Extended Forms» был переименован в «XForms» и переехал в свою собственную Рабочую Группу. Эта группа работала параллельно с Рабочей Группой HTML и, наконец, опубликовала первую редакцию XForms 1.0 в октябре 2003 года.
Между тем, с переходом на XML полностью, Рабочая Группа HTML нацелилась на создание «следующего поколения HTML». В мае 2001 года она опубликовала первую редакцию XHTML 1.1 , в которой добавились только несколько незначительных особенностей вверху XHTML 1.0, но и устранилась лазейка «Приложения C». Начиная с версии 1.1, все XHTML-документы должны передаваться с MIME-типом application/xhtml+xml .
Все, что вы знаете об XHTML, неверно
Почему MIME-типы так важны? Почему я продолжаю возвращаться к ним? Три слова: драконовская обработка ошибок. Браузеры всегда были «снисходительны» с HTML. Если вы создали страницу HTML, но забыли тег , браузер все равно покажет страницу (некоторые теги неявно вызывают завершение
и начало ). Вы должны подразумевать иерархическую вложенность тегов - они закрываются в обратном порядке - но если вы создадите код вроде , браузеры обработают его (так или иначе) и двинутся дальше без отображения сообщения об ошибке.
Как и следовало ожидать, тот факт, что «ломаная» разметка HTML работает в браузерах, позволило авторам создавать ломаные HTML-страницы. Много ломаных страниц. По некоторым оценкам, более 99% HTML-страниц в вебе сегодня, содержат, по меньшей мере, одну ошибку. Но так как эти ошибки не заставляют браузеры отображать видимые сообщения об ошибках, никто никогда их не исправляет.
W3C увидел в этом фундаментальную проблему с вебом и стал исправлять ее. XML, опубликованный в 1997 году, вырвался из традиции прощать клиентов и постановил, что все программы, которые потребляют XML должны рассматривать так называемые «синтаксические» ошибки как фатальные. Эта концепция провала на первой же ошибке стала известна как «драконовская обработка ошибок», подобно греческому лидеру Драконту , кто учредил смертную казнь за малейшее нарушение его законов. Когда W3C переформулировал HTML как словарь XML, он поручил, что все документы, передаваемые с новым MIME-типом application/xhtml+xml , будут зависеть от драконовской обработки ошибок. Если есть хотя бы одна ошибка синтаксиса на XHTML-странице - такая как забытый тег или неверно вложенные начальные и конечные теги - у браузеров не будет иного выбора, кроме как остановить обработку и показать сообщение об ошибке конечному пользователю.
Эта идея не везде популярна. При оценке нормы ошибок в 99% на существующих страницах, повсеместной вероятности отображения ошибок конечному пользователю и нехватки новых возможностей в XHTML 1.0 и 1.1, для оправдания затрат авторы в основном игнорируют application/xhtml+xml . Но это не означает, что они игнорировали XHTML в целом. О, определенно нет. Приложение С спецификации XHTML 1.0 дало авторам мира лазейку: «Сделайте что-то, что выглядит подобно синтаксису XHTML, но позвольте передавать это с MIME-типом text/html ». И это именно то, что тысячи веб-разработчиков сделали: они «обновились» до синтаксиса XHTML, но продолжили передавать с MIME-типом text/html .
Даже сегодня, миллионы веб-страниц претендуют на XHTML. Они начинаются с XHTML доктайпа на первой строке, используют имена тегов в нижнем регистре, кавычки вокруг атрибутов и добавляют слэш после пустых элементов вроде
и
. Но только небольшая часть из этих страниц передается с MIME типом application/xhtml+xml , который включает драконовскую обработку ошибок XML. Любая страница переданная с MIME-типом text/html - независимо от доктайпа, синтаксиса или стиля кодирования - будет обрабатываться с помощью «снисходительного» анализатора HTML, молча игнорируя любые ошибки разметки и никогда не оповещая конечных пользователей (или кого-то еще) даже если страница технически нарушена.
XHTML 1.0 включил эту лазейку, но XHTML 1.1 закрыл ее, а незавершенный XHTML 2.0 продолжил традицию требования драконовской обработки ошибок. Именно поэтому есть миллиарды страниц, которые утверждают, что они XHTML 1.0 и только горстка, которые утверждают, что они XHTML 1.1 (или XHTML 2.0). Так вы действительно используете XHTML? Проверьте свой MIME-тип (на самом деле, если вы не знаете, какой MIME-тип используете, я могу почти гарантировать, что вы еще используете text/html ). Пока вы не передаете ваши страницы с MIME-типом application/xhtml+xml , ваш так называемый «XHTML» является XML только по названию.
Конкурентное видение
В июне 2004 года W3C провел семинар по Веб-приложениям и составным документам . На этом семинаре присутствовали представители трех браузеров, компании по веб-разработке и другие члены W3C. Группы заинтересованных сторон, включая Mozilla Foundation и Opera Software, рассказали о своих конкурентных видениях будущего веба: эволюция существующего стандарта HTML 4 включает новые возможности для современных разработчиков веб-приложений.
Следующие семь принципов отражают то, что мы считаем наиболее важными требованиями для этой работы.
Обратная совместимость, понятный путь миграции Технологии веб-приложений должны базироваться на технологиях знакомым авторам и включающим HTML, CSS, DOM и JavaScript. Основные характеристики веб-приложения должны выполняться с использованием поведения, скриптов и таблиц стилей в IE6 сегодня, так что авторы имеют понятный путь миграции. Любое решение, которое не может быть использовано текущим пользовательским агентом без необходимых плагинов, вероятно не может быть успешным. Обработка ошибок правильности построения Обработка ошибок в веб-приложениях должна быть определена на уровне детализации, где пользовательские агенты не должны изобретать свои собственные механизмы обработки ошибок или реверсивное проектирование других пользовательских агентов. Пользователи не должны подвергаться авторским ошибкам Спецификации должны указывать точное поведение восстановления для каждого возможного сценария ошибки. Обработка ошибок должна по большей части определяться в терминах изящного устранения ошибок (как в CSS), а не как очевидный и катастрофический сбой (как в XML). Практическое использование Каждая функция, которая идет в спецификации веб-приложения, должна быть обоснована практическим использованием. Обратное не всегда верно: каждый вариант использования не обязательно гарантирует новую функцию. Использовать аргументы предпочтительнее на базе реальных сайтов, где авторы ранее применяли плохое решение для обхода ограничения. Скрипты остаются Но их следует избегать там, где может быть использована удобная разметка. Скрипты должны быть нейтральными к устройствам и представлениям пока это возможно в конкретных устройствах (например, если они не включены в XBL). Следует избегать профиля конкретного устройства Авторы должны иметь возможность полагаться на те же функции, которые выполняются в настольных и мобильных версиях одного и того же пользовательского агента. Открытый процесс Веб принес пользу, потому что разрабатывался в открытой среде. Веб-приложения будет ядром веба и их разработчик должен пребывать в открытости. Списки рассылки, архивы и проекты спецификаций должны быть постоянно видимыми для общественности.
В неофициальном опросе участников семинара спросили: «Должен ли W3C развивать декларативное расширение HTML и CSS и обязательно дополнять DOM для решения требований среднего уровня веб-приложений, в отличие от сложных API полноценной ОС? (предложил Ян Хиксон, Opera Software)». Голосовали 11 за, 8 против. В своем резюме семинара , W3C написал: «В настоящее время W3C не намерен предоставлять любые ресурсы сторонней теме неофициального опроса: расширение HTML и CSS для веб-приложений, помимо технологий, разрабатываемых в соответствии с уставом текущей Рабочей Группы W3C».
Столкнувшись с этим решением, у людей, которые предложили развивать HTML и HTML-формы, было только два варианта: отказаться или продолжить свою работу за пределами W3C. Они выбрали последнее и зарегистрировали домен whatwg.org , так в июне 2004 года родилась WHAT Working Group .
WHAT Working Group?
Что еще за, черт побери, WHAT Working Group? Я позволю объяснить это им самим :
Рабочая группа по разработке гипертекстовых приложений для веб (WHAT Working Group) это свободное, неофициальное и открытое сотрудничество производителей браузеров и заинтересованных сторон. Группа направлена на разработку спецификаций на основе HTML и связанных с ним технологий, чтобы облегчить развертывание совместимых веб-приложений с целью предоставления результатов организации по стандартам. Это предоставление затем будет основой работы по формальному расширению HTML в курсе стандартов.
Создание этого форума следует из нескольких месяцев работы приватной переписки по спецификациям для каждых технологий. Основное внимание было уделено расширению форм HTML4 для поддержки функций по просьбе авторов, без нарушения обратной совместимости с существующим содержанием. Эта группа была создана, чтобы обеспечить будущее развитие этих спецификаций, и будет полностью открыта через публичные архивы, доступный список рассылки.
Ключевая фраза здесь «без нарушения обратной совместимости». XHTML (исключая лазейку Приложения C) не является обратно совместимым с HTML. Он требует совершенно новый MIME-тип, который включает драконовскую обработку ошибок для любого контента передаваемого с этим MIME-типом. XForms не совместимы с формами HTML, потому что они могут использоваться только в документах, которые передаются с новым MIME-типом XHTML, это означает, что XForms также включают драконовскую обработку ошибок. Все дороги ведут в MIME.
Вместо выбрасывания более десяти лет вложений в HTML и создания 99% существующих веб-страниц непригодными, WHAT Working Group решила принять другой подход: документированы «прощающие» алгоритмы обработки ошибок, которые фактически используется браузерами. Браузеры всегда прощают ошибки HTML, но никто никогда не удосужился написать, как именно они это сделали. NCSA Mosaic имеет свои собственные алгоритмы для работы с неправильными страницами, а Netscape пытался соответствовать им. Затем Internet Explorer пытается состязаться с Netscape. Затем Opera и Firefox пытаются состязаться с Internet Explorer. Затем Safari пытается состязаться с Firefox. И так далее, вплоть до наших дней. На этом пути разработчики сожгли тысячи и тысячи часов, пытаясь сделать свой продукт совместимым с конкурентами.
Если это звучит как безумное количество работы, то потому, что так и есть. Вернее, было. Потребовалось пять лет, но WHAT Working Group успешно документировала, как парсить HTML так, что это совместимо с существующим веб-контентом. В окончательном алгоритме нигде нет шага, который устанавливает, что HTML должен остановить обработку и показать сообщение об ошибке конечному пользователю.
Пока происходило реверсивное проектирование, WHAT Working Group тихо работала над некоторыми другими вещами. Одна из них была спецификация, первоначально дублирующая Web Forms 2.0 и добавляющая новые типы полей в HTML-формы (вы узнаете больше о веб-формах в ). Другой проект спецификации называется «Web Applications 1.0», который включал много новых возможностей вроде холста для непосредственного рисования и встроенную поддержку аудио и видео без плагинов.
Назад в W3C
Два с половиной года W3C и WHAT Working Group в основном игнорировали друг друга. Хотя WHAT Working Group сосредоточила внимание на веб-формах и новых функциях HTML, Рабочая Группа W3C по HTML была занята XHTML версии 2.0. Но к октябрю 2006 года стало понятно, что WHAT Working Group подняла серьезный импульс, в то время как XHTML 2 по-прежнему томится в черновой форме и не был реализован в каком-либо серьезном браузере. В октябре 2006 года Тим Бернерс-Ли, основатель W3C, объявил, что W3C будет работать вместе с WHAT Working Group над развитием HTML.
Некоторые вещи становятся понятны спустя несколько лет. Необходимо развивать HTML постепенно. Попытка получить мир переходом к XML, включая кавычки вокруг значений атрибутов и слэш в пустых тегах и пространство имен, все сразу не работает. Огромная сформированная вокруг HTML общественность не двигалась, в основном, потому что браузеры не жаловались. Некоторые крупные сообщества сделали сдвиг и пользуются плодами синтаксически правильных систем, но не все. Важно поддерживать HTML постепенно, а также продолжить переход к синтаксически правильному миру и развитие больших усилий в этом мире.
Планируется организовать совершенно новую HTML-группу. В отличие от предыдущей группы, она будет делать постепенные улучшения в HTML, а также параллельно XHTML. Она будет иметь другое руководство и штат сотрудников. Он будет работать над HTML и XHTML вместе. Мы имеем сильную поддержку этой группы от многих людей, о которых мы говорили, в том числе разработчиков браузеров.
Также будет работа с формами. Это сложная область, поскольку существующие HTML-формы и XForms являются языком форм. HTML-формы повсеместно развернуты и существует много реализаций и пользователей XForms. Между тем, WebForms подчиняются разумному расширению в HTML-формы. Планируется образовать WebForms в расширение HTML-форм.
Одной из первых вещей недавно организованной W3C HTML Working Group было решение переименовать «Web Applications 1.0» в «HTML5». И вот мы погружаемся в HTML5.
Постскриптум
В октябре 2009 года W3C закрыл Рабочую Группу XHTML 2 и выпустил заявление, объясняющее это решение:
Когда W3C анонсировал Рабочие Группы HTML и XHTML 2 в марте 2007 года, мы показали, что будем продолжать мониторинг рынка для XHTML 2. W3C признает важный четкий сигнал сообщества о будущем HTML.
Хотя мы признаем значение Рабочей Группы XHTML 2 на протяжении многих лет, после обсуждения с участниками руководство W3C решило устав Рабочей Группы, который истекает в конце 2009 года, не продлевать.
Выиграли от этого те, кто воплотил.
- Перевод
Примечание: это не полный перевод статьи. Я выбрал только самые интересные лично для себя пункты. Статья не претендует на свежесть, но возможно даже люди хорошо знакомые с версткой найдут для себя что-то интересное. Статья затрагивает некоторые аспекты семантики верстки с конкретными примерами.
Под катом много букв! Чтоб не потеряться в их обилии все пункты выделены заголовками.
2. Какие версии HTML существуют?
Первая версия HTML (1989) не имела номера версии; это был просто «HTML». Первая стандартизированная версия HTML, выпущенная Internet Engineering Task Force (IETF) в 1995, называлась HTML 2.0.7. Какая разница между Strict, Transitional и Frameset DTD"шками?
Разница между этими DTD в том, какие элементы и атрибуты они декларируют и в том, каким образом они позволяют (обязывают) соблюдать вложенность элементов.- HTML 4.01 Strict DTD - делает ударение на разделении содержимого от презентации и поведения. Эту DTD W3C рекомендует для всех новых документов.
- HTML 4.01 Transitional DTD - является неким промежуточным звеном при переходе от «старой» (old-scool"ьной, доHTMLьной) разметки к современной. Не рекомендуется использовать при написании новых документов. Содержит 11 презентационных элементов (прим. переводчика: не несущих смысловой нагрузки, а используемых исключительно для изменения внешниго вида; например элемент ) и полный набор презентационных атрибутов, которые отменены в Strict DTD. Transitional DTD часто необходима для страниц располагающихся внутри фреймов, т.к. она имеет атрибут target , необходимый для открытия ссылки в другом фрейме.
- HTML 4.01 Frameset DTD - используется для страниц на основе фреймов. Консорциум W3 не рекомендует использовать фреймы. Для современных сайтов более удачным решением будет использование приложений на стороне сервера для решения подобных задач.
8. Какой DOCTYPE выбрать?
Если мы создаем новую страницу, W3C рекомендует использовать HTML 4.01 Strict (прим. переводчика: конечно, всем известно, что всё-таки лучше использовать XHTML 1.0 Strict) .Если мы собираемся переводить старые HTML 2.0 или HTML 3.2 документы, то пока мы не перевели всю презентацию в CSS, а элементы, отвечающие за поведение в JavaScript, мы можем использовать HTML 4.01 Transitional.
11. Почему валидатор ругается на тэг
никогда не был частью HTML спецификации. Это не стандартизированный элемент, который хотя и поддерживается большинством браузеров, но не является частью HTML.На протяжении «войны браузеров» в конце 90-х, такие производители браузеров как Microsoft и Netscape соревновались, кто больше придумает «крутых» фич для стилизации и оформления HTML страниц. Проблема была в том, что эти фичи не были стандартизированными и, в большинстве случаев, были не кроссбраузерными.
Есть и другие элементы, которые достаточно широко использовались (например, marquee ), но никогда не были включены в спецификацию. По возможности никогда их не используйте.
Также были широко распространены нестандартизированные атрибуты. Один из примеров - marginwidth .
13. Что такое BOM?
BOM , или byte order mark (отметка последовательности байтов) - используется в некоторых кодировках, которые используют больше 8-ми бит для кодирования данных (например, UTF-8 или UTF-16). Процессор умеет использовать две разные схемы хранения больших целых чисел: «big-endian» (тупоконечная) и «little-endian» (остроконечная). BOM содержит 16 бит, записанных в самом начале файла, которые указывают браузерам, какая схема используется.К сожалению многие старые браузеры не могут обработать эту информацию, вместо этого они отображают эти биты как символьные данные. Если вы видите несколько странных символов вверху страницы, то это вероятнее всего означает, что BOM не был обработан браузером (или не верно была установлена кодировка).
Единственное решение проблемы - не использовать BOM. Редакторы, которые умеют сохранять документ в UTF-8 обычно позволяют выбрать, использовать или не использовать BOM.
14. Какую кодировку использовать?
Прим. переводчика: переводить этот пункт не стал; думаю, всем известно, что UTF-8 - это наше всё. Следует использовать UTF-8 . А при сохранении документа выбирать UTF-8 without BOM .16. Почему нужно писать & amp; вместо &?
Прим.: HTML-последовательности у меня написаны с пробелом после амперсанда, потому что в противном случае парсер Хабра их отображает не так как надо.Некоторые символы имеют особое значение в HTML: < (меньше), > (больше), & (амперсанд), " (кавычки), " (апостроф). Иногда, когда мы хотим использовать эти значки в обычном тексте, мы должны заменять их HTML-последовательностями.
Для первых четырех указанных выше знаков последовательности будут выглядеть так:
- & lt; (меньше)
- & gt; (больше)
- & amp; (амперсанд)
- & (кавычки)
Т.к. амперсанд используется во всех этих последовательностях, он всегда должен быть преобразован в HTML-последовательность, включая случаи, когда он используется внутри атрибутов, в частности в атрибуте href в ссылках. К сожалению амперсанд очень часто встречается в URI в качестве разделителя аргументов.
В большинстве случаев в HTML амперсанд не замененный последовательностью ничего не ломает (но XHTML - это другая история). Но что если нам случится столкнуться с параметром запроса, совпадающим с названием html-последовательности…
21. Что использовать,
Или
?
Элемент p
используется для выделения абзацев в тексте. Абзац - одно или больше предложений объединенных одной мыслью.
Перенос строки (br ) в основном используется как презентационный инструмент и должен скорее быть реализован на CSS чем на HTML. Впрочем, есть несколько ситуаций, когда перенос строки может иметь семантический смысл, например, при разметке строк в стихах и песнях, при написании почтовых адресов или при разметке примеров кода. В этих случаях использование br оправдано, но использование br для разделения абзацев не допустимо.
С другой стороны p имеет довольно четкое семантическое значение: разметка абзацев. Иногда веб-разработчики склонны рассматривать p как основной блочный для использование в качестве контейнеров, но это не верно. Не редкость увидеть элементы label и input внутри p в формах, но я бы назвал это семантически неверным. Метки и поля ввода не могут являться содержимым абзаца.
23. Стоит ли заменить и на и ?
Только если вы действительно хотите подчеркнуть что-то (сделать на чем-то ударение, выделить). Эти теги не являются равноценными.В Теперешние Не Менее Грустные Времена, авторы используют strong и em для того, чтобы сделать текст жирным или курсивом .
em означает семантическое ударение, усиление значения. Содержимое, к которому применяется такой вид выделения, должно иметь усиление во время прочтения вслух (например, громче или протяжнее). strong означает ещё большее ударение, но часто это считается излишним (можно использовать вложенные em для указания еще большего ударения). Некоторые эксперты советуют использовать strong только для определенных элементов на странице, которые однозначно должны быть выделенными (например, указатель «текущей страницы»), и не должны отмечать слова и фразы внутри основного текста.
b и i не имеют семантической нагрузки; они всего лишь меняют шрифт на жирный или курсив. Они хороши для использования в общепринятых типографских правилах, которые не нашли семантически подходящего HTML элемента. Например, названия кораблей традиционно отображаются курсивом, но в HTML нет элемента <корабль> . По этому можно записать Титаник.
27. Как правильно использовать элемент ?
address используется для указания контактной информации на странице. Это может быть почтовый адрес, номер телефона, любая другая контактная информация. address - блочный элемент, который может содержать только текст и inline-элементы. В большинстве браузеров по умолчанию отображается курсивом, но это легко исправить с помощью CSS.address может быть использован только для указания почтового адреса, но это не так.
28. Как правильно использовать элемент ?
dfn используется для «определения значений терминов». Это типографское соглашение, особенно общепринятое в научных документах, для выделения курсивом нового термина, с которым читатель возможно не знаком, когда определение появляется в тексте первый раз. По умолчанию dfn отображается курсивом.Общеизвестное заблуждение, что dfn означает «сокращение» и многие авторы используют его также как abbr и acronym (указывая пояснение к термину с помощью атрибута title). Термины должны отмечаться с помощью dfn в документах только один раз (при первом употреблении термина и его пояснении).
29. Как правильно использовать элемент ?
var используется для разметки переменных, или заменяемых частей текта. Это типографское соглашение, принятое для выделения переменных курсивом, которые в реальной жизни заменяются другими данными. Например, в руководстве к телефонным коммуникациям, инструкция по перенаправлению входящего телефонного звонка на другой дополнительный номер может выглядеть приблизительно так:* 21 * дополнительный номер #
Здесь тег var используется для указания «дополнительного номера» (который будет отмечен курсивом). Тот, кто захочет перенаправить звонок на дополнительный номер 942 напишет «21*942# ». Таким образом, var означает не то, что вы должны ввести «д-о-п-о-л-н-и-т-е-л-ь-н-ы-й н-о-м-е-р», а то, что вместо слов «дополнительный номер» будут цифры.
Общеизвестное заблуждение, что var должно использоваться для указания переменных в примерах программного кода.
31. Какая разница между тегами и ?
Никто толком не может дать ответ на этот вопрос! Даже спецификация HTML в какой-то степени противоречит сама себе.abbr было расширением Netscape для HTML на протяжении «войны браузеров». acronym было Майкрософтовским расширением. Оба варианта означают приблизительно одно и тоже. Оба элемента были включены в спецификацию HTML с разной семантической нагрузкой. Проблема в том, что никто толком не может объяснить, в чем заключается эта семантика.
Давайте обратимся к словарю:
Аббревиатура - сокращенная форма слова или фразы.
Акроним - слово, сформированное из первых букв или нескольких первых букв слов в составе фразы или нескольких слов.
Определение акронима говорит, что это слово, т.е. оно может быть произнесено. Таким образом, «NATO» является акронимом, т.к. состоит из начальных букв в словосочетании «North Atlantic Treaty Organization». Напротив, «FBI» не будет являться акронимом, в соответствии с определением, потому что его нельзя произнести как целое слово, а скорее оно будет звучать как «еф-би-ай». Вот тут то и начинает неразбериха. Технически известно, что «FBI» - это инициализм (прим. переводчика: в оригинале «initialism») , определение которого по словарю звучит так:
Инициализм - 1) название или термин, сформированный из первых букв или из нескольких первых букв слов, которые произносятся как отдельные слова; 2) группа первых букв означающих имя, организацию и т.д., которые произносяться отдельно.
Первое определение почти то же, что и акроним, а второе более отстраненное. Не смотря на это в спецификации нет элемента initialism , и путаница усугубляется тем, что слово «акроним» в простой американской речи используется как синоним слова «инициализм».
Спецификация HTML предлагает следующие определения:
abbr
- указывает на сокращенную форму (например, WWW, HTTP, URI, Mass и т.д.).
acronym
- указывает на акроним (например, WAC, radar и т.д.).
Похоже на то, что спецификация ссылается на словарные определения, что означает что «FBI» должно быть размечено тегом abbr , т.к. не может быть произнесено как целое слово. Не смотря на это, несколькими абзацами ниже спецификация говорит:
Западные языки широко используют такие акронимы как «GmbH», «NATO», и «F.B.I.», в качестве аббревиатур таких как «M.», «Inc.», «et al.», «etc.»
Вы еще не запутались? Я да. Безопаснее всего всегда использовать abbr , так как все акронимы также являются аббревиатурами, но не наоборот. Не смотря на это, тут есть небольшая проблема. Microsoft были так расстроены решением W3C использовать abbr для абревиатур и инициализмов вместо acronym , что они отказались от поддержки тега abbr ! (Но все же ввели поддержку abbr в Internet Explorer 7.)
Так что же делать бедным веб-разработчикам? И почему мы вообще должны заморачиваться? Конечно, хорошо иметь элемент, к которому можно прилепить атрибут title , но мы же это можем сделать и со span "ом. Суть в том, что размечать акронимы и аббревиатуры хорошо для смежных технологий; в частности для screen reader"ов. Но скрин ридеры в большинстве предпочитают игнорировать теги abbr и acronym , т.к. никто точно не знает, как правильно их использовать и Microsoft не поддерживает тег abbr . Это палка о двух концах.
Вопрос на этот ответ я не знаю! Лично я использую abbr для таких очевидных аббревиатур как «Inc.» и для таких инициализмов как «FBI», и использую acronym для сокращений, которые можно прочесть как слово, например «GIF». Но в соответствии со спецификацией я не могу никого обвинить в разметке «FBI» в качестве акронима. А как на счет «SQL», который некоторые произносят по буквам, а некоторые называют «сикуэл».
32. Почему отменяются определенные фичи?
Самая распространенная фича которой интересуются новички - это атрибут target . Этот атрибут запрещен в HTML 4.01 Strict, но до сих пор поддерживается в HTML 4.01 Transitional. Существует много элементов и атрибутов, которые разрешены в Transitional, но запрещены в Strict.Причина, по которой W3C отменяет некоторые элементы и атрибуты - желает разделить содержимое (HTML), внешний вид (CSS) и поведение (JavaScript). Заставить элемент отображаться по середине - это вопрос презентационный; он должен быть решен средствами CSS, а не с помощью тега center . Открыть ссылку в новом окне - это вопрос поведения; он должен решаться средствами JavaScript, а не с помощью атрибута target .
В основном, отмененные фичи - те, которые появились на протяжении войны браузеров в 90-х. Эти фичи были включены в HTML 3.2, чтобы хоть как-то навести порядок, но это не главная задача, которая стояла перед HTML. С релизом HTML 4, его авторы попытались «переучить Веб» убирая «пагубные» части, которые были включены в HTML 3.2, по крайней мере в Strict DTD.
Другими словами эти вещи отменены не просто так. По возможности старайтесь их не использовать.
37. Как подключить HTML страницу внутри другой страницы?
Если вы используете Strict DTD, то у вас есть только один валидный способ - использовать элемент object :
К сожалению поддержки object "а нет в Internet Explorer"е.
При использовании Transitional DTD можно использовать iframe "ы:
Лекция 2. Основы HTML . Возможности HTML 5.
1. История развития языка html
В 1989 году Тим Бернерс-Ли предложил руководству международного центра высоких энергий (CERN) проект распределенной гипертекстовой системы, которую он назвал World Wide Web (WWW), Всемирная паутина. Первоначально идея системы состояла в том, чтобы при помощи гипертекстовой навигационной системы объединить все множество информационных ресурсов CERN в единую информационную систему.
Одним из компонентов технологии создания распределенной гипертекстовой системы World Wide Web стал язык гипертекстовой разметки HTML (HyperText Markup Language – язык гипертекстовой разметки документов), разработанный Тимом Бернерсом-Ли на основе стандарта языка разметки печатных документов - SGML (Standard Generalised Markup Language, стандартный обобщенный язык разметки). Дэниел В. Конноли написал для него Document Type Definition - формальное описание синтаксиса HTML в терминах SGML.
Разработчики HTML смогли решить две задачи:
предоставить дизайнерам гипертекстовых баз данных простое средство создания документов;
сделать это средство достаточно мощным, чтобы отразить имевшиеся на тот момент представления об интерфейсе пользователя гипертекстовых баз данных.
Первая задача была решена за счет выбора теговой модели описания документа. Такая модель широко применяется в системах подготовки документов для печати.
Язык НТМL позволяет размечать электронный документ, который отображается на экране с полиграфическим уровнем оформления; результирующий документ может содержать самые разнообразные метки, иллюстрации, аудио- и видеофрагменты и так далее. В состав языка вошли развитые средства для создания различных уровней заголовков, шрифтовых выделений, различные списки, таблицы и многое другое.
Вторым важным моментом, повлиявшим на судьбу HTML, стало то, что в качестве основы был выбран обычный текстовый файл.
Таким образом, гипертекстовая база данных в концепции WWW - это набор текстовых файлов, размеченных на языке HTML, который определяет форму представления информации (разметка) и структуру связей между этими файлами и другими информационными ресурсами (гипертекстовые ссылки). Гипертекстовые ссылки, устанавливающие связи между текстовыми документами, постепенно стали объединять самые различные информационные ресурсы, в том числе звук и видео; в результате возникло новое понятие - гипермедиа.
Такой подход предполагает наличие еще одного компонента технологии - интерпретатора языка. В World Wide Web функции интерпретатора разделены между Web-сервером гипертекстовой базы данных и интерфейсом пользователя. Сервер, кроме доступа к документам и обработки гипертекстовых ссылок, обеспечивает предпроцессорную обработку документов, в то время как интерфейс пользователя осуществляет интерпретацию конструкций языка, связанных с представлением информации.
Версии
HTML 4.01 (изменения, причём более значительные, чем кажется на первый взгляд) - 24 декабря1999 года;
ISO/IEC 15445:2000 (так называемый ISO HTML, основан на HTML 4.01 Strict) - 15 мая2000 года.
HTML 5- в разработке. Конец разработки запланирован на 2014 год.
Официальной спецификации HTML 1.0 не существует. До 1995 года существовало множество неофициальных стандартов HTML. Чтобы стандартная версия отличалась от них, ей сразу присвоили второй номер.
Версия 3 была предложена Консорциумом всемирной паутины(W3C) в марте 1995 года и обеспечивала много новых возможностей, таких как создание таблиц, «обтекание» изображений текстом и отображение сложныхматематических формул, поддержка gif формата. Даже при том, что этот стандарт был совместим со второй версией, реализация его была сложна для браузеров того времени. Версия 3.1 официально никогда не предлагалась, и следующей версией стандарта HTML стала 3.2, в которой были опущены многие нововведения версии 3.0, но добавлены нестандартные элементы, поддерживаемые браузерамиNetscape NavigatorиMosaic.
В версии HTML 4.0 произошла некоторая «очистка» стандарта. Многие элементы были отмечены как устаревшие и нерекомендованные (англ.deprecated ). В частности, элемент font, используемый для изменения свойств шрифта, был помечен как устаревший (вместо него рекомендуется использовать таблицы стилейCSS).
В 1998 годуконсорциум Всемирной паутиныначал работу над новым языком разметки, основанном на HTML 4, но соответствующим синтаксису XML. Впоследствии новый язык получил названиеXHTML. Первая версия XHTML 1.0 одобрена в качестве Рекомендации консорциума Всемирной паутины26 января2000 года.
Планируемая версия XHTML 2.0 должна была разорвать совместимость со старыми версиями HTML и XHTML, но 2 июля 2009 годаконсорциум Всемирной паутиныобъявил, что полномочия рабочей группы XHTML2 истекают в конце2009 года. Таким образом, была приостановлена вся дальнейшая разработка стандарта XHTML 2.0.
В настоящее время Консорциум всемирной паутины разрабатывает HTML версии 5. Черновой вариант спецификации языка появился в Интернете 20 ноября 2007 года.