javascript/DOM tên sự kiện ước

Question

Xin chào khi tôi bắt đầu phát triển web, tôi nhận ra rằng tên sự kiện javascript là tất cả trong trường hợp thấp hơn không có dấu tách, tức là "mousedown", "mouseup", v.v. thư viện giao diện người dùng jQuery, tôi nhận thấy họ cũng sử dụng cùng một quy ước; ví dụ: "dropdeactivate" như trong ví dụ sau

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

Trong khi điều này hoạt động tốt cho những tên chỉ có 2 hoặc 3 từ, nó thực sự là khủng khiếp cho tên với lời thêm về nó.

Mặc dù vậy, tôi cũng tuân thủ quy ước đó khi tôi phải kích hoạt các sự kiện tùy chỉnh (tổng hợp) mà tôi đã tạo, cho đến gần đây khi tôi quyết định bắt đầu sử dụng một số hình thức tách khác. Bây giờ tôi sử dụng một cái gì đó như "thả: hủy kích hoạt" hoặc "ứng dụng: sẵn sàng".

trên iOS táo được thêm gần đây sự kiện này cho Airplay API HTML 5, và tôi đồng ý với autor của bài đăng này http://www.mobilexweb.com/blog/safari-ios7-html5-problems-apis-review khi ông nói:

Tôi nghĩ "webkitcurrentplaybacktargetiswirelesschanged" đã giành được kỷ lục: tên sự kiện JavaScript dài nhất từ ​​trước đến nay.

Lý do đằng sau quy ước lạ này là gì? tại sao không sử dụng bất kỳ hình thức phân tách hoặc quy ước camelCase nào để đặt tên cho các sự kiện theo cách dễ đọc hơn?

Tôi nghĩ rằng có một lý do cho điều đó, rất nhiều người thông minh đã làm việc về điều này ... Nhưng sau một thời gian tôi vẫn tự hỏi tại sao?

Answer 1

Thật không may, nó không đơn giản như vậy khi bạn xử lý các quy ước cũ. Và sự kiện DOM có rất nhiều lịch sử đằng sau chúng.

Sau đây là cách loại thuộc tính của Event được định nghĩa trong DOM2 Sự kiện đặc điểm kỹ thuật:

Giao diện tổ chức sự kiện (được giới thiệu trong DOM Level 2)
loại (loại DOMString, chỉ đọc)

Tên của sự kiện (không phân biệt chữ hoa chữ thường). Tên phải là một tên XML.

Lý do đằng sau này, tôi cho rằng, được giải thích bởi đoạn này trong cùng một doc:.

Trong HTML 4.0, nghe sự kiện được quy định như các thuộc tính của một phần tử [...] Để đạt được khả năng tương thích với HTML 4.0, người triển khai có thể xem cài đặt thuộc tính thể hiện sự kiện xử lý sự kiện là tạo và đăng ký EventListener trên Mục tiêu sự kiện .

Bây giờ, trong khi các lập trường đã thay đổi trong DOM3 (nơi tên sự kiện là case-sensitive), cách tiếp cận ban đầu là, tôi cho rằng, khả năng tiếp xúc được coi là đặt cược an toàn nhất - vì vậy ai sẽ không phải phụ thuộc vào đại lý người dùng 'đúng đắn (kiểm tra this discussion và this funny issue làm ví dụ).

Lưu ý rằng chính W3C đã đăng ký toàn bộ các sự kiện CamelCased trong DOM2 (tất cả các MutationEvents, DOMActivate, DOMFocusIn và DOMFocusOut).

Answer 2

Theo như tôi có thể biết, không có thực hành chính thức nào về chủ đề đó. Dường như với tôi rằng vì camelCase là tiêu chuẩn được chấp nhận chung cho các tên trong js, điều tương tự sẽ áp dụng với việc đặt tên sự kiện. Tuy nhiên, như bạn đã lưu ý, js chính nó và nhiều thư viện làm khác. Tôi đã thấy cả hai quy ước được sử dụng bởi các lập trình viên tuyệt vời, vì vậy tôi tin rằng nó chỉ đơn giản là không quan trọng. Trong trường hợp "tên sự kiện JavaScript dài nhất từng có" là ví dụ tuyệt vời về sự kiện đáng lẽ nên sử dụng camelCase, theo ý kiến ​​của tôi ... hoặc có thể họ đã rút ngắn nó :)

Nếu bạn muốn gắn bó với những gì bạn đã thấy thường xuyên hơn, sử dụng chữ thường. Nếu bạn nghĩ rằng đó là khó khăn trên mắt (tôi làm), sử dụng camelCase. Tôi có lẽ sẽ không sử dụng bất cứ điều gì khác nếu bạn đang cố gắng để phù hợp với một tiêu chuẩn.

Answer 3

khi nói đến quy ước, theo cách này hay cách khác, thói quen, khung JavaScript dường như tuân theo quy ước của API sự kiện JavaScript DOM, tôi không biết liệu có lý do hay ít nhất là rõ ràng lý do tại sao, nhưng nó chỉ là. cho các quy ước chung, crockford là một trong những tham chiếu tốt nhất, nhưng không đề cập đến việc đặt tên sự kiện, nhưng đồng thời here các sự kiện dường như hơi khác một chút, điều đó khiến tôi nghĩ về nó như một sự lựa chọn , không hơn, không ít hơn