Ссылки о веб-разработке за апрель 2011

CSSO

Ребята из симферопольского «Яндекса» сказали новое слово в оптимизации CSS — CSSO. Оптимизатор интересен тем, что умеет минимизировать с изменением структуры — то есть удалять перекрываемые свойства, производить слияние блоков с одинаковыми селекторами и тому подобное.

Сергей Крыжановский, который занимается программированием CSSO, в своём блоге хорошо описал отличия CSSO от YUI Compressor, CSSTidy и им подобных.

Например, CSSO умеет вот такое:
/* до CSSO */
.a {
    color: red;
    border: 0;
}

.b {
    color: red;
}

/* после CSSO */
.a{border:0}.a,.b{color:red}
Меня несказанно печалит, что оптимизатор написан на JavaScript, потому что хостинг с серверным JS найти крайне проблематично, но зато оптимизацию в действии можно попробовать прямо в браузере.

a peculiar cross-browser onresize quirk

While working on understanding an input problem on a section of the Chinese qq.com site, I wanted to understand when the resize event fires for IFRAMEs. In particular, if width/height of the IFRAME are set by a script to its current values, will a resize event fire?

The script I was looking at intended to resize the IFRAME to fit its contents. To do so, it set with/height of the IFRAME to an empty string, read scrollWidth/scrollHeight of the document inside, and set width/height to the values it had read. Meanwhile, in another and odder part of their JavaScript, an onresize listener would toggle contentEditable for the element you'd type your status update in off and back on again each time the resize event fired! I can sort of understand the logic of the IFRAME resize part, but I don't have a clue why they would turn contentEditable off and back on for every resize.. This made the input cursor go away for every resize, and since the script "resized" the IFRAME for every single keypress, typing anything at all was pretty hard..

Trying to build a minimal test case, I had a hard time reproducing the resize events that were fired on the live site. On the site, onresize fired twice. I assumed it happened once when width/height was set to an empty string, and once when they were reset to original values. But why didn't this happen in a test doing those two things?

Gradually including more code from the live site, the penny dropped: simply reading scroll dimensions from the inside document, caused extra calculations of the document's dimension that wouldn't otherwise occur. As a side effect of this, resize events would fire. Very quirky..

Well, we're used to quirks - we're dealing with web browsers, after all. But here's the weirdest part: this very obscure and quirky behaviour happens in all four major browser engines! Check the testcase - Opera, Chrome, IE8 and Firefox all fire 8 events for 4 resizes if you read scroll dimensions while the script runs, no events otherwise. So there, a cross-browser compatible quirk! And Opera's bug is not that we fire too many resize events - it is that we need to remember cursor position and re-focus the element when contentEditable is toggled off and on again.

Or perhaps work on heuristics for running only intelligently written JavaScript :)

Nginx / Вышел Nginx 1.0



Сегодня, в день космонавтики, Игорь Сысоев выпустил стабильную версию веб-сервера Nginx 1.0.

Список изменений по сравнению с предыдущей версией:

Репозитарий доступен по адресу svn://svn.nginx.org. Инструкция по установке из исходников.
RPM пакетов пока нет.

one keyboard to rule them all

недавно мне пришлось по очереди настраивать два ноутбука, и чтобы не прыгать от клавиатуры к клавиатуре и от мыши к тачпаду, я снова воспользовался маленькой, но очень удобной программкой Synergy. Она просто подключает мышь и клавиатуру одного компьютера к другому по сети. Достаточно перевести мышь за правую (на выбор) границу одного экрана — и она оказывается на другом. Работает в винде, линуксе и маке, андроиде и ифоне настроек почти не требует. Рекомендую.

← предыдущий месяц