Khi cung cấp các tệp JavaScript, tốt hơn là sử dụng ứng dụng / javascript hoặc ứng dụng / x-javascript

95

Toàn bộ câu hỏi phù hợp với tiêu đề. Và để thêm một số bối cảnh: Tôi không hỏi điều gì là tốt nhất theo những gì thông số kỹ thuật đang nói, mà là điều gì hoạt động tốt nhất với sự kết hợp của các trình duyệt được triển khai hiện nay.

Một số điểm dữ liệu:

  • Google sử dụng text/javascriptJS được sử dụng trên trang chủ của họ.
  • Google sử dụng text/javascripttrên Google Tài liệu.
  • Google sử dụng application/x-javascriptđể cung cấp các tệp JavaScript với dịch vụ thư viện Ajax của họ .
  • Yahoo sử dụng application/x-javascriptđể phục vụ JS của họ.
  • Yahoo sử dụng application/x-javascriptJavaScript được phân phối trên trang chủ của họ.
javascript  http  content-type 
— avernet
nguồn
4
Buồn cười. Bạn đưa ra giải pháp thay thế thứ ba trong các ví dụ của mình ... Và theo Tim, cả hai người chơi lớn đều sai (về tiêu chuẩn), điều này có lẽ chỉ có nghĩa là các trình duyệt chịu đựng được (không có tin tức lớn ở đây) và nó có thể không quan trọng.
— PhiLho
1
có thể dupe: Javascript Loại MIME
— Bergi

Câu trả lời:

115
  • text/javascript Là lỗi thời
  • application/x-javascript đang thử nghiệm trong khi quyết định chuyển sang…
  • application/javascript là kiểu MIME chính thức hiện tại cho JS

Điều đó nói rằng, các trình duyệt thường bỏ qua việc content-typegửi bởi máy chủ và chú ý rất nhiều đến typethuộc tính (và một số có thể chưa nhận ra application/javascript).

Đề nghị của tôi:

  • Sử dụng ứng dụng / javascript trên máy chủ
  • Sử dụng HTML 5 và bỏ qua typethuộc tính khỏi các phần tử tập lệnh

NB: đặc tả HTML mâu thuẫn với tiêu chuẩn MIME và có một nỗ lực để thay đổi nó trở lại để text/javascriptđiều này có thể thay đổi trong tương lai.

— Quentin
nguồn
3
Câu hỏi này từ vài tháng trước nói hoàn toàn ngược lại. Có người là nhầm lẫn :) "đúng Kelly, trình duyệt có xu hướng tin tưởng kiểu MIME gửi với các tiêu đề phản ứng trên các loại thuộc tính của thẻ script" stackoverflow.com/questions/189850/...
— Marco
6
Ôi không! Những tổ chức lớn, đơn lẻ, chậm chạp phải đúng! Các thông số kỹ thuật phải được sai! Hừ! Tôi sẽ tiếp tục tin tưởng vào đặc điểm kỹ thuật và kinh nghiệm của bản thân đối với các công ty lớn (chậm chạp), ngay cả khi một trong số họ đã từng tuyển dụng tôi.
— Quentin
1
Rất tiếc, ai đó đã quên nói với W3C rằng văn bản / javascript đã lỗi thời. Nó dường như là mặc định trong HTML 5 . :: gãi đầu :: Cũng có vẻ như (nếu đọc lướt qua của tôi về phần này là chính xác) rằng các tác nhân người dùng được cho là chỉ truy cập vào typethuộc tính, do đó bỏ qua Content-typehành vi sẽ là đúng.
— big_m
1
@big_m - Đó là bởi vì nhiều trình duyệt không nhận dạng được application/javascriptnên việc chỉ định nó sẽ khiến họ bỏ qua tập lệnh. Tác nhân người dùng không được phép bỏ qua Loại nội dung. Thuộc tính type cho họ biết những gì họ mong đợi. Nếu họ không ủng hộ, họ không nên bận tâm yêu cầu. Nếu sau đó máy chủ nói rằng đó là một cái gì đó khác, họ nên tiếp tục điều đó thay vì HTML nói (ít nhất là theo HTTP, bạn có thể đang xem xét một thông số kỹ thuật khác, bạn không cung cấp bất kỳ liên kết nào).
— Quentin
1
@Quentin, tôi đang đề cập đến phần HTML 5 trên scriptphần tử mà tôi đã liên kết đến. Tôi đọc phần đó khác với những gì bạn mô tả; nó dường như đặt rất nhiều tầm quan trọng vào typethuộc tính và không đề cập đến việc kiểm tra Content-Type, ngoại trừ việc xác định mã hóa ký tự. Tôi đồng ý rằng có vẻ như sẽ là khôn ngoan nếu tác nhân người dùng xác minh rằng Loại nội dung phù hợp với những gì được mong đợi, nhưng tôi chưa tìm thấy bất kỳ điều gì trong thông số kỹ thuật HTML yêu cầu hoặc thậm chí khuyến nghị làm điều đó.
— big_m
7

Nếu bạn chọn sử dụng ứng dụng / javascript cho js trong các trang của mình, IE7 và IE8 sẽ không chạy tập lệnh của bạn! Đổ lỗi cho Microsoft tất cả những gì bạn muốn, nhưng nếu bạn muốn hầu hết mọi người chạy các trang của bạn, hãy sử dụng văn bản / javascript.

— Phi hành đoàn B
nguồn
3
Khi bạn nói rằng "ứng dụng / javascript" sẽ không hoạt động, bạn có nghĩa là nếu điều đó được đặt làm loại nội dung trên phản hồi HTTP hoặc làm thuộc tính "loại" của thẻ tập lệnh? Câu hỏi ban đầu là về loại nội dung trên phản hồi HTTP. Dựa trên các câu trả lời khác, có vẻ như chỉ giá trị của thuộc tính "type" trên các thẻ script sẽ tạo ra sự khác biệt trong IE.
— Jesse Hallett
7

Nó đã từng như vậy language="javacript". Sau đó, nó thay đổi thành type="text/javascript". Bây giờ nó là type="application/javacript". Ok, điều này đang trở nên ngu ngốc. Một số trình duyệt cũ không nhận ra cái mới application/javascript, nhưng vẫn nhận ra cái cũ hơn text/javascript. Tôi định tiếp tục sử dụng cái này, nếu không tôi sẽ lãng phí hàng giờ đồng hồ để cố gắng thay đổi MỌI phiên bản text/javascriptthành application/javascript.
Bây giờ một ngày nào đó điều ngược lại có thể đúng. Một ngày nào đó các trình duyệt mới nhất có thể từ chối kỹ thuật cũ để tuân thủ nghiêm ngặt tiêu chuẩn.
Nhưng cho đến khi mọi người xem trang web của tôi bắt đầu phàn nàn rằng "kể từ khi nâng cấp trình duyệt của tôi, khoảng 50% trang web của bạn đã biến mất", tôi không có động cơ nào để thay đổi mã trong trang web của mình.

— Sandip Armal Patil
nguồn
7

Đây là câu trả lời năm 2020 cho câu hỏi này.

text/javascriptlà loại MIME JavaScript chính xác theo Tiêu chuẩn HTML , trong đó nêu rõ:

Máy chủ nên sử dụng text/javascriptcho các tài nguyên JavaScript. Máy chủ không được sử dụng các loại MIME JavaScript khác cho các tài nguyên JavaScript và không được sử dụng các loại MIME không phải JavaScript.

Và cũng :

[…] Kiểu MIME được sử dụng để chỉ JavaScript trong đặc tả này là text/javascript, vì đó là kiểu được sử dụng phổ biến nhất, mặc dù nó là kiểu chính thức bị loại bỏ theo RFC 4329.

Công việc đang được tiến hành để phản ánh thực tế này trong RFC ở cấp IETF: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

Bất kỳ tuyên bố nào " text/javascriptlà lỗi thời" đều nói như vậy dựa trên RFC 4329, mà cả Tiêu chuẩn HTML và dự thảo IETF nói trên (tức là RFC sắp ra mắt) đều đang sửa chữa rõ ràng.

— Mathias Bynens
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.