Поддерживаю. В статье изложены неверные выводы. Переменные вообще никак к отрисовке не относятся и сами по себе ее не вызывают. Просто в одном варианте часов отдельный слой создается при каждом сдвиге стрелки, а во втором варианте слой существует постоянно.
Для плавности же можно просто добавить тех же стилей вроде `transition: 1s linear;`. В итоге код в статье сильно усложнился / запутался, а прибавилось только минусов. %)
Так i5 i5-ому рознь. Посмотрите характеристики тех процессоров. :) А приложений и в сети сейчас хватает, к примеру, Figma для редактирования векторной графики вполне себе требовательна и прочие. Ну и если у вас имеются средства, а задачи только офисные, то будет плюс в меньшем количестве тормозов, быстром запуске и подобном.
А чем SBH80 так плоха? Уже ~ пару лет с ней хожу, + бег, велосипед, сноуборд, все отлично работает. Единственное нарекание — максимальный уровень громкости низковат, в шумной обстановке порой плохо слышно собеседника.
Application Cache является устаревшей технологией и, скорее всего, будет со временем удалена поддержка сего в браузерах. Service Worker является ее заменой. localStorage для чего-то более-менее простого, для более сложных вещей — IndexedDB.
Интереса ради не могли бы привести пример? Меня всегда интересовали вопросы производительности и изучить в этом плане градиенты было бы увлекательным занятием для меня.
@EvgenyMakhnovets Уже много раз писал (не конкретно вам, а вообще), но толку все равно нет. Забудьте о свойстве flex. Пишите все раздельно. Тогда и про "растягивается", "жадность" и прочие недоразумения писать не нужно будет, так как об этом скажет ваш код, а не набор непонятных 0 0 auto и т.п.
А зачем тогда, собственно, will-change, если браузер все равно проведет подготовительные работы во время трансформации? Вся проблема will-change в том, что его сложно использовать. Мы все привыкли ко всяким там "непонятным" эвристикам и т.п., что браузер все за нас делает и т.п., и т.д. А тут появился will-change (и contains ;)) и разработчики браузеров предложили нам все самим делать в помощь браузеру (увы, не во всех сценариях браузер может все верно оптимизировать и оптимизировать ли?..). kahi4, в целом, неплохо все объяснил. Дополню, что will-change нужен не только во время анимации, но и при любом ином изменении, а не только CSS transform. То, что делает это свойство, будет и без него проделано, но на эти подготовительные работы нужны ресурсы (время и мощности железа). При открытии меню, к примеру, мы хотим увидеть начало анимации сразу же после клика на кнопку и эти подготовительные работы отсрочат начало анимации на n миллисекунд, что будет замечено пользователем и испортит пользовательский опыт. Вот чтобы этого не происходило, посредством will-change можно подготовить элемент заранее. :)
Для плавности же можно просто добавить тех же стилей вроде `transition: 1s linear;`. В итоге код в статье сильно усложнился / запутался, а прибавилось только минусов. %)
Так и вышло. :)
http://lametric.com — давно пользуюсь. Судя по фотографиям у LaMetric'а экран заметно лучше, да и в целом выглядит приятнее.
А чем SBH80 так плоха? Уже ~ пару лет с ней хожу, + бег, велосипед, сноуборд, все отлично работает. Единственное нарекание — максимальный уровень громкости низковат, в шумной обстановке порой плохо слышно собеседника.
SVG иконки поддерживаются лишь частично и с ограничениями на различных платформах. Работа ведется. :)
Application Cache является устаревшей технологией и, скорее всего, будет со временем удалена поддержка сего в браузерах. Service Worker является ее заменой. localStorage для чего-то более-менее простого, для более сложных вещей — IndexedDB.
Интереса ради не могли бы привести пример? Меня всегда интересовали вопросы производительности и изучить в этом плане градиенты было бы увлекательным занятием для меня.
А что не так с генерируемой картинкой? Браузер ее отрисовал и все, далее просто копирует как тот же растр, по сути все то же самое.
Проблема подмены решается сим: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity.
@EvgenyMakhnovets Уже много раз писал (не конкретно вам, а вообще), но толку все равно нет. Забудьте о свойстве
flex. Пишите все раздельно. Тогда и про "растягивается", "жадность" и прочие недоразумения писать не нужно будет, так как об этом скажет ваш код, а не набор непонятных0 0 autoи т.п.И вот, кстати, решение задачи из статьи, только без горы мусора и с читаемым CSS'ом: https://jsbin.com/gajozaj/5/edit?html,css,output.
На подготовку слоев может уйти и больше. ;) Впрочем, я сего и не отрицал, хоть и не являюсь приверженцем данной теории...
А зачем тогда, собственно,
will-change, если браузер все равно проведет подготовительные работы во время трансформации? Вся проблемаwill-changeв том, что его сложно использовать. Мы все привыкли ко всяким там "непонятным" эвристикам и т.п., что браузер все за нас делает и т.п., и т.д. А тут появилсяwill-change(иcontains;)) и разработчики браузеров предложили нам все самим делать в помощь браузеру (увы, не во всех сценариях браузер может все верно оптимизировать и оптимизировать ли?..). kahi4, в целом, неплохо все объяснил. Дополню, чтоwill-changeнужен не только во время анимации, но и при любом ином изменении, а не только CSStransform. То, что делает это свойство, будет и без него проделано, но на эти подготовительные работы нужны ресурсы (время и мощности железа). При открытии меню, к примеру, мы хотим увидеть начало анимации сразу же после клика на кнопку и эти подготовительные работы отсрочат начало анимации на n миллисекунд, что будет замечено пользователем и испортит пользовательский опыт. Вот чтобы этого не происходило, посредствомwill-changeможно подготовить элемент заранее. :)