Cảnh báo JavaScript của Chrome

Thông thường, khi tôi dạy mọi người phát triển web, họ bắt đầu học JavaScript bằng cách xây dựng một trò chơi đoán số đơn giản theo những dòng này

function game() {
  let number = Math.ceil(Math.random() * 100);
  let guess = prompt(`Guess a number between 1 and 100`);

  guess = Number(guess);

  while (guess !== number) {
    if (guess < number) {
      guess = prompt(`Too low! Guess again`);
    } else {
      guess = prompt(`Too high! Guess again`);
    }

    guess = Number(guess);
  }

  alert(`That's right! The number was ${number}`);
}

game();

Vào chế độ toàn màn hình Thoát chế độ toàn màn hình

Đó là những thứ trông khá đơn giản, nhưng trong không gian của một vài dòng mã, sinh viên tiếp xúc với nhiều khái niệm xa lạ

• Các loại dữ liệu (chuỗi so với số và chuyển đổi giữa chúng)
• Các chức năng, cả chức năng tích hợp sẵn và chức năng bạn tự viết
• Vòng lặp và câu lệnh if-else
• nhà điều hành

Đó là một bài học phổ biến và thậm chí còn báo trước các cuộc thảo luận về thuật toán trong tương lai (những sinh viên thông minh nhất sẽ sớm trực giác rằng họ có thể 'chiến thắng' bằng cách tiến hành tìm kiếm nhị phân), nhưng nó khó - dễ dàng có giá trị một giờ. Bây giờ hãy tưởng tượng rằng trước khi họ có thể hoàn thành nó, họ được yêu cầu tìm hiểu về DOM, xử lý sự kiện và lập trình không đồng bộ. Các nhà giáo dục hướng tới việc chặn các API hộp thoại là có lý do

Không thể hiểu tại sao các API này lại có giá trị như vậy trong bối cảnh giáo dục là điều không thể tránh khỏi nếu bạn không coi giáo viên là một phần của khu vực bầu cử của mình khi thiết kế các tiêu chuẩn. Thật sáo rỗng (và chỉ chính xác một phần) khi nói rằng web từng có đường dẫn tốt hơn cho các nhà phát triển, nhưng có sự thật đằng sau lời càu nhàu hoài cổ. khả năng học hỏi của nền tảng web từ lâu đã là điều cần thiết cho sự thành công của nó. Chúng tôi làm hỏng nó trong tình trạng nguy hiểm của chúng tôi

tín hiệu ẩn

"Tín hiệu chính" mà Chrome sử dụng để xác định xem có thể xóa nội dung nào đó khỏi nền tảng web một cách an toàn hay không là số lượt xem trang bị ảnh hưởng. Một tính năng xuất hiện trên 0. 001% lượt xem trang được coi là mức sử dụng 'nhỏ nhưng không tầm thường'. (Chéo nguồn gốc alert ở khoảng 0. 006%, cao hơn đáng kể so với ngưỡng này; . )

Thật dễ dàng để lập chỉ mục quá mức cho những thứ bạn có thể định lượng, đặc biệt nếu bạn là Google. Nhưng không phải tất cả những thứ được coi là sử dụng một số tính năng đều hiển thị trong dữ liệu, khi dữ liệu chủ yếu là các trang web sản xuất công khai. Dạy học là một trong những trường hợp như vậy. Co nhung nguoi khac

Ví dụ: tôi đã có một số trải nghiệm trong đó một alert được đặt đúng vị trí là cách duy nhất để kiểm tra các giả thuyết trong quá trình gỡ lỗi. Trong một thế giới lý tưởng, tất cả chúng ta đều có phòng thí nghiệm thiết bị đầy đủ và có thể kiểm tra từ xa mã của chúng ta ở bất cứ đâu nó đang chạy, bất kể thời hạn sắp đến như thế nào. Thực tế không phải lúc nào cũng thuận lợi như vậy

Ngay cả khi mã của tôi đang hoạt động như dự kiến ​​— đôi khi nó vẫn xảy ra — tôi có khả năng đạt tới alert trước khi bổ sung thêm cách xử lý lỗi phức tạp, nếu tôi đang xây dựng thứ gì đó cho bản thân hoặc đồng nghiệp của mình và tôi mong rằng các lỗi sẽ hiếm khi xảy ra

Và các nhà nghiên cứu bảo mật thường xuyên sử dụng alert để chứng minh các lỗ hổng. (Vâng, trong tương lai họ có thể sử dụng thứ gì đó ít súc tích hơn và ít hiển thị hơn như alert()2, nhưng trong thời gian chờ đợi, những tài liệu có giá trị trong nhiều năm sẽ ngay lập tức lỗi thời nếu alert biến mất. )

Tất cả những cách sử dụng này đều hợp pháp, nhưng không có cách sử dụng nào sẽ ảnh hưởng đến chỉ số xác định liệu chúng có đủ quan trọng để được Chrome hỗ trợ hay không. Ngay cả khi chúng tôi chỉ tập trung vào các trang web sản xuất, việc sử dụng không nhất thiết tương quan với tầm quan trọng, như Dan Abramov đã lưu ý

vỡ

Theo Emily Stark, một chuyên gia bảo mật trong nhóm Chrome, sự cố là điều thường xuyên xảy ra trên web.

Nhưng nếu đó là sự thật, thì phần lớn là do Chrome. Trong một thời gian dài, 'không phá vỡ trang web' được coi là một chỉ thị chính trong hoạt động tiêu chuẩn. Nhớ lại #smooshgate. đề xuất thêm phương pháp alert()4 vào alert()5 hóa ra lại là một thay đổi đột phá vì một phiên bản cũ của MooTools, vẫn được một số ít trang web sử dụng, đã thêm vào phương pháp alert()4 không tương thích của chính nó. Thật đáng thất vọng, một số nhà phát triển lập luận rằng việc phá vỡ trang web có thể chấp nhận được, nhưng TC39 đã thực hiện nghiêm túc trách nhiệm tương thích ngược của mình và thay vào đó đổi tên alert()4 thành alert()8. Mathias Bynens của Google đã viết

Hóa ra, “không phá vỡ Web” là nguyên tắc thiết kế số một cho HTML, CSS, JavaScript và bất kỳ tiêu chuẩn nào khác được sử dụng rộng rãi trên Web

Lần này, cách tiếp cận khá ung dung hơn

Những người hợp lý có thể không đồng ý về sự cân bằng của các ưu tiên khi xem xét các thay đổi vi phạm, nhưng thật tốt khi hiểu rõ 'sự vi phạm' nghĩa là gì. Một trong nhiều giai thoại tôi đã nghe sau khi thay đổi cảnh báo nguồn gốc chéo nổi bật

Tôi đã cố gắng xóa tài khoản thanh toán định kỳ của mình khỏi trang web siêu cũ của cơ quan quản lý rác thải tại địa phương của tôi. Tôi đã bị lỗi xác nhận tên miền chéo () trong Chrome 92. Tôi đã chuyển sang Firefox để hoàn thành

Điều gì sẽ xảy ra nếu Firefox không còn là một tùy chọn nữa, vì Mozilla thiếu tiền mặt đã ngừng phát triển nó hoặc vì họ đã triển khai các thay đổi thông số kỹ thuật hiện đã được tiêu chuẩn hóa? . Một ngụ ý thường xuyên trong cuộc thảo luận tuần trước là chủ sở hữu trang web có thể chỉ cần thiết kế lại ứng dụng của họ để không sử dụng hộp thoại chặn, bất kể chi phí làm như vậy. Nhưng nhiều trang web không còn được duy trì và chúng không kém giá trị vì điều đó

Chúng tôi không thể bình thường hóa quan điểm rằng thiệt hại tài sản thế chấp là cái giá phải trả của sự tiến bộ, ngay cả khi chúng tôi chấp nhận tiền đề — điều mà tôi không chấp nhận — rằng việc xóa các API như alert thể hiện sự tiến bộ. Đối với tất cả các sai sót của nó, web thường được đồng ý là một nền tảng ổn định, nơi các khoản đầu tư được thực hiện ngày hôm nay sẽ đứng trước thử thách của thời gian. Một thế giới trong đó các trang web được coi là các đối tượng tạm thời vốn có, nơi các API mà chúng ta thường dựa vào ngày nay có thể bị những người sắp xếp thông số kỹ thuật của ngày mai gạt sang một bên như hành lý không mong muốn, là một thế giới mà web đã mất

Nếu cảnh báo là gì. tốt, thực sự?

Chúng tôi thường được nhắc sử dụng các thành phần biểu mẫu tích hợp sẵn của web thay vì tạo lại các hộp kiểm và nút với một món salad confirm()0. Chúng không chỉ dễ truy cập hơn so với những gì bạn có thể tự xây dựng, tính nhất quán về hình ảnh giúp người dùng điều hướng ứng dụng của bạn dễ dàng hơn ngay cả khi bạn cho rằng giao diện mặc định là "xấu xí"

Tuy nhiên, khi nói đến hộp thoại, mặc định xấu xí được coi là một lỗi hơn là một tính năng. Tại sao?

Sử dụng cảnh báo (), nhắc () và xác nhận () trong MVP là cách gần nhất mà hầu hết các nhà phát triển sẽ có được để cung cấp các hộp thoại có thể truy cập. Chrome xóa chúng chỉ cần cắt bỏ bước đó. Các nhà phát triển có thể đi thẳng vào việc xây dựng các hộp thoại hoạt động kém, không thể truy cập của riêng họ

Vào những ngày tồi tệ trước đây, hành vi của alert hơi đáng ghét — nó sẽ tập trung vào tab được đề cập và ngăn bạn điều hướng khỏi. Nhờ nhiều năm làm việc chăm chỉ, điều đó không còn xảy ra nữa, đến mức tôi cho rằng trong nhiều trường hợp, alert tốt hơn bất cứ thứ gì bạn tự mày mò

Có vấn đề về bảo mật với iframe có nhiều nguồn gốc. Tôi vẫn không tin rằng loại bỏ là một giải pháp tốt hơn là cải thiện thiết kế theo cách làm cho nguồn gốc của chúng rõ ràng hơn

Ai sở hữu web?

Một phản ứng phổ biến đối với sự lộn xộn của tuần trước là 'sử dụng Firefox'. Nhưng đó không phải là một giải pháp. Mặc dù thay đổi được đề xuất bởi Chromium (ý định xóa trước bất kỳ cuộc thảo luận nào với các nhà cung cấp trình duyệt khác), Firefox cuối cùng đã hỗ trợ nó. Đó là tất cả những gì cần thiết để một thứ gì đó trở thành 'tiêu chuẩn' - hỗ trợ từ hai nhà cung cấp và không có sự phản đối nào từ nhà cung cấp.

Đặt khác nhau. khi nói đến các tiêu chuẩn web, các trình duyệt chỉ quyết định

Bất cứ khi nào tôi đặt câu hỏi về sự khôn ngoan của đề xuất này hay đề xuất kia, tôi được cho biết rằng tôi chỉ nên tham gia vào các cuộc thảo luận về tiêu chuẩn - chúng ở ngay trên GitHub. Nhưng tính mở chẳng có ý nghĩa gì nếu không có khả năng tác động thay đổi và các trình duyệt có tất cả quyền lực. Điều này sẽ khiến chúng tôi cảm thấy kỳ lạ — ưu tiên của các khu vực bầu cử của W3C nêu rõ rằng nhu cầu của người dùng và tác giả (i. e. các nhà phát triển) nên được coi là ưu tiên cao hơn so với những người triển khai (i. e. các nhà cung cấp trình duyệt), tuy nhiên các khu vực bầu cử có mức độ ưu tiên cao hơn lại phụ thuộc vào các khu vực có mức độ ưu tiên thấp hơn. (Các nhà phát triển Chrome lập luận rằng họ đang hành động vì lợi ích của người dùng trong trường hợp này, nhưng chủ đề này từ Mike Sherov đưa ra một trường hợp thuyết phục rằng đây là lá sung cho động cơ thực sự, đó là nợ kỹ thuật. )

Trong khi đó, chúng ta dường như không học hỏi từ quá khứ. Nếu alert là trò chơi công bằng để xóa, thì mọi API chúng tôi thêm vào nền tảng cũng vậy nếu những người quản lý tương lai của web cho rằng nó có hại. Do đó, bạn sẽ nghĩ rằng chúng tôi sẽ hết sức thận trọng khi mở rộng diện tích bề mặt của nền tảng;

Với sự kiểm soát gần như độc quyền của Chrome đối với thị trường trình duyệt, tôi thực sự lo ngại về ý nghĩa của điều này đối với tương lai của web. Một công ty quảng cáo không nên có nhiều ảnh hưởng đến thứ thuộc về tất cả chúng ta. Tôi không biết làm thế nào để khắc phục quy trình tiêu chuẩn để nó đại diện hơn cho sự đa dạng của các bên liên quan trên web, nhưng tôi ngày càng tin rằng chúng ta cần phải tìm ra nó

Tại sao cảnh báo không hoạt động trong Chrome?

Tại sao cảnh báo JavaScript của tôi không hoạt động?

Làm cách nào để xóa thông báo cảnh báo trong JavaScript?

Sự khác biệt giữa cảnh báo cửa sổ và cảnh báo là gì?