БЭМ решает такие проблемы. К счастью или несчастью, коду больше 10 лет. Так что сам понимаешь ;-)
Кстати, у нас крон ходит по списку завершившихся экспериментов и напоминает авторам, что надо бы почистить за собой, если они этого еще не сделали.
Про случай. У нас очень большая кодовая база, которая продолжает расти вместе с количеством разработчиков. И интересно наблюдать за изменением ее характеристик.
Например, эти данные можно использовать для составления плана дальнейших действий. Представьте, что вы не один раз оказывались в ситуации, когда для реализации некоторого эксперимента, вам необходимо перебить CSS свойство у элемента. И сделать вы это можете либо добавив !important, либо дополнительный класс в итоговый селектор. В какой то момент вам может показаться, что код деградирует, поддерживать его становится сложнее. А данные, полученный подобной утилитой, могут служить подтверждением или опровержением вашей гипотезы.
Ну и как я уже упоминал в статье — это должно быть хотя бы интересно. Так и есть, в моем случае.
У нас нет полностью отрисованных макетов под опорные разрешения экранов (мы сейчас находимся на такой стадии, что у нас постоянно что-то меняется в интерфейсах). Широкие элементы страниц, такие как кнопки например, прорисованы в обычном состоянии и в «укороченном» варианте. Вопрос о скрытии каких-либо функциональных элементов решается по мере поступления проблем, то есть, например, добавили новую кнопку в тулбар, взяли браузер и начали заужать окно, определили на каком этапе стоит скрыть эту кнопку в тулбаре и показать теперь ее в меню.
Хорошее замечание. Правда, мне, кажется, что с помощью математических выражений показать идею было бы легче. Например, высота .button__inner равно не просто 26px, а именно потому что…
У нас есть отдельный файл со стилями для IE8, который загрузится только IE8 (так как он объявлен в комментариях).
Internet Explorer 8 можно отделить теми же условными комментариями или даже снифингом на сервере. Мобильные устройства так снифать однозначно тяжелее.
Мы так и сделали :-)
Грузите ли вы все части кода для мобильных устройств, включая те, что заведомо не будут использованы?
Весь JS сейчас загружается каждым клиентом. Это минус, мы это понимаем. У нас есть технические возможности сделать множество сборок JS (packages), и загружать по мере необходимости. Но на данном этапе загрузка зазипованного JS занимает сравнительно малую долю, так как клиенту приходится грузить медиа-контент.
Опять же, заботясь об ограниченных ресурсах мобильных устройств, не лучше ли использовать вместо прожорливых градиентов (даже десктопные браузеры могут с ними заметно тормозить), внедрённые через data:url, картинки?
Возможно. Мы постоянно экспериментируем. И inline картики на очереди. Обязательно поделимся результатами в будущем :-)
По браузерам: как вы относитесь к андроидному браузеру разных версий: 2.1, 2.2, 2.3, 4? К мобильному Firefox, обычному и бете, Chrome Beta на 4 андроиде? Или почти все они в категории X?
Все верно, они в классе X. Но мы частенько проверяем на реальных устройствах с Android 2.3 (иногда и на четверке) и Mobile Firefox.
Мы у себя используем SWIG для трансформации на ноде и в браузере. Далее поток мыслей — январь 2012 года (в феврале его обновили хорошо, но я не смотрел, что там сделали). В браузер перенес небольшим допиливанием. Ужасно объемный код на выходе, который получает в итоге клиент. Из-за того что, все конструкции заворачиваются в замыкания, то нет возможности установить переменную внутри конструкции if, а затем к ней обратиться извне. В Opera проблемы из-за того, что в скомпилированном шаблоне все обращения к переменным проходят в итоге через window, а Opera создает в window переменные указатели на input с именами аттрибутов name и получаем строки [Object HTMLInputElement] в выдаче.
И всетаки можете поделится временем синтетических тестов? На сколько я понял, вы замеры проводили для TT и Fest/V8MonoContext.
Кстати, у нас крон ходит по списку завершившихся экспериментов и напоминает авторам, что надо бы почистить за собой, если они этого еще не сделали.
Это хорошая идея. Я был бы рад видеть подобный функционал в уже существующих сервисах, таких как, например, Calibre.Ну и как я уже упоминал в статье — это должно быть хотя бы интересно. Так и есть, в моем случае.
У нас есть отдельный файл со стилями для IE8, который загрузится только IE8 (так как он объявлен в комментариях).
Мы так и сделали :-)
Весь JS сейчас загружается каждым клиентом. Это минус, мы это понимаем. У нас есть технические возможности сделать множество сборок JS (packages), и загружать по мере необходимости. Но на данном этапе загрузка зазипованного JS занимает сравнительно малую долю, так как клиенту приходится грузить медиа-контент.
Возможно. Мы постоянно экспериментируем. И inline картики на очереди. Обязательно поделимся результатами в будущем :-)
Все верно, они в классе X. Но мы частенько проверяем на реальных устройствах с Android 2.3 (иногда и на четверке) и Mobile Firefox.