Кстати говоря, а правда, зачем нужна задержка меньше 35 миллисекунд?

Если у пользователя шустрый браузер, он увидит в среднем 28 FPS, что выше 24, необходимых для иллюзии плавного движения.

Если не сильно шустрый, чуток подёргается, но не будет дьявольски тормозить.

Оно так и работает, моё сообщение выше -
Мне интересна причина этого явления. По ссылкам рони скачал Speed Tracer для хрома. На первом рисунке работа скрипта без height:100%, на втором разворачиваемый элемент static, а на третем с height:100%. На первых двух рисунках разница параметров мала, а на третем заметно увеличился Paint (The browser's rendering engine updated the screen). По каким-то причинам возросло время отрисовки.

Причина возросшего времени отрисовки найдена. При height:100% и position:relative у обёртки, при раздвижении элемента перерисовывается вся страница, т.е. "1024 x высота_контента". Если эти свойства стилей убрать, то перерисовывается сам раздвигаемый элемент - "17 x кол-во_пикселей". Отсюда и такая задержка.

position:relative нужен для абсолютных бордеров, так как в этом случае смещение абсолютного бордера отсчитывается от обёртки (position:relative), а не от самого экрана, что позволяет прижать бордеры к контенту при прокрутке страницы. Остаётся вариант с избавлением от height:100% и указания величины в пикселях, тут видимо только javascript. Есть вариант третий, оставить всё как есть, скрипты раздвижения и так ко времени привязаны, тормозить не будут, а вот например замена рисунка при onmouseover и остальное в таком роде, видно как тормозит. Если есть предложения, пишите, пока остановлюсь на варианте с заданием высоты с помощью javascript.