ทำไมไม่มีแท็ก HTML ฝั่งไคลเอ็นต์รวมอยู่ด้วย

18

ฉันมีคำถามที่โพสต์เมื่อวันก่อนโดยโปรแกรมเมอร์อื่น ฉันจำได้ (นานมาแล้ว) สงสัยเหมือนกันมาก ทำไมแท็กรวมถึงเบราว์เซอร์จึงไม่เคยพิจารณา หรือว่ามัน?

โดยเฉพาะกับแท็กที่สั่งให้เบราว์เซอร์รวม HTML เพิ่มเติมจากแหล่งอื่น ๆ <include src="http://server/foo/bar.html">เช่น หลายคนจะเรียกใช้จาวาสคริปต์และเติมinnerHTMLเพื่อให้เหมือนกันเมื่อเบราว์เซอร์ภายนอกสามารถสร้างเอ็นจิ้นจาวาสคริปต์ได้

มันจะเจ็บปวดที่จะมี<HTML>s ซ้อนกัน<BODY>(เช่น) แต่เราต้องพิจารณาด้านนั้นทุกที่

history html

— เจคิว
แหล่งที่มา

หน่วยงานภายนอกไม่ได้ให้สิ่งนี้กับคุณแล้วใช่ไหม

— Peter Taylor

Transclusion ถูกพิจารณาว่าเป็นคุณลักษณะหลักของไฮเปอร์เท็กซ์แม้จะเป็นสิ่งประดิษฐ์ในยุค 60 ดังนั้นฉันแน่ใจว่ามันได้รับการพิจารณา ...

— อเล็กซ์ Feinman

12

ฉันเป็นคนสุดท้ายในโลกที่จำ ( Netscape 4-only ) layerและilayerแท็กหรือไม่

Netscape 4 ยังได้รับอนุญาตdivแท็กจะมีsrcแอตทริบิวต์ซึ่งประสบความสำเร็จในสิ่งเดียวกัน

Netscape ส่งพวกเขาไปที่ W3C ซึ่งเลือกที่จะไม่รวมพวกเขา - ใช้iframeแทน

— Dori
แหล่งที่มา

ฉันจำ NS4 ได้ แต่ไม่จำคุณสมบัติเหล่านั้น น่าเสียดายที่ฉันยังคงพึงพอใจกับเนื้อหาที่จะช่วยลดจาวาสคริปต์เบราว์เซอร์ BS จำนวนมาก

— Jé Queue

ฉันจำได้ว่าเกลียด NS4 ด้วยความหลงใหลว่าที่อยู่อีเมลที่ไม่ใช่ ISP รายแรกของฉันคือบัญชีฟรีที่ ihatenetscape.com Ah, ช่วงเวลาที่ดี: D

— wildpeaks

เลเยอร์โน้ตไม่ได้รวมฝั่งไคลเอ็นต์เนื่องจากยังคงมีdocumentวัตถุแยกต่างหากภายใต้นโยบายกำเนิดเดียวกัน พวกเขาเป็น iframe ที่วางตำแหน่งได้อย่างมีประสิทธิภาพ

— bobince

14

ทำไมแท็กรวมถึงเบราว์เซอร์จึงไม่เคยพิจารณา หรือว่ามัน?

เป็นที่ต้องการอย่างแน่นอนจากผู้เขียนเว็บมือใหม่ทุกคนที่ยังไม่ได้ใช้ Server Side รวมถึงในช่วงต้นของรายการ www-html แต่ในสมัยนั้น W3 มีความสุขที่ไม่สนใจความกดดันจากผู้เขียนเว็บ

หากอนุญาตให้มีการรวมข้ามไซต์มันจะเป็นหายนะด้านความปลอดภัย คุณสามารถดึงหน้าจากธนาคารของผู้ใช้และอ่านเนื้อหาจากมัน ( แต่เดิม DOM สคริปต์ถูก จำกัด แต่คุณสามารถยังคงได้อ่านจากdocument.links, document.imagesฟังก์ชั่นการเขียนสคริปต์ลดลงเพจเป้าหมาย ฯลฯ ตั้งแต่นั้นคุณสามารถทำในสิ่งที่คุณชอบที่มีเนื้อหาที่นำเข้า.)

หากไม่อนุญาตให้มีการรวมข้ามไซต์ ... ดีแล้วสถานที่นั้นจะไม่มีข้อได้เปรียบด้านเซิร์ฟเวอร์ มันจะยิ่งทำงานช้าลงสำหรับลูกค้าที่จะทำเช่นนั้นเซิร์ฟเวอร์จะได้รับการจัดการที่ดีขึ้น ซึ่งแตกต่างจาก<iframe>การรวมจะต้องป้องกันการโหลดหน้า SSIs จะดีกว่าทุกอย่าง

— bobince
แหล่งที่มา

5

ที่จริงแล้วไคลเอนต์ (หรือพร็อกซี) สามารถแคชได้อย่างมีประสิทธิภาพมากขึ้นเนื่องจากเทมเพลต (หรือส่วนหัว / ส่วนท้ายรวมถึง) ไม่มีแนวโน้มที่จะเปลี่ยนจากหน้าหนึ่งไปอีกหน้าซึ่งหมายความว่าอย่างน้อยผู้ใช้อาจเห็นส่วนหนึ่งของหน้า การประมวลผลฝั่งเซิร์ฟเวอร์เกิดขึ้น

— Alan Pearce

1

มันจะทำมากกว่าเซิร์ฟเวอร์ ฉันไม่แน่ใจว่าทำไมต้องบล็อกการโหลดหน้าเว็บอาจอนุญาตให้โหลดแบบเต็มหน้าเว็บด้วยการเติมเนื้อหา async แน่นอนว่าเบราว์เซอร์อาจถูก จำกัด ให้อนุญาตการดึงจากเซิร์ฟเวอร์ต้นทางหรืออนุญาตให้ใช้โดเมน DOM เท่านั้น

— Jé Queue

ฉันไม่เข้าใจว่ามันเป็นหายนะด้านความปลอดภัยหรือไม่ ฉันสามารถอ่านหน้าธนาคารทางฝั่งเซิร์ฟเวอร์ตอนนี้และคายมันไปที่หน้าอื่น - มันเป็นหายนะหรือไม่? อาจ แต่ไม่แน่นอนเกี่ยวกับความปลอดภัย ภัยพิบัติด้านความปลอดภัยจะอ่านคุกกี้จากโดเมนอื่น หากไม่มีฝั่งไคลเอ็นต์นี้จะเหมือนกับเซิร์ฟเวอร์ฝั่งเดียว ไม่เห็นปัญหาใด ๆ ที่นี่

— serg

คุณสามารถลองดึงข้อมูลหน้าธนาคารทางฝั่งเซิร์ฟเวอร์ แต่คำขอของคุณจะไม่ได้รับการตรวจสอบสิทธิ์ดังนั้นคุณจึงไม่สามารถดาวน์โหลดข้อมูลที่ฉ่ำได้ การร้องขอจากฝั่งไคลเอ็นต์รวมถึงคุกกี้และโทเค็นการตรวจสอบสิทธิ์ HTTP หากคุณสามารถอ่านการตอบสนองจากคำขอดังกล่าวคุณสามารถปลอมตัวเป็นผู้ใช้อย่างสมบูรณ์

— bobince

@bince: มีเหตุผลใดที่คำขอในฝั่งไคลเอ็นต์จะต้องมีคุกกี้และโทเค็นการตรวจสอบสิทธิ์ HTTP หรือไม่ สถานการณ์การใช้งานหลักที่ฉันเห็นสำหรับฝั่งไคลเอ็นต์รวมถึงเพื่อปรับปรุงการแคชเนื้อหาสแตติกเพจ หากสิบหกหน้าทั้งหมดรวมส่วนหัวและส่วนท้ายเดียวกันการใช้ฝั่งไคลเอ็นต์จะเพิ่มเวลาที่ต้องใช้ในการโหลดหน้าแรก แต่ลดเวลาในการโหลดหน้าสิบห้าที่เหลือ กรณีการใช้งานที่รวมถึงจะเป็นประโยชน์มากที่สุดจะได้อย่างแม่นยำผู้ที่ข้อมูลที่จะรวม "" จะคงที่และไม่จำเป็นต้อง ...

— supercat

10

ที่พวกเขาทำ. มันกลายเป็น<frameset>แท็ก ไม่นานพวกเขาก็เพิ่ม<iframe>แท็ก

เว็บเซิร์ฟเวอร์รุ่นแรก ๆ ส่วนใหญ่รองรับการใช้งานฝั่งเซิร์ฟเวอร์ดังนั้นการรวมข้อความของฝั่งไคลเอนต์จึงมีแนวโน้มว่าจะไม่จำเป็นเนื่องจากฟังก์ชั่นเดียวกันนี้ยังมีเฟรมอยู่

— greyfade
แหล่งที่มา

4

ไม่ใช้เฟรมเพื่อจุดประสงค์ที่แตกต่างจากการรวม บวกกับข้อ จำกัด ของ iframe โดยเฉพาะอย่างยิ่งในขนาดชุดวัตถุแน่นอนไม่สามารถคิดที่จะเกิดขึ้น

— Jé Queue

5

ฉันไม่เห็นด้วย - ฉันคิดว่านั่นเป็นสิ่งที่เฟรมทำ มีอะไรอีกบ้างที่เป็นเฟรมสำหรับการยกเว้น HTML เพิ่มเติม

— Jaco Pretorius

5

เฟรมรวม HTML ในเฟรมไม่ใช่โดยตรง - นี่คือความแตกต่าง

— mbq

4

@Xepoch: ... <iframe>ด้วย นั่นคือสิ่งที่มันเป็นสำหรับ มันจริงๆไม่แตกต่างกันมากจาก<div>ที่มีoverflow:auto;

— greyfade

3

ส่วน <iframe> องค์ประกอบบอกว่า "โหลดเอกสาร html ที่ระบุและติดที่นี่" คุณจะเลือกแทนที่จะเป็น Ajax หากคุณต้องการให้เอกสารถูกโหลดทันทีไม่ใช่ในการโทรแบบจาวาสคริปต์ ... เฟรมไม่ใช่โครงร่างของ HTML Div, p, br - เหล่านี้เป็นองค์ประกอบทั้งหมดที่ใช้สำหรับการจัดวาง คุณไม่ได้ใช้เฟรมสำหรับการจัดวาง

— Jaco Pretorius

3

วัตถุยังคงแสดงผลในเฟรมและคุณไม่สามารถเข้าถึง "ข้อมูล" ใน DOM สิ่งที่นักพัฒนาควรได้รับเมื่อหลายปีก่อนเป็นวิธีการรวมตัวอย่างด้วยแท็กง่ายๆ แม้ว่าแท็กนี้จะมีข้อ จำกัด แซนด์บ็อกซ์ของโดเมนมันจะค่อนข้างมีประโยชน์ในการแยกคุณลักษณะต่างๆให้ดีขึ้นปรับปรุงการบำรุงรักษาและใช้ประโยชน์จากการแคชเบราว์เซอร์

ฉันรู้ว่ามีปลั๊กอิน jquery ที่ดีมากมายที่ทำเช่นนี้และสคริปต์ด้านเซิร์ฟเวอร์จำนวนมาก แต่ไม่มีเหตุผลที่ดีที่จะไม่สนับสนุนแท็กดังกล่าว IMO เป็นคำถามที่ดี "ทำไมไม่มีแท็กรวมฝั่งไคลเอ็นต์"

ถ้าคุณชอบ jquery ที่นี่เป็นฝั่งไคลเอนต์ที่ดีรวมถึงสคริปต์: inc: super-จิ๋วฝั่งไคลเอ็นต์รวม JavaScript jQuery plugin

— โจนัส
แหล่งที่มา

คำตอบของคุณเป็นสิ่งเดียวที่ดูเหมือนจะตอกตะปูบนหัว คุณกำลังคิดบางอย่างเช่น #include ใน C หรือไม่ นี่คือสิ่งที่ "ลูกค้ารวม" หมายถึงฉัน - สิ่งอำนวยความสะดวกสำหรับการรวมตัวอย่าง HTML โดยพลการ (มากกว่าเอกสาร HTML ทั้งหมด) ภายในเอกสาร HTML เป็นเนื้อหาเอกสารที่สำคัญ แม้ว่ามันจะได้รับการออกแบบให้เป็นองค์ประกอบสำคัญของ HTML แทนที่จะเป็นขั้นตอนการแยกวิเคราะห์ - ผู้ถามที่แนะนำ <รวม src = "... "> ไวยากรณ์จะพอดีกับสิ่งนี้

— Stewart

ปัญหาของการเพิ่มเข้าไปในตอนนี้ก็คือความเข้ากันได้แบบย้อนหลัง แน่นอนว่านี่ไม่ได้อธิบายว่าทำไมมันจึงไม่รวมอยู่ในการออกแบบดั้งเดิมของ HTML

— Stewart

มันอาจได้รับการออกแบบให้เป็นคุณสมบัติของ SGML / XML โดยทั่วไปอีกด้วย ...

— Stewart

2

คุณเคยลองไหม

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

ฉันคิดว่ามีการใช้งานในเบราว์เซอร์ส่วนใหญ่

— Peter Turner
แหล่งที่มา

จะต้องลอง

— Jé Queue

2

ตัวแปรใน<include>แท็กได้รับการพิจารณาในประวัติต้น ๆ ของ HTMLแต่ไม่เคยไปไกล

— หนุน
แหล่งที่มา

1

อย่างไรก็ตามความหมายของแท็ก <include> นั้นคล้ายกับของเฟรม / iframe / object ของวันนี้ - มันจะรวมถึงเอกสาร html และไม่ใช่แค่ตัวอย่างของข้อความ / รหัสหรือแท็กแบบสุ่มตามที่ #include ของ C ต้องการ

— TomášPospíšek