Что означает синхронизация/асинхронность в таблице событий

Я не могу получить доступ к сайту, поэтому не совсем уверен, но обычно синхронизация/асинхронизация связана с блокировкой. Думаю, Sync щелчки будут блокировать друг друга, а Async колеса — нет.

@LãNgọcHảпопробуйте использовать прокси или сайт web.archive.org, чтобы открыть мою ссылку. Было бы здорово, если бы можно было дать ответ.

Ps: надеюсь, что однажды все спецификации UI Events перейдут в собственность WHATWG и станут менее «магическими».

Ммм интересно. Но больше всего меня интересует порядок выполнения синхронных событий с асинхронными. Допустим, у нас накопилась очередь из 100 событий кликов, при добавлении в эту очередь кликов по 60-му элементу (на момент добавления) произошло событие загрузки. Каков тогда порядок исполнения? Предположим, что компьютер просто долго думает и поэтому возникла такая очередь :)

Поскольку они не будут использовать один и тот же источник задач, и один синхронизирован, а другой асинхронен, это реализация определена, и браузеры имеют различные эвристики, чтобы решить, какую задачу они предпочтут другой, например. у них есть некоторая система голодания, позволяющая избежать слишком долгого запуска одного и того же источника задач, даже если он обычно имеет более высокий приоритет (щелчок IIRC будет иметь более высокий приоритет, по крайней мере, в Chrome и FF).

Простите, а что вы имеете в виду, когда говорите, что они используют не одни и те же источники задач? Это где-то в характеристиках написано?

Также есть примечание : There can be interactions between different event orders. For example, a click event might be modified by a concurrent keydown event (e.g., via Shift+click). However, the event orders of these different event sources would be distinct. Что значит click might be modified?

1/2 Вы не сказали, какое событие загрузки запускается, поэтому сложно указать конкретное место в спецификации, но вы можете начать с html.spec.whatwg.org/#event-load , нажмите на значок «загрузить» гиперссылку, чтобы увидеть перекрестные ссылки. Там, если мы возьмем, например. для <style> мы видим, что мы из источника сетевой задачи, для документа мы находимся в одном манипе DOM. К сожалению, для клика он плохо определен (еще раз надеюсь, что WHATWG скоро возьмет на себя ответственность и за него)

2/2, но общепринято, что для них предназначен источник задач пользовательского интерфейса. Что касается измененного события, они означают такие свойства, как ctrlKey, altKey или конкретно здесь shiftKey, а также другие, которые зависят от других событий от других устройств (здесь от клавиатурных).

Подводя итог моему пониманию: синхронные события — это события, которые зависят от других событий, например, нажатие левой кнопки мыши запускает группу событий mousedown -> mouseup -> click как задачу; Напротив, асинхронные события — это те, которые не имеют зависимости от других событий, поэтому загрузка картинки или скрипта, который поставит задачу «завершить загрузку», и событие load будет независимым от других событий. Но есть нюанс: событие abort указано асинхронным, как это понимать? Как ты понимаешь это Кайидо?

И еще, событие колеса указано как асинхронное, но почему? Это полностью синхронно, если я правильно понял всю теорию, ctrl+wheel up меняет поведение в документе, он переключается с прокрутки на изменение размера. Что-то здесь не так.

Честно говоря, я не знаю, как они выбирали, какой из них должен быть синхронизирован, какой из них должен быть асинхронным. Действительно, очень удивительно, что колесо является асинхронным, а отмена - синхронизированным, но ваше понимание все равно кажется неправильным: между нажатием кнопки мыши вниз и вверх может быть много задач и много событий от одного и того же устройства (например, перемещение мыши при перетаскивании). Но поскольку они приходят с одного и того же устройства, синхронизировать нужно не те. Вместо этого клавиатура и мышь отправляют свои события одновременно.

Возьмем, к примеру, эту скрипту: jsfiddle.net/yh98tfs1 При нажатии клавиши Shift цикл событий блокируется на 3 секунды. Если вы нажмете в течение этих 3 секунд, вы могли либо уже отпустить клавишу Shift, если событие мыши shiftKey должно быть ложным, либо вы могли бы все еще нажимать ее. Поскольку объект Event будет создан только после того, как цикл событий снова будет освобожден, потенциальное событие нажатия клавиши должно быть запущено в том же порядке, в котором оно было запущено относительно события mousedown, чтобы при построении события мыши оно имело правильный состояние. Их необходимо синхронизировать.

Также обратите внимание, что они работают над тем, чтобы полностью избавиться от этого понятия и вместо этого разработать более алгоритмическую спецификацию: w3c.github.io/uievents/event-algo.html Я не думаю, что вам следует тратить слишком много времени. в этом плане известно, что это плохо.

Ну я вроде все правильно понял, следуя порядку событий , когда я описывал порядок трёх событий мыши, это относится к порядку процесса (да, то, что вы расширили другими событиями, необязательно, я видел это в спецификации здесь), а ваш пример со скрипкой относится к порядку устройства. Или я ошибаюсь?

Не могли бы вы привести примеры этого предложения: Some sync events are driven by a specific device or process? Что движет устройством, а что — процессом? Если вы объясните этот момент, я обязательно пойму концепцию, это последнее, что я хотел знать. P.S. Извините, за много вопросов.