Как вариант. Но с точки зрения ux – не очень (на мой взгляд). Ты просишь пользователя установить другое приложение, чтобы у тебя работало твое приложение. Если уж на то пошло, то можно и через телеграм доставлять пуши. Качать ничего не надо -- надо просто заставить пользователей нажать start в боте.
Не согласен, что данный подход усложняет разработку и делает ее дороже для бизнеса, ведь использовать css-шлюзы на практике довольно просто: необходимо написать всего лишь 1 строчку в нужном месте.
Не вижу причин не использовать препроцессоры, ведь данные технологии очень удобны при разработке, а в конечном счете превращаются в css.
Не согласен с тем, что проблема выдумана, ведь я выражаю свое мнение.
Используйте пиксели, если они вам удобнее. Я считаю, использовать rem-ы/em-ы — отличный способ привязать все размеры к базовой величине, что является стандартным решением, например, для дизайн систем.
Я лишь продемонстрировал подход как сделать интерфейс по-настоящему резиновым. Использовать его или нет — решение за вами!
Ваш вывод никак не противоречит моим рассуждением. Наклон прямой я выбрал лишь для простоты демонстрации. И, конечно, я специально делаю акцент, что можно менять масштаб пропорционально не только прямой, но и по другим функциям тоже. Можно делать кусочно-линейную функцию, которая будет иметь разный наклон для разных брейкпоинтов. Также я отметил, что данное поведение можно сделать и для высоты экрана, если это будет необходимо.
Я лишь демонстрирую подход, который максимально поддается управлению. Можно так файнтюнить/подкручивать, что интерфейс будет смотреться адекватно на больших экранах. Для меня этот подход приятнее, чем боковые распорки. Но опять же это дело вкуса :)
Я для примера сделал резиновость по линейной функции, никак не ограничивая эту функциональность. В продакшине, конечно, так делать не стоит. В самом простом случае, эту функциональность, надо, ограничивать через медиа-выражения, как минимум, до планшетных разрешений. Также через медиа-выражения вы можете менять наклон этой прямой на промежуточных брейкпоинтах.
Статья для примера применения резиновости. На каких разрешениях и как добавлять резиновость -- дело за вами!
Не вижу никакой ошибки. Вы можете как эталонное разрешение взять 1920х1080 и поддержать резиново только бОльшие разрешения. Для меньших экранов - не использовать данный функционал.
Когда я говорил «вследствие чего глазу очень тяжело остановиться на чем-то одном, а мышкой тяжело дотянуться до маленьких элементов», я имел ввиду действительно большие десктопные экраны 2k и больше.
Это дело вкуса. Меня, например, бесят большие боковые распорки, которые светят белым светом и выжигают глаза)
Я продемонстрировал подход, который помогает резиново масштабировать интерфейс. Причем функция адаптивности может быть любой, это настраиваемый момент. То есть если уменьшить наклон прямой, то можно масштабировать не совсем пропорционально и не так сильно. Я хочу сказать, что это можно отладить/подкрутить и сделать интерфейс адекватным на очень больших разрешениях.
Добавление таких распорок может помочь сохранить честный скролбар, однако в ограниченном числе случаев. При первой работе со списком, кешировние размеров уже загруженных элементов может вам помочь в калькуляции размеров распорки. Но такой подход позволит вам вернуться с помощью ползунка только в те места списка, которые уже когда-то были загружены. Не совсем честный скролбар получается. Также если перезагрузить страницу, необходимо будет выполнить вычисления заново.
К тому же, непонятно что делать, если заресайзилось окно. Размеры элемента списка могли ведь поменяться. Поэтому высота распорки становится неактуальной, ее бы надо пересчитать. Ещё одним минусом является то, что нельзя сразу при первой загрузке сделать такие распорки, ведь мы не знаем наперед размеры элементов. Можно в принципе их прогнозировать через медианное значение уже загруженных элементов и каждый раз это значение рекалькулировать. Однако непонятно какие именно элементы и с каким офсетом грузить, если потянуть ползунок скроллбара в свободное место.
Если коротко, сделать честный скролбар — это отдельная задача, не такая уж и простая. Есть несколько граничных проблем, которые, по моему мнению, заставят вас отказаться от этой затеи. Но если все же вас не отговорить — то тогда это отличное поле для идей и экспериментов!
В некоторых браузерах я ловил поведение, что просто свойства transform: translateZ(0); не хватало. Работало только в связке с will-change. Поэтому я обычно стараюсь использовать такое сочетание.
Да, имелось ввиду содержимое контейнера. Спасибо за замечание. Поправил.
Как вариант. Но с точки зрения ux – не очень (на мой взгляд). Ты просишь пользователя установить другое приложение, чтобы у тебя работало твое приложение. Если уж на то пошло, то можно и через телеграм доставлять пуши. Качать ничего не надо -- надо просто заставить пользователей нажать start в боте.
Но для этого это прокси-приложение должно быть установлено у пользователя?
К сожалению, нет. Нативные пуши могут доставлять только приложения, которые доступны в AppStore.
Да, так и есть. Но ничего, подождем еще альтернативные сторы!
Спасибо за комментарий!
Не согласен, что данный подход усложняет разработку и делает ее дороже для бизнеса, ведь использовать css-шлюзы на практике довольно просто: необходимо написать всего лишь 1 строчку в нужном месте.
Не вижу причин не использовать препроцессоры, ведь данные технологии очень удобны при разработке, а в конечном счете превращаются в css.
Не согласен с тем, что проблема выдумана, ведь я выражаю свое мнение.
Используйте пиксели, если они вам удобнее. Я считаю, использовать rem-ы/em-ы — отличный способ привязать все размеры к базовой величине, что является стандартным решением, например, для дизайн систем.
Я лишь продемонстрировал подход как сделать интерфейс по-настоящему резиновым. Использовать его или нет — решение за вами!
Ваш вывод никак не противоречит моим рассуждением. Наклон прямой я выбрал лишь для простоты демонстрации. И, конечно, я специально делаю акцент, что можно менять масштаб пропорционально не только прямой, но и по другим функциям тоже. Можно делать кусочно-линейную функцию, которая будет иметь разный наклон для разных брейкпоинтов. Также я отметил, что данное поведение можно сделать и для высоты экрана, если это будет необходимо.
Я лишь демонстрирую подход, который максимально поддается управлению. Можно так файнтюнить/подкручивать, что интерфейс будет смотреться адекватно на больших экранах. Для меня этот подход приятнее, чем боковые распорки. Но опять же это дело вкуса :)
Я для примера сделал резиновость по линейной функции, никак не ограничивая эту функциональность. В продакшине, конечно, так делать не стоит. В самом простом случае, эту функциональность, надо, ограничивать через медиа-выражения, как минимум, до планшетных разрешений. Также через медиа-выражения вы можете менять наклон этой прямой на промежуточных брейкпоинтах.
Статья для примера применения резиновости. На каких разрешениях и как добавлять резиновость -- дело за вами!
Не вижу никакой ошибки. Вы можете как эталонное разрешение взять 1920х1080 и поддержать резиново только бОльшие разрешения. Для меньших экранов - не использовать данный функционал.
Когда я говорил «вследствие чего глазу очень тяжело остановиться на чем-то одном, а мышкой тяжело дотянуться до маленьких элементов», я имел ввиду действительно большие десктопные экраны 2k и больше.
Это дело вкуса. Меня, например, бесят большие боковые распорки, которые светят белым светом и выжигают глаза)
Я продемонстрировал подход, который помогает резиново масштабировать интерфейс. Причем функция адаптивности может быть любой, это настраиваемый момент. То есть если уменьшить наклон прямой, то можно масштабировать не совсем пропорционально и не так сильно. Я хочу сказать, что это можно отладить/подкрутить и сделать интерфейс адекватным на очень больших разрешениях.
Чтобы посмотреть как оно вживую ощущается, можете долго поскролить любой чат в телеграмме)
Я попробую пока что-нибудь придумать с демо-вариантом.
Добавление таких распорок может помочь сохранить честный скролбар, однако в ограниченном числе случаев. При первой работе со списком, кешировние размеров уже загруженных элементов может вам помочь в калькуляции размеров распорки. Но такой подход позволит вам вернуться с помощью ползунка только в те места списка, которые уже когда-то были загружены. Не совсем честный скролбар получается. Также если перезагрузить страницу, необходимо будет выполнить вычисления заново.
К тому же, непонятно что делать, если заресайзилось окно. Размеры элемента списка могли ведь поменяться. Поэтому высота распорки становится неактуальной, ее бы надо пересчитать. Ещё одним минусом является то, что нельзя сразу при первой загрузке сделать такие распорки, ведь мы не знаем наперед размеры элементов. Можно в принципе их прогнозировать через медианное значение уже загруженных элементов и каждый раз это значение рекалькулировать. Однако непонятно какие именно элементы и с каким офсетом грузить, если потянуть ползунок скроллбара в свободное место.
Если коротко, сделать честный скролбар — это отдельная задача, не такая уж и простая. Есть несколько граничных проблем, которые, по моему мнению, заставят вас отказаться от этой затеи. Но если все же вас не отговорить — то тогда это отличное поле для идей и экспериментов!
Спасибо за комментарий.
В некоторых браузерах я ловил поведение, что просто свойства
transform: translateZ(0);не хватало. Работало только в связке с will-change. Поэтому я обычно стараюсь использовать такое сочетание.Да, имелось ввиду содержимое контейнера. Спасибо за замечание. Поправил.