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

слов<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; }

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

Верстальщики недолюбливают компанию «Микрософт» за жуткую глючность и непоследовательность IE в разборе и отображении CSS. Но есть две вещи, которые компания «Микрософт» сделала правильнее, чем все остальные.

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

В «Техногрете» появилась статья Андрея Шитова, где он рассказывает о способе заставить position: fixed работать в IE. Несколько раньше на сайте Ромы Воронежского появился этот ужас «в действии».

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

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

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

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



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

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

Придя домой, я заглянул в справочник и обнаружил там вот что:

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

Мильчин А. Э., Чельцова Л. К. Справочник издателя и автора. Редакционно-издательское оформление издания. - М: Олимп, 1998; стр. 39

Это написано уже после того, как перечислено несколько способов нумерации, что косвенно подтверждает её предпочтительность. Также обратим внимание, что "кляксы" перечисляются в скобках, а основным символом называется знак тире. Я помню, что в школьных учебниках использовалось именно оно, но многие годы работы с Word и CSS отучили от этого символа совершенно. Попробовав заменить в Word'е в стиле "маркированный" буллет на тире, я обнаружил, что так действительно смотрится лучше:



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

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

Обнаружил, что оказывается свойства типа -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.

Из 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)

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

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

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

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

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

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

Update: немного перекроил дивы - стало работать.

Вот здесь календарь наезжает на Шарапову.

Календарь - это <div class="right_calendar">:

div.right_calendar {
  position: absolute;
  top: -100px;
  left: 60%;
  width: 40%;
}

Если его просто убрать из HTML, то надпись "Мария Шарапова выиграла Wimbledon" смещается чуть ниже - как раз туда, где она должны быть, чтобы не пересекаться с календарём. Если вернуть, надпись поднимается выше пикселей на 30. Эффект наблюдается в IE 6 и Netscape 7. В Опере, естественно, не наблюдается. С каких пор у нас абсолютно позиционированные элементы affect normal flow? Кто умный, как сделать, чтобы не сползало?

Кажется, я придумал, как победить высоту. Поскольку задача (у меня) не в том, чтобы конкретный див был высотой на всю страницу, а просто в том, чтобы закрасить колонку нужным цветом, то... в самой нижней части страницы пишем:

<div class="column_fix"></div>

CSS:

.column_fix {
position: absolute; left: -280px; top: -10000px; height: 10080px; width: 280px; background: #fff; z-index: -20;
}


Как написать в CSS, что высота данного DIV'а равна высоте страницы?

height: 100%% не спасает, почему-то, в отличие от таблиц, дивы считают, что 100% - это высота клиентской части окна браузера (IE, Opera, Mozilla), поэтому, когда появляется скроллинг, то 100% уже составляют меньше реальной высоты страницы.

bottom: 0px тоже не спасает: даёт тот же эффект, что и предыдущий вариант, что уж совсем странно.

Как сделать реальную высоту?

Выяснилось, что у некоторых enclub.ru отображается Таймсом, в то время как должен - Trebuchet MS. CSS выглядит примерно так:

font-family: Trebuchet MS, Arial, sans-serif;

По идее, на системах, где нет Trebuchet MS должен использоваться Arial. Реально, выяснилось, что на некоторых системах он есть, но не кириллизован, например, Windows 2000. В результате браузер не пытается искать следующий шрифт, а кириллицу выводит дефолтом, то есть Таймсом.

Что делать?

Научился наконец справляться с флоатами в HTML/CSS. С ними была такая проблема: если вертикальный размер у флоата больше, чем у текста, который его обтекает, а действие происходит внутри div'а, выкрашенного в зеленый, скажем, цвет, то вертикальный размер этого div'а становится равным вертикальному размеру текста, плюс поля. То есть получается, что флоат, скажем картинка, вылазит за див снизу. Когда этот div выкрашен в зеленый цвет, то эту засаду сразу видно. Всё это прямо следует из:

Since a float is not in the flow, non-positioned block boxes created before and after the float box flow vertically as if the float didn't exist.

(c) W3 Consortium

Это хоть и соответствует спецификации, но это бред. Решение проблемы: внутрь зеленого div'а добавляем в самом конце

<div class="fuck_w3c_standards"></div>

В CSS:

.fuck_w3c_standards {
  clear: both;
}

Статья Making the Absolute, Relative о том как сделать абсолютное относительным (смайлик).

Update: Чем занимаются больные люди в свободное время.

Update 2: Больше смысла в XHTML, больше внешнего вида в CSS. Автор пишет:

I find that most pages on the web contain a menu of links in a navigation area. These are often marked up as a string of links, often in separate DIVs or paragraphs. Structurally, however, they are a list of links, and should be marked up as such.

Update 3: Еще одна статья, на этот раз с русским переводом от Webmascon.com, о том, как не делать версию для печати, а обойтись умным CSS. Я сам это давно придумал, только вот не реализовал. Если воспользоваться небольшим серверным скриптом, то это можно сделать без свойства content, которое не поддерживается IE.

Update 4: Еще можно хорошо повеселиться, организовав закладки вместо простого списка ссылок. При этом HTML остается чистым списком ссылок (UL LI A)