Заметки с тегом «css» (страница 3)

Дефект в IE при большом количестве начертаний в @font-face

В статье « Setting Weights And Styles With The @font-face Declaration» рассматривается любопытный случай, возникающий в IE7 и IE8 при объединении различных начертаний шрифта. Если количество начертаний для одной гарнитуры будет больше четырёх, то браузер будет не корректно их использовать.

Так же упоминается тот факт, что это вызывает падение браузера на iPad 1. Но в комментариях указывают на то, что дефект, приводящий к падению браузера, был исправлен более двух лет назад. У меня он не воспроизвёлся.

Комментарии к заметке: 2

White-space, word-wrap и их друзья

Для разного контента нужны разные правила форматирования: фрагменты кода должны сохранять все переносы строк и табуляцию; текст, написанный случайным посетителем сайта, не должен «порвать» вёрстку и т.п. Форматирование можно контролировать с помощью CSS.

Свойство white-space

CSS свойство white-space описывает то, как будут обрабатываться пробельные символы внутри элемента.

 Новая строкаПробелы и табуляцияПеренос текста
normalсхлопываетсясхлопываютсяесть
nowrapсхлопываетсясхлопываютсянет
preостаётсяостаютсянет
pre-wrapостаётсяостаютсяесть
pre-lineостаётсясхлопываютсяесть

Значения pre-wrap и pre-line доступны во всех современных версиях браузеров и в IE начиная с версии 8.0.

Подробнее o white-space на w3.org

Свойство word-wrap

Изначально это свойство появилось в линейке браузеров IE и только потом перекочевало в другие браузеры, так и не появившись в спецификации CSS2. В CSS3 аналогичное поведение закреплено за свойством overflow-wrap, а word-wrap останется в качестве псевдонима.

Это свойство может принимать значения:

normal

Переносы строк будут формироваться только в дозволенных позициях.

break-word

Слово будет разрываться, если в пределах строки нет подходящей позиции для переноса строки.

Это свойство можно использовать для переноса строк в теге <pre> даже в старых версиях IE:

pre {
  word-wrap: break-word; /* IE 5.5-7 */
  white-space: pre-wrap; /* current browsers */
}

Подробнее o word-wrap (overflow-wrap) на w3.org

Свойство word-break

Когда нужно применить «грубую силу» и переносить любую строку в любом месте (я даже не представляю себе где это может потребоваться), то в дело вступает word-break.

.text_user-generated_yes {
  word-break: break-all;
}

Это свойство имеет больший приоритет, чем word-wrap (overflow-wrap) и будет разрывать слова даже там, где это особо и не требуется.

В браузерах на Webkit это свойство имеет ещё одно нестандартное значениеbreak-word, которое по своему действию аналогично word-wrap .

Подробнее o word-break на w3.org

Свойство hyphens

С нетерпением ждём, когда браузеры начнут делать автоматическую расстановку переносов в словах.


.text {
  -webkit-hyphens: auto;
  -moz-hyphens: auto;
  hyphens: auto;
}

Основным препятствием на пути внедрения этой технологии стоит то, что браузеру требуется описание правил переноса слов для различных языков. На сегодняшний день только Safari и Firefox могут похвастаться этим.

Подробнее o hyphens на w3.org

Комментарии к заметке: 3

Равномерное выравнивание блоков по ширине

Подсказали шикарную статью про « равномерное выравнивание блоков по ширине». Решение работает с произвольным количеством блоков различных габаритов даже в самых старых, но всё ещё популярных, браузерах.

За базу берётся обычный список, построенный на элементах ul и li. Всем элементам списка назначается display: inline-block , а сам список получает стиль text-align: justify . А дальше идут мелочи и тонкости, которые в итоге и заставляют все блоки равномерно разместиться в контейнере, даже если они сами имеют разную ширину.

Равномерное выравнивание блоков по ширине

Комментарии к заметке: 3

Профилирование CSS и неиспользуемые селекторы

Я уже писал, что самыми эффективными селекторами с точки зрения анализа и обработки их браузером будут простые селекторы . Когда браузер встречает каскад, то ему требуется пройти от текущего элемента до корня документа в поисках всех элементов, удовлетворяющих условию селектора.

А что произойдет, если браузер никогда не встретит элемент с нужными характеристиками во время такого обхода? Чтобы ответить на этот вопрос я решил сделать несколько замеров скорости отрисовки достаточно сложной страницы (около 2500 элементов и глубиной 20 уровней). Страница содержала реальные и вполне типичные для проекта данные — таблица на сотню строк, свёрстанная блочными элементами.

Для создания нагрузки я применил модифицированный скрипт, который постоянно прокручивает окно, заставляя браузер перерисовывать всё содержимое окна. А замеры делал с помощью профайлера Opera Dragonfly.

Итак, на моей тестовой странице была подключена библиотека виджетов jQuery UI. Но так как фактически никаких виджетов там не было, то CSS-правила, относящиеся к jQuery UI, никогда не применялись. Они-то и создавали эту паразитную нагрузку.

Сначала я сделал замер с подключенными стилями темы.

Эксперимент с подключенными стилями темы jQuery UI

А затем повторил эксперимент без подключения этих стилей.

Эксперимент без стилей jQuery UI

По рейтингу затраченного времени на пересчёт стилей видно, что самыми «тяжёлыми» оказались каскады, для которых никогда не находятся подходящие элементы. На странице множество элементов span (1123, если быть точнее), но, ни один не имеет предка с классом ui-datepicker-next или ui-datepicker-prev.

Из этого конкретного эксперимента можно сделать вывод, что чем больше будет загружено CSS-правил, тем медленнее будет работать движок браузера на перерисовке страницы, даже если эти правила никогда не будет применены на странице.

Отсюда напрашивается ещё один вывод: объединение разношерстных стилей в один файл с большой вероятностью ухудшит производительность стадий reflow и repaint. Деградация будет не так заметна, если в стилях гарантировано не применяются каскады с селекторами по тегу.

Комментарии к заметке: 6

Подсветка области клика на iOS

Когда пользователь прикасается к ссылке или элементу, для которого указан обработчик клика, то Safari на iOS подсвечивает этот элемент.

Цвет этой подсветки задается с помощью CSS свойства -webkit-tap-highlight-color.

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

Предположим, что нас интересует только клик по элементу с классом item__add.


$(".list").on("click", ".item__add", function () { … });

Но подсветка будет активироваться у элемента с классом list , так как именно на него повешен обработчик события. Исправим это CSS свойством в селекторе .list.


.list {
    -webkit-tap-highlight-color: rgba(0, 0, 0, 0);
}
Комментарии к заметке: 3