Причуды прогресса

В HTML-элементе LI есть простое как два пальца свойство «value», которое просто и ненавязчиво позволяет установить номер элемента в нумерованном списке. Работает с любыми типами нумераций (например, с римскими числами тоже), ненапряжно устанавливается через JavaScript ( <элемент>.value=»10″ без каких-либо ухищрений), не создавая большого overhead’а и не сильно загрязняя код позволяет легко оперировать нумерацией, так как следующий элемент после того, которому мы установили value продолжает нумерацию от него (т.е. если в value поставили «5», то у следующего LI даже без установленного value сразу будет номер «6» и не важно, что было у предыдущих)… Одним словом — хорошее и полезное свойство, не вызывающее никаких спорных вопросов и, с моей точки зрения, не создающее проблем с точки зрения семантики.

Однако де, W3C решил несколько иначе и с HTML 4, а также во всех XHTML это свойство осуждается и валидный код можно получить только установив DOCTYPE в Transitional. Казалось бы — ну по любому, умные дяди решили так не зря и нам предлагают что-то более удобное, простое или хотя бы — более функциональное. Однако же, нам предлагают концепцию «CSS Counters«, которая, если в тезисах, состоит в следующем:

  • Для хранения нумераций используются специальные переменные — их нужно обнулять перед использованием, одновременно декларируя, например:

    ol {
    counter-reset: section; /* Set the section counter to 0 */
    list-style-type: none;
    }

  • Значения этих переменных локальны для каждого списка (!!!).
  • Изменять значения этих переменных можно опять же либо через CSS-команду counter-reset, указывая конкретное значение, либо через counter-increment, чтобы увеличить его (например, на каждом пункте списка):

    li {
    counter-increment: section; /* Increments only this instance of the section counter */
    }

  • Вставка непосредственно номеров элементов осуществляется через генерацию контента процедурами counters() и counter() в свойстве content в псевдоклассах :before и :after, например:

    li:before {
    content: counters(section, ".") " "; /* Adds the value of all instances of the section counter separated by a ".". */
    }

Я как со всем этим ознакомился - даже пробовать не стал и тут же, плюнув, поставил Transitional. Потому что даже в минимальном варианте при настроенных соответствующим образом стилях мне нужно будет писать

<li style="counter-reset: my-counter 5;">

вместо

<li value="5">

При этом простое и семантичное свойство заменяется набором из костылей - каких-то процедур, вставкой контента, переменных, - которые добавили в CSS, предназначенный изначально тупо для оформления! И черт с ними с несовместимостями и т.п. - мне вполне достаточно, что созданный в :after и :before контент пользователь не сможет выделить и скопировать. И дело не в недостатках before/after - если на них делать то, для чего они и предназначены (например, уголки круглые навешивать на блоки), то таких проблем и не возникает. А вот если пытаться чесать ухо рукой пропущенной под коленкой...

В общем, я для себя приобрел отличный пример того, как не надо перебарщивать в попытках создать обще-большое-красивое-универсальное-замечательное решение для замены всего-на-свете. Иногда лучше оставить в покое имеющиеся  мелочи, которые нормально работают и успешно справляются со своей задачей.

Internet Explorer убивает

В буквальном смысле — тем что тратит время жизни тем, что вынуждает бороться с его багами.

В данном конкретном случае столкнулся с багом, о котором до этого ни разу нигде не читал и не слышал. Более того, уже после решения проблемы поиском в Гугле так найти почти ничего и не смог. Хотя, возможно, плохо искал, так как ситуация достаточно неочевидная и нечастая… Примеры кода есть по ссылке приведенной ниже, а в тезисах суть следующая. Имеем div с содержимым, которому изначально присвоен некий скрывающий его со страницы класс, типа такого:

.ui-tabs-hide {
left:-15000px;
position:absolute;
top:-15000px;
visibility:hidden;
}

Потом посредством JavaScript этот класс с блока убирается, но содержащиеся внутри div’а таблицы остаются невидимыми (иногда частично — границы есть, а содержимого — нет, что уж совсем футуристично).

Описание проблемы с примерами дается тут — http://wiki.orbeon.com/forms/doc/contributor-guide/ie-bugs (пункты 2.1.4, 2.1.5). Сам столкнулся с этим багом при работе с модулем Tabs для Drupal, в котором все реализовано посредством JQuery UI Tabs. По приведенной ссылке предлагается вносить изменения в код JavaScript, но мне лезть во внутренности JQuery не хотелось (возможно, проблема решения в новых версиях JQuery UI Tabs, т.к. в комплекте модуля идет 1.6, но обновляться не хотелось, так как могли вылезти какие-нибудь новые грабли, связанные с несовместимостями самого Drupal’а, а мне срочно надо было решить вопрос), поэтому подумал и добавил в вышеприведенный класс для скрывания блока строчку «display: none;«, что полностью решило проблему и IE6/7 стали нормально отображать таблицу внутри div’а.

Пустая картинка в data:uri

Больше девать некуда, поэтому пусть тут полежит — пригодится когда-нибудь. 1-пиксельный прозрачный png с минимизированной палитрой и удаленной мета-информацией: «data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQMAAAAl21bKAAAABGdBTUEAAK/INwWK6QAAAANQTFRF////p8QbyAAAAAF0Uk5TAEDm2GYAAAAKSURBVAgdY2AAAAACAAHPyDXlAAAAAElFTkSuQmCC»