Продолжение. Первая часть была опубликована вчера.
Почему вы предпочли блочную модель, в которой отступы, границы и поля добавляются к заданной ширине, а не модель box-sizing: border-box из IE5?
Есть подходящие случаи использования для обеих моделей. Если вы хотите, чтобы изображение растягивалось, чтобы заполнить блок — оригинальная модель CSS подходит лучше. А если надо, чтобы поля и границы не выходили за пределы определённой области, лучше модель IE5. Лично я думаю, что случаев, для которых лучше подходит стандартная модель CSS, больше, но некоторые люди, которых я очень уважаю, считают иначе. Этот конфликт был изящно разрешён добавлением свойства box-sizing, которое сейчас поддерживают все браузеры.
Я никогда не любил абсолютное позиционирование. Я не прав? Как оно появилось в спецификации?
Ваш вопрос возвращает меня в 1996 год, когда по этому поводу шли жаркие дебаты. В двух словах: Microsoft предлагала ввести абсолютное позиционирование в черновике CSS Regions: Absolute Positioning and Z-Ordering (к сожалению, обсуждение проходило в закрытом списке рассылки W3C, вот ближайший по смыслу общедоступный документ). У некоторых членов сформированной недавно рабочей группы по CSS возникли сомнения, и Берт и я написали упрощенное встречное предложение. В нём мы предлагали избавиться от свойства position (и использовать вместо него display) и описали только относительно позиционирование (что давало нам время хорошенько продумать позиционирование абсолютное). Тем не менее, Microsoft уже реализовала собственное предложение и не хотела убирать эту функцию. В конце концов единственными существенными изменениями были добавление свойств right и bottom в дополнение к left и top и position: fixed. В таком виде спецификация стала частью стандарта CSS2.
Как и вам, мне никогда не было приятно работать с абсолютным позиционированием. Тем не менее, оно нашло своё место в веб-разработке, и иногда я его использую, чтобы сделать то, что по-другому сделать трудно или невозможно.
Иногда мне приходится слышать, что неправильно использовать плавающие блоки для вёрстки, так как они для этого «не предназначены» — они были задуманы только чтобы задавать обтекание картинок текстом. Разве это имеет значение, если такой метод верстки хорошо работает?
Обтекание картинок текстом — одна из базовых техник вёрстки, так что плавающие блоки безусловно могут использоваться в ней. Одно из направлений, в котором, по-моему должен развиваться стандарт CSS — разбитые на страницы презентации. Когда ваш контент явным образом разбит на страницы, плавающие блокаи становятся ещё более важными, так как можно привязывать их к верху и низу страницы.
Если бы у вас была волшебная палочка, какую часть CSS вы бы удалили бесследно, и что бы вы наоборот, добавили повсеместно?
Я бы выбросил любой код, привязанный к конкретным версиям браузеров, вроде <!--[if lt IE 7 ]>. Хотя, строго говоря, такие «комментарии» не являются частью CSS, они не должны использоваться нигде — они сильно понижают стандарты веба.
Вторая часть вашего вопроса гораздо интереснее. В 2006 году я бы добавил веб-шрифты. В 2007 — элемент <video> (если позволить себе ненадолго вторгнуться на территорию HTML). Сейчас обе эти возможности поддерживают все браузеры.
В 2011 году, видя, как многие приложения предпочитают разбивать контент на страницы, вместо использования скроллинга, я начал продвигать мысль о том, что веб-страницы должны стать настоящими страницами. Суть идеи состояла в том, что в стилях можно будет включить страничный режим, в котором содержимое документа разделяется на отдельные страницы. Их можно будет перелистывать жестами или клавишами PageUp и PageDown. Я хочу, чтобы в браузере было легко создавать приложения для чтения книг. Вот для этого мне бы пригодилась магия. У вас, случайно, не найдётся немного волшебной пыльцы, чтобы развеять её над подушками всех производителей браузеров?
По чему до сих пор нет способа сверстать страницу, который не требует двух высших образований? (Я говорю о тебе, flexbox...)
Вёрстка — сложное дело, а вёрстка для веба ещё сложнее, потому что страницы должны отображаться на множестве устройств. В CSS есть несколько механизмов для вёрстки, включая абсолютное позиционирование, плавающие блоки, многоколоночную вёрстку и таблицы. Сочетать эти механизмы бывает нелегко, но не думаю, что для этого нужны два высших образования. Правда, должен признаться, я пока не слишком много использовал flexbox.
Как вы относитесь к препроцессорам, таким как SASS и LESS? CSS есть чему у них поучиться?
Да, препроцессоры — полезная штука. Думаю нам стоит взять пяток самых популярных вещей из препроцессоров и включить их в состав CSS. Лично мне очень нравятся вложенные селекторы и однострочные комментарии (которые начинаются с //). Когда CSS исполнится 50 лет, я вам расскажу, почему они не были включены в стандарт с самого начала.
Вы один из членов WHATWG. Как вы туда попали?
WHATWG была сформирована, когда стало понятно, что W3C отходит от работы над HTML и концентрируется на составных документах, основанных на XHTML, XForms, SMIL и SVG. Для изготовителей браузеров HTML был слишком важен, чтобы вот так его забросить. Поэтому Ян Хиксон, который в то время работал вместе со мной в Opera, основал WHATWG, чтобы продолжить работу над паутиной, какой мы её знали. Кроме того, у нас вызвал сомнения майкрософтовский XAML, который представлял собой тонкий слой XML поверх проприетарного языка приложений. Поэтому WHATWG сконцентрировалась на веб-приложениях, а не на документах. Ян продолжает делать замечательную работу в качестве редактора стандарта HTML.
Вы отец CSS, и тем не менее вы недавно опубликовали несколько спецификаций под эгидой WHATWG, а не рабочей группы по CSS в составе W3C. Почему?
Действительно, над стандартами по иллюстрациям (CSS figures) и книгам (CSS books) сейчас работает именно WHATWG. Публикация стандартов в WHATWG имеет несколько важных преимуществ. Модель «живого стандарта» позволяет делать быстрые обновления с минимальными накладными расходами; в прошлом было очень трудно публиковать рабочие черновики W3C в этой области. Я горячо поддерживаю WHATWG в стремлении поддерживать стандарты в таком состоянии, чтобы они лишь слегка опережали текущий уровень реализации, а не уходили далеко вперёд, так что у разработчиков опускаются руки.
Последний вопрос: справляется ли CSS со своими задачами? Или может быть нам лучше прейти на другую модель, например Grid Style Sheets?
Итан Мансон и Филип М. Мэрден писали в 1999 году, что «языки стилей исследованы очень плохо». Это утверждение правдиво до сих пор, и попытки изучать и улучшать языки стилей можно только приветствовать.
GSS — это очень интересный пример, его создатели применяют алгоритм удовлетворения ограничений Cassowary к механизму таблиц стилей. В моей первоначальной реализации CSS я использовал для разрешения конфликтов между противоречивыми выражениям алгоритм SkyBlue. (Кстати, оба этих алгоритма разработаны в Вашингтонском университете.) Алгоритм удовлетворения ограничений позволяет выражать отношения между произвольными элементами и автомагически разрешать конфликты. Но всё значительно усложняется, когда элементы постоянно исчезают и добавляются, как это бывает при манипуляции с DOM. Так же нужно очень осторожно работать с кольцевыми зависимостями. Поэтому от идеи позволить CSS выражать ограничения вёрстки между любыми элементами пришлось отказаться на ранней стадии развития.
В прошлом, чтобы добавить поддержку нового стандарта, надо было убедить всех разработчиков браузеров потратить на это своё драгоценное время. Это становилось серьёзным препятствием, пожалуй даже слишком. В наши дни возможности браузеров можно расширять с помощью JavaScript. Стало гораздо легче ставить эксперименты и проводить исследования, которых давно заслуживают таблицы стилей.
Возвращаясь к вашему вопросу: справляется ли CSS со своими задачами? Я думаю, да. Я не вижу в обозримом будущем ничего, что заставило бы меня думать иначе. Появляются новые идеи, но они скорее расширяют CSS, чем заменяют. Я верю, что код CSS, который мы пишем сегодня, будет понятен компьютерам и через 500 лет.
Спасибо. С днем рождения, CSS!
Автор: ilya42
