ว่าด้วยการฟอร์ก Web
(dillo-browser.org)- เป้าหมายของสเปกทางเลือกไม่ใช่ทั้ง Web แต่เริ่มจากสเปก HTML ซึ่งมีขนาดหลังแตกไฟล์ 18.3MiB ณ วันที่ 6 พฤษภาคม 2026 โดยมุ่งรักษาข้อดีของ Web และหลีกเลี่ยงข้อเสีย
- สเปกควรสั้นและเรียบง่าย และควรลดภาระในการพัฒนาให้เกิดเบราว์เซอร์และไคลเอนต์ที่หลากหลายได้ เช่น จำกัด
tar.gzที่บรรจุสเปกทั้งหมดไว้ที่ 1.44MiB - แทนที่จะเป็นเอกสารที่เปลี่ยนตลอดเวลาเหมือน Web specification ในปัจจุบัน ควรมี semantic version อย่าง
1.2.3และเวอร์ชันมาตรฐานที่เผยแพร่แล้วต้องไม่ถูกแก้ไขโดยเด็ดขาด - สเปกต้องมี ไวยากรณ์เชิงรูปแบบที่ไม่กำกวม ซึ่งพาร์สได้ง่าย และหน้าที่ไม่เป็นไปตามมาตรฐานต้องไม่ถูกเรนเดอร์ เพื่อลดต้นทุนในการสร้างพาร์สเซอร์และเครื่องมือจัดการคอนเทนต์
- สเปกทางเลือกไม่ได้มุ่งคัดลอก Web ตามฟีเจอร์ แต่เน้นการแลกเปลี่ยนข้อมูลที่มีศูนย์กลางอยู่ที่ ข้อความที่เขียนขึ้น และนิยมวิธีเปิดไฟล์หรือ URL ที่เป็นมาตรฐานในโปรแกรมเนทีฟ เช่น มาตรฐาน Geo link หรือ tiled web map แทนการใช้สคริปต์
เป้าหมายของสเปกทางเลือกสำหรับเว็บ
- สเปก HTML มีขนาดหลังแตกไฟล์ 18.3MiB ณ วันที่ 6 พฤษภาคม 2026 และขอบเขตที่พิจารณาเป็นอันดับแรกจำกัดอยู่ที่สเปก HTML ไม่ใช่ Web ทั้งหมด
- เป้าหมายคือการสร้าง สเปกทางเลือก ที่รักษาข้อดีของ Web ให้ได้มากที่สุดพร้อมหลีกเลี่ยงข้อเสีย
- ตอนนี้ยังไม่ใช่สเปกอย่างเป็นทางการ แต่ใกล้เคียงกับบันทึกไม่เป็นทางการที่อาจเปลี่ยนแปลงได้ตามเวลา
ความเรียบง่ายและความหลากหลายของการนำไปใช้
- สเปกทั้งหมดควรสั้นและเรียบง่าย และควรสามารถสร้างเบราว์เซอร์และไคลเอนต์ที่หลากหลายได้ด้วยความพยายามไม่มาก
- เนื่องจากการรักษาความเรียบง่ายไว้ตลอดหลายทศวรรษเป็นเรื่องยากมาก กฎที่จำกัดความยาวของสเปกในระดับไบต์อาจเป็นวิธีหนึ่ง
- Dillo ใช้วิธีเดียวกันนี้เพื่อให้รีลีสพอดีกับฟลอปปีดิสก์แผ่นเดียว และสเปกทางเลือกก็อาจกำหนดเพดาน 1.44MiB สำหรับ
tar.gzที่บรรจุสเปกทั้งหมด
การจัดการเวอร์ชันแบบ semantic
- Web specification ปัจจุบันเป็นหน้าที่เปลี่ยนแปลงแทบทุกสัปดาห์ ทำให้ไคลเอนต์ที่ต้องการทำตามสเปกจำเป็นต้องตามการเปลี่ยนแปลงอยู่ตลอด
- สเปกทางเลือกควรมี semantic version ที่ชัดเจน เช่น
1.2.3 - จำเป็นต้องมีเกณฑ์ความเข้ากันได้ในลักษณะว่า เอกสาร
1.2.3ควรถูกเรนเดอร์ได้อย่างถูกต้องในเบราว์เซอร์ที่รองรับ1.2.3,1.2.0,1.3.0แต่ไม่ใช่ในเบราว์เซอร์ที่รองรับเพียง1.1.0หรือ2.0.0 - เป้าหมายของการเขียนเอกสารควรเป็นเวอร์ชันของมาตรฐาน ไม่ใช่สถานะการรองรับแยกตามเบราว์เซอร์ เช่น หากสมมติว่า 90% ของเบราว์เซอร์รองรับมาตรฐาน
1.2.0ก็สามารถเขียนโดยเล็งเป้าไปที่เวอร์ชันนั้นได้ - เวอร์ชันมาตรฐานที่เผยแพร่แล้ว ต้องไม่ถูกแก้ไขโดยเด็ดขาด
- การแก้คำผิดให้จัดการด้วยการเพิ่ม patch version
- ฟีเจอร์ใหม่ที่ยังเข้ากันได้ย้อนหลังให้จัดการด้วยการเพิ่ม minor version
- การเปลี่ยนแปลงที่ทำลายความเข้ากันได้ต้องเพิ่ม major version
- ต่อให้มีเพียงฉบับพิมพ์ของมาตรฐาน
1.2.0ก็ยังควรสามารถสร้างเบราว์เซอร์ที่สอดคล้องอย่างสมบูรณ์ในสภาพแวดล้อมที่แยกขาดได้ และเบราว์เซอร์นั้นต้องสามารถพาร์สเอกสาร1.2.Xได้อย่างถูกต้องตลอดไป
ไวยากรณ์ที่เข้มงวด
- สเปกต้องมี ไวยากรณ์เชิงรูปแบบที่ไม่กำกวม ซึ่งพาร์สได้ง่าย
- หน้าเพจต้องถูกทดสอบกับมาตรฐานเพื่อวินิจฉัยว่าเป็นไปตามข้อกำหนดหรือไม่ และหน้าที่ไม่เป็นไปตามข้อกำหนดต้องไม่ถูกเรนเดอร์
- ห้ามอย่างชัดเจนไม่ให้ไคลเอนต์ยอมรับหน้าเพจที่ไม่เป็นไปตามสเปก
- วิธีนี้ทำให้ไม่จำเป็นต้องพัฒนากฎมาตรฐานที่ซับซ้อนเพื่อซ่อมหน้าเพจที่เสีย และยังบังคับให้ความผิดพลาดในสเปกถูกแก้ในเวอร์ชันถัดไป
- ไวยากรณ์ที่เข้มงวดอาจผลักให้ย้ายไปใช้ภาษาที่มนุษย์เขียนง่ายกว่าและยืดหยุ่นกว่า เช่น Markdown ซึ่งเป็นผลลัพธ์ที่ตั้งใจไว้
- เป้าหมายคือทำให้พาร์สเซอร์ง่ายขึ้นและลดต้นทุนในการสร้างเครื่องมือที่จัดการคอนเทนต์
- การเปลี่ยนแปลงระดับ patch version จะเปลี่ยนเฉพาะถ้อยคำ โดยตัวไวยากรณ์ยังคงเดิม
ความเป็นไปได้ในการนำ HTML มาใช้ซ้ำ
- หากสามารถสร้าง ส่วนย่อยของ HTML ที่ทำงานกับซอฟต์แวร์เดิมได้ด้วยความพยายามน้อยที่สุด ก็ถือเป็นเรื่องน่าพึงปรารถนา
- อย่างไรก็ตาม อาจทำไม่ได้เพราะความซับซ้อนของการพาร์ส HTML
- แม้แต่การสร้างไวยากรณ์เชิงรูปแบบสำหรับเอกสาร XML ก็ไม่ใช่เรื่องง่าย จึงต้องพิจารณาว่า HTML/XML เหมาะกับรูปแบบที่พาร์สอย่างง่ายหรือไม่
การต้านทานการยึดกุมมาตรฐาน
- ปัญหาอย่างหนึ่งของ Web คือเมื่อมีผู้เล่นที่มีอำนาจผูกขาดสามารถสร้างกลไกดูดผลประโยชน์ได้ ก็จะเกิดแรงจูงใจให้ยึดกุมมาตรฐานและปรับมันให้เข้าทางตนเอง
- มุมมองนี้เห็นว่า ใน Web ผลลัพธ์คือความซับซ้อนของมาตรฐานเพิ่มขึ้นจนควบคุมไม่ได้ อุปสรรคในการเข้าสู่ตลาดของเบราว์เซอร์ใหม่สูงขึ้น และการแข่งขันลดลง
- แม้จะมีแนวคิดเบื้องต้นบางอย่างเพื่อป้องกันสถานการณ์นี้ แต่ยังต้องพิจารณาอย่างรอบคอบกว่านี้ในมุมมองทฤษฎีเกม
หลักการให้ความสำคัญกับข้อความ
- จุดมุ่งหมายของสเปกคือครอบคลุมรายละเอียดที่เพียงพอสำหรับการสื่อสารข้อมูลระหว่างมนุษย์ เช่น หนังสือหรือข้อเขียนที่พิมพ์ออกมา
- ข้อความที่เขียนขึ้น ควรถูกให้ความสำคัญก่อนในฐานะสื่อที่อเนกประสงค์ที่สุดสำหรับการเข้ารหัสข้อมูล
- ข้อความสามารถแปลได้ ให้คอมพิวเตอร์อ่านออกเสียงได้ และเก็บได้ด้วยพื้นที่จัดเก็บน้อย
- เอกสารควรตัดบรรทัดตามขนาดหน้าจอ เพื่อให้อ่านเอกสารเดียวกันได้ทั้งบนหน้าจอเล็กและหน้าจอใหญ่
การตัดสคริปต์ออก
- การเพิ่มความสามารถด้านสคริปต์เป็นความผิดพลาด จึงสามารถหลีกเลี่ยงได้ในสเปกทางเลือก
- แต่นั่นไม่ได้หมายความว่าจะจำกัดการใช้โปรแกรมแบบโต้ตอบของผู้ใช้
- ตัวอย่างเช่น ปัจจุบันอาจโหลดแผนที่แบบโต้ตอบในเบราว์เซอร์ด้วย JavaScript เพื่อแสดงตำแหน่งจุดที่สนใจ แต่สามารถให้ Geo link แทน เพื่อเปิดตำแหน่งนั้นในไคลเอนต์ใดก็ได้ที่รองรับโปรโตคอลดังกล่าว
- ในทำนองเดียวกัน หากมีสเปกสาธารณะ ไคลเอนต์ใดก็สามารถใช้ map tile จากเซิร์ฟเวอร์ได้ โดยมี มาตรฐาน tiled web map เป็นตัวอย่างที่เกี่ยวข้อง
- วิธีเปิดไฟล์หรือ URL ที่เป็นมาตรฐานในโปรแกรมเนทีฟสามารถปรับให้เหมาะกับอุปกรณ์ที่ใช้งานอยู่ และหลีกเลี่ยง แนวทางแบบเดียวกันทั้งหมด ของหน้าเว็บโต้ตอบจำนวนมากได้
สิ่งที่ไม่ใช่เป้าหมาย
- เป้าหมายไม่ใช่การทำซ้ำ Web แบบไล่ตามฟีเจอร์
- เป้าหมายคือสร้างสเปกที่ทำให้มนุษย์สามารถแลกเปลี่ยนความรู้ บันทึกย่อ และข้อมูลอื่น ๆ ได้ โดยตัดความจำเป็นที่จะต้องรัน VM เต็มรูปแบบเพียงเพื่ออ่านมันออกไป
1 ความคิดเห็น
ความเห็นจาก Lobste.rs
งั้นก็แปลว่าต้องกลับไปมีแอปสำหรับทุกอย่างอีกแล้วเหรอ? ผมไม่เห็นด้วยว่าความสามารถด้านสคริปต์นั้นเป็นความผิดพลาดตั้งแต่แรก
ผมมองว่าจุดที่ดีคือ เว็บเป็นแพลตฟอร์มอเนกประสงค์ที่ข้ามขอบเขตของระบบปฏิบัติการได้
ยุคที่รองรับแค่ Windows และบางทีก็ค่อยเพิ่ม Mac ทีหลังนั่นแหละ
แล้วสถานะของการพัฒนาแอปเดสก์ท็อปแบบเนทีฟก็ไม่ได้ง่ายนัก เลยเข้าใจคนที่เลือกเว็บแอปหรือ Electron บนเดสก์ท็อปได้มาก
ปัญหาของเว็บยุคใหม่คือชอบประดิษฐ์แนวคิดเดิมซ้ำไปเรื่อย ๆ ทั้งที่หลายอย่างควรเป็นมาร์กอัปเชิงประกาศ เส้นทางการแสดงผลของเว็บไซต์ไม่ควรต้องมี JavaScript มาแทรกอยู่ สคริปต์ควรใช้กับงานฝั่งไคลเอนต์แบบเฉพาะเจาะจง เช่น เอาชุดข้อมูลที่เซิร์ฟเวอร์ส่งกลับมาประมวลผลต่อ แทนงานที่เดิมทำบนเซิร์ฟเวอร์
เหมือนวงการ IT ผลักเว็บเบราว์เซอร์ให้กลายเป็นเครื่องเสมือนโดยพฤตินัย หลังจากชัดเจนว่าทางเลือกแบบ sandbox อย่าง Java กับ Swing หรือ Flash ด้อยกว่าจนน่าปวดหัว ตอนนี้แอปเดียวอย่าง Google Chrome กลายเป็นเครื่องเสมือนสำหรับงานคอมพิวเตอร์ทั่วไปของผู้ใช้ส่วนใหญ่ไปแล้ว แถมยังเป็นของและพัฒนาโดยบริษัทผูกขาดสายทุนนิยมสอดส่องอีกต่างหาก ผมไม่แน่ใจว่านี่ปลอดภัยกว่าจริงไหม หรือแค่ zero-day ของจริงมันแพงเกินกว่าจะถูกเปิดเผย
ผมคิดว่าการเพิ่มสคริปต์เข้ามาเป็นความผิดพลาด อย่างน้อยมันก็เป็นฟีเจอร์ที่เติมทีหลัง และผมเห็นด้วยกับ Dillo ที่จำกัดขอบเขตของตัวอ่านเอกสารไฮเปอร์เท็กซ์ไว้ที่การอ่านเอกสาร ไม่ใช่พยายามให้เขียนหรือแก้ไขเอกสารจากในตัวอ่านได้ด้วย
เป้าหมายไม่ใช่การทำเว็บซ้ำแบบแยกฟังก์ชัน แต่คือการสร้างสเปกที่อ่านได้โดยไม่ต้องมีข้อกำหนดว่าต้องรันเครื่องเสมือนเต็มรูปแบบเพื่อแลกเปลี่ยนความรู้ บันทึกย่อ หรือข้อมูล
ผมอยากเห็น แอปพลิเคชันอเนกประสงค์ แบบย่อส่วนที่จัดการความต้องการเรื่อง “การโต้ตอบ” ส่วนใหญ่ได้ภายใต้ sandbox ที่ดีกว่า เราจำเป็นต้องใช้เครื่องเสมือนทั้งก้อนจริง ๆ หรือในการส่งไฮเปอร์เท็กซ์ไปมาบนฟีดโซเชียลมีเดียอย่าง Reddit? หรือแม้แต่ในการจัดการตะกร้าสินค้าและข้อมูลชำระเงิน?
แต่คำว่า “อเนกประสงค์” ก็มักจะกลืนกินคำว่า “แอปพลิเคชัน” สุดท้ายอาจกลับไปประดิษฐ์เว็บใหม่อีกอยู่ดี ถึงอย่างนั้น ถ้ามีโอกาสให้สิ่งนี้ตั้งอยู่บนฐานที่ไม่ใช่ Google และไม่ใช่ภาษา C++ ก็คงดีกว่า แม้ Dillo จะเป็น C กับ C++ ก็ตาม อย่างน้อยก็เหมือนดีขึ้นสักอย่าง
อีกอย่างที่น่าจะปรับปรุงได้คือใช้ HTTP แบบย่อส่วน แต่รองรับคุกกี้เฉพาะ session cookie ที่ไคลเอนต์ควบคุมเอง ห้าม resource จาก third party และให้ทรัพยากรทั้งหมดอยู่บนเว็บเซิร์ฟเวอร์เดียวกับเอกสาร รวมถึงบังคับให้มีตัวแปลงภายในเบราว์เซอร์สำหรับเรนเดอร์ฟอร์แมตอย่าง text/markdown
รอบนี้ผมอยากลองปรับวิธีให้ดีขึ้นเพื่อเลี่ยงคุกกี้ให้ได้ นี่คือการแทนเอกสารในเชิงเครื่องจักร ออกแบบมาให้อ่านได้โดยมนุษย์ แต่ไม่ได้ตั้งใจให้มนุษย์เขียนโดยตรง น่าจะดีกว่าถ้าใช้ภาษา frontend อย่าง Markdown แล้วคอมไพล์เป็นเอกสารแบบเคร่งครัดที่พกพาได้
example.netไม่ควรถูกส่งไปที่sub.example.netและsub.example.netก็ไม่ควรตั้งคุกกี้ให้example.netได้HTTP/2 และ HTTP/3 ควรปล่อยไว้กับเว็บแบบแอป ส่วน HTTP/1 ควรเหลือไว้กับเว็บแบบเอกสาร ผมไม่รู้เหมือนกันว่าจะจำกัด JavaScript ยังไงเพื่อเลี่ยงปัญหา “ต้องใช้เบราว์เซอร์เฉพาะถึงจะดูคอนเทนต์ฉันได้” ดังนั้นคงไม่ควรมี JavaScript เลย
ถ้าจะบังคับให้เรนเดอร์ text/markdown ก็ยังมีปัญหาว่าหมายถึงเวอร์ชันไหน เพราะรูปแบบแปรผันที่ต้องรองรับมีประมาณครึ่งโหล
ไวยากรณ์แบบเคร่งครัด คงไปไม่รอด เหตุผลเดียวกับที่ XHTML ล้มเหลว และเป็นเหตุผลที่ HTML5 ต้องเพิ่มกติกาสำหรับจัดการสิ่งที่ “พัง” แบบที่เจอบ่อย
จะเอา HTML5 มาเขียนสเปกใหม่ให้เป็นไวยากรณ์ที่เป็นทางการมากขึ้นแบบที่ผู้เขียนอยากได้ก็พอทำได้ แต่การปฏิเสธหน้าเพจอย่างเข้มงวดดูไม่ใช่การใช้ฟอร์กที่ดี อีกทางเลือกก็คือกลายเป็นตัวแทน gopher/gemini อีกอัน ซึ่งแม้จะมีแฟนเหนียวแน่น แต่ที่ไม่ดังมันก็มีเหตุผล พลังของความเข้ากันได้ย้อนหลังมันแรงมาก
ความเคร่งครัดอาจดีมากก็ได้ แต่ต้องมีการรองรับก่อนถึงจะใช้ได้ผล
แนวคิดว่า “การเพิ่มความสามารถด้านสคริปต์เป็นความผิดพลาด” เป็นมีมเก่าในหมู่โปรแกรมเมอร์สายหม่น ๆ ที่ไม่ยอมให้มีความสนุก แต่ผมว่ามันใกล้เคียงกับการขาดจินตนาการมากกว่า
มัลติมีเดียเชิงโต้ตอบ ที่ใช้อย่างระมัดระวังสามารถยกระดับการสื่อสารและการอธิบายได้มาก เช่น แผนภาพอินเทอร์แอ็กทีฟใน Red Blob Games Hex-Grid tutorial หรือ คำอธิบายอันยอดเยี่ยมของ Bartosz Ciechanowski เกี่ยวกับกลไกนาฬิกา และเพราะสื่อแบบโต้ตอบบนเว็บ เราจึงลองใช้คอมพิวเตอร์หายากที่สำคัญทางประวัติศาสตร์อย่าง Canon Cat ได้ในไม่กี่วินาทีหลังคลิกลิงก์ โดยไม่ต้องเจอกระบวนการฝันร้ายในการคอมไพล์และรันเนทีฟอีมูเลเตอร์ ฟอร์ม submit และ image map เป็นเพียงเงาจาง ๆ ของมัลติมีเดียเท่านั้น และยังย้ายภาระของการรองรับการโต้ตอบไปสู่โมเดลที่ยึดเซิร์ฟเวอร์เป็นศูนย์กลางโดยเนื้อแท้ และอาจกินแบนด์วิดท์มาก
ปัญหาไม่ใช่พฤติกรรมของสคริปต์เอง แต่คือสิ่งที่เบราว์เซอร์ปัจจุบัน อนุญาตให้สคริปต์ทำได้ เช่นเดียวกับที่เราย่อ HTTP และ HTML ให้เล็กลง เรียบง่ายขึ้น และเคารพอำนาจของผู้ใช้มากขึ้นได้ เราก็อาจรักษาข้อดีส่วนใหญ่ของ JavaScript บนเว็บไว้ได้ พร้อมลดพื้นที่ API และศักยภาพในการใช้งานที่เป็นพิษลงอย่างมาก ตัวอย่างเช่น ลองนึกถึงเว็บที่มีกรอบโต้ตอบแบบ Flash อยู่ในหน้า และการโต้ตอบนั้นขับเคลื่อนด้วยสคริปต์ Lua ที่ผู้ใช้เข้าถึงและตรวจสอบได้ ร่วมกับความสามารถด้านกราฟิกและอินพุตแบบ Love2D ส่วนการติดต่อเซิร์ฟเวอร์ระยะไกลหรือเข้าถึงเว็บแคม ซึ่งเป็นงานที่กระทบความเป็นส่วนตัว ก็ค่อยวางไว้หลัง sandbox ที่เข้มงวดและการยินยอมล่วงหน้าอย่างชัดเจนจากผู้ใช้
ทุกวันนี้ก็ยังสร้างเว็บแอปที่เคารพผู้ใช้แบบนี้ได้ แต่พื้นฐานมันขรุขระ ไม่สม่ำเสมอ เต็มไปด้วยการขาดหายของฟีเจอร์ที่มีประโยชน์อย่างชัดเจน และภัยคุกคามที่ไม่จำเป็นต่อความปลอดภัยกับความเป็นส่วนตัวของผู้ใช้ก็มีอยู่ทั่ว
ถ้ามองจากวิสัยทัศน์ด้านการเข้าถึง อาจนึกถึง ฟอร์มฝั่งไคลเอนต์ ที่จัดการอินพุต UI เชิงประกาศอย่างปุ่ม ฟิลด์ เช็กบ็อกซ์ และสไลเดอร์อย่างเคร่งครัด แล้วเรนเดอร์รูปภาพและมาร์กอัปใน
<iframe>แบบหน้า static แต่ทำงานได้โดยไม่ต้องไป-กลับกับเซิร์ฟเวอร์ เครื่องคิดเลข เครื่องมือ และภาพแสดงผลแบบโต้ตอบหลากหลายชนิดก็น่าจะอยู่ในโมเดลนี้ได้ และมี latency กับความปลอดภัยของผู้ใช้ดีกว่าโมเดลที่แบ็กเอนด์เป็นตัวขับถ้าจะเอาแบบ text-first ก็ต้องปล่อย CSS ไปด้วย CSS มีอยู่โดยมากเพื่อบริษัท ไม่ใช่เพื่อผู้ใช้ สไตล์ควรเป็นสิ่งที่เบราว์เซอร์ควบคุม ไม่ใช่หน้าเพจ
ถ้าผู้ใช้เลือกอ่าน payload ดิบของหน้า สิ่งนั้นส่วนใหญ่ก็ควรตรงกับข้อมูลที่เบราว์เซอร์แสดงให้อ่าน ทุกวันนี้คอนเทนต์ที่อ่านได้จริงเป็นแค่ยอดภูเขาน้ำแข็ง
เรื่อง “ไม่มีสคริปต์” ผมเดาว่าถ้าตัดสไตล์และหน้าเพจอ้วน ๆ ออกไป ความจำเป็นของสคริปต์ที่มีผลต่อการแสดงผลก็น่าจะลดลงมาก สคริปต์ที่ไม่กระทบการแสดงผลส่วนใหญ่ก็มักถูกใช้สวนทางกับผลประโยชน์ของผู้ใช้
แต่ CSS กับการจัดรูปแบบมันซับซ้อนเกินไปแล้ว ทุกวันนี้ user style ต้องเริ่มจาก CSS reset ทั้งก้อน ไม่ก็ต้องเจาะจงมากเป็นพิเศษรายเว็บไซต์
ผมเจอปัญหานี้ตอนทำเครื่องมือส่วนตัวที่ไม่มี JS ฝั่งไคลเอนต์ แล้วพบว่าต้องมี “การตั้งค่าเขตเวลาของฉัน” บนเซิร์ฟเวอร์ หรือไม่ก็เพิ่มสคริปต์ช่วยเล็ก ๆ
ถ้าให้เบราว์เซอร์ควบคุมสไตล์ ปัญหาแบบ “หน้าเว็บฉันอ่านได้ในเบราว์เซอร์ X กับ Y แต่ไม่ได้ใน Z” อาจยิ่งหนักกว่าตอนนี้ก็ได้
ผมว่าดีกว่าการต้องมองแต่เอกสารจืด ๆ ที่ล้างเสียงของผู้เขียนจนเหลือแค่ตัวอักษรสีดำบนพื้นขาว CSS คือวิธีแสดงออกของผู้เขียนบนเว็บ และผมไม่อยากให้มันหายไปจริง ๆ มันซับซ้อนก็จริง แต่ในอีกด้านมันทำให้คนทั่วไปทำอะไรสนุก ๆ บนเว็บไซต์ของตัวเองได้มากขึ้น ซึ่งผมมองว่าเป็นข้อดี
ผมก็มีความรู้สึกคล้ายกันว่าถ้าตัดสไตล์กับหน้าเพจอ้วน ๆ ออก ความจำเป็นของสคริปต์ที่ใช้เปลี่ยนการแสดงผลก็น่าจะลดลง ถ้ามีไวยากรณ์ที่เรียบง่าย เราอาจฝัง “เอกสาร” เข้าไปในโปรแกรมเนทีฟแบบอินเทอร์แอ็กทีฟได้ แทนที่จะเป็นอีกทาง
อย่างที่คนอื่นพูดกัน ผมว่า Gemini เป็นตัวอย่างอ้างอิงที่ดี อีกครั้งนะ Gemini ดูเหมือน performance art แต่ก็มีอะไรให้เรียนรู้อีกมาก
ฟีเจอร์หนึ่งของ Gemini ที่โดดเด่นแต่ไม่ค่อยถูกพูดถึงคือหน้าแบบ subscribe ได้ ภายในหน้าจะมีลิงก์ที่ขึ้นต้นด้วยข้อความ
YYYY-MM-DDซึ่งก่อเป็นฟีดโดยปริยาย มันจำกัดมากและดูทื่อ ๆ แต่ผมว่ามันเป็นหนึ่งในฟีเจอร์ที่น่าประทับใจที่สุดของ Gemini Spec hereใน HTML แบบดั้งเดิม การเขียนบล็อกด้วยมือเป็นไปได้ ถึงจะน่าเบื่อแต่ก็ทำได้จริง แต่ถ้าจะดูแลฟีด RSS/ATOM คุณแทบต้องมีเครื่องมือสร้างฟีดเกือบแน่นอน
ถ้าเป็น HTML แบบ “เน้นคอนเทนต์” รุ่นถัดไป ก็ควรมีฟีเจอร์คล้ายกันอยู่ด้วย บางที
h-feedin microformats อาจเป็นแนวทางที่ถูก แต่ผมชอบความเรียบง่ายของหน้าแบบ subscribe ได้ใน Gemini มาก และการมีฟีดอยู่ทุกที่ก็เป็นเรื่องดีการที่ Gemini เป็นแบบทีละบรรทัดและ parse ง่ายนั้นเป็นข้อได้เปรียบใหญ่ แต่ก็รู้สึกว่ามันจำกัดเกินไปและอาจส่งผลเสียต่อการเข้าถึง ถึงอย่างนั้น ถ้ามี HTML-lite ที่หน้าตาเหมือน Gemini ก็น่าจะโอเค
อีกประโยชน์หนึ่งที่การฟอร์กเว็บอาจได้คือการเก็บกวาดส่วนที่ถูกพอกเข้าไปใน HTML
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>นี่ค่อนข้างน่ารำคาญ ถ้าสร้างเวอร์ชันใหม่จากความรู้ที่เรามีวันนี้ มันน่าจะออกมาดีพอสมควรส่วนอื่นผมยังไม่ค่อยมั่นใจ ในเชิงหลักการผมเห็นด้วยเต็มที่กับการไม่มี JS เพียงแต่หนึ่งในการใช้งานเว็บที่ดีที่สุดคือการเข้าถึงบริการจำเป็นแบบครอบจักรวาล เช่น รัฐบาลหรือธนาคาร ผมยังไม่มั่นใจเต็มร้อยว่าเราจะทำทุกอย่างนั้นได้จริงโดยไม่มี JS พร้อมยังคง usability ที่ดีไว้ แต่อาจเป็นไปได้
และอยากเน้นส่วนใน ความเห็นอีกอัน ที่ว่า “สเปกนี้ไม่ได้ห้ามการรันในเว็บเบราว์เซอร์ทั่วไป และเว็บแบบทุกวันนี้ก็ไม่ได้จะหายไปไหน”
ผมอยากให้เรารัน “เบราว์เซอร์เว็บคอนเทนต์” กับ “เบราว์เซอร์เว็บแอป” แยกกันได้ สำหรับหลายวัตถุประสงค์ เว็บในฐานะแพลตฟอร์มแอปก็แทบไม่มีทางเลือกอื่นที่ดีเท่า เว็บพัฒนามาไกลมากแล้ว และดูเหมือนนักพัฒนาก็ชอบมันมากกว่าสิ่งอื่น ๆ มาก
ในโลกแบบนั้น Google Maps จะไม่ทำงานในเบราว์เซอร์เว็บคอนเทนต์ของผม แต่จะเปิดในเบราว์เซอร์แอปแทน และถ้าผมรัน GMail ในเบราว์เซอร์แอป ลิงก์ในอีเมลก็ควรเปิดในเบราว์เซอร์เว็บคอนเทนต์
ตามอุดมคติแล้ว เบราว์เซอร์เว็บคอนเทนต์ควรถูกสร้างให้ใช้งานง่ายกว่ามาก ซึ่งจะช่วยกระตุ้นการแข่งขันและนวัตกรรม แต่ก็น่าเสียดายที่ผมยังไม่เห็นเส้นทางทำให้สิ่งนี้เกิดขึ้นได้ ถ้าสามารถใช้เบราว์เซอร์คอนเทนต์แบบนั้นท่องทุกอย่างได้ ผมคงมีความสุขกว่านี้มาก เพราะพื้นที่โจมตีจะเล็กลงมาก ทำให้สบายใจเรื่องความปลอดภัยกว่า แต่ดูเหมือนตอนนี้ไม่มีใครสนใจแล้ว
งั้นก็แค่ เพิ่มมันเป็นฟังก์ชันของเบราว์เซอร์ ไปเลย
ฟังดูคล้าย Gemini อยู่บ้าง แต่ฟอร์กนี้น่าจะยอมให้ทำอะไรได้มากกว่า
ผมว่าเว็บไซต์สามารถเขียนด้วยรูปแบบแปรผันของ Markdown หรืออะไรทำนองนั้นได้ มันควรเป็นเอกสารที่อ่านในรูปดิบได้ง่าย นึกถึง Gemtext ที่เพิ่มอะไรอย่างสื่อแบบอินไลน์เข้ามาอีกนิด
และก็ควรยอมให้มีความสามารถด้านสไตล์เล็กน้อยด้วย เว็บเคยเป็นและยังเป็นที่ที่ยอดเยี่ยมสำหรับการแสดงความคิดสร้างสรรค์ ถ้ายังคง ชุดสไตล์ ที่เรียบง่ายและสม่ำเสมอไว้ คนที่มีความคิดสร้างสรรค์ก็น่าจะทำเว็บไซต์ที่แปลกใหม่ได้มากขึ้น
น่าจะรองรับ องค์ประกอบพื้นฐานของ HTMX ด้วย
ไอเดียนี้จะทำงานได้ดีกว่าถ้ามี แรงจูงใจที่ชัดเจน คำว่า “ทำให้เรียบง่าย” มันนามธรรมเกินไป แต่ละคนก็มองความเรียบง่ายไม่เหมือนกัน จึงควรมีเป้าหมายที่ชัดกว่านี้ว่าทำไมเว็บต้องเรียบง่ายขึ้น และมันตอบโจทย์ความต้องการเฉพาะอะไร
ตัวอย่างเช่น โครงการ Gemini มุ่งไปที่การสร้างชุมชนที่ให้คุณค่ากับการสื่อสารรูปแบบหนึ่งโดยเฉพาะ เพราะมันสอดคล้องกับเป้าหมายของชุมชนนั้น เขาจึงลดความซับซ้อนของเว็บด้วยการจำกัดให้เหลือรูปแบบการสื่อสารนั้น และถ้าจำไม่ผิด แม้แต่รูปภาพก็ไม่รองรับในเชิงเทคนิค
ในทางกลับกัน เครื่องมืออย่าง Sciter หรือ Blitz มีเป้าหมายทำให้ฝังตัวเรนเดอร์แบบคล้ายเบราว์เซอร์ลงในแอปอื่นได้ง่ายขึ้น พวกมันลดความซับซ้อนด้วยการตัดพฤติกรรมแปลก ๆ ที่ไม่จำเป็นออก หรือทำให้การ parse HTML กับการรัน JS เป็นตัวเลือกได้ แบบนี้ทั้งสิ่งที่ต้องพัฒนาและสิ่งที่ผู้ใช้ต้องฝังก็ลดลง
ทั้งสองแบบต่างก็มุ่งสู่ความเรียบง่าย แต่เพราะเป้าหมายพื้นฐานต่างกันมาก ผลลัพธ์จึงต่างกันมาก แล้วเป้าหมายพื้นฐานในที่นี้คืออะไรกันแน่?