ข้อเสนอให้ลบการกล่าวถึง XSLT ออกจากสเปก HTML

 (github.com/whatwg)
2 คะแนน โดย GN⁺ 2025-08-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการเสนอ Pull Request เพื่อลบการกล่าวถึง XSLTออกจากเอกสารมาตรฐาน HTML
  • ผู้เสนออธิบายว่ามีการรายงานบั๊กของการใช้งานจริงที่เกี่ยวข้องในเบราว์เซอร์หลักอย่าง Chrome, Firefox และ Safari รวมถึงมีประเด็นด้านการทดสอบและการจัดทำเอกสารที่กำลังดำเนินการอยู่
  • ความเห็นคัดค้านชี้ถึงปัญหาความเข้ากันได้กับเว็บไซต์เดิม และปัญหาเรื่องการอ่านเอกสารที่อาจเสียหายเมื่อถอด <?xml-stylesheet?> ออก ทำให้เอกสาร XML พัง
  • นักพัฒนาบางส่วนย้ำว่า XSLT ยังถูกใช้งานในเอกสารภาครัฐ, RSS และสภาพแวดล้อมแบบฝังตัว
  • มีการแสดงความกังวลว่าการตัดสินใจที่ขับเคลื่อนโดยผู้ผลิตเบราว์เซอร์รายใหญ่อาจนำไปสู่การลดทอนความเปิดกว้างและความหลากหลายทางประวัติศาสตร์ของเว็บ

ภาพรวม Pull Request

  • ชื่อ PR: Remove mentions of XSLT from the html spec
  • ผู้เสนอ: mfreed7
  • เป้าหมาย: whatwg/html:main
  • อีเวนต์ที่เกี่ยวข้อง: #11523
  • มีรายงานบั๊กการใช้งานจริงที่เกี่ยวข้องใน Chromium, Gecko และ WebKit ทั้งหมด
  • มีแผนจะอัปเดตเอกสารที่เกี่ยวข้อง เช่น เอกสาร MDN และ HTML AAM

ความเห็นคัดค้านหลัก

gucci-on-fleek (2025-08-15)

  • เสนอว่าควรคำนึงถึงสถิติการใช้งานและขนาดของเว็บไซต์
    • เว็บไซต์ขนาดใหญ่อาจอัปเดตได้ แต่เว็บไซต์ขนาดเล็ก/เว็บไซต์ส่วนบุคคลจำนวนมากไม่ได้รับการดูแลมานานหลายสิบปี จึงเสี่ยงต่อความเข้ากันได้ที่พังถาวร
  • การถอด XSLTProcessor() จะจำกัดแค่ความสามารถฝั่ง JS แต่ถ้าถอด <?xml-stylesheet?> ออก จะเกิดปัญหาที่เอกสาร XML ไม่แสดงผลเลย
  • ฟีเจอร์ HTML แบบเก่าก่อนหน้านี้ (<font>, <align>, <xmp>) ยังทำงานได้อยู่ แต่ครั้งนี้ถูกชี้ว่าเป็นการเปลี่ยนแปลงที่ไม่เคยมีมาก่อนเพราะทำให้ตัวเอกสารพังโดยตรง
  • เน้นย้ำความเสี่ยงที่การเข้าถึงข้อมูลสำคัญ เช่น คลังเอกสารเก่า เว็บไซต์มหาวิทยาลัย อาจถูกตัดขาด

nomis (2025-08-18)

  • ยกตัวอย่างการใช้งาน XSLT ที่เป็นรูปธรรม
  • กรณีใช้งานส่วนตัว
    • แปลงข้อมูล XML ที่ซับซ้อนเป็นตาราง HTML
    • แปลง XML แบบไดนามิกเป็น XSLT แบบสแตติกบนไมโครคอนโทรลเลอร์ที่มีข้อจำกัดด้านหน่วยความจำ
  • วิจารณ์ว่าการทำ JS polyfill ที่รวม libxml2 ทั้งชุดนั้นไม่สมเหตุสมผล และการเลิกซัพพอร์ตในเบราว์เซอร์ก็แทบจะเป็นการบังคับให้ต้องเขียนใหม่เอง

jonsterling (2025-08-18)

  • วิจารณ์ความเป็นจริงที่ผู้ผลิตเบราว์เซอร์เป็นผู้กำหนดเว็บแพลตฟอร์มแบบผูกขาด
  • มองว่า XSLT ยังมีส่วนช่วยให้เกิดการใช้งานเว็บที่หลากหลายและสร้างสรรค์ และการถอดออกจะทำให้Open Web อ่อนแอลง
  • ย้ำหลักการว่า “เว็บเป็นของพวกเราทุกคน” และเสนอว่าควรเคารพประวัติศาสตร์และความหลากหลาย

ความเห็นสนับสนุนและการดำเนินการต่อ

  • domenic (2025-08-19): ตอบรับในเชิงบวก พร้อมชี้ว่าจำเป็นต้องอัปเดตการกล่าวถึง XSLT ในสเปก DOM ด้วย
  • mfreed7 (2025-08-19): ตอบว่าจะส่ง PR แยกสำหรับสเปก DOM เช่นกัน

สรุป

  • การถอด XSLT ถูกเสนอในฐานะส่วนหนึ่งของความพยายามทำให้เบราว์เซอร์เรียบง่ายขึ้นและทันสมัยขึ้น
  • อย่างไรก็ตาม ฝ่ายคัดค้านกังวลต่อความเข้ากันได้ของเอกสารเดิม การเข้าถึงข้อมูลภาครัฐ/วิชาการ และความหลากหลายของ Open Web
  • การถกเถียงครั้งนี้จึงลุกลามไปไกลกว่าทางเลือกเชิงเทคนิคธรรมดา สู่ข้อถกเถียงเชิงปรัชญาว่าใครควรเป็นผู้มีอำนาจตัดสินใจในมาตรฐานเว็บ

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

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

 
GN⁺ 2025-08-20
ความเห็นจาก Hacker News

  • มีหลายจุดที่น่าสนใจ

    • การตัดสินใจครั้งนี้ไม่ใช่การกระทำฝ่ายเดียวของ Chrome และสามารถยืนยันได้จาก การติดตาม issue และบันทึกการประชุมมาตรฐานที่เกี่ยวข้อง ว่าตัวแทนจากเบราว์เซอร์หลักทั้งหมดแสดงการสนับสนุน

    • วาระล่าสุดก็ถูกเสนอโดยวิศวกรของ Mozilla

    • การยื่น PR ไม่ได้แปลว่าจะถูก merge ทันที และยังมีงานที่ยังไม่ได้ตรวจสอบเหลืออยู่อีกมาก

    • แต่ในสถานการณ์ที่ผู้ผลิตเบราว์เซอร์หลายเจ้าตกลงกันแล้ว ก็มีโอกาสสูงที่จะถูก merge

    • issue ที่กำลังพิจารณาว่าจะถอด XSLT ออกจากเว็บแพลตฟอร์มหรือไม่ ไม่ได้มีไว้เพื่อรับฟังความเห็นจากชุมชน แต่เป็น issue สำหรับผู้ดูแลสเปก HTML ใช้หารือกัน

    • issue นี้ถูกเปิดโดยวิศวกร Chrome แต่ที่สำคัญคือวิศวกร Mozilla ยกประเด็นนี้ขึ้นมาหลายครั้งในการประชุม และมีฉันทามติจาก vendor อยู่ก่อนแล้ว

    • เคยมี การค้นพบ ช่องโหว่ความปลอดภัยร้ายแรง

    • แม้แต่ maintainer หลักของ libxslt ก็ ลาออกด้วยตนเอง แล้ว

    • มีการเอาคำว่า Chrome ออกจากชื่อเรื่องแล้ว

    • ชื่อเรื่องเดิมที่ส่งมาคือ "Chrome intends to remove XSLT from the HTML spec"

    • ตามข้อมูล telemetry ของ Chrome เว็บไซต์ที่ใช้ XSLT จริง ๆ แทบไม่มีเลย

    • อย่างน้อยก็ยืนยันจากข้อมูลได้ว่าข้อเสนอนี้ไม่น่าจะมีผลกระทบใหญ่ต่อเว็บโดยรวม

    • ฉันเป็นนักพัฒนาที่เคยทำงานทั้งที่ Mozilla และ Google (ทีม Chrome)

    • เข้าใจว่า Chrome/Blink, Safari/Webkit, Firefox/Gecko ต่างก็สนับสนุนการถอด XSLT ออก แต่สองโปรเจ็กต์มีทรัพยากรจำกัด และอีกแห่งมีแนวโน้มจะยัดฟีเจอร์ใหม่เข้าไปอย่างหักโหม

    • นักพัฒนา Safari และ Firefox ก็มีเหตุผลที่จะต้อนรับการเปลี่ยนแปลงแบบนี้

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

    • ต่อให้มีเพียง 0.1% ของผู้ใช้หลายพันล้านคนที่พึ่งพามัน ก็ยังถือว่าเยอะมาก

    • ถ้าไม่มีใครใช้จริง ก็ไม่มีเหตุผลที่ polyfill จะมีอยู่

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

    • Google เลือกเองที่จะไม่รองรับ XSLT อย่างเต็มที่ ทั้งที่มีทั้งทุนและกำลังคนมากพอ

    • มีหลายกรณีที่เมื่อหลาย vendor เห็นตรงกัน ก็ถูกผลักดันทันที

    • การถอด confirm/prompt ก็เป็นแบบนั้น แต่สุดท้ายก็ถูกเลื่อนออกไปอย่างไม่มีกำหนด

    • Google มีเอกสารกระบวนการถอดฟีเจอร์ที่เป็นทางการอยู่
      Google feature removal doc

    • การสนับสนุนแบบ "มีแต่ vendor เห็นด้วย" ไม่ได้ตรวจสอบการใช้งานจริงอย่างรอบด้าน

  • จากสองเธรดที่ฉันอ่าน Google ขอ feedback แต่ feedback เกือบทั้งหมดคือ "อย่าทำ"

    • แต่ Google มีท่าทีประมาณว่า "ขอบคุณสำหรับความเห็น แต่เราจะทำอยู่ดี!"

    • ถ้าประเด็นคือเรื่องความปลอดภัย ก็ยังมีทางเลือกอื่นอีกมาก เช่น สนับสนุนโอเพนซอร์ส, เปลี่ยนไปใช้ไลบรารีที่ปลอดภัยกว่า, หรือคงไว้ใน JS sandbox แต่ส่วนใหญ่ถูกมองข้าม

    • มีการขอให้รองรับเวอร์ชันใหม่อย่าง XSLT 3.0 อย่างต่อเนื่อง แต่ก็ไม่ถูกนำไปทำ

    • แม้ XSLT จะเป็นเทคโนโลยีที่สนับสนุนเว็บแบบเปิด แต่ Google กลับลดการสนับสนุนและปล่อยทิ้งมาตั้งแต่ 10 ปีก่อน พร้อมใช้ส่วนแบ่งการใช้งานที่ลดลงเป็นเหตุผลในการพยายามถอดออกมาโดยตลอด

    • ในช่วงที่ XSLT เริ่มกลับมาได้รับความนิยมอีกครั้ง กลับรู้สึกเหมือนพยายามฆ่ามันทิ้งก่อนที่คู่แข่งแบบเปิดจะเกิดขึ้น

    • issue ที่เกี่ยวข้อง

    • สำหรับคำกล่าวอ้างที่ว่า feedback จำนวนมากเป็น "อย่าทำ" นั้น เธรดดังกล่าวถูกล็อกตั้งแต่ต้นเพราะมีคอมเมนต์ไม่หวังดี การใส่ร้าย และอื่น ๆ

    • ความเห็นประเภท "นี่เป็นไอเดียที่ดี" ปกติมักไม่ค่อยมีคนเข้ามาเขียน จึงอาจทำให้ดูเหมือนมีแต่คนคัดค้าน

    • ทุกคนใช้ถ้อยคำรุนแรงกันจนการสนทนาต้องถูกปิด ซึ่งก็เป็นผลที่พวกเขาก่อขึ้นเอง

    • ถ้าความเห็นแนว "อย่าทำ" ไม่ได้มาจากผู้ใช้จริง หรืออธิบายไม่ได้ว่าทำไมมันจำเป็นจริง ๆ การที่ทีมพัฒนาเพิกเฉยก็ถือว่าสมเหตุสมผล

    • การขอ feedback ไม่ใช่แค่การโหวตเห็นด้วยหรือไม่เห็นด้วย

    • ถ้าสามารถย้าย XSLT 3.0 ไปไว้ใน JS/wasm sandbox แล้วรองรับได้ก็น่าจะดี

    • อาจมี performance ลดลงเล็กน้อย แต่จะได้ข้อดีของทั้งสองฝั่ง

    • XML มีคุณสมบัติอย่าง schema สำหรับจัดการเวอร์ชัน, namespace ฯลฯ จึงทำให้การบูรณาการทำได้ค่อนข้างง่าย

    • ต่างจาก js framework อย่าง Angular ตรงที่สามารถมี data contract ที่เชื่อถือได้สูง

    • ด้วยความสุกงอมของตระกูล XML จึงมีเครื่องมือเฉพาะทางมากมาย และในทางปฏิบัติก็ไม่จำเป็นต้องจัดการ XML/XSD ด้วยข้อความล้วนโดยตรงเสมอไป

    • Google ใช้วิธีตั้งคำถามล่วงหน้าเพื่อบอกให้รู้ว่าอะไรจะเกิดขึ้นกับเว็บ

  • แนะนำเธรดก่อนหน้าที่เกี่ยวข้อง

  • สงสัยว่าเบราว์เซอร์จำเป็นต้องมีการรองรับในตัวสำหรับ template engine บางตัวอย่าง XSLT หรือไม่

    • มันไม่ใช่ text engine แบบ Jinja และก็สามารถนำไปทำใหม่ใน JS/wasm ได้

    • ตอนนี้เบราว์เซอร์หนักเกินไป และการพัฒนาเอนจินใหม่ก็ยาก

    • อยากให้มีมาตรฐานที่เรียบง่ายกว่านี้สำหรับ "มินิมอลเบราว์เซอร์" เช่นมีแค่ tag พื้นฐาน, layout ฯลฯ

    • WebAudio, Canvas และอย่างอื่นก็ทำเป็นโมดูล wasm ได้เช่นกัน (และถ้าทำแบบนี้ก็ช่วยป้องกัน fingerprinting ได้ด้วย)

    • XSLT เป็น "สเปก" ของ template engine ไม่ใช่เอนจินตัวใดตัวหนึ่ง และมี implementation หลายแบบ

    • Mozilla ใช้ transformiix แทน libxslt

    • Jinja เป็นแค่งานข้อความธรรมดา แต่ XSLT ทำงานในระดับ node จึงเหนือกว่ามาก

    • การแปลงด้วย JS ช้ากว่าการแปลงแบบ native ของ XSLT มาก และยัง cache ผลลัพธ์ได้ยาก

    • ฉันก็เข้าใจมุมมองที่เห็นว่า XSLT ล้าสมัย แต่ในช่วง 20 ปีที่ผ่านมา มันเป็นอาวุธลับด้าน performance ที่ใช้งานได้ดีมาก

    • ท้ายที่สุด Google น่าจะพยายามใช้ทางเลือกอย่าง AMP มาปกปิดปัญหา

    • ที่เบราว์เซอร์หนักก็เพราะ Google

    • XSLT เป็นภาษา (spec) ไม่ใช่เอนจิน

    • การเปลี่ยน implementation ไปเป็น JS/wasm เป็นเรื่องภายใน implementation ไม่ใช่สิ่งที่จะเกิดขึ้นเมื่อภาษาเองถูกถอดออกจากเว็บแพลตฟอร์ม

    • audio หรือ canvas เป็นความสามารถ I/O พื้นฐานของเบราว์เซอร์ ถ้าย้ายไป wasm จะมีปัญหารุนแรงทั้งด้าน performance และความเข้ากันได้

    • องค์ประกอบบางส่วนของ audio อาจย้ายไปเป็น wasm blob ได้ แต่จะย้ายทั้งหมดนั้นยาก

    • canvas context หรือ WebGL มีหัวใจสำคัญอยู่ที่การเชื่อมกับ GPU โดยตรง จึงทำใน wasm ไม่ได้

    • ท้ายที่สุดฟีเจอร์เหล่านี้ก็เป็น primitive API พื้นฐานอยู่แล้ว จึงเป็นส่วนที่ยอมถอยไม่ได้

    • มีการพูดคุยถึงแนวคิดเอาโค้ด XSLT เก่าไปแพ็กเป็น wasm เพื่อให้เว็บเก่าไม่พังและยังเข้ากันได้

    • มีการพิจารณาภายในจริง แต่สุดท้ายตัดสินใจว่าไม่ทำ

    • ฉันคิดว่าฟังก์ชันที่มีคนน้อยมากใช้และห่างไกลจากเว็บสมัยใหม่อาจเป็นเป้าหมายในการถอดออกได้

    • แต่ไม่เห็นด้วยกับการใช้ช่องโหว่ความปลอดภัยมาเป็นเหตุผลหลัก

    • ถ้ายังไม่ได้ตรวจสอบเลยว่ามีแพ็กเกจแบบ memory-safe หรือไม่ ก็ยังฟังไม่ค่อยน่าเชื่อ

    • มีการอ้างว่าอัตราการใช้งานจริงอยู่ราว 0.001%

  • การทำลายคำมั่นพื้นฐานของ HTML เป็นเรื่องใหญ่มาก

    • กลับน่าแปลกที่การถกเถียงไม่ได้ลงลึกในประเด็นนี้

    • HTML เคยเป็นคำมั่นว่า "นี่คือ HTML เชื่อถือได้" แต่ตอนนี้กลายเป็น "ตอนนี้มันยังเป็น HTML อยู่ แต่ไม่มีอะไรรับประกันว่าอนาคตก็จะยังเป็น"

    • ถ้าใช้ตรรกะเดียวกับการถอด XSLT ก็อาจมีเทคโนโลยีเก่าอื่น ๆ ถูกตัดออกต่อไปเรื่อย ๆ

    • สุดท้ายแล้วมันคือข้อเสนอให้ตัดส่วน 'long tail' ของเว็บทิ้ง

    • และยังควรคิดต่อด้วยว่าเทคโนโลยีเว็บอีกมากมายที่ถูกเพิ่มในภายหลังจะกลายเป็น long tail และถูกเล็งถอดออกเพิ่มอีกหรือไม่

    • สำหรับการรองรับสื่อและซอฟต์แวร์เก่า ในที่สุดก็คงต้องมีช่วงเวลาที่แก้ผ่านการพอร์ต, อีมูเลชัน, การเก็บถาวร ฯลฯ

    • จำเป็นต้องมีสมดุลระหว่างการให้เวลาและเครื่องมือเพียงพอสำหรับการปรับตัว กับการหลีกเลี่ยงความซับซ้อนสะสมแบบค่อยเป็นค่อยไป

    • ถ้าดูส่วนที่ถูกลบใน PR จริง ดูเหมือนจะไม่มีข้อกำหนดชัดเจนใน HTML ที่บังคับให้ต้องรองรับ XSLT

    • สิ่งที่เห็นมีเพียงว่าผู้คนตอบสนองแรงกับประเด็นการรองรับของเบราว์เซอร์

    • ตัว PR เองสั้นอย่างน่าประหลาด

    • WHATWG นิยาม HTML เป็น "Living Standard" ทำให้ในทางปฏิบัติมันไม่ใช่มาตรฐานการ implement อีกต่อไป แต่เป็นการแชร์สถานะของสิ่งที่ vendor เบราว์เซอร์กำลังทำอยู่ในตอนนี้

    • เพราะแบบนั้นจึงเลิกใช้ชื่อเวอร์ชันอย่าง HTML5 และใช้เพียง "HTML" เท่านั้น

    • Living Standard FAQ

    • HTML standard FAQ

    • ที่น่าขันคือหนึ่งในผู้ที่ผลักฟีเจอร์จำนวนมหาศาลเข้าไปในสเปก HTML/CSS/เบราว์เซอร์มากที่สุดก็คือ Google เอง

    • ถ้า Google ยืนหยัดอย่างสม่ำเสมอว่า "เบราว์เซอร์ควรเบา และของแปลก ๆ ควรปล่อยให้เป็นหน้าที่ของ JS library" มาตลอด มาตรการนี้ก็คงพอเข้าใจได้ แต่ความจริงไม่ใช่แบบนั้นเลย

  • หลังจากถอดการรองรับ FTP ชะตาของ XSL ก็ดูเหมือนจะถูกคาดไว้แล้ว

    • เบราว์เซอร์มักให้ความสำคัญสูงสุดกับการลด attack surface

    • คิดว่าผู้ถูกเล็งรายต่อไปอาจเป็นคุณสมบัติ XML อย่างแอตทริบิวต์แอนิเมชัน SVG SMIL, MathML เป็นต้น

    • เธรดที่เกี่ยวข้อง

    • SMIL สามารถควบคุมแอนิเมชันแบบเรียงลำดับตามจุดเริ่มและจุดจบของแอนิเมชันเฉพาะได้ ซึ่ง CSS animation ยังขาดตรงนี้

    • CSS ยังไม่มีทางอื่นนอกจากใช้การคำนวณเวลา

    • Chromium เคยแสดงเจตนาจะถอด SMIL เหมือนกัน แต่ตอนนั้น CSS ยังไม่พร้อม จึงถือว่าเร็วเกินไปมาก

    • ผลจากเรื่องนั้นทำให้เอกสารและคำแนะนำเกี่ยวกับ SMIL หลายอย่างถูกปล่อยทิ้งโดยไม่อัปเดต

    • อยากตั้งคำถามว่าการลด attack surface เป็นเรื่องดีหรือไม่ดีแน่

    • ลำดับความสำคัญของคนทำเทคโนโลยีกับผู้ใช้ทั่วไปนั้นต่างกันอยู่แล้ว

    • สงสัยว่าการถอดฟังก์ชัน FTP เกิดขึ้นเมื่อไร

    • เท่าที่รู้ยังพิมพ์ ftp:// ในแถบที่อยู่เพื่อเข้าได้อยู่

  • implementation ของ XSLT ใน Blink และ WebKit ไม่มีประสิทธิภาพมาก

  • แม้จะเสียดายการตัดสินใจครั้งนี้ แต่ที่น่าเสียดายยิ่งกว่าคือไม่มีใครทุ่มเทกับการผสาน XSLT ให้ทันสมัยกว่าเดิม

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

    • XML หากตัดความซับซ้อนแบบองค์กรใหญ่ทิ้งไปได้ มาตรฐานนี้เองก็ทรงพลังมากและเป็นเทคโนโลยีที่ยอดเยี่ยม

    • ฉันชอบมากที่ใช้ XSLT แปลง xml/ข้อมูลขนาดเล็กและเรียบง่ายเป็น html ได้ตรง ๆ

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

  • มีคนบอกว่า @whatwg ล็อก issue นี้ให้เฉพาะผู้ร่วมงาน หลังบอกว่าการถกเถียง "ร้อนแรงเกินไป"

    • เท่าที่ดูมันค่อนข้างมีเหตุผลและสงบดี เลยอดสงสัยไม่ได้ว่ามาตรฐานของคำว่า 'ร้อนแรง' เปลี่ยนไปตามว่าคุณเข้าข้าง vendor บางเจ้าหรือไม่หรือเปล่า

    • คำว่า "ร้อนแรงเกินไป" มักถูกตีความว่าเป็นการไม่อยากรับมือกับความเห็นคัดค้าน

    • ชุมชนอื่นอย่าง Reddit ก็เหมือนกัน

    • จริง ๆ แล้วคอมเมนต์เดียวที่ยังเหลืออยู่ข้างล่างคือของนักพัฒนาจาก Google Chrome ที่บอกว่า "ทำได้ดีมาก"

    • ดูแล้วค่อนข้างชวนอึดอัดนิดหน่อย

    • มีการพูดถึงกรณีที่ issue tracker ถูกถล่มด้วยคำด่าหยาบคาย แนวคิดสมคบคิด ข้อความการเมือง ฯลฯ

    • ถ้าเป็นแบบนี้ก็แทบเป็นไปไม่ได้ที่จะมีการพูดคุยอย่างสร้างสรรค์ และผู้ดูแล repository ก็คงต้องรีบปิดการสนทนา

    • ได้ยินว่าการล็อกการสนทนาใน repository นี้จริง ๆ แล้วเป็นการตัดสินใจของพนักงาน Apple

    • แต่ผู้คนกลับโยนความรับผิดชอบไปที่พนักงาน Google ที่เป็นคนเปิดประเด็นนี้

    • ช่วงหลัง Google ชูเรื่องการรับฟังความเห็นจากชุมชนและเปิดให้ถกเถียง แต่หลังจากนั้นกลับเพิกเฉยต่อทุกความเห็นและพยายามผลักให้ผ่านอยู่ดี

    • issue ที่เกี่ยวข้อง

  • ควรมีการทบทวนภาพรวมเกี่ยวกับองค์ประกอบเว็บแบบเก่า

    • สำหรับฉัน การที่หน้าเว็บเก่า ๆ ยังทำงานได้อย่างถูกต้องต่อไปมีคุณค่ามาก

    • เพราะ HTML/JS รักษาความเข้ากันได้มาโดยตลอด แม้แต่หน้าเว็บอายุหลายสิบปีก็ยังใช้งานได้ปกติหากแค่ติดตั้ง TLS certificate

    • แต่ก็เป็นไปไม่ได้ที่จะรองรับเทคโนโลยีมรดกทั้งหมดไปตลอดกาล

    • สุดท้าย Flash ก็เปลี่ยนผ่านไปเป็นประสบการณ์ผ่านอีมูเลเตอร์อย่าง Ruffle สำหรับเกมหรือเว็บไซต์แห่งความทรงจำ

    • ในระยะยาว การใช้เบราว์เซอร์เฉพาะทางหรืออีมูเลเตอร์ที่เน้นการเรนเดอร์แบบเก่าก็อาจเป็นทางเลือกได้

    • ตอนนี้มี ส่วนขยาย XSLT polyfill สำหรับเรื่องนี้แล้ว

    • Chrome ไม่ต้องการจัดส่งหรือดูแลมันอย่างเป็นทางการ

    • สถานการณ์คล้ายกับ Ruffle มาก