Javascript/соглашение о названии события DOM

Привет, когда я начал заниматься веб-разработкой, я понял, что имена событий javascript были в нижнем регистре без разделителей, т.е. "mousedown" , "mouseup" и т.д. И, работая с библиотекой jQuery UI, я заметил, что они также используют одно и то же соглашение; то есть "dropdeactivate" , как в следующем примере

javascript $( ".selector" ).on( "dropdeactivate", function( event, ui ) {} )

Хотя это хорошо работает для имен, которые всего 2 или 3 слова, это действительно ужасно для имен с большим количеством слов на нем.

Несмотря на это, я также следовал этому соглашению, когда мне приходилось запускать настраиваемые (синтетические) события, которые я создал, до недавнего времени, когда я решил, что лучше начать использовать какую-то форму разделителя. Теперь я использую что-то вроде "drop: deactivate или " приложение: готово.

в iOS apple недавно добавили это событие для API 5 Airplay API, и я согласен с автором этой публикации http://www.mobilexweb.com/blog/safari-ios7-html5-problems-apis-review, когда он говорит:

Я думаю, что "webkitcurrentplaybacktargetiswirelesschanged" выиграл запись: самое длинное имя события JavaScript.

В чем причина этого странного соглашения? почему бы не использовать какую-либо форму разделителя или соглашения camelCase, чтобы назвать события более читаемым способом?

Я думаю, что есть причина для этого, многие умные люди работали над этим... Но через некоторое время мне все еще интересно, почему?

Ответ 1

К сожалению, это не так просто, когда вы имеете дело с устаревшими соглашениями. И DOM Events имеют много истории за ними.

Здесь как атрибут типа Event определяется в спецификации DOM2 Events:

Событие интерфейса (введено в DOM Level 2)
type (типа DOMString, только для чтения)

Название события (без учета регистра). Имя должно быть именем XML.

Обоснование этого, я полагаю, объясняется этим абзацем в том же документе:

В HTML 4.0 прослушиватели событий были указаны как атрибуты элемент. [...] Чтобы добиться совместимости с HTML 4.0, разработчики могут просматривать настройки атрибутов, которые представляют событие обработчиков как создание и регистрация EventListener на EventTarget.

Теперь, когда позиция изменилась в DOM3 (где имена событий чувствительны к регистру), исходный подход, я полагаю, считается самым безопасным ставка - поэтому вам не придется зависеть от корректности пользовательских агентов (проверьте эту дискуссию и эту забавную проблему в качестве примеров).

Обратите внимание, что сам W3C зарегистрировал целое число событий CamelCased в DOM2 (все MutationEvents, DOMActivate, DOMFocusIn и DOMFocusOut).

Ответ 2

Насколько я могу судить, официальной практики в отношении этого предмета нет. Мне кажется, что поскольку camelCase является общепринятым стандартом для имен в js, то то же самое относится и к именованию событий. Однако, как вы отметили, сами js и многие библиотеки делают иначе. Я видел обе конвенции, используемые великими программистами, поэтому я считаю, что это просто несущественно. В случае "самого длинного имени события JavaScript когда-либо" это отличный пример события, которое должно было использовать camelCase, на мой взгляд... или, может быть, они могли бы просто сократить его:)

Если вы хотите придерживаться того, что вы видели чаще, используйте строчные буквы. Если вы думаете, что трудно на глаза (я делаю), используйте camelCase. Я, вероятно, не буду использовать ничего другого, если вы попытаетесь соответствовать стандарту.

Ответ 3

когда дело доходит до соглашений, это так или иначе, привычка, рамки JavaScript, похоже, соответствуют соглашению API-интерфейса JavaScript DOM, я не знаю, есть ли причина или, по крайней мере, четкая аргументация почему, но это просто так. для общих соглашений crockford является одной из лучших ссылок, но упоминаний о наименовании событий нет, но в то же время здесь события кажутся немного разными, что заставило меня думать об этом как о предмете выбора, не более, не менее