Будучи бэкэнд разработчиком меня всегда не устраивали существующие хтмл парсеры
«Существующие парсеры» были «бэкэнд разработчиком»? Может, все-таки «будучи бэкэнд разработчиком, вы были не удовлетворены парсерами», или «парсеры не устраивали вас как бэкэнд разработчика» ;-)
В секции Model-View-Controller в качестве признака Контроллера указан пункт «Контроллер определяет, какие представление должно быть отображено в данный момент;», однако на прикрепленной вами диаграмме не указана определяющая связь от Контроллера к Представлению. Скорее, указана определяющая связь от Представления к Контроллеру. Я правильно понимаю, что это противоречие?
В этой диаграмме действительно показана определяющая роль Контроллера при выборе Представления.
Также должен сказать, что в ряде обучающих статей на тему (например, в Википедии ru.wikipedia.org/wiki/Model-View-Controller) действия пользователя передаются не в Представление, а в Контроллер. Но тут стоит сказать, что общее несоответствие в этой детали по поводу MVC мы можем наблюдать во всех статьях по теме.
Большое спасибо, я читал эту статью вчера, и после вашего упоминания решил прочесть еще раз, повнимательнее.
Она даёт ключ к пониманию того, почему у очень многих комментаторов производительность плачевна даже с transform3d — не очень производительный GPU и большой размер экрана. Мне определенно стоит подумать над тем, как со своей стороны улучшить их UI в таких ограничивающих условиях.
Посылки:
— Не все браузеры поддерживают translate3d.
— Побочные анимации, не сводящиеся к одному translate3d, во время скольжения по странице ужасно убивают производительность.
Вывод:
Для некоторых браузеров приходится идти на компромисс и отсрочивать анимацию до того момента, когда пользователь закончит движение. Во время остановки же даже очень интенсивные вычисления — субъективно — не сильно скажутся на UI.
Это очень занятный, хотя и предсказуемый факт :-)
На Win-системах IE в комбинации с обычным left — куда быстрее, чем IE с transform3d и даже чем другие браузеры, включая Хром, с transform3d.
Проблема в том, что на производительность влияет не вес картинки, а размер. Даже очень маловесящие картинки, растянутые на весь экран, заставляют браузер тратить огромные ресурсы на перерисовку.
«Существующие парсеры» были «бэкэнд разработчиком»? Может, все-таки «будучи бэкэнд разработчиком, вы были не удовлетворены парсерами», или «парсеры не устраивали вас как бэкэнд разработчика» ;-)
В секции Model-View-Controller в качестве признака Контроллера указан пункт «Контроллер определяет, какие представление должно быть отображено в данный момент;», однако на прикрепленной вами диаграмме не указана определяющая связь от Контроллера к Представлению. Скорее, указана определяющая связь от Представления к Контроллеру. Я правильно понимаю, что это противоречие?
Возможно, вы имели в виду что-то вроде www.sitepoint.com/getting-started-with-mvc с диаграммой
В этой диаграмме действительно показана определяющая роль Контроллера при выборе Представления.
Также должен сказать, что в ряде обучающих статей на тему (например, в Википедии ru.wikipedia.org/wiki/Model-View-Controller) действия пользователя передаются не в Представление, а в Контроллер. Но тут стоит сказать, что общее несоответствие в этой детали по поводу MVC мы можем наблюдать во всех статьях по теме.
Она даёт ключ к пониманию того, почему у очень многих комментаторов производительность плачевна даже с
transform3d— не очень производительный GPU и большой размер экрана. Мне определенно стоит подумать над тем, как со своей стороны улучшить их UI в таких ограничивающих условиях.Тут я должен заметить, что png-24 — не моё единоличное решение.
Даже качество png-24 не всегда до конца устраивало нашу команду.
Посылки:
— Не все браузеры поддерживают
translate3d.— Побочные анимации, не сводящиеся к одному
translate3d, во время скольжения по странице ужасно убивают производительность.Вывод:
Для некоторых браузеров приходится идти на компромисс и отсрочивать анимацию до того момента, когда пользователь закончит движение. Во время остановки же даже очень интенсивные вычисления — субъективно — не сильно скажутся на UI.
Скажите, пожалуйста, во всех ли ваших браузерах вы наблюдаете смещение у всего и вся с помощью
absolute:left?Надо заметить, что для покоящихся внутри своих родителей объектов абсолютное позиционирование никак не влияет на производительности.
На Win-системах IE в комбинации с обычным
left— куда быстрее, чем IE сtransform3dи даже чем другие браузеры, включая Хром, сtransform3d.А управление клавиатурными стрелочками есть! Извините, что не дали об этой возможности наглядно узнать.
Проблема в том, что на производительность влияет не вес картинки, а размер. Даже очень маловесящие картинки, растянутые на весь экран, заставляют браузер тратить огромные ресурсы на перерисовку.
Вполне возможно, что благодаря вашему замечанию и плюсам к нему впредь я буду добавлять куда больше технической начинки.
Хоть и считаю, что JS/CSS-иллюстрации к данной статье для любителя программировать вышли бы простыми и даже унизительно простыми.
Я тоже против синих квадратов. Если от выделения текста мы можем полностью отказаться, определенно добавлю эти правила.