Как стать автором
Обновить
1
0
Агафонов Владимир @Serator

Пользователь

Отправить сообщение

Модальность должна ограничивать пользователя во взаимодействии с родительским окном. В вашем случае доступ с клавиатуры никак не блокируется. Только указатель (к примеру, курсор мыши) и то при условии, что всякие там z-index у родителя и его потомков не будут перекрывать ваше окно. Проблема всей статьи в том, что слой поверх слоя можно было и 10 лет назад сделать относительно просто на "чистом CSS и JS", а вот именно модальное окно уже сильно сложней, если вообще осуществимо даже сейчас (т.е. воссоздать поведение нативного dialog в полной мере).

А модальность окна в чем заключается? Статья про div в виде окна, не более. Нативный dialog - не просто тег и он, как минимум, уже поддерживается. Почитайте еще про атрибут inert, технику focus trap, accessibility... И обновите свой пример, он сломан, так как modalTrigger пропущен.

Так лучше Tailwind JIT погуглить. Он давно уже из коробки только используемые классы добавляет. Как по мне, Tailwind проще классического CSS (назовем это так) для простых "вещей" и сложней для сложных. В основном, все пишут простые "вещи", от туда и его популярность.

Что я делаю не так?

place-items вместо place-content используете?

Потому что, к примеру, `display: grid; place-items: center; ` у родителя - не тоже самое, что `margin: auto;` у его потомка. Разные способы годятся под разные задачи.

`display: grid; place-content: center;` у родителя?

Можно и в одну строку записать как `margin-inline: auto`. В подавляющем большинстве случаев это будет тоже самое. Но в любом случае лучше не обнулять что-то, если это не требуется, а просто "так короче".

У самого 9550, сталкивался с проблемой вздутия батареи где-то через год после покупки. Заменили по гарантии. Через 3 года сломалась клавиша Enter (раскололась пополам) и здесь уже засада. Гарантия закончилась, а донора не найти (нашел на Али, оказалась гадостью редкостной, клавиши посыпались как осенние листья через месяц использования). Теперь вот думаю, стоит ли обновляться до нового XPS, аль смотреть в другую сторону...

А если открыть инструменты разработчика, то сразу становится понятно, что узкое место в демке — перерасчет стилей. Казалось бы, как здесь может помочь WebRender?..

prnt.sc/n47kkv — Chrome
prnt.sc/n47m4r — Firefox с включенным WebRender'ом
Есть предложение для будущей реализации: github.com/tc39/proposal-promise-allSettled.
mozillagfx.wordpress.com — хороший блог, где описывается процесс развития WebRender'а. Пока проект только пилится, разработчики решили ограничить число поддерживаемых карт, ОСей и т.п.
Я на 4k смотрю и все сильно хуже именно на этой станице, но это, как надеются сами разработчики, временно. Когда кеширование допилят, то и здесь все ок будет.

Выше много писали, что сейчас невозможно создать новый браузер и т.п. Mozilla же в случае с WebRender не браузер новый создает, а пробует совершенно новый подход к отрисовке, без этих костыльных и неудобных слоев на каждый чих. Если это решение окажется еще и быстрее существующего подхода, то, с точки зрения разработчика, это будет неоспоримое преимущество. Правда, обычному пользователю будет все равно, так как сейчас, по сути, все браузеры достаточно быстрые.
Так не везде и работает. :)
Проверьте на всякий about:support#graphics-features-tbody. В графе «Композитинг» должен стоять «WebRender». Насколько я знаю, подобные страницы все еще представляют большую проблему для WebRender'а из-за того, что при прокрутке он пытается на каждое смещение отрисовать всю сцену целиком. С отключенным WebRender'ом эта страница отрисуется как вы и описали (правда, у меня Chrome быстрее), но вот с включенным браузер намертво подвисает на секунды.
about:config > «gfx.webrender.all». Нет, его еще не включили в стабильной версии.
Не все так радужно. Попробуйте diana-adrianne.com/purecss-francine открыть с включенным WebRender. Fx будет очень тяжко переваривать и так при каждом сдвиге прокрутки. Но WebRender еще не в релизе, так что посмотрим, что будет в конце, самому интересно увидеть.

Сама карта уже ключём является. Для входа в банковское приложение также понадобится пароль, двухфакторная аутентификация и т.п.

Мои доводы касались тех проблем, решение которых описывалось в статье. Речь шла о производительности, а не о поддержке IE. Если бы все описывалось в контексте обратной совместимости, то мне это было бы неинтересно, так как, благо, под IE уже давно не пишу.

Про то, как работают браузеры (хоть открытые, хоть закрытые), написано множество статей + море информации можно найти в исходниках (не у всех открыты), багтрекерах, инструментах разработчика и прочем.

60 вызовов — это к тому, что штуки вроде `requestAnimationFrame`, CSS animation / transisition.., как раз и ограничиваются этими 60-ю кадрами, то бишь 60-ю перерисовками. Если transform отправляет что-то на GPU, а инструменты разработчика Chrome'а не показывают перерисовки, то это вовсе не означает, что ничего не происходит. Картинка-то на экране меняется. Вот как раз с потолком в 60FPS и меняется. А Paint flashing (зеленый прямоугольник) этого и не покажет.
Ваше утверждение немного неверно. 60fps — этакий стандарт для браузера. Соответственно, 60 вызовов функции перерисовки внутри браузера. Но суть не в этом. Я пока отброшу второй абзац вашего ответа, так как, если основываться на нем, то переменных (пользовательских свойств) CSS вообще быть не может, так как нет поддержки. В оригинальной статье автор обновлял DOM не только с целью проброски CSS переменных, но и с целью обновления данных для доступности, чего у вас уже нет. Для глаз это погоды не делает, а вот для слуха очень даже (по сему поводу чистая теория, так как нет желания проверить). Идем дальше. Ваш код создает отдельный слой и крутит его. И этот слой висит постоянно из-за анимации и не объединяется с другими слоями (http://prntscr.com/ir5mc8), посему вы не видите перерисовки. Такая «магия» дается не бесплатно, на нее выделяется память, что, как бы, тоже ресурс системы. Выше вам уже писали про «волшебное» свойство `will-change`, которое может сделать тоже самое для решения из оригинальной статьи. Добавьте `transition` и увидите теже 60FPS (появится постоянная перерисовка). Ну а если учесть
Так как часы отсчитывают время CSS-ом, то если забить тред какими-то тяжёлыми заданиями — часы перестанут идти и когда страница освободится — будут отставать. Но все это можно поправить заново задав keyframe.
то получается, что нам нужно точно так же пробрасывать в DOM кучу стилей не реже, чем раз в секунду. Так в чем профит-то? IE11?

И про загадочные 50.2FPS все тоже просто и понятно. Если открыть счетчик FPS на оригинальных часах, то там будет 1FPS (логично же, 1 перерисовка всего, но, на самом-то деле, это тоже может варьироваться, так как процессор можно нагрузить так, что будет 0FPS). На вашем же скрине видно, что включена настройка отображения перерисовок (зеленый прямоугольник), которая сама по себе вызывает перерисовку, так как этот самый зеленый прямоугольник появляется / исчезает плавно. Вот и FPS проседает (а проседает ли? :)).

Информация

В рейтинге
Не участвует
Откуда
Ростов-на-Дону, Ростовская обл., Россия
Дата рождения
Зарегистрирован
Активность