ทำไม HTML ถึงไม่รองรับฟีเจอร์ `include` ได้ด้วยตัวเอง?

 (frontendmasters.com)
2 คะแนน โดย GN⁺ 2025-05-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ความต้องการที่จะไม่ต้องเขียน header ซ้ำในหลายหน้าเป็นเรื่องพื้นฐาน แต่ใน HTML ไม่มี แท็ก include แบบเนทีฟ สำหรับจัดการเรื่องนี้โดยตรง
  • นักพัฒนาแก้ปัญหาเดียวกันนี้มานานด้วย วิธีอ้อม อย่าง JavaScript fetch, server directives, static site generators, template languages, backend languages และ Web Components
  • แม้ <iframe> จะเป็นวิธีที่ใกล้เคียงกับ HTML ล้วนมากที่สุด แต่ก็ไม่เหมาะกับการใช้งานนี้ในแง่ประสิทธิภาพ การเข้าถึง และการใช้งานโดยรวม
  • CSS สามารถ import CSS ได้ และ JavaScript ก็สามารถ import JavaScript ได้ แต่ HTML กลับ import HTML ไม่ได้ จนทำให้ ความสอดคล้องของเว็บแพลตฟอร์ม ดูสั่นคลอน
  • ผลกระทบต่อ preload scanner, อาการ layout ขยับจากการโหลดแบบ asynchronous, include แบบซ้อนหรือวนลูป, จำนวน request ที่เพิ่มขึ้น, ข้อจำกัดด้านโดเมน และความต้องการที่อาจไม่มากพอ ยังคงเป็น อุปสรรคในการทำให้เป็นมาตรฐาน

ความต้องการพื้นฐานในการนำชิ้นส่วน HTML ที่ซ้ำกันกลับมาใช้ใหม่

  • ปัญหานี้เห็นได้ชัดเมื่อ index.html, about.html, contact.html ทั้งสามหน้าต้องมี header เดียวกัน
  • แทนที่จะคัดลอกโค้ดเดียวกันสามครั้ง ก็เป็นเรื่องธรรมชาติที่จะอยากสร้าง header ไว้ครั้งเดียวแล้ว include ในหลายหน้า
  • ถ้าจำนวนหน้าเพิ่มเป็นหลักพัน นี่จะไม่ใช่แค่เรื่องความสะดวก แต่เป็นปัญหาเรื่อง การหลีกเลี่ยงโค้ดซ้ำซ้อน

มีวิธีแก้อยู่แล้วหลากหลายแบบ

  • การดึงชิ้นส่วน HTML มาแทรกนั้นทำได้อยู่แล้วผ่านเครื่องมือและหลายชั้นของระบบ
    • JavaScript สามารถใช้ fetch เพื่อดึง HTML และใช้ insertAdjacentElement เพื่อแทรกได้
    • ยังมี Server Side Includes ซึ่งเป็น server directive แบบเก่า
    • ใช้ฟีเจอร์จาก static site generator อย่าง Jekyll include ได้
    • ใช้ task runner อย่าง gulp-include ได้เช่นกัน
    • template language อย่าง Handlebars partials ก็มักมีฟีเจอร์ include มาให้
    • backend language อย่าง PHP ก็สามารถสร้าง HTML แบบไดนามิกได้ผ่าน include
    • ยังมีแนวทางแบบ Web Component ที่ทำมาเพื่อ include โดยเฉพาะ
  • <iframe> แม้ในเชิงเทคนิคจะเป็นวิธีนำ HTML อื่นเข้ามาด้วย HTML ล้วน แต่ก็มีปัญหาใหญ่ด้าน ประสิทธิภาพ การเข้าถึง และการใช้งาน สำหรับจุดประสงค์นี้
  • อีกทางเลือกหนึ่งคือไม่ใช้ include เลย แล้วพึ่งความสามารถ find/replace ที่ทรงพลังแทน

แต่ตัว HTML เองกลับไม่มี

  • วิธีทั้งหมดข้างต้นไม่ใช่การ “ใช้แท็ก HTML ตัวเดียวเพื่อดึง HTML มาใส่ไว้ตรงนี้”
  • เหมือนกับที่ <img> ดึงรูปภาพมาแสดงตรงตำแหน่งนั้น HTML กลับไม่มี แท็กเชิงประกาศโดยตรง ที่บอกว่า “ดึง HTML นี้มาแล้วใส่ไว้ที่นี่”
  • ใน ShopTalk Show ก็มีการพูดคุยคำถามนี้ต่อเนื่องเช่นกัน โดยมีทั้ง Jake Archibald และ Dave Rupert ร่วมถกประเด็นนี้

จุดที่ขัดกับแนวโน้มเดิมของเว็บแพลตฟอร์ม

  • มาตรฐานเว็บและเบราว์เซอร์มักค่อย ๆ ดูดซับสิ่งที่นักพัฒนาแก้กันเองซ้ำ ๆ ให้กลายเป็นฟีเจอร์ของแพลตฟอร์ม
  • จากเดิมที่ต้องใช้ third-party JavaScript จัดการเรื่องวันที่ ตอนนี้ก็มี Temporal
  • ความต้องการเรื่อง page transition ที่เคยพึ่ง framework ก็มี View Transition API มารองรับ
  • พื้นที่ของไลบรารีที่ใช้วางตำแหน่งองค์ประกอบอย่างปลอดภัย ก็เริ่มมี CSS anchor positioning เข้ามา
  • ในเมื่อแทบทุกเว็บไซต์ต้องการใช้ชิ้นส่วน HTML ซ้ำ และต่างก็ใช้เครื่องมือที่ไม่เป็นมาตรฐานกันไปเอง การไม่มี HTML include จึงดูเหมือนเป็น ช่องว่างที่ผิดปกติ

ทำไม HTML include ถึงกลายเป็นมาตรฐานได้ยาก

  • ในมุมของเบราว์เซอร์และระบบนิเวศ HTML include มีภาระหลายด้าน
    • อาจทำให้ preload scanner ทำงานได้แย่ลง และส่งผลเสียต่อประสิทธิภาพเว็บ
    • ถ้าต้องเป็นแบบ asynchronous ก็อาจทำให้หน้าจอสั่น ขยับ หรือกระโดดระหว่างโหลด
    • อาจเพิ่มความซับซ้อนที่กระทบต่อความเรียบง่ายหรือความบริสุทธิ์ของ HTML
    • การจัดการ include แบบซ้อนและ include แบบวนลูปอาจทำได้ยาก
    • ผู้ให้บริการเว็บโฮสติ้งอาจคัดค้านเพราะจำนวน request เพิ่มขึ้น
    • ต่างจาก image, CSS และ JavaScript นั้น HTML อาจต้องมีข้อจำกัดที่เข้มงวดกว่าสำหรับการดึงจากโดเมนอื่น
    • อาจยังมีปัญหาอื่นนอกเหนือจากรายการนี้อีก
    • และในความเป็นจริง ความต้องการฟีเจอร์นี้อาจไม่ได้สูงมากนัก
  • มากกว่าจะเป็นคำตอบที่ชี้ชัด นี่จึงใกล้เคียงกับการ สำรวจเหตุผล ว่าทำไม HTML ถึงยัง include HTML โดยตรงไม่ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-05-05
ความคิดเห็นบน Hacker News

  • ในอดีต HTML เป็นการประยุกต์ใช้ SGML และ SGML สามารถ include ได้
    สามารถนิยาม “entity” ใหม่ได้ และถ้าสร้าง “system” entity ก็จะอ้างอิงในภายหลังเพื่อให้ถูกแทนที่ได้ SGML ซับซ้อน จึงมีความพยายามหลายครั้งที่จะทำให้ HTML เรียบง่ายขึ้น และฟีเจอร์นี้ก็หลุดออกไประหว่างทาง

    • ช่วงสั้น ๆ เคยผ่านทางฝั่ง XML ด้วย XHTML และ XML มี XInclude แต่ไม่ใช่ฟีเจอร์บังคับ
    • เป็นข้อมูลอ้างอิงที่น่าสนใจ เลยคิดว่าจะค้นต่ออีก
      แท็กดังกล่าวดูเหมือนจะรวม หรือฝังหน้า HTML อื่นเข้ามา หน้า HTML ที่ถูกฝัง: https://www.w3schools.com/tags/tag_object.asp
    • นั่นเป็น attack surface แบบเต็มตัวในตัวมันเอง
      https://en.wikipedia.org/wiki/Billion_laughs_attack
    • ใน DTD ที่ใช้กับ HTML 4 หรือต่ำกว่าและ XML ก็มีอยู่ และน่าจะมาจาก SGML

  • เป็นโพรงกระต่ายที่หลงเข้าไปตั้งแต่ปลายยุค 90 และจนถึงตอนนี้ก็ยังออกมาไม่ได้
    ตอนนั้นเป็นเว็บมาสเตอร์ของเว็บไซต์ Analog Science Fiction และต้องสร้างหน้า static จำนวนมหาศาลที่มี header กับ sidebar เหมือนกันจนแทบคลั่ง พอค้นไปค้นมาก็เจอ server-side include ของ Apache และทำให้มันเป็นแบบ DRY ได้ตั้งแต่ก่อนจะรู้จักคำว่า DRY ด้วยซ้ำ บางคนบอกว่า iframe ก็พอ แต่จริง ๆ ไม่พอ iframe ไม่ขยายตามขนาดเนื้อหา และทางออกฝั่ง server ก็ต้องมี server ไม่เข้าใจว่าทำไมจึงไม่มีวิธีง่าย ๆ ฝั่ง client และตอนนี้ที่กำลังแก้ความน่ารำคาญหลายอย่างของ web development ก็น่าจะเป็นคำถามที่ควรพิจารณา

    • server-side include นั้นยอดเยี่ยมที่สุด
      ตอนที่เริ่มทำ “web stuff” กับเพื่อนในช่วงกลางยุค 90 แนวคิด DRY ก็เข้าใจได้เองโดยธรรมชาติ ตอนนั้น ISP แบบ dial-up ไม่ได้ห้ามใช้ .htaccess ในพื้นที่เว็บของผู้ใช้ จึงเปิด server-side include ได้ และต่อมาก็ค้นพบวิธีเปิด CGI ด้วย ถึงขั้นเขียน web shell พื้นฐานด้วย Perl เพื่อสำรวจกล่องเว็บเซิร์ฟเวอร์
    • ด้วยเหตุผลแบบนี้จึงชอบ https://htmx.org
      เป็น ไลบรารีขนาดเล็ก 10KB ที่เสริมฟีเจอร์หลักอย่าง dynamic import ของ static HTML ให้กับ HTML
    • ส่วนที่ว่า “iframe ไม่ขยายตามเนื้อหา” จริง ๆ แล้วอยู่ในแผนเดิม
      https://caniuse.com/iframe-seamless
    • แม้แต่ Netscape ปี 1996 ก็ทำแบบนี้ได้ ตอนนี้ก็ยังดูแลเซิร์ฟเวอร์ของเว็บไซต์ที่ใช้วิธีนี้อยู่
      สิ่งที่รำคาญเสมอเกี่ยวกับ frame คือมันพยายามฉลาดเกินไป เวลาคลิกขวาแล้ว refresh ไม่ได้อยากให้โหลดเฉพาะ HTML ของ frame ใหม่ เข้าใจเจตนาที่ต้องการ cache แยกต่างหาก แต่ frame กับ cache ควรแก้ปัญหาคนละเรื่อง กลับเอามาปนกันจนทั้งสองอย่างครึ่ง ๆ กลาง ๆ ผมคิดว่า HTML include ควรทำงานแบบโง่ ๆ ให้มากที่สุด แค่เอาข้อความที่ include มาวางในตำแหน่ง include แล้วให้ browser รับข้อความผลลัพธ์นั้นก็พอ ถ้าอยาก cache navigation เดียวกันในทุกหน้าแยกต่างหาก ก็เพิ่มคุณสมบัติ cache เพื่อแก้ปัญหานั้นอย่างอิสระได้ อาจโน้มน้าวได้ว่า include ควรทำงานมากกว่านี้ แต่ พฤติกรรมแบบโง่ ๆ ไม่ใช่บั๊ก แต่เป็นฟีเจอร์
    • ทางออกที่ดีที่สุดคือสร้างเอกสาร static ด้วย template engine

  • ข้อเสนอฟีเจอร์นี้ถูกเรียกว่า HTML Imports และถูกสร้างขึ้นเป็นส่วนหนึ่งของงาน Web Components
    เคยมีคำอธิบายว่า “HTML Imports are a way to include and reuse HTML documents in other HTML documents” และเอกสารแผนอยู่ที่ https://www.w3.org/TR/html-imports/

    • ตรงกับสิ่งที่คอมเมนต์ [1] ในบทความกล่าวถึง เช่น ความต้องการน้อย ผู้ผลิตไม่ค่อยกระตือรือร้น เป็นต้น
      แต่เหตุผลเหล่านี้แทบเป็นเหตุผลที่ไม่อธิบายอะไรจริง ๆ ฟีเจอร์นี้ถูกขอมาตลอด 20 ปี และมี shim implementation สารพัดที่ทำด้วย script หรือ backend engine ฯลฯ จึงเชื่อได้ยากว่าความต้องการต่ำ การปฏิเสธของ vendor ก็ไม่ได้อธิบายว่าทำไมถึงปฏิเสธถึงขั้นย้อนเอา implementation ที่มีอยู่แล้วออกไปด้วย “ผลกระทบด้านความปลอดภัย” ก็แปลก เพราะเราสามารถใช้แท็ก script ดึง HTML ข้าม origin มาแล้ว document.write() ได้อยู่แล้ว น่าสงสัยว่าทำไม script ที่ document.write() ถึงโอเค แต่แท็ก HTML ที่ทำเรื่องเดียวกันกลับเป็นปัญหาใหญ่ เข้าใจข้อกังวลด้านความปลอดภัยที่ควรป้องกันการ clone หน้าแรกของ Google แบบทันที แต่เรื่องนั้นดูเหมือนแก้ได้ง่ายด้วย CORS
      [1] https://frontendmasters.com/blog/seeking-an-answer-why-cant-...
    • HTML Imports ก็ไปในทิศทางคล้ายกัน แต่ไม่เหมือนฟีเจอร์ที่บทความบล็อกพูดถึง
      HTML ควรถูก import เข้ามาและแสดงที่ตำแหน่งเฉพาะในเอกสาร แต่ HTML Imports ทำสิ่งนี้ไม่ได้หากไม่มี JavaScript ดูรายละเอียดได้ที่ https://github.com/whatwg/html/issues/2791#issuecomment-3112...
    • ถ้าพูดอย่างเป็นธรรม มันค่อนข้างซับซ้อน
      เท่าที่จำได้ หลัง import แล้วต้องใช้ JavaScript instantiate template และไม่ใช่วิธีที่ทำได้ด้วยแท็กง่าย ๆ เพียงแท็กเดียว
    • ดู https://caniuse.com/imports จะเห็นว่า Firefox ก็เคยมีอยู่ผ่าน setting flag
    • HTML Imports ซับซ้อนกว่า include ที่บทความนี้ต้องการมาก

  • Netscape 4 เคยมีฟีเจอร์นี้ในชื่อ inflow layer
    https://web.archive.org/web/19970630074729fw_/http://develop...
    https://web.archive.org/web/19970630094813fw_/http://develop...

    • เท่าที่รู้ การเปลี่ยนแอตทริบิวต์ SRC ทำให้แครชได้ค่อนข้างง่าย และฟีเจอร์นี้ก็ถูกถอดออกไปไม่นานหลังจากนั้น
      จำได้ว่าเคยลองเล่นในเวอร์ชันเบต้า แต่พอเป็นเวอร์ชันจริงก็หายไปแล้ว
    • สงสัยมาตลอดว่าทำไมถึงตั้งชื่อว่า ILAYER ตอนนี้เข้าใจแล้ว

  • ฟีเจอร์นี้เรียกว่า transclusion
    https://en.wikipedia.org/wiki/Transclusion
    มันเป็นส่วนหนึ่งของ Project Xanadu และเดิมทีถูกมองว่าเป็นฟีเจอร์สำคัญของไฮเปอร์เท็กซ์ โดยเฉพาะ MediaWiki ใช้ transclusion อย่างกว้างขวาง และบางครั้งวิกิก็ให้ความรู้สึกเหมือนเป็นรูปแบบที่บริสุทธิ์ที่สุดของไฮเปอร์เท็กซ์

    • Ward Cunningham ผู้สร้าง Wiki เคยพยายามสร้าง วิกิที่ให้ transclusion เป็นหลัก ซึ่งทุกคนมีพื้นที่วิกิของตัวเองและใช้ transclusion กันในเชิงสังคม
      https://en.wikipedia.org/wiki/Federated_Wiki
      แต่ก็ไม่ได้ดังขึ้นมาอย่างจริงจัง
    • ผมคิดว่า transclusion ของจริงมีความหมายมากกว่านั้น
      ใน Xanadu สามารถ transclude เฉพาะบางส่วนที่ตัดมาจากเอกสารหนึ่งไปไว้ในอีกเอกสารหนึ่งได้ หากจะทำสิ่งนี้ใน HTML จำเป็นต้องมีคำตอบเรื่อง CSS ในบางสถานการณ์อาจตัดสินใจและแก้ได้ว่าควรทำให้พร็อพเพอร์ตีใดสอดคล้องกันระหว่างเอกสารโฮสต์ เอกสารเกสต์ และเกสต์ที่ฝังอยู่ในโฮสต์ แต่กรณีทั่วไปนั้นไม่ชัดเจน หากเป็นวิธีแบบแท็กง่าย ๆ เอกสารเกสต์ต้องถูกออกแบบให้ใช้ชีวิตอยู่ภายในสภาพแวดล้อม CSS ที่โฮสต์ใส่ไว้ อีกคำตอบแบบง่ายคือ Shadow DOM ซึ่งโดยทั่วไปทำให้เกสต์ใช้สไตล์ของตัวเองได้โดยไม่กระทบเอกสารส่วนที่เหลือ ผมคิดว่าในกรณีนี้โฮสต์ก็น่าจะยังใส่สไตล์บางส่วนเพื่อปรับแต่งเกสต์ได้

  • คิดว่านี่อาจเป็นสิ่งที่ frameset แบบจริงจังเมื่อสมัยก่อนพยายามทำอยู่ ไม่ใช่ iframe แต่เป็น frameset ยุค HTML 4
    อย่างน้อยการขยายขนาดอัตโนมัติก็ทำได้ดี และผู้ใช้ยังปรับเป็นขนาดที่ต้องการได้ด้วย มีคำวิจารณ์ต่อเฟรมมากมาย [1] แต่ก็ถูกใช้ได้สำเร็จในที่ที่มีประโยชน์ เช่น เอกสาร Java API [2] สุดท้ายที่มันหายไป ผมคิดว่าเพราะมันยืดหยุ่นไม่พอสำหรับดีไซเนอร์ สำหรับหน้าข้อมูลนั้นเพียงพอแล้ว แต่สกรอลล์บาร์ที่เทอะทะและการแบ่งหน้าจอที่จำกัดไม่ตอบโจทย์ความต้องการของดีไซเนอร์ ตอนนี้ frameset แบบเดิมคงทำงานบนมือถือได้ไม่ดี จึงสายเกินไปที่จะรื้อฟื้นมันกลับมา
    [1] <https://www.nngroup.com/articles/why-frames-suck-most-of-the...> - น่าสนใจที่เนื้อหาหลายส่วนในนี้ใช้ไม่ได้แล้วในตอนนี้ และปัญหาทุกอย่างที่เคยชี้ว่าเกิดกับเฟรมนั้นมีอยู่บนเว็บปัจจุบันในรูปแบบที่ยุ่งเหยิงกว่าเดิม
    [2] <https://www.eeng.dcu.ie/~ee553/ee402notes/html/figures/JavaD...>

    • ปัญหาของ frameset นั้นพื้นฐานยิ่งกว่านั้นมาก
      เพราะ ทำ deep link ไม่ได้ คนที่เข้ามาผ่านบุ๊กมาร์ก Google หรือเสิร์ชเอนจินก่อนหน้านั้น จะไปตกอยู่ที่หน้าที่ไม่มีระบบนำทาง และแม้จะพยายามเลี่ยงด้วย JavaScript ก็ไม่สามารถสร้างประสบการณ์ที่ดีได้

  • ฟีเจอร์ “include” ถูกมองว่าเป็นสิ่งที่ประมวลผลฝั่งเซิร์ฟเวอร์ หรือก็คือนอกเว็บเบราว์เซอร์
    HTML อยู่ฝั่งไคลเอนต์ และโดยแท้จริงแล้วไม่ใช่ภาษาโปรแกรม แต่เป็นไวยากรณ์มาร์กอัป อย่างที่บทความบอก ปัญหานี้เป็นปัญหาที่แก้ไปแล้ว สิ่งแรก ๆ ที่นักศึกษาเว็บดีไซน์ได้เจอเมื่อเรียน PHP ก็คือ include และใน CMS ส่วนใหญ่ include จะกลายเป็น template partial ที่อธิบายไว้ตั้งแต่ช่วงต้นของเอกสาร ไม่ได้มีความจำเป็นเป็นพิเศษที่จะต้องทำให้ include ใช้ได้ด้วย HTML เพียงอย่างเดียว HTML เป็นรูปแบบการนำเสนอ และถ้าไม่มี CSS กับ JS ก็ไม่ได้ทำอะไรที่น่าสนใจ

    • การบอกว่า “include เป็นฟีเจอร์ฝั่งเซิร์ฟเวอร์” ไม่ใช่เหตุผลว่าไม่ควรมี include ฝั่งไคลเอนต์
      ที่จริง HTML มีเวอร์ชันที่แย่กว่านั้นอยู่แล้วคือ frames และ iframes สิ่งที่เทียบเคียงกับ server-side include ในฝั่งไคลเอนต์นั้นเข้ากับสิ่งที่ผู้คนทำด้วย HTML ได้อย่างเป็นธรรมชาติ
    • เหตุผลที่รู้สึกแปลกคือไฟล์ HTML สามารถรวมสคริปต์ ฟอนต์ รูปภาพ วิดีโอ สไตล์ ฯลฯ ได้ แต่ รวม HTML ไม่ได้
      อาจจะเขียนด้วย custom elements ได้ และถ้าไม่มี repository คล้าย ๆ กันใน GitHub เลยก็คงน่าแปลกใจมากกว่า
    • ที่บอกว่านักศึกษาหลายคนเริ่มรู้จัก PHP ด้วยเหตุนี้ก็ถูก แต่ก็ยังสงสัยอยู่ดีว่าทำไมถึงทำเป็นแท็กแบบง่าย ๆ ไม่ได้
      มีคอนเทนต์บางอย่างที่โหลดแบบอะซิงโครนัสอยู่แล้ว เช่น รูปภาพหรือคอนเทนต์ด้านล่างของหน้าจอ การบอกว่า “HTML ไม่ใช่ภาษาโปรแกรม แต่เป็นไวยากรณ์มาร์กอัป” ค่อนข้างเป็น flamebait และมันเป็น ภาษาเชิงประกาศ ที่ถูกตีความโดยเอนจินเบราว์เซอร์แต่ละตัว
    • เห็นด้วยกับสิ่งที่พูดมา แต่ HTML ไม่ใช่รูปแบบการนำเสนอ หากเป็น ภาษาบรรยายเอกสาร
      ถ้าหมายถึงเรื่องการจัดรูปแบบ การนำเสนอนั้นเป็นหน้าที่ของ CSS
    • คำว่า “ฟีเจอร์ include เป็นของฝั่งเซิร์ฟเวอร์” นั้นถูกต้อง server-side include เป็นเรื่องเป็นธรรมชาติมาก แต่ client-side include หมายความว่าไคลเอนต์ต้องสามารถแก้ไข DOM เดิม ณ เวลาที่ไคลเอนต์ไม่อาจรู้ล่วงหน้าได้
      มีสองทางเลือก ทางแรกคือประมวลผลตอน parsing HTML หรือก็คือก่อนสร้าง DOM แต่วิธีนี้ต้องมีคำขอแบบ synchronous ไปยังเซิร์ฟเวอร์เพื่อ include จึงไม่พึงประสงค์ ทางที่สองคือหลังสร้าง DOM แล้วให้ element บางตัวปรากฏใน DOM โหลดชิ้นส่วนแบบ asynchronous จากนั้นแทนที่ DOM element นั้นด้วยชิ้นส่วนภายนอก แต่วิธีนี้ทำให้กลไกตรวจสอบโครงสร้าง DOM เดิมหมดความหมาย อย่างไรก็ตาม ในเอนจิน Sciter มีการ implement ด้วยกลยุทธ์แรก HTML ของ Sciter มักมาจาก resource ของแอปภายในเครื่องหรือจากระบบไฟล์ ดังนั้นต้นทุนของคำขอชิ้นส่วนเพิ่มเติมจึงถือว่าเล็กน้อยจนมองข้ามได้
      https://docs.sciter.com/docs/HTML/html-include

  • HTML include มีปัญหาหลายอย่างตามที่คนอื่นพูดไว้
    ถ้า main.html include child/include1.html และใน child/include1.html มีลิงก์ src="include2.html" เมื่อผู้ใช้คลิกแล้วควรไปที่ไหน? ถ้าไปที่ include2.html ตามชื่อแล้วก็น่าจะเป็นหน้าสำหรับ include ทำให้ส่วนที่เหลือหายไป แต่ถ้าไปที่ main.html แล้วคราวนี้จะระบุอย่างไรว่าให้ใช้ include2.html ไม่ใช่ include1.html? กลับกัน อาจให้ article1.html, article2.html, article3.html แต่ละไฟล์ include header.html, footer.html, navi.html ได้ แต่ถ้าเป็นอย่างนั้น หากต้องการเปลี่ยนโครงสร้างบทความทั้งหมดแบบ global ก็ต้องแก้ทุกบทความ ถ้าต้องการเพิ่ม comments.html ในบทความทั้งหมด สุดท้ายก็จะอยากกลับไปสร้างหน้าด้วย template อยู่ดี และ ณ จุดนั้นก็ไม่จำเป็นต้องมี include ในเบราว์เซอร์แล้ว ยังมีปัญหาว่า header ต้องรู้ชื่อเรื่อง หรือ footer ต้องรู้ลิงก์ก่อนหน้า/ถัดไป และต้องมีวิธีส่งข้อมูลระหว่าง include สุดท้ายก็ย้อนกลับไปสู่การสร้างหน้า เมื่อลองพิจารณาแล้ว HTML include อาจแทบไม่มีประโยชน์ในทางปฏิบัติสำหรับการใช้งานส่วนใหญ่

    • ปัญหาเหล่านี้ล้วนแก้ได้ และมีแนวทางแก้ที่ค่อนข้างชัดเจน
      ตรงนี้มี use case สองแบบที่ปะปนกันอยู่ แบบหนึ่งคือ การใช้ชิ้นส่วนซ้ำ และอีกแบบคือเกาะอิสระที่ฝังได้ แบบหลัง iframe จัดการอยู่แล้ว ดังนั้นต้องแก้เฉพาะแบบแรก
    • ตรรกะเรื่อง include2.html สูญเสียส่วนที่เหลือนั้นใช้กับ include อื่น ๆ ได้เหมือนกัน
      ถ้าผู้ใช้คลิกลิงก์ src="include.css" ก็คงเละเทะได้เหมือนกัน แต่สำหรับข้อมูลแบบ static, รูปภาพ, CSS และคอนเทนต์ HTML แบบ static อาจใช้ได้

  • มี issue ที่ยังเปิดอยู่ใน WHATWG เกี่ยวกับเรื่องนี้ และถูกกล่าวถึงในส่วนความคิดเห็นของบล็อกด้วย
    Client side include feature for HTML
    https://github.com/whatwg/html/issues/2791

  • HTML เคยมี include และมันก็เสื่อมความนิยมไป
    คำว่า “include” จริง ๆ เป็นฟีเจอร์ของ XML และสิ่งที่บทความต้องการก็คือฟีเจอร์นั้น ใน HTML มีแนวทางอีกแบบที่เกิดขึ้นก่อน XML นั่นคือ frames เนื่องจาก frames ทำอะไรได้มากกว่า XML include มาก HTML จึงไม่ได้รับฟีเจอร์นั้นแยกต่างหาก frames เสื่อมความนิยมลงเพราะปัญหาหลายอย่าง เช่น การใช้งานผิดวัตถุประสงค์ ความปลอดภัย และการเข้าถึง

    • ต่างจาก Frameset ดูเหมือนว่า XML include จะไม่เคยได้รับการรองรับอย่างเหมาะสมในเบราว์เซอร์จำนวนมาก หรืออาจจะไม่มีในเบราว์เซอร์หลักใดเลย
      ยังชอบใช้เป็นครั้งคราวอยู่ แต่ต้องมี ขั้นตอน compile เพื่อประเมินมันก่อนส่งต่อให้ผู้ใช้หรือเบราว์เซอร์