Сергей Протько

Требования по поддержке браузеров должны быть согласованы с заказчиком. Но обычно это Firefox, Chrome, Safari (с ним бывает много бед), для русскоязычного сегмента стоит пробежаться в Opera, но по сути в последних версиях с ним намного меньше проблем ( в связи с переходом на blink). Ну и конечно IE9+ (если нету договоренности о том что бы не суппортить девятый).

Вообще нету разницы в масштабах проектов. Штуки типа префиксы и прочее лучше доверить штукам типа autoprefixer, для кучи штук есть полифилы и шимы (скажем, можно безболезненно использовать es5 в ie, просто подключив полифил, или добавить в ie поддержку селекторов, аля :valid, для ie меньше 10-ой версии.

То есть по сути все сводится к modernizer, полифилам, autoprefixer и смоук-тестам верстки по итогу во всех поддерживаемых браузерах.

эм... что?

конкатенация стилей/скриптов и их последующая минификация - это нормальная практика. Для этого ненужно никаких стандартов. Делайте хоть на лету, хоть собирайте один раз при деплое (что было бы логично) а еще лучше сразу же ложите рядом уже сжатый в gzip вариант ваших скомпиленых файлов. Опять же смысла сделать из двух файлов один я не вижу как минимум по следующей причине: стили должны загрузиться раньше скриптов. Во всяком случае в большинстве случаев. Загрузка скриптов не должна блокировать загрузку страницы.

Что касается SPDY - то тут вы вообще ни капельки не попали. Там профит в том что используется одно tcp-соединение с сервером и мультиплексирование данных. Это позволяет снизить нагрузку на сервер, не тратить время на подключение к серверу по новой для загрузки следующих файлов и т.д. По сути при использовании этого протокола конкатенация файлов стилей и скриптов не должна приносить существенного профита, ибо соединение все равно будет одно и то же.

p.s. приведенная вами статья не даром находится в хабе "ненормальное программирование".

Можно вешать и тот и другой обработчик. С разными приоритетами. Словом выход можно найти.

А в чем тогда смысл SSD, если довольно критичные вещи вы перенесете на носитель с низкой скоростью работы? Я к примеру уменьшил SWAP (по сути он у меня не сильно используется, благо оперативки хватает), TEMP браузера вообще отключил оставив только кэш в оперативке, и вообще все ненужное отключил. 8-ми гигов оперативки для всех моих нужд пока хватает, кэш браузера… проблем пока не наблюдаю.

TMP позже перемещу на HDD (как только приедет 2nd hdd caddy).

Автоматизировать — bash + ssh, из браузера только селентиум.
На JS вы это реализовать не сможете (ибо нельзя).

Единственный достойный вариант: по domloaded из js жать на файловый инпут с аттрибутом multiple, а затем все как обычно.

Если у .content убрать margin-left — поведение становится одинаковым во всех браузерах. Должнно быть все же как в FF и опере. На правах большинства так сказать.

Меня больше бесит зум в WebKit браузерах. Постоянно какие-то косяки со слайдерами, каруселями и т.д.

Наверное потому что это никому не надо. Если вам надо сразу же после того, как вы сделали фото, залить его, скажем, на фотохостинг какой-то или в соц сеть — то для этого есть какие-нибудь приложения (не уверен но скорее всего должны быть).
А так это вопервых не нужно, а во вторых будет захламлять и без того сочащийся стандарт HTML5.