Saat menyajikan file JavaScript, lebih baik menggunakan application / javascript atau application / x-javascript


95

Seluruh pertanyaan cocok dengan judulnya. Dan untuk menambahkan beberapa konteks: Saya tidak bertanya apa yang terbaik menurut spesifikasi, melainkan apa yang paling berhasil mengingat campuran browser yang diterapkan saat ini.

Beberapa poin data:

  • Google menggunakan text/javascriptJS yang digunakan di beranda mereka.
  • Google menggunakan text/javascriptdi Google Docs.
  • Google menggunakan application/x-javascriptuntuk menyajikan file JavaScript dengan layanan perpustakaan Ajax mereka .
  • Yahoo digunakan application/x-javascriptuntuk melayani JS mereka.
  • Yahoo menggunakan application/x-javascriptJavaScript yang disajikan di halaman beranda mereka.

4
Lucu. Anda memberikan alternatif ketiga dalam contoh Anda ... Dan menurut Tim, kedua pemain besar itu salah (dalam hal standar), yang mungkin hanya berarti browser toleran (tidak ada berita besar di sini) dan mungkin tidak masalah.
PhiLho

1
kemungkinan dupe: Javascript Jenis MIME
Bergi

Jawaban:


115
  • text/javascript sudah usang
  • application/x-javascript masih eksperimental saat memutuskan untuk pindah ke…
  • application/javascript adalah tipe MIME resmi saat ini untuk JS

Meskipun demikian , browser sering mengabaikan yang content-typedikirim oleh server dan sangat memperhatikan typeatributnya (dan beberapa mungkin belum mengenali application/javascript).

Rekomendasi saya:

  • Gunakan application / javascript di server
  • Gunakan HTML 5 dan hilangkan typeatribut dari elemen skrip

NB: spesifikasi HTML bertentangan dengan standar MIME, dan ada upaya untuk mengubahnya kembali text/javascriptsehingga dapat berubah di masa mendatang.


3
Pertanyaan dari beberapa bulan yang lalu ini mengatakan yang sebaliknya. Seseorang salah :) "Benar Kelly, browser cenderung mempercayai jenis MIME yang dikirim dengan header respons di atas atribut jenis tag skrip" stackoverflow.com/questions/189850/…
Marco

6
Oh tidak! Organisasi yang besar, monolitik, dan lambat pasti benar! Speknya pasti salah! Narghh. Saya akan terus mempercayai spesifikasi dan pengalaman saya sendiri terhadap perusahaan besar (lambat), bahkan jika salah satu dari mereka pernah mempekerjakan saya.
Quentin

1
Hmm, seseorang lupa memberi tahu W3C bahwa teks / javascript sudah usang. Sepertinya ini default di HTML 5 . :: scratch head :: Tampaknya juga (jika pembacaan sepintas saya pada bagian ini benar) bahwa agen pengguna seharusnya hanya menggunakan typeatribut, sehingga mengabaikan Content-typeperilaku yang benar.
big_m

1
@big_m - Itu karena banyak browser tidak mengenali application/javascriptsehingga menentukannya akan menyebabkan mereka mengabaikan skrip. Agen pengguna tidak seharusnya mengabaikan Content-Type. Atribut type memberi tahu mereka apa yang diharapkan. Jika mereka tidak mendukung, mereka tidak perlu repot-repot memintanya. Jika server kemudian mengatakan itu adalah sesuatu yang berbeda, mereka harus melanjutkannya daripada apa yang dikatakan HTML (setidaknya menurut HTTP, Anda mungkin melihat spesifikasi yang berbeda, Anda tidak memberikan tautan apa pun).
Quentin

1
@Quentin, saya merujuk ke bagian HTML 5 pada scriptelemen, yang saya tautkan . Bacaan saya tentang bagian itu berbeda dari apa yang Anda gambarkan; tampaknya sangat mementingkan typeatribut dan tidak menyebutkan memeriksa Content-Type, kecuali untuk menentukan pengkodean karakter. Saya setuju bahwa tampaknya akan bijaksana bagi agen pengguna untuk memverifikasi bahwa Jenis Konten cocok dengan yang diharapkan, tetapi saya belum menemukan apa pun dalam spesifikasi HTML yang memerlukan atau bahkan merekomendasikan untuk melakukan itu.
big_m


7

Jika Anda memilih untuk menggunakan application / javascript untuk js di halaman Anda, IE7 dan IE8 tidak akan menjalankan skrip Anda! Salahkan Microsoft semua yang Anda inginkan, tetapi jika Anda ingin kebanyakan orang menjalankan halaman Anda, gunakan teks / javascript.


3
Ketika Anda mengatakan bahwa "application / javascript" tidak akan berfungsi, apakah yang Anda maksud jika itu disetel sebagai tipe konten pada respons HTTP atau sebagai atribut "type" dari tag skrip? Pertanyaan asli tentang jenis konten pada tanggapan HTTP. Berdasarkan jawaban lain, sepertinya hanya nilai atribut "type" pada tag skrip yang akan membuat perbedaan di IE.
Jesse Hallett

7

Dulu language="javacript". Kemudian berubah menjadi type="text/javascript". Sekarang type="application/javacript". Oke, ini semakin bodoh. Beberapa browser lama tidak mengenali yang baru application/javascript, tetapi masih mengenali yang lama text/javascript. Saya berencana untuk terus menggunakan ini, atau saya akan membuang waktu berjam-jam untuk mencoba mengubah SETIAP contoh text/javascriptmenjadi application/javascript.
Sekarang suatu hari kebalikannya mungkin benar. Suatu hari nanti browser terbaru mungkin menolak teknik lama agar sesuai dengan standar.
Namun hingga orang yang melihat situs web saya mulai mengeluh bahwa "sejak peramban saya ditingkatkan versinya, sekitar 50% situs web Anda menghilang", saya tidak memiliki motif untuk mengubah kode di situs web saya.


7

Inilah jawaban tahun 2020 untuk pertanyaan ini.

text/javascriptadalah jenis MIME JavaScript yang benar sesuai dengan Standar HTML , yang menyatakan:

Server harus digunakan text/javascriptuntuk sumber daya JavaScript. Server tidak boleh menggunakan jenis MIME JavaScript lain untuk sumber daya JavaScript, dan tidak boleh menggunakan jenis MIME non-JavaScript.

Dan juga :

[…] Jenis MIME yang digunakan untuk merujuk ke JavaScript dalam spesifikasi ini adalah text/javascript, karena itu adalah jenis yang paling umum digunakan, meskipun jenis itu secara resmi sudah usang menurut RFC 4329.

Pekerjaan sedang dilakukan untuk mencerminkan kenyataan ini dalam RFC di tingkat IETF: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

Setiap klaim bahwa " text/javascriptadalah yang usang" mengatakan demikian berdasarkan RFC 4329, yang baik Standar HTML maupun draf IETF yang disebutkan di atas (yaitu RFC yang akan datang) secara eksplisit mengoreksi.


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.