Подписка на блог

В Телеграме помимо ссылок на заметки делюсь околодизайнерскими наблюдениями.

В Твиттере помимо ссылок на заметки пишу всякую чушь.

В Тумблере и Же-же есть автоматические трансляции. Если не работает, напишите мне: ilyabirman@ilyabirman.ru.

По РСС и Джейсон-фиду трансляции для автоматических читалок

ЦСС

Абсолютно относительно

В ЦССе постоянно приходится делать абсолютно позиционированные элементы внутри относительно позиционированных, чтобы «привязаться» к какой-то плавающей точке в нормал-флоу. Это тупизм, потому что это вынуждает в разметке добавлять лишние элементы. Например, нам надо пририсовать к слову значок суффикса, который у нас есть в виде гифовой картинки. Вот что хочется писать в разметке:

слов<img class="suffix" src="i/suffix.gif" />ечко

Но что написать в стилях?

.suffix {
  position: ???
  width: 1.5em; /* на три буквы чтоб */
  bottom: -1em;
}


Относительно позиционированный элемент занимает собой места в нормал-флоу столько же, сколько непозиционированный, а потом может быть сдвинут относительно этого места так, что нормал-флоу этого не заметит. В нашем случае это не подходит, потому что будет разрыв между «слов» и «ечко» шириной в картинку.

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

Поэтому всё время приходится делать так:

слов<span class="suffix"><img src="i/suffix.gif" /></span>ечко

.suffix { position: relative }
.suffix img {
  position: absolute;
  width: 1em;
  bottom: -1em;
}


Спан, конечно, красивее было бы закрыть после «ечк», но это не про семантику заметка. Так вот, весь этот спан, получается, существует только для того, чтобы задать «систему координат» для картинки. Но ведь она уже задана тем, куда вы воткнули эту картинку в разметке!

Так почему было не придумать какой-нибудь position: anchored, который бы участвовал в нормал-флоу, но с точки зрения нормал-флоу имел бы размеры 0 на 0? Можно было бы развить идею, введя anchored-x и anchored-y, чтобы, допустим, сделать сноски на поля, висящие на уровне того места, откуда на них ссылаются. Атрибут position: anchored-y означал бы, что left / right для этого элемента имеют смысл по принципу position: absolute; а top / bottom — по принципу position: anchored, т. е. относительно точки, где элемент встретился в разметке. Тогда текст, снесённый на поля, можно было бы размечать так:

Пушкин писал<sup>1</sup><div class="sidenote"><sup>1</sup> В «Капитанской дочке»</div>: «Береги честь смолоду».

.sidenote {
  position: anchored-y;
  left: 110%; /* чтобы отступить от самого текста 10% его ширины */
  top: 0;
}


Почему создатели стандартов придумывают всякую хрень (вроде box-shadow или анимации) раньше, чем решают базовые задачи вёрстки?

Добавлено несколько позже: Оказывается, я ничего не понимаю в вёрстке. Спасибо комментаторам за прояснение ситуации.

Верхние и нижние индексы, не портящие вид текста

Для нижних и верхних индексов в ХТМЛе есть элементы sub и sup. К сожалению, при использовании их в тексте равенство высот строк ломается, и образуются неприятные дыры:

Верхние и нижние индексы, портящие высоту строки

Но ведь мы знаем, что элементы выглядят в браузере так, как выглядят, лишь потому, что про них написано что-то во встроенной таблице стилей браузера (иногда, правда, воображаемой).

Элементы sub и sup для выравнивания используют свойство vertical-align со значениями sub или super. Именно они и влияют на высоту строки. Стало быть, нам нужно вместо них использовать какой-нибудь vertical-align, оставляющий строку прежней высоты, и сдвигать индексы иным способом, например, с помощью position: relative.

Я уже давно почти везде использую примерно вот такую конструкцию:

sup, sub {
  vertical-align: middle;
  position: relative;
  font-size: 75%;
}
sup { bottom: 0.5em; }
sub { top: 0.5em; }


В результате получается нормальный текст:

Верхние и нижние индексы, не портящие высоту строки

О фиксированном позиционировании в CSS

Верстальщики недолюбливают компанию «Микрософт» за жуткую глючность и непоследовательность IE в разборе и отображении CSS. Но есть две вещи, которые компания «Микрософт» сделала правильнее, чем все остальные.
  1. Компания «Микрософт» забила на идиотский стандарт, согласно которому шириной бокса является ширина его содержимого, а не ширина самого бокса, и предпочла использовать здравый смысл. Когда стандартизаторы поняли, какую ахинею они придумали, они добавили свойство box-sizing, и поэтому теперь мы имеем возможность верстать страницы нормально под всеми браузерами.
  2. Компания «Микрософт» не реализовала поддержку идиотского значения атрибута position: fixed. Благодаря этому такого извращения нет почти ни на каких сайтах.
В «Техногрете» появилась статья Андрея Шитова, где он рассказывает о способе заставить position: fixed работать в IE. Несколько раньше на сайте Ромы Воронежского появился этот ужас «в действии».

Это совершеннейший интерфейсный кошмар, заставляющий прокрутку в браузере работать не так, как она работает во всех остальных приложениях в мире. Когда менюшка расположена в верхней части экрана, тебе кажется, что ты находишься и в самой верхней точке прокрутки — но на самом деле можно крутить ещё и ещё. Часть страницы сверху уже «упёрлась» в край, а у части начало было явно где-то выше, потому, что строки торчат из-за верней границы. К этому невозможно привыкнуть, и это не укладывается в голове нормального человека — как теория об искривлённости пространства.

Если очень-очень надо, чтобы крутилась только часть страницы, то скроллинг должен быть именно вокруг этой части. Это делается фреймами или дивом, у которого overflow: scroll. У всего этого есть ещё целая куча недостатков, про которые можно рассказывать часами (хотя бы то, что скролбар, не упёртый в правый угол, имеет маленькую ширину, и в него приходиться целиться).

Давно известно, что техническая возможность что-либо сделать не может являться поводом это делать. Не нужно разукрашивать скролбар в разные цвета, не нужно делать бегущую строку тегом <marquee>, не нужно подвешивать менюшки с помощью position: fixed. Это «прикольно», но пользователя всё это бесит.
 27 комментариев    49   2007   веб-дизайн   ЦСС

Маркированные списки

Одной из претензий нормоконтролёра к моей пояснительной записке было использование маркированных списков с буллетами. Вот таких:

Список маркированный буллетами

Нормоконтролёр называл буллеты кляксами и утверждал, что таких символов в русском языке не бывает. Я не очень-то ему верил, в чём честно признался. Как же не бывает, вон они, повсюду!

В любом случае, мне было предложено избавиться от маркированных списков, заменив их нумерованными. Аргумент: в техническом документе должны быть возможность на любой «объект» сослаться по нормальному идентификатору, а не словами вроде «ну, там, где у вас ещё говорится о том-то». Нормоконтролёр сказал, что готов мне простить буллеты в списках из 2-3 элементов, но не в более длинных. Аргумент про возможность сослаться мне представился бесспорным.

Придя домой, я заглянул в справочник и обнаружил там вот что:
Знак тире (кружок, ромбик и т. п.) [рекомендуется употреблять в случае, если] перечень не требует запоминания его элементов в определённом порядке или элементы перечня относятся к самой низшей ступени, когда либо остальные техн. средства обозначения уже использованы, либо по значимости данный перечень относится к низшей ступени в сопоставлении с аналогичными элементами в других перечнях.

Мильчин А. Э., Чельцова Л. К. Справочник издателя и автора. Редакционно-издательское оформление издания. — М: Олимп, 1998; стр. 39
Это написано уже после того, как перечислено несколько способов нумерации, что косвенно подтверждает её предпочтительность. Также обратим внимание, что «кляксы» перечисляются в скобках, а основным символом называется знак тире. Я помню, что в школьных учебниках использовалось именно оно, но многие годы работы с Word и CSS отучили от этого символа совершенно. Попробовав заменить в Word’е в стиле «маркированный» буллет на тире, я обнаружил, что так действительно смотрится лучше:

Список маркированный тире

На вторую попытку прохождения нормоконтроля я пришёл довольным, а ушёл, оставив довольным и нормоконтролёра (по крайней мере, в этой части).

Теперь захотелось посмотреть, как будут смотреться списки с тире на вебе. Но что же делать с CSS? В нём мне не удалось найти никакого способа использовать тире вместо буллетов. Даже в CSS 3. Возможно, я просто чего-то не увидел? Подскажите, кто разбирается (картинки не предлагать).

Border East Color

Обнаружил, что оказывается свойства типа -moz-box-sizing соответствуют стандарту. В том смысле, что W3C резервируют синтаксис -id-blah-blah для расширений разных браузеров и даже перечисляет уже известные префиксы (-moz-, -o-, -atsc- и -wap-) прямо в спецификации.

Чувством юмора они тоже не обделены:
For example, if XYZ organization added a property to describe the color of the border on the East side of the display, they might call it -xyz-border-east-color.
 5   2005   смешное   ссылки   ЦСС

IE7 узнает о существовании стандартов

Из IEBlog:
In IE7, we will fix as many of the worst bugs that web developers hit as we can, and we will add the critical most-requested features from the standards as well.

<...>

In addition we’ve added support for the following 
  • HTML 4.01 ABBR tag
  • Improved (though not yet perfect) <object> fallback
  • CSS 2.1 Selector support (child, adjacent, attribute, first-child etc.)
  • CSS 2.1 Fixed positioning
  • Alpha channel in PNG images
  • Fix :hover on all elements
  • Background-attachment: fixed on all elements not just body
<...>

We fully recognize that IE is behind the game today in CSS support. We’ve dug through the Acid 2 Test and analyzed IE’s problems with the test in some great detail, and we’ve made sure the bugs and features are on our list — however, there are some fairly large and difficult features to implement, and they will not all sort to the top of the stack in IE7. I believe we are doing a much better service to web developers out there in IE7 by fixing our known bang-your-head-on-the-desk bugs and usability problems first, and prioritizing the most commonly-requested features based on all the feedback we’ve had.
Неужели скоро жизнь наладится?..

Три маленьких открытия

Так не бывает, чтобы сверстал сайт, а он — хоба-на — работает во всех браузерах отлично. Каждый раз приходится что-то подкручивать, подделывать. Но с другой стороны, благорадря этому узнаёшь всё больше разного. Сегодня я узнал три разного.

1. Как заставить IE нормально понимать z-index?

Есть такая проблема, что IE применяет z-index’ы не ко всему документу, а как-то выборочно. Например, относительно позиционированный элемент оказывается «ближе к пользователю», чем статический, даже если его z-index меньше. Создаётся впечатление, что каждый relative-элемент создаёт своё пространство z-индексов.

Исследования показали, однако, что это ложное впечатление. На самом деле своё пространство z-индексов едино для всех относительных элементов. Таким образом, проблема решается просто путём изменения статического элемента на относительный. По идее, других проблем это вызвать не должно?

2. Как в Mozilla изобразить overflow-x/overflow-y?

У меня тут ситуация такова, что на странице почти обязательно появляется горизонтальный скроллинг (по смыслу), но видимым он быть не должен. В IE эта проблема решается вот так:

overflow-x: hidden;

Но на самом деле свойства overflow-x и overflow-y придумали в Microsoft, а W3C про них ничего не знают. Как же сделать это в Мозилле? А вот так:

overflow: -moz-scrollbars-vertical;

Итого имеем:

body {
  overflow: -moz-scrollbars-vertical;
  overflow-x: hidden;
}


Осталось понять, как сделать то же самое в Опере.

3. Как в Opera изобразить overflow-x/overflow-y?

А никак. То есть, как, но только совсем другим путём. Потыкавшись в Гуголь минуты полторы и не найдя готового решения (вроде -o-scrollbars-vertical), я решил, что нужно сочинять своё имеющимися средствами (то есть, средствами W3C). Но это оказалось просто.

W3C считает, что свойство overflow может иметь значения visible, hidden, scroll, auto, inherit. То есть, применяя это всё к body, мы можем получить либо полное отсутствие скроллбара, либо присутствие обоих (понятно, что речь идёт о странице, которая не помещается в отведённые ей рамки). Но кто сказал, что применять его нужно к body? Итак, решение.

Внутрь body запихиваем вот такой вот div:

#wrapper {
  width: 100%;
  height: auto;
  overflow: hidden;
}


И весь остальной контент запихиваем уже в него. Теперь всё работает так, как нам надо. Элемент body отображает только вертикальный скроллбар; горизонтальный ему не нужен, так как единственный элемент, находящийся внутри него — #wrapper — имеет ширину 100%, то есть прекрасно влезает по ширине.

В этом месте кажется, что можно выкинуть IE-only overflow-x и MZ-only -moz-scrollbars-vertical, дабы получить красивый, внятный и совместимый со стандартами CSS. Но не тут-то было. Mozilla всё-таки снова отображает горизонтальный скроллинг. Как же она его любит...

В общем, для надёжности оставляем всё, и overflow-x, и -moz и wrapper. И чёрт с ними, со стандартами.

Hope it helps(tm)
 1 комментарий    31   2005   ИЕ   Фаерфокс   ЦСС

Following The CSS Standards

Lets say you have a div that is set to 300 pixels in CSS. You then put a 250 pixel wide float inside that div. Immediately after that you have a 100 pixel wide overflow:hidden div. All sizes have been specified in CSS.

Now here’s the pop quiz. What do you think the layout should be? Should the overflow div:
(a) Be on the same line with the float and spill out of the enclosing 300 pixel div
(b) Be placed underneath the float, automatically clearing it because there is insufficient space for
the overflow div next to the float

Before I give an answer, lets see what the CSS specification has to say on this issue.
Surfin’ Safari
 2 комментария    10   2005   браузеры   Сафари   ЦСС

CSS Box Model

(Как бы в сторону.) Господи, ну что курили люди из W3C, когда придумывали, что width бокса не включает padding... Это же просто потрясающий, вопиющий, выдающийся, неукладывающийся в голове идиотизм! Из-за этого вёрстка всего усложняется вдвое.
 4 комментария    7   2004   ЦСС

А ещё

А ещё Мозилла рендерит одну и ту же страницу по-разному, в зависимости от того, где находилась полоса прокрутки в момент нажатия F5. По-моему, такого поведения можно добиться, только если целенаправленно его запрограммировать...

Вопрос по существу. Стандарты не позволяют выровнять элемент по нижнему краю страницы либо экрана, в зависимости от того, что из этого выше. Однако табличная вёрстка с такой задачей с успехом справлялась, когда table height="100%". Вроде бы, справляется она и сейчас: я делаю 100% таблицу из двух ячеек, одна под другой; внутри верхней делаю всё то, что должно быть на странице, используя нормальную CSS-вёрстку, а внутри нижней пишу копирайты и всё, что нужно.

Как это всегда у меня и бывает, всё это отлично работает и в IE, и в Opera, и даже в Netscape 7, а в Mozilla и Firefox работать не хочет. Самое смешное, что совсем недавно я делал другую страницу ровно по тому же принципу, и она-таки работала везде.

Кто знает надёжное решение этой проблемы?

Update: немного перекроил дивы — стало работать.
Ранее Ctrl + ↓