Mengapa tidak ada HTML sisi klien yang menyertakan tag?


18

Saya punya pertanyaan diajukan kepada saya hari lain oleh programmer lain. Saya ingat (dulu sekali) bertanya-tanya hal yang sama. Mengapa tag menyertakan sisi browser tidak pernah dipertimbangkan? Atau apakah itu?

Khususnya dengan tag yang menginstruksikan browser untuk memasukkan HTML tambahan dari sumber lain. mis <include src="http://server/foo/bar.html">. Banyak orang akan melakukan panggilan javascript dan mengisi innerHTMLuntuk melakukan hal yang sama, ketika hal yang sama di luar mesin javascript dapat dilakukan oleh browser.

Itu akan menjadi menyakitkan telah bersarang <HTML>s <BODY>s (yaitu) tapi kita harus mempertimbangkan aspek yang mana saja pula.


Bukankah entitas eksternal sudah memberi Anda ini?
Peter Taylor

Transklusi dianggap sebagai fitur inti dari hiperteks bahkan dari penemuannya di tahun 60an. Jadi saya yakin itu dianggap ...
Alex Feinman

Jawaban:


12

Apakah saya orang terakhir di bumi yang mengingat (hanya Netscape 4 ) layerdan ilayertag?

Netscape 4 juga memungkinkan para divtag memiliki srcatribut yang dilakukan hal yang sama.

Netscape mengirimkannya ke W3C, yang memilih untuk tidak memasukkannya — gunakan iframesaja.


Saya memang ingat NS4 tetapi tidak ingat fitur-fitur itu. Sayang sekali, saya tetap konten itu akan menyimpan banyak javascript BS lintas-browser.
Jé Queue

Saya ingat membenci NS4 dengan penuh semangat sehingga salah satu alamat email non-ISP pertama saya adalah akun gratis di ihatenetscape.com. Ah, masa-masa indah: D
wildpeaks

Lapisan catatan tidak cukup sisi klien termasuk karena mereka masih memiliki documentobjek terpisah tunduk pada Kebijakan Asal yang Sama; mereka secara efektif merupakan iframe yang dapat diposisikan.
bobince

14

Mengapa tag menyertakan sisi browser tidak pernah dipertimbangkan? Atau apakah itu?

Itu pasti diminta oleh setiap penulis web pemula yang belum bekerja di Server Side Include, kembali pada hari-hari awal di daftar www-html. Tetapi pada hari-hari itu W3 senang sepenuhnya mengabaikan tekanan penulis web.

Jika inklusi lintas situs diizinkan, itu akan menjadi bencana keamanan. Anda bisa menarik halaman dari bank pengguna dan membaca konten darinya. (Awalnya, skrip DOM terbatas, tetapi Anda masih bisa membaca dari document.links,, document.imagesfungsi skrip dijatuhkan oleh halaman target, dll. Sejak itu, Anda dapat melakukan apa yang Anda suka dengan konten yang diimpor.)

Jika inklusi lintas-situs tidak diizinkan ... yah maka fitur tidak akan memiliki keuntungan lebih dari sisi server. Akan lebih, kerja lebih lambat bagi klien untuk melakukan hal yang seharusnya ditangani server dengan lebih baik. Tidak seperti <iframe>, sebuah menyertakan harus memblokir pemuatan halaman. SSI akan lebih unggul dalam segala hal.


5
Sebenarnya, klien (atau proxy) dapat melakukan cache lebih efisien, seperti template (atau header / footer) tidak cenderung berubah dari halaman ke halaman, yang berarti pengguna setidaknya dapat melihat bagian halaman sementara beberapa pemrosesan sisi server sedang berlangsung.
Alan Pearce

1
Itu akan melakukan lebih dari server secara signifikan. Saya tidak yakin mengapa itu perlu memblokir memuat halaman, itu bisa memungkinkan untuk memuat halaman penuh dengan isi-konten async. Tentu saja itu dapat dibatasi oleh browser untuk hanya mengizinkan tarikan dari server asal atau untuk mengizinkan DOM domain.
Jé Queue

Saya tidak mengerti bagaimana ini merupakan bencana keamanan. Saya dapat membaca halaman bank di sisi server sekarang dan memuntahkannya di halaman lain - apakah ini bencana? Mungkin, tapi yang pasti tidak terkait keamanan. Bencana keamanan akan membaca cookie dari domain yang berbeda. Tanpa ini sisi klien termasuk akan persis sama dengan sisi server satu. Tidak ada masalah di sini.
serg

Anda dapat mencoba mengambil halaman bank di sisi server tetapi permintaan Anda tidak diautentikasi sehingga Anda tidak dapat mengunduh informasi menarik. Permintaan dari sisi klien termasuk cookie dan token otentikasi HTTP; jika Anda dapat membaca respons dari permintaan seperti itu, Anda dapat sepenuhnya meniru pengguna.
bobince

@obobince: Apakah ada alasan bahwa permintaan di sisi klien harus menyertakan cookie dan token otentikasi HTTP? Skenario penggunaan utama yang akan saya lihat untuk sisi klien termasuk untuk meningkatkan caching konten halaman statis. Jika enam belas halaman semuanya menyertakan header dan footer yang sama, menggunakan include sisi-klien akan meningkatkan waktu yang diperlukan untuk memuat yang pertama, tetapi mengurangi waktu untuk memuat lima belas sisanya. Kasus penggunaan di mana penyertaan akan menjadi yang paling membantu justru di mana data yang akan "dimasukkan" akan menjadi statis dan karenanya tidak perlu ...
supercat

10

Mereka lakukan. Itu menjadi <frameset>tag. Tidak lama kemudian, mereka menambahkan <iframe>tag.

Sebagian besar server web awal yang mendukung server-side meliputi, jadi sebuah tekstual sisi klien kemungkinan dianggap tidak perlu, mengingat bahwa fungsionalitas yang sama tersedia juga dengan bingkai.


4
Tidak benar-benar bingkai melayani tujuan yang sangat berbeda dari penyertaan. Ditambah pembatasan iframe terutama dalam ukuran objek yang ditetapkan pasti tidak bisa berpikir untuk menggantikannya.
Jé Queue

5
Saya tidak setuju - saya pikir itulah yang dilakukan frame. Untuk apa lagi frame kecuali termasuk lebih banyak HTML?
Jaco Pretorius

5
Bingkai termasuk HTML dalam bingkai, tidak langsung - ini bedanya.
mbq

4
@ Xepoch: ... Dengan sebuah <iframe>. Itulah apa itu untuk . Ini benar-benar tidak jauh berbeda dari <div>denganoverflow:auto;
greyfade

3
Elemen <iframe> pada dasarnya mengatakan "muat dokumen html yang ditentukan dan tempel di sini". Anda akan memilihnya daripada ajax jika Anda ingin dokumen tersebut dimuat segera, bukan pada panggilan javascript ... Frame TIDAK tata letak jendela HTML. Div, p, br - ini semua elemen yang digunakan untuk tata letak. Anda tidak menggunakan bingkai untuk tata letak (atau Anda tidak boleh lagian).
Jaco Pretorius

3

Objek masih merender dalam bingkai dan Anda tidak memiliki akses DOM ke "data." Apa yang seharusnya diberikan pengembang bertahun-tahun yang lalu adalah cara untuk memasukkan cuplikan dengan tag sederhana. Bahkan jika tag ini memiliki batasan kotak pasir domain, akan sangat berguna untuk mengelompokkan fitur, meningkatkan pemeliharaan, dan memanfaatkan caching peramban.

Saya tahu ada banyak plugin jquery bagus yang melakukan ini dan banyak skrip sisi server, tetapi tidak ada alasan bagus untuk tidak mendukung tag semacam itu. IMO itu pertanyaan yang bagus, "Mengapa tidak ada tag sisi klien termasuk?"

Jika Anda suka jquery di sini adalah sisi klien yang baik termasuk skrip: inc: Sisi klien yang sangat kecil termasuk plugin JavaScript jQuery


Balasan Anda adalah satu-satunya yang tampaknya telah memukul paku di kepala. Apakah Anda memikirkan sesuatu seperti #termasuk dalam C? Ini persis seperti hal "sisi klien termasuk" berarti bagi saya - fasilitas untuk memasukkan potongan HTML sewenang-wenang (bukan seluruh dokumen HTML) dalam dokumen HTML sebagai konten dokumen yang tidak terpisahkan. Meskipun itu dapat dirancang sebagai fitur integral dari HTML daripada sebagai tahap pra-parsing - penanya yang disarankan <src = "..."> sintaksis akan cocok dengan ini.
Stewart

Masalah dengan menambahkannya sekarang adalah kompatibilitas ke belakang. Tentu saja, ini tidak menjelaskan mengapa itu tidak termasuk dalam desain HTML asli.
Stewart

Atau bisa juga dirancang sebagai fitur SGML / XML lebih umum ....
Stewart

2

Sudahkah Anda mencoba

<object  type="text/html" data="page.html" height="500" width="500">
What I see if that didn't work 
</object>

Saya pikir itu diterapkan di sebagian besar browser.


Akan perlu mencoba.
Jé Queue

2

Varian pada <include>tag memang dipertimbangkan dalam sejarah awal HTML , tetapi mereka tidak pernah terlalu jauh.


1
Namun semantik tag <include> itu mirip dengan yang ada di frame / iframe / object hari ini - itu akan mencakup dokumen html , dan bukan hanya potongan teks / kode atau tag acak seperti yang dicantumkan oleh C's #include.
Tomáš Pospíšek
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.