s0rr0w

Гораздо дешевле генерировать большое количество тегов на стороне сервера, чем бороться с глюками и ограниченной функциональностью автоматического генератора контента.

Бедняги, я им сочувствую.

Не вижу никаких проблем.

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

Да, я не умею пользоваться шприцами с герычем и трубочками для нюханья кокса, потому что считаю, что это плохое. Я глупый человек?

При рендеринге CSS.

<myNameSpace:myCustomTag />

event is not defined

Итак, мы раздуваем css, html, чтобы сэкономить на спичках? Да, еще вести разработку и поддерживать такой код становится в пару раз сложнее. Так кому лучше делаем? Считать нифига не умеем. Садись, два. Это количество тегов реально не достижимо практически никогда. В моих проектах, где все построено путем догрузки в одну страницу, я максимум добивался 5к тегов. Итак, эффективность оценивается по скорости работы селектора. Так вот простые селекторы тоже могут быть медленными, особенно если это селекторы с неймспейсами и кастом-тегами.

Надо пересмотреть доки, там какие-то костыли были, чтобы поведение было примерно как у флеша: если есть специальный разрешающий XML, то кроссдоменные запросы проходят на ура. Если нет - то "чао, бамбино"

Мы рады за тебя.

И методология оценки эффективности тоже не помешала бы...

Это зависит от процесса разработки. В моих процессах я участвовал в создании дизайнов непосредственно, проверяя то, что нарисуют дизайнеры. Потому что легче им потратить 10 минут на рисование, чем мне потом пол дня воевать со сборкой. Это экономически неэффективно. Поэтому задротство с pixel perfect'ом говорит скорее о негибкости процесса разработки, чем о качестве работы. А среди них были и полезные...

Вы ошиблись адресом, это не техподдержка Яндекса

1. Читабельность кода 2. Устойчивость к модификациям 3. Семантика

Заценил, заценил

Зачем? Есть ведь querySelector

Он по-своему прав. Знать JS и jQuery - разные вещи. Смотря какую анимацию. Допустим, на 1.6 jQ мне пришлось самому писать функцию анимации позиции фона. Это был костыль еще тот, проще было на чистом JS написать, и кода в 10 раз меньше было бы.

И что? Наличие фреймворка должно на что-то влиять?

Три языка, на текущий язык вообще никогда не обращаю внимания. Через некоторое время входит в привычку автоматически помнить про текущий язык данного приложения. Поэтому просто работаю и все. Да, в линухе гораздо больше вариантов для настройки клавиш переключения раскладки, и с кнопкой Win в качестве переключателя вообще все эти запарки с раскладками не волнуют никак. Я не использую 10 пальцев, только 8. Мизинцы не использую.

Не пользовался ибо набираю тексты вслепую, а значит и смысла в пунтосвитчере не вижу.

Оно в целом верно. Но если изменить подход к интерфейсу, то на некоторые недочеты кастомных элементов можно закрыть глаза.

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

Мой опыт говорит, что клавиатурные фичи слабовостребованы для селектов. Мы заменили почти все селекты на кастомные, никто даже не обратил внимания на то, что они не на 100% соответствуют обычным. Потому что их воспринимают как другой элемент управления. Да ладно! Используем все типы селектов, мультиселекты самые востребованные.

Не завершив проекта, никогда не узнаешь его узких мест. Реально узких мест, а не крохоборства. Простой пример: уменьшение количества файлов экономит 500 милисекунд из 5 секунд, а оптимизация базы данных - 3 секунды. Вопрос, какую оптимизацию лучше проводить? Еще один пример: на 90% реализации проекта стало понятно, что вместо 5 страниц настройки можно сделать всего одну, и весь графический контент этих страниц можно выкидывать. А вы потратили на преждевременные оптимизации неделю работы. Вопрос, стоило ли тратить эту неделю, если результат нулевой?