• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

Гостевая статья "История CSS: Старый CSS, Новый CSS" Часть вторая

Ранние будни
Вот с чего мы начали, и это отстой. Если вы хотели какой-либо согласованности на нескольких страницах, ваши варианты были очень ограничены, и они были в значительной степени ограничены большим количеством копирования и вставки. Сайт Space Jam решил, по большей части, вообще не беспокоиться - как и многие другие.

Потом появился CSS, это было чертовски здорово. Все это встроенное повторение ушло. Вы хотите, чтобы все ваши заголовки верхнего уровня были определенного цвета? Нет проблем:
Код:
H1 {
    color: #FF0000;
}
Бам! Независимо от того, сколько
Код:
<h1>
у вас есть в вашем документе, каждый из них будет ярко-красным, и вам никогда не придется думать об этом снова. Более того, вы можете поместить этот фрагмент в отдельный файл и применить этот сомнительный эстетический выбор к каждой странице всего сайта практически без усилий! То же самое относится и к вашему великолепному фоновому изображению, цветам ваших ссылок и размеру шрифта в ваших таблицах.

(Только не забудьте обернуть содержимое ваших тегов
Код:
<style>
в комментарии HTML, или старые браузеры без поддержки CSS будут отображать их как текст.)

Вы также не ограничивались массовым оформлением тегов. CSS ввел «классы» и «идентификаторы» для нацеливания только на специально помеченные элементы. Селектор типа
Код:
P.important
влияет только на
Код:
<P CLASS = "важный">
, а
Код:
#header
влияет только на
Код:
<H1 ID = "заголовок">
. (Разница в том, что идентификаторы должны быть уникальными в документе, тогда как классы могут использоваться любое количество раз.) С помощью этих инструментов вы можете эффективно изобретать свои собственные теги, предоставляя вам индивидуальную версию HTML, специфичную для вашего веб-сайта!

Это был огромный шаг вперед, но в то время никто (скорее всего) не думал об использовании 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
    будет рассматриваться как a.
  • IE 3 и IE 4 рассматривали автоматические поля как ноль. На самом деле, я думаю, что это могло сохраняться вплоть до IE 6. Но это было нормально, потому что IE 6 также неправильно применял
    Код:
    text-align: center
    для блокировки элементов.
  • Если вы установите фоновое изображение для абсолютного URL, IE 3 попытается открыть изображение в локальной программе, как если бы вы загрузили его.
  • Netscape 4 воспринимал селектор идентификаторов как
    Код:
    #id
    , но игнорировал [/CODE]h1 # id[/CODE] как недействительный.
  • Netscape 4 не наследовал свойства - включая шрифт и цвет текста! - в ячейки таблицы.
  • Netscape 4 применил свойства
    Код:
    <li>
    к маркеру списка, а не к содержимому.
  • Если один и тот же элемент имеет как
    Код:
    float
    , так и
    Код:
    clear
    (не без оснований), Netscape 4 для Mac вылетает.
Это то, с чем нам пришлось работать. И люди хотели использовать CSS, чтобы выложить всю страницу? Ха.
Все же идея росла в популярности. Это даже стало своего рода элитарным сплетничающим криком, лучшей практикой, используемой, чтобы избивать других людей по голове. Столы для разметки просто плохие, вы услышите! Они путают программы чтения с экрана, они семантически неверны, они плохо взаимодействуют с позиционированием 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;
… Таким образом, будет иметь ширину 124 пикселя от границы до границы.

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>
.) В ретроспективе это действительно странный способ выбрать правильное поведение CSS; doctypes были частью спецификации 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 был и все еще есть как соединенный с шаблонами, которые рассматривают его как текстовый поток.

Если бы HTML был написан только как полные статические документы, то XHTML мог бы сработать - вы пишете документ, вы видите его в браузере, вы знаете, что он работает, нет проблем. Но генерирование его динамически и риск того, что конкретные крайние случаи могут заменить весь ваш сайт непонятной ошибкой браузера? Это отстой.

Делу не помогало что мы начали слышать об этой новомодной Unicode-вещи в это время, и все еще не всегда было ясно, как именно с ним работать, и одной неверной последовательности UTF-8 достаточно что бы XML-документ считался уродливым!

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

1)Это заставило нас всех перестать использовать имена тегов в верхнем регистре! Вместо
Код:
<BODY>
, привет
Код:
<body>
. Видите ли, XML чувствителен к регистру, и все теги XHTML были определены в нижнем регистре, поэтому теги в верхнем регистре просто не будут работать. (Интересный факт: по сей день API-интерфейсы JavaScript сообщают об именах HTML-тегов в верхнем регистре.) Вероятно, это также имеет отношение к повышенной популярности подсветки синтаксиса; мы уже не пользовались блокнотом, как это было в 1997 году.

2)Группа людей все еще думает, что самозакрывающиеся теги необходимы. Видите ли, HTML имеет два вида тегов: контейнеры, такие как
Код:
<p> ... </ p>
, и маркеры, такие как
Код:
<br>
. Поскольку
Код:
<br>
не может ничего содержать, такого понятия, как
Код:
</br>
, не существует. XML, как общая грамматика, не имеет этого различия; каждый тег должен быть закрыт, но в качестве ярлыка вы можете написать
Код:
<br/>
для обозначения
Код:
<br> </br>
.

XHTML был мертв в течение многих лет, но по некоторым причинам я все еще вижу людей, пишущих
Код:
<br/>
в обычных документах HTML. Вне XML этот слеш ничего не делает; HTML5 определил его по причинам совместимости, но он игнорируется. Это даже активно вредно, так как это может привести вас к мысли, что
Код:
<script />
- это пустой тег
Код:
<script>
- но в HTML это определенно не так!

Я скучаю по одной вещи в XHTML. Вы можете объединить его с XSLT, метаязыком XML-шаблонов, для создания шаблонов в браузере (т. е. Для размещения содержимого страницы в общем макете сайта) без использования сценариев. Это единственный способ, который когда-либо был возможен, и это было круто, когда это работало, но недостатки были слишком серьезными, когда нет. Кроме того, XSLT абсолютно чертовски непостижимо.

Оригинал:
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!