Ранние будни
Вот с чего мы начали, и это отстой. Если вы хотели какой-либо согласованности на нескольких страницах, ваши варианты были очень ограничены, и они были в значительной степени ограничены большим количеством копирования и вставки. Сайт Space Jam решил, по большей части, вообще не беспокоиться - как и многие другие.
Потом появился CSS, это было чертовски здорово. Все это встроенное повторение ушло. Вы хотите, чтобы все ваши заголовки верхнего уровня были определенного цвета? Нет проблем:
Бам! Независимо от того, сколько
у вас есть в вашем документе, каждый из них будет ярко-красным, и вам никогда не придется думать об этом снова. Более того, вы можете поместить этот фрагмент в отдельный файл и применить этот сомнительный эстетический выбор к каждой странице всего сайта практически без усилий! То же самое относится и к вашему великолепному фоновому изображению, цветам ваших ссылок и размеру шрифта в ваших таблицах.
(Только не забудьте обернуть содержимое ваших тегов
в комментарии HTML, или старые браузеры без поддержки CSS будут отображать их как текст.)
Вы также не ограничивались массовым оформлением тегов. CSS ввел «классы» и «идентификаторы» для нацеливания только на специально помеченные элементы. Селектор типа
влияет только на
, а
влияет только на
. (Разница в том, что идентификаторы должны быть уникальными в документе, тогда как классы могут использоваться любое количество раз.) С помощью этих инструментов вы можете эффективно изобретать свои собственные теги, предоставляя вам индивидуальную версию HTML, специфичную для вашего веб-сайта!
Это был огромный шаг вперед, но в то время никто (скорее всего) не думал об использовании CSS для фактической организации страницы. Когда CSS 1 был рекомендован в декабре 1996 года, он почти не затрагивал макет. Все, что он сделал, это отделил существующие возможности HTML от тегов, к которым они были прикреплены. У нас были цвета шрифта и фон, потому что
и
, которое тянет изображение в сторону и позволяет тексту обтекать его, как в журнальной статье.
Это было не слишком удивительно. У HTML не было никаких реальных ответов для макета, кроме таблиц, и свойства таблицы были слишком сложны для обобщения в CSS и слишком запутаны в структуре тегов, поэтому CSS 1 не мог ничего унаследовать. Это просто уменьшило повторение того, что мы уже делали, например, Теги
- делают веб-дизайн менее тяжелым, менее подверженным ошибкам, менее шумным и намного более легким в обслуживании. Довольно хороший шаг вперед, и все с радостью приняли его за это, но
оставались главными для организации вашей страницы.
Это было хорошо, хотя; все, что действительно нужно вашему блогу, - это заголовок и боковая панель, и таблицы могут работать очень хорошо, и не похоже, что вы собираетесь пересматривать эту базовую структуру очень часто. Скопировать/вставить несколько строк
и
было не так уж сложно.
В течение некоторого промежутка времени - хочетса сказать пару лет, но время проходит медленнее, когда вы ребенок - это было состоянием Интернета. Таблицы для разметки,а CSS для ... ну, стиля. Цвета, размеры, жирность, подчеркивание. Был даже этот трюк, который вы могли сделать со ссылками, где они были бы подчеркнуты, только когда указатель мыши указывал на них. мммм!
(Интересный факт: электронная почта на HTML все еще в основном в ловушке той эпохи.)
(А вот о том, как я в зрелом возрасте 11 лет, не имея ни малейшего представления о том, что я делаю, и в основном учась у других 11-летних, которые также понятия не имели, что они делают. Но это было прекрасно; Огромный кусок интернета составляли 11-летние, делающие свои собственные сайты, и это было прекрасно. Зачем вам посещать бизнес-сайт, когда вы можете взглянуть на очень специфические увлечения кого-то на другом конце планеты? )
Темные времена
Спустя полтора года, в середине 98 года, мы получили
Использование position казалось приятным, но идеальное позиционирование с пикселями было в серьезном противоречии с плавным дизайном HTML, и было трудно сделать что-то, что не развалилось бы на экранах других размеров или имело бы другие серьезные недостатки. Эта скромная вещь в inline-block казалась достаточно интересной; в конце концов, это решило основную проблему макета HTML, которая заключается в том, чтобы положить вещи рядом друг с другом. Но, по крайней мере, на данный момент ни один браузер не реализовал это, и это было в значительной степени проигнорировано.
Я не могу точно сказать, было ли это введением позиционирования или каким-то другим фактором, но что-то в это время вдохновило людей попробовать сделать макет в CSS. В идеале вы должны полностью отделить структуру своей страницы от ее внешнего вида. Был даже веб-сайт, чтобы довести этот принцип до крайности -
Проблема была в том, что ранняя поддержка CSS была чертовски глючной. Оглядываясь назад, я подозреваю, что поставщики браузеров просто выдернули поведение из тегов HTML и назвали это днем. Я рад сообщить, что RichInStyle по-прежнему имеет обширный список ранних ошибок в браузере
Все же идея росла в популярности. Это даже стало своего рода элитарным сплетничающим криком, лучшей практикой, используемой, чтобы избивать других людей по голове. Столы для разметки просто плохие, вы услышите! Они путают программы чтения с экрана, они семантически неверны, они плохо взаимодействуют с позиционированием CSS! Все это правда, но глотать таблетку было гораздо сложнее, когда альтернатива была ...
Ну, мы вернемся к этому через минуту. Во-первых, некоторые сведения датируютса 2000 годом.
Конец войн браузера и сопутствующего застоя
Краткая версия такова: эта компания Netscape продавала свой браузер Navigator предприятиям (он был бесплатен для личного использования), а затем Microsoft вышла на рынок со своим совершенно бесплатным браузером Internet Explorer, а затем у Microsoft хватило смелости связать IE с Windows. Ты можешь представить? Операционная система, которая поставляется с браузером? Это было очень большое дело, на
Но это не имело бы значения в любом случае, потому что они все еще сделали это, и это сработало. IE практически уничтожил долю рынка Netscape. Оба браузера были глючными до чертиков, и по-разному глючными, как ад, поэтому сайт, созданный исключительно для одного, скорее всего, будет большим беспорядком при просмотре в другом - это означало, что когда доля Netscape на рынке падала, веб-дизайнеры обращали все меньше внимания это, и меньше сети работало в нём, и его доля рынка уменьшалась далее.
Думаю, это отстой, если вы не используете Windows. Что забавно, потому что был IE для Mac 5.5, и он был в целом менее глючным, чем IE 6. (Между прочим, Билл Гейтс не был таким же блестящим ботаником, как агрессивный и безжалостный бизнесмен, который сделал свое состояние, сознательно стремясь к уничтожению любой конкуренции, стоящую у него на пути, и в результате чего компьютер в целом не стал лучше.)
К моменту выпуска Windows XP в середине 2001 года со встроенным Internet Explorer 6 Netscape превратилась из огромного игрока в крошечного нишевого игрока.
И затем, целиком и полностью доминируя, Microsoft остановилась. Internet Explorer выпускал релиз каждый год или около того с момента своего появления, но IE 6 был последним выпуском на протяжении 5 лет. Он был все еще глючным, но это было менее заметно, когда не было соревнования, и это было достаточно хорошо. Windows XP, также, была достаточно хороша, чтобы захватить рабочий стол, и не будет новой Windows так же долго.
W3C, группа, которая пишет стандарты (не путать с W3Schools, сомнительными SEO-пиявками), также остановилась. HTML видел несколько изменений в середине 90-х, а затем замерз как HTML 4. CSS получил обновление всего через полтора года, незначительное обновление CSS 2.1 не получило статус рекомендации в кандидаты до начала 2004 года, и для его завершения потребовалось еще семь лет.
С доминированием IE 6 все выглядело так, как будто весь Интернет застыл во времени. Стандарты не имели значения, потому что фактически был только один браузер, и все, что он делал, стало стандартом де-факто. По мере того как популярность Интернета росла, удушение IE также затрудняло использование любой другой платформы, кроме Windows, поскольку IE был только для Windows, и это было броском монеты, будет ли веб-сайт работать с любым другим браузером.
(Начали подозревать, что монополии плохи. Должен быть закон!)
В то же время, Netscape поставил себя в еще худшее положение, приняв решение переписать свой браузерный движок, кульминацией которого стал значительно более совместимый с стандартами Netscape 6 - ценой нескольких лет отсутствия на рынке. В это время IE достигнет максимума в 96%. С другой стороны, новый движок был открыт с открытым исходным кодом, как Mozilla Application Suite, что будет важно через несколько лет.
Прежде чем мы доберемся до этого, происходило еще кое-что.
Причудливый режим
Все ранние реализации CSS были пронизаны ошибками, но одна из них, пожалуй, самая печально известная ошибка CSS всех времен: ошибка блочной модели.
Видите ли, у блока (прямоугольное пространство, занимаемое элементом) есть несколько измерений: его собственная ширина и высота, затем окружающий пробел, называемый отступом, затем необязательная граница, а затем поле, отделяющее его от соседних блоков. CSS указывает, что все эти свойства являются аддитивными. Коробка с этими стилями:
… Таким образом, будет иметь ширину 124 пикселя от границы до границы.
IE 4 и Netscape 4, с другой стороны, использовали другой подход: они рассматривали ширину и высоту как измерения от границы до границы, и вычитали границу и отступы, чтобы получить ширину самого элемента. Один и тот же блок в этих браузерах будет иметь ширину 100 пикселей от границы до границы, а для контента останется 76 пикселей.
Этот конфликт со спецификацией не был идеальным, и IE 6 решил его исправить. К сожалению, простое внесение изменений будет означать полное разрушение дизайна большого количества веб-сайтов, которые ранее работали в IE и Netscape.
Поэтому команда IE пришла к очень странному компромиссу: они объявили старое поведение (вместе с несколькими другими серьезными ошибками) как «режим причуд» и сделали его по умолчанию. В новом «строгом режиме» или «стандартном режиме» нужно было выбрать, поместив «doctype» в начале документа перед тегом <html>. Это будет выглядеть примерно так:
Каждый должен был годами вставлять эту чертову неразбериху в начало каждого HTML-документа. (Позже HTML5 упростит его до
.) В ретроспективе это действительно странный способ выбрать правильное поведение CSS; doctypes были частью спецификации HTML с тех пор, когда это был
Самое смешное, что режим причуд по-прежнему существует и по-прежнему используется по умолчанию во всех браузерах двадцать лет спустя! Точные причуды менялись со временем, и, в частности, ни Chrome, ни Firefox не используют блочную модель IE даже в режиме причуд, но есть еще немало эмулируемых
Современные браузеры также имеют режим «почти стандартов», который имитирует только одну причуду, возможно, второй самый печально известный: если ячейка таблицы содержит только одно изображение, пространство под базовой линией удаляется. По обычным правилам CSS изображение находится внутри строки (в противном случае пустого) текста, что требует некоторого пространства, зарезервированного снизу для спусковых устройств - хвостов на буквах, подобных y. Ранние браузеры не справлялись с этим правильно, и некоторые веб-сайты строгого режима примерно с 2000 года полагаются на это - например, вырезая большое изображение и размещая фрагменты в ячейках таблицы, ожидая, что они будут отображаться вплотную друг к другу - отсюда промежуточный режим, чтобы держать их хромать.
Но вернемся к прошлому: хотя это, безусловно, было победой стандартов (и, следовательно, взаимодействия), оно создало новую проблему. Поскольку доминировал IE 6, а типы документов были необязательными, было мало веских причин для использования строгого режима. Другие браузеры в конечном итоге эмулировали его, и нестандартное поведение стало его собственным стандартом де-факто. Веб-дизайнеры, которые заботились о подобных вещах (и, к нашей чести, нас было много), сделали решительный призыв к включению строгого режима, поскольку это был абсолютно минимальный шаг к обеспечению совместимости с другими браузерами.
Рассвет и падение XHTML
Тем временем W3C утратил интерес к HTML в пользу разработки XHTML, попытки изменить HTML с использованием синтаксиса XML, а не SGML.
(Что такое SGML, спросите вы? Я не знаю. Никто не знает. Это грамматика HTML, на которой построен, и это единственная причина, по которой кто-то слышал об этом.)
К их чести, в то время было несколько веских причин сделать это. HTML, как правило, был написан от руки (как и сейчас), и все, что написано от руки, может иметь случайные ошибки. Браузеры не имели привычки прямо отказываться от ошибочного HTML, поэтому у них были разные методы исправления ошибок - и, как и во всем остальном, разные браузеры по-разному обрабатывали ошибки. Слегка искаженный HTML-код может хорошо работать в IE 6 (где «отлично работает» означает «делает то, на что вы рассчитывали»), но превращается в ужасный беспорядок во всем остальном.
Решением W3C был XML, потому что в начале 2000-х годов их решением было везде использовать на XML. Если вы не знаете, XML использует гораздо более явный и агрессивный подход к обработке ошибок - если ваш документ содержит ошибку разбора, весь документ недействителен. Это означает, что если вы сделаете ставку на XHTML и сделаете где-нибудь одну опечатку, вы ничего не получите. Просто "небольшая" ошибка.
А это отстой. На первый взгляд, это нормально, но учтите: универсальный XML обычно собирается динамически с библиотеками, которые обрабатывают документ как дерево, которым вы манипулируете, а затем превращаете все это в текст, когда вы закончите. Это отлично подходит для обычного использования XML в качестве сериализации данных, когда ваши данные уже являются деревом, и большая часть структуры XML проста и повторяется, и ее легко сжимать в функциях.
HTML не такой. HTML-документ имеет мало надежной повторяющейся структуры; даже этот пост в блоге, построенный в основном из тегов
, также содержит неожиданные
внутри основного текста и случайные
между абзацами. Это не весело выражать как древо. И это большое дело, потому что рендеринг на стороне сервера стал популярным примерно в то же время, и сгенерированный HTML был и все еще есть как соединенный с шаблонами, которые рассматривают его как текстовый поток.
Если бы HTML был написан только как полные статические документы, то XHTML мог бы сработать - вы пишете документ, вы видите его в браузере, вы знаете, что он работает, нет проблем. Но генерирование его динамически и риск того, что конкретные крайние случаи могут заменить весь ваш сайт непонятной ошибкой браузера? Это отстой.
Делу не помогало что мы начали слышать об этой новомодной Unicode-вещи в это время, и все еще не всегда было ясно, как именно с ним работать, и одной неверной последовательности UTF-8 достаточно что бы XML-документ считался уродливым!
И вот, после некоторых проблем, XHTML был в значительной степени забыт. Его наследие живет двумя способами:
1)Это заставило нас всех перестать использовать имена тегов в верхнем регистре! Вместо
, привет
. Видите ли, XML чувствителен к регистру, и все теги XHTML были определены в нижнем регистре, поэтому теги в верхнем регистре просто не будут работать. (Интересный факт: по сей день API-интерфейсы JavaScript сообщают об именах HTML-тегов в верхнем регистре.) Вероятно, это также имеет отношение к повышенной популярности подсветки синтаксиса; мы уже не пользовались блокнотом, как это было в 1997 году.
2)Группа людей все еще думает, что самозакрывающиеся теги необходимы. Видите ли, HTML имеет два вида тегов: контейнеры, такие как
, и маркеры, такие как
. Поскольку
не может ничего содержать, такого понятия, как
, не существует. XML, как общая грамматика, не имеет этого различия; каждый тег должен быть закрыт, но в качестве ярлыка вы можете написать
для обозначения
.
XHTML был мертв в течение многих лет, но по некоторым причинам я все еще вижу людей, пишущих
в обычных документах HTML. Вне XML этот слеш ничего не делает; HTML5 определил его по причинам совместимости, но он игнорируется. Это даже активно вредно, так как это может привести вас к мысли, что
- это пустой тег
- но в HTML это определенно не так!
Я скучаю по одной вещи в XHTML. Вы можете объединить его с XSLT, метаязыком XML-шаблонов, для создания шаблонов в браузере (т. е. Для размещения содержимого страницы в общем макете сайта) без использования сценариев. Это единственный способ, который когда-либо был возможен, и это было круто, когда это работало, но недостатки были слишком серьезными, когда нет. Кроме того, XSLT абсолютно чертовски непостижимо.
Оригинал:
Вот с чего мы начали, и это отстой. Если вы хотели какой-либо согласованности на нескольких страницах, ваши варианты были очень ограничены, и они были в значительной степени ограничены большим количеством копирования и вставки. Сайт Space Jam решил, по большей части, вообще не беспокоиться - как и многие другие.
Потом появился CSS, это было чертовски здорово. Все это встроенное повторение ушло. Вы хотите, чтобы все ваши заголовки верхнего уровня были определенного цвета? Нет проблем:
Код:
H1 {
color: #FF0000;
}
Код:
<h1>
(Только не забудьте обернуть содержимое ваших тегов
Код:
<style>
Вы также не ограничивались массовым оформлением тегов. CSS ввел «классы» и «идентификаторы» для нацеливания только на специально помеченные элементы. Селектор типа
Код:
P.important
Код:
<P CLASS = "важный">
Код:
#header
Код:
<H1 ID = "заголовок">
Это был огромный шаг вперед, но в то время никто (скорее всего) не думал об использовании CSS для фактической организации страницы. Когда CSS 1 был рекомендован в декабре 1996 года, он почти не затрагивал макет. Все, что он сделал, это отделил существующие возможности HTML от тегов, к которым они были прикреплены. У нас были цвета шрифта и фон, потому что
Код:
<FONT COLOR>
Код:
<BODY BACKGROUND>[CODE] существовали. Единственная особенность, которая даже отдаленно влияла на расположение объектов, - это свойство [CODE]float[.CODE], эквивалентное [CODE]<IMG ALIGN>
Это было не слишком удивительно. У HTML не было никаких реальных ответов для макета, кроме таблиц, и свойства таблицы были слишком сложны для обобщения в CSS и слишком запутаны в структуре тегов, поэтому CSS 1 не мог ничего унаследовать. Это просто уменьшило повторение того, что мы уже делали, например, Теги
Код:
<FONT>
Код:
tables
Это было хорошо, хотя; все, что действительно нужно вашему блогу, - это заголовок и боковая панель, и таблицы могут работать очень хорошо, и не похоже, что вы собираетесь пересматривать эту базовую структуру очень часто. Скопировать/вставить несколько строк
Код:
<TABLE BORDER = 0>
Код:
<TD WIDTH = 20%>
В течение некоторого промежутка времени - хочетса сказать пару лет, но время проходит медленнее, когда вы ребенок - это было состоянием Интернета. Таблицы для разметки,а CSS для ... ну, стиля. Цвета, размеры, жирность, подчеркивание. Был даже этот трюк, который вы могли сделать со ссылками, где они были бы подчеркнуты, только когда указатель мыши указывал на них. мммм!
(Интересный факт: электронная почта на HTML все еще в основном в ловушке той эпохи.)
(А вот о том, как я в зрелом возрасте 11 лет, не имея ни малейшего представления о том, что я делаю, и в основном учась у других 11-летних, которые также понятия не имели, что они делают. Но это было прекрасно; Огромный кусок интернета составляли 11-летние, делающие свои собственные сайты, и это было прекрасно. Зачем вам посещать бизнес-сайт, когда вы можете взглянуть на очень специфические увлечения кого-то на другом конце планеты? )
Темные времена
Спустя полтора года, в середине 98 года, мы получили
Ссылка скрыта от гостей
. (Кстати, мне нравится фон на этой странице.) Это было скромное обновление, которое устраняло несколько недостатков в различных областях, но самым интересным было добавление пары позиционирующих примитивов: свойство position, которое позволяет размещать элементы с точными координатами, и режим отображения inline-block , который позволяет вставлять элемент в строку текста, как это можно сделать с изображениями.Использование position казалось приятным, но идеальное позиционирование с пикселями было в серьезном противоречии с плавным дизайном HTML, и было трудно сделать что-то, что не развалилось бы на экранах других размеров или имело бы другие серьезные недостатки. Эта скромная вещь в inline-block казалась достаточно интересной; в конце концов, это решило основную проблему макета HTML, которая заключается в том, чтобы положить вещи рядом друг с другом. Но, по крайней мере, на данный момент ни один браузер не реализовал это, и это было в значительной степени проигнорировано.
Я не могу точно сказать, было ли это введением позиционирования или каким-то другим фактором, но что-то в это время вдохновило людей попробовать сделать макет в CSS. В идеале вы должны полностью отделить структуру своей страницы от ее внешнего вида. Был даже веб-сайт, чтобы довести этот принцип до крайности -
Ссылка скрыта от гостей
все еще существует, и демонстрирует тот же HTML, радикально преобразующийся в совершенно разные дизайны с применением различных таблиц стилей.Проблема была в том, что ранняя поддержка CSS была чертовски глючной. Оглядываясь назад, я подозреваю, что поставщики браузеров просто выдернули поведение из тегов HTML и назвали это днем. Я рад сообщить, что RichInStyle по-прежнему имеет обширный список ранних ошибок в браузере
Ссылка скрыта от гостей
; Вот некоторые из моих любимых:- IE 3 будет игнорировать все, кроме последнего тега
Код:
<style>
- IE 3 игнорирует псевдоклассы, поэтому
Код:
a: hover
- IE 3 и IE 4 рассматривали автоматические поля как ноль. На самом деле, я думаю, что это могло сохраняться вплоть до IE 6. Но это было нормально, потому что IE 6 также неправильно применял
Код:
text-align: center
- Если вы установите фоновое изображение для абсолютного URL, IE 3 попытается открыть изображение в локальной программе, как если бы вы загрузили его.
- Netscape 4 воспринимал селектор идентификаторов как
Код:
#id
- Netscape 4 не наследовал свойства - включая шрифт и цвет текста! - в ячейки таблицы.
- Netscape 4 применил свойства
Код:
<li>
- Если один и тот же элемент имеет как
Код:
float
Код:clear
Все же идея росла в популярности. Это даже стало своего рода элитарным сплетничающим криком, лучшей практикой, используемой, чтобы избивать других людей по голове. Столы для разметки просто плохие, вы услышите! Они путают программы чтения с экрана, они семантически неверны, они плохо взаимодействуют с позиционированием CSS! Все это правда, но глотать таблетку было гораздо сложнее, когда альтернатива была ...
Ну, мы вернемся к этому через минуту. Во-первых, некоторые сведения датируютса 2000 годом.
Конец войн браузера и сопутствующего застоя
Краткая версия такова: эта компания Netscape продавала свой браузер Navigator предприятиям (он был бесплатен для личного использования), а затем Microsoft вышла на рынок со своим совершенно бесплатным браузером Internet Explorer, а затем у Microsoft хватило смелости связать IE с Windows. Ты можешь представить? Операционная система, которая поставляется с браузером? Это было очень большое дело, на
Ссылка скрыта от гостей
подали в суд, и они проиграли, и в результате ничего не произошло.Но это не имело бы значения в любом случае, потому что они все еще сделали это, и это сработало. IE практически уничтожил долю рынка Netscape. Оба браузера были глючными до чертиков, и по-разному глючными, как ад, поэтому сайт, созданный исключительно для одного, скорее всего, будет большим беспорядком при просмотре в другом - это означало, что когда доля Netscape на рынке падала, веб-дизайнеры обращали все меньше внимания это, и меньше сети работало в нём, и его доля рынка уменьшалась далее.
Думаю, это отстой, если вы не используете Windows. Что забавно, потому что был IE для Mac 5.5, и он был в целом менее глючным, чем IE 6. (Между прочим, Билл Гейтс не был таким же блестящим ботаником, как агрессивный и безжалостный бизнесмен, который сделал свое состояние, сознательно стремясь к уничтожению любой конкуренции, стоящую у него на пути, и в результате чего компьютер в целом не стал лучше.)
К моменту выпуска Windows XP в середине 2001 года со встроенным Internet Explorer 6 Netscape превратилась из огромного игрока в крошечного нишевого игрока.
И затем, целиком и полностью доминируя, Microsoft остановилась. Internet Explorer выпускал релиз каждый год или около того с момента своего появления, но IE 6 был последним выпуском на протяжении 5 лет. Он был все еще глючным, но это было менее заметно, когда не было соревнования, и это было достаточно хорошо. Windows XP, также, была достаточно хороша, чтобы захватить рабочий стол, и не будет новой Windows так же долго.
W3C, группа, которая пишет стандарты (не путать с W3Schools, сомнительными SEO-пиявками), также остановилась. HTML видел несколько изменений в середине 90-х, а затем замерз как HTML 4. CSS получил обновление всего через полтора года, незначительное обновление CSS 2.1 не получило статус рекомендации в кандидаты до начала 2004 года, и для его завершения потребовалось еще семь лет.
С доминированием IE 6 все выглядело так, как будто весь Интернет застыл во времени. Стандарты не имели значения, потому что фактически был только один браузер, и все, что он делал, стало стандартом де-факто. По мере того как популярность Интернета росла, удушение IE также затрудняло использование любой другой платформы, кроме Windows, поскольку IE был только для Windows, и это было броском монеты, будет ли веб-сайт работать с любым другим браузером.
(Начали подозревать, что монополии плохи. Должен быть закон!)
В то же время, Netscape поставил себя в еще худшее положение, приняв решение переписать свой браузерный движок, кульминацией которого стал значительно более совместимый с стандартами Netscape 6 - ценой нескольких лет отсутствия на рынке. В это время IE достигнет максимума в 96%. С другой стороны, новый движок был открыт с открытым исходным кодом, как Mozilla Application Suite, что будет важно через несколько лет.
Прежде чем мы доберемся до этого, происходило еще кое-что.
Причудливый режим
Все ранние реализации CSS были пронизаны ошибками, но одна из них, пожалуй, самая печально известная ошибка CSS всех времен: ошибка блочной модели.
Видите ли, у блока (прямоугольное пространство, занимаемое элементом) есть несколько измерений: его собственная ширина и высота, затем окружающий пробел, называемый отступом, затем необязательная граница, а затем поле, отделяющее его от соседних блоков. CSS указывает, что все эти свойства являются аддитивными. Коробка с этими стилями:
Код:
width: 100px;
padding: 10px;
border: 2px solid black;
IE 4 и Netscape 4, с другой стороны, использовали другой подход: они рассматривали ширину и высоту как измерения от границы до границы, и вычитали границу и отступы, чтобы получить ширину самого элемента. Один и тот же блок в этих браузерах будет иметь ширину 100 пикселей от границы до границы, а для контента останется 76 пикселей.
Этот конфликт со спецификацией не был идеальным, и IE 6 решил его исправить. К сожалению, простое внесение изменений будет означать полное разрушение дизайна большого количества веб-сайтов, которые ранее работали в IE и Netscape.
Поэтому команда IE пришла к очень странному компромиссу: они объявили старое поведение (вместе с несколькими другими серьезными ошибками) как «режим причуд» и сделали его по умолчанию. В новом «строгом режиме» или «стандартном режиме» нужно было выбрать, поместив «doctype» в начале документа перед тегом <html>. Это будет выглядеть примерно так:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Каждый должен был годами вставлять эту чертову неразбериху в начало каждого HTML-документа. (Позже HTML5 упростит его до
Код:
<! DOCTYPE html>
Ссылка скрыта от гостей
. Я предполагаю, что идея заключалась в том, что, поскольку никто не удосужился включить его, это был удобный способ разрешить вход, не требуя запатентованных расширений, просто чтобы избежать поведения, которое было изначально неправильным. Хорошо для команды IE!Самое смешное, что режим причуд по-прежнему существует и по-прежнему используется по умолчанию во всех браузерах двадцать лет спустя! Точные причуды менялись со временем, и, в частности, ни Chrome, ни Firefox не используют блочную модель IE даже в режиме причуд, но есть еще немало эмулируемых
Ссылка скрыта от гостей
.Современные браузеры также имеют режим «почти стандартов», который имитирует только одну причуду, возможно, второй самый печально известный: если ячейка таблицы содержит только одно изображение, пространство под базовой линией удаляется. По обычным правилам CSS изображение находится внутри строки (в противном случае пустого) текста, что требует некоторого пространства, зарезервированного снизу для спусковых устройств - хвостов на буквах, подобных y. Ранние браузеры не справлялись с этим правильно, и некоторые веб-сайты строгого режима примерно с 2000 года полагаются на это - например, вырезая большое изображение и размещая фрагменты в ячейках таблицы, ожидая, что они будут отображаться вплотную друг к другу - отсюда промежуточный режим, чтобы держать их хромать.
Но вернемся к прошлому: хотя это, безусловно, было победой стандартов (и, следовательно, взаимодействия), оно создало новую проблему. Поскольку доминировал IE 6, а типы документов были необязательными, было мало веских причин для использования строгого режима. Другие браузеры в конечном итоге эмулировали его, и нестандартное поведение стало его собственным стандартом де-факто. Веб-дизайнеры, которые заботились о подобных вещах (и, к нашей чести, нас было много), сделали решительный призыв к включению строгого режима, поскольку это был абсолютно минимальный шаг к обеспечению совместимости с другими браузерами.
Рассвет и падение XHTML
Тем временем W3C утратил интерес к HTML в пользу разработки XHTML, попытки изменить HTML с использованием синтаксиса XML, а не SGML.
(Что такое SGML, спросите вы? Я не знаю. Никто не знает. Это грамматика HTML, на которой построен, и это единственная причина, по которой кто-то слышал об этом.)
К их чести, в то время было несколько веских причин сделать это. HTML, как правило, был написан от руки (как и сейчас), и все, что написано от руки, может иметь случайные ошибки. Браузеры не имели привычки прямо отказываться от ошибочного HTML, поэтому у них были разные методы исправления ошибок - и, как и во всем остальном, разные браузеры по-разному обрабатывали ошибки. Слегка искаженный HTML-код может хорошо работать в IE 6 (где «отлично работает» означает «делает то, на что вы рассчитывали»), но превращается в ужасный беспорядок во всем остальном.
Решением W3C был XML, потому что в начале 2000-х годов их решением было везде использовать на XML. Если вы не знаете, XML использует гораздо более явный и агрессивный подход к обработке ошибок - если ваш документ содержит ошибку разбора, весь документ недействителен. Это означает, что если вы сделаете ставку на XHTML и сделаете где-нибудь одну опечатку, вы ничего не получите. Просто "небольшая" ошибка.
А это отстой. На первый взгляд, это нормально, но учтите: универсальный XML обычно собирается динамически с библиотеками, которые обрабатывают документ как дерево, которым вы манипулируете, а затем превращаете все это в текст, когда вы закончите. Это отлично подходит для обычного использования XML в качестве сериализации данных, когда ваши данные уже являются деревом, и большая часть структуры XML проста и повторяется, и ее легко сжимать в функциях.
HTML не такой. HTML-документ имеет мало надежной повторяющейся структуры; даже этот пост в блоге, построенный в основном из тегов
Код:
<p>
Код:
<em>
Код:
<h2>
Если бы HTML был написан только как полные статические документы, то XHTML мог бы сработать - вы пишете документ, вы видите его в браузере, вы знаете, что он работает, нет проблем. Но генерирование его динамически и риск того, что конкретные крайние случаи могут заменить весь ваш сайт непонятной ошибкой браузера? Это отстой.
Делу не помогало что мы начали слышать об этой новомодной Unicode-вещи в это время, и все еще не всегда было ясно, как именно с ним работать, и одной неверной последовательности UTF-8 достаточно что бы XML-документ считался уродливым!
И вот, после некоторых проблем, XHTML был в значительной степени забыт. Его наследие живет двумя способами:
1)Это заставило нас всех перестать использовать имена тегов в верхнем регистре! Вместо
Код:
<BODY>
Код:
<body>
2)Группа людей все еще думает, что самозакрывающиеся теги необходимы. Видите ли, HTML имеет два вида тегов: контейнеры, такие как
Код:
<p> ... </ p>
Код:
<br>
Код:
<br>
Код:
</br>
Код:
<br/>
Код:
<br> </br>
XHTML был мертв в течение многих лет, но по некоторым причинам я все еще вижу людей, пишущих
Код:
<br/>
Код:
<script />
Код:
<script>
Я скучаю по одной вещи в XHTML. Вы можете объединить его с XSLT, метаязыком XML-шаблонов, для создания шаблонов в браузере (т. е. Для размещения содержимого страницы в общем макете сайта) без использования сценариев. Это единственный способ, который когда-либо был возможен, и это было круто, когда это работало, но недостатки были слишком серьезными, когда нет. Кроме того, XSLT абсолютно чертовски непостижимо.
Оригинал:
Ссылка скрыта от гостей