Рабочая группа CSS3 постоянно ведет дискуссии по поводу того, что же будет в новом стандарте. Иногда буйная фантазия и желание сделать все настолько круто, насколько это возможно, приводит разработчиков в глухой тупик.

Предыдущая часть тут

Анимация скрытых объектов




Похоже, одной из серьезных проблем для модуля CSS3 Animations станут объекты, которые имеют display: none и visibility: hidden.

В данной спецификации свойства, которые невозможно проитерировать, игнорируются. Однако есть пример, когда это делать не стоит. Допустим, есть блок, если ему присвоить некий класс hidden, то он должен плавно раствориться и полностью убраться из потока. Вполне нормальное поведение, которое уже присутствует во многих JS-библиотеках.

Код должен быть таким:
div {
    display:block;
}

div.hidden {
    display:none;
    animation: slide-out 1s 1;
}


Однако, если указано свойство display:none, анимации не будет. Ну правильно, кому нужна анимация для скрытых объектов?

Но, если указать вот такой код для декларации анимации
@keyframes slide-out {
    0% { display:block; opacity: 1; }
    100% { display:none; opacity:0; }
}

и не игнорировать неитерируемые свойства, то получается вполне логичная картина. Если браузер понятия не имеет, что такое анимация, то он просто скроет блок, так как сработает правило display:none в div.hidden. Если же поддержка анимации есть, то в начале анимации блоку будет возвращено значение свойства как block, проитерировано свойство opacity, и в конце блок будет скрыт.

Это не первая проблема с анимацией скрытых объектов, и далеко не последняя.

Градиенты станут проще?


Для упрощения синтаксиса градиентов было предложен новое ключевое слово transparent, чтобы можно было записывать вот так:
 linear-gradient(red, transparent, blue);

вместо 
 linear-gradient(red, rgba(255,0,0,0) 50%, rgba(0,0,255,0) 50%, blue);

Для обычных кодеров первый вариант, конечно же, многократно удобнее второго.

Ты куда кликнул?


Еще одно очень полезное предложение поступило для модулей 2D и 3D трансформации. Допустим, у нас есть квадрат. Мы поворачиваем его на 45 градусов и получаем ромб. Пользователь кликает на ромб, и нам нужно узнать, какие координаты клика относительно ромба, а не всего окна. Тут может выручить разделение на события, которые были навешаны на window и события document'a. В первом случае поведение остается как и предже, координаты клика отсчитываются относительно окна, а во втором случае они берутся в относительных координатах элемента. Это край необходимо для дальнейшего развития этих модулей, иначе для рассчетов координат нужно будет постоянно применять сложные вычисления на JavaScript.

На этой неделе все, спасибо за внимание!