เดิมพันกับ HTML
(catskull.net)- เมื่อ AI ที่ขับเคลื่อนด้วยโมเดลภาษาขนาดใหญ่แพร่หลายมากขึ้น คุณค่าของ semantic HTML ที่เครื่องอ่านได้ ก็ยิ่งเพิ่มขึ้นพอๆ กับหน้าจอที่มนุษย์มองเห็น
- สวนปิด ของโซเชียลมีเดียรายใหญ่ขัดขวางการย้ายข้อมูลและการทำงานร่วมกันระหว่างแพลตฟอร์ม ขณะที่ความพยายามแบบกระจายศูนย์อย่าง fediverse, Threads และ Bluesky ก็ยังมีแรงจูงใจไม่มากพอจะดึงผู้ใช้ทั่วไป
- HTML สมัยใหม่มี องค์ประกอบ UI พื้นฐาน สำหรับเว็บแอปอยู่แล้วค่อนข้างมาก เช่น
<details>,<dialog>และ<input>หลากหลายแบบ - หากใช้สไตล์พื้นฐานของเบราว์เซอร์และ reader mode ก็สามารถลดการพึ่งพา CSS และ JavaScript ที่มากเกินไปได้ และการใช้แท็กที่ถูกต้องยังช่วยปรับปรุง ความสามารถในการอ่านโดยเครื่อง และประสบการณ์การป้อนข้อมูลบนมือถือ
- ในกระแสที่ RSS ยังมีชีวิตอยู่ และอินเทอร์เฟซแบบ ChatGPT กำลังกลายเป็นวิธีเข้าถึงข้อมูล แนวทางที่ใช้ HTML แบบมีโครงสร้าง อาจเป็นรากฐานที่ใช้งานได้จริงกว่าส่วนติดต่อที่ขับเคลื่อนด้วยโฆษณา
HTML ในฐานะอินเทอร์เฟซข้อมูลพื้นฐานของเว็บ
- การมาถึงของ AI ที่ขับเคลื่อนด้วยโมเดลภาษาขนาดใหญ่ทำให้ความสำคัญของ semantic HTML กลับมาโดดเด่นอีกครั้ง
- แก่นของอินเทอร์เน็ตคือการส่งมอบข้อมูลที่มนุษย์ต้องใช้เพื่อโต้ตอบกับโลก แต่ความยืดหยุ่นของ HTML/CSS/JavaScript ก็มีอีกด้านที่ทำให้การเข้าถึงข้อมูลถูกจำกัดได้เช่นกัน
- โซเชียลมีเดียของบริษัทยักษ์ใหญ่ด้านเทคโนโลยีผูกผู้ใช้ไว้ใน แพลตฟอร์มปิด มากกว่าจะใช้รูปแบบข้อมูลและ API ที่เปิดเผยและเข้าถึงได้
- การทำงานร่วมกันระหว่างแพลตฟอร์มจึงแทบเป็นไปไม่ได้
- เมื่อบริษัทต่างๆ ไม่เต็มใจให้ย้ายข้อมูลได้ง่าย ปัญหาก็ยิ่งซับซ้อนขึ้น
- ความไม่เสถียรของโซเชียลมีเดียในช่วงหลังทำให้ความสนใจต่อแพลตฟอร์มแบบกระจายศูนย์อย่าง fediverse กลับมาเพิ่มขึ้นอีกครั้ง
- Threads ของ Meta และ Bluesky ที่ Jack Dorsey สร้างขึ้นต่างชูจุดเด่นเรื่องการทำงานร่วมกับ fediverse ที่ใหญ่กว่า
- อย่างไรก็ตาม ผู้ใช้ทั่วไปมักไม่ได้เลือกโซเชียลมีเดียใหม่ด้วยเหตุผลนี้เพียงอย่างเดียว
- ถึงเวลาที่ควรหันกลับไปมอง HTML ในฐานะทางออกที่ผ่านการพิสูจน์มาแล้ว
- ในอดีตต้องใช้ CSS มากพอสมควรเพื่อไม่ให้เนื้อหา HTML ดูแย่ในเบราว์เซอร์
- แต่ตอนนี้มีองค์ประกอบ HTML สมัยใหม่เพิ่มเข้ามามาก และรองรับองค์ประกอบ UI ส่วนใหญ่ที่เว็บแอปสมัยใหม่ต้องการ
- reader mode สามารถทำให้เวลาที่ทุ่มไปกับการตกแต่งสไตล์ไร้ผลได้ และเรื่องนี้อาจมองในแง่บวกได้
- แท็กที่ถูกต้องช่วยให้ได้ รูปแบบที่เครื่องอ่านได้ง่าย
- นี่เป็นเหตุผลที่หนักแน่นกว่าการประหยัดเวลางานออกแบบเพียงอย่างเดียวสำหรับการเลือกใช้ HTML สมัยใหม่
- RSS ยังมีชีวิตอยู่
- อินเทอร์เฟซแบบ ChatGPT ก็อาจกลายเป็นวิธีที่มนุษย์ใช้เข้าถึงข้อมูลในอนาคต
องค์ประกอบ HTML ที่มีประโยชน์หรือควรมองใหม่
- ควรลองดู รายการองค์ประกอบ HTML ทั้งหมดของ MDN
- ตัวอย่างด้านล่างใช้เพียงสไตล์พื้นฐานของเบราว์เซอร์ โดยไม่ใส่สไตล์เพิ่มเติม
- รูปลักษณ์อาจต่างกันมากตามเบราว์เซอร์ หรือบางตัวอาจไม่รองรับเลย
<abbr>: องค์ประกอบสำหรับครอบคำย่อ- สามารถใส่สไตล์เพื่อเน้นได้
- มีประโยชน์หลักกับ การอ่านโดยเครื่อง
<datalist>: องค์ประกอบที่ให้รายการตัวเลือกสำหรับการป้อนข้อมูล- สามารถสร้าง UI ที่ดูคล้าย typeahead ได้
- ดูเหมือนไม่มีการตรวจสอบความถูกต้องแบบฝังในตัว
- ใน Safari ต้องปิดแท็ก
optionมิฉะนั้นจะไม่ทำงาน
<details>: องค์ประกอบเปิด-ปิดเพื่อแสดงรายละเอียด- ใช้เป็นดรอปดาวน์ขนาดเล็กได้
- ยังสามารถใส่สไตล์ได้มากพอสมควร
<dialog>: องค์ประกอบกล่องโต้ตอบ- เป็นองค์ประกอบที่มีปุ่ม ฟอร์ม แอตทริบิวต์ และเปิดปิดได้ด้วย JavaScript ในตัว
- แม้จะไม่เหมือน modal เป๊ะๆ แต่ถ้าจะทำ modal ก็เหมาะจะใช้เป็นฐาน
- ดูเหมือนว่าจะถูกเรนเดอร์อยู่เหนือองค์ประกอบถัดไป
<i>และ<em>- ควรทำความเข้าใจความแตกต่างของสององค์ประกอบนี้
<iframe>- อยู่ในรายการตัวอย่าง แต่ถูกยกมาแบบติดตลก
<input>: องค์ประกอบรับค่าฟอร์ม- ควรใช้ป้ายกำกับและประเภทที่เหมาะสมกับข้อมูลที่รับ
- บนมือถือ ระบบปฏิบัติการจะเปิดคีย์บอร์ดต่างกันตามบริบท จึงสำคัญมากที่จะกำหนด input type ให้ถูกต้อง
- มีรูปแบบอินพุตเกี่ยวกับเวลาให้เลือกหลากหลาย จึงช่วยลดการใช้ JavaScript date picker แยกต่างหากได้
- ยกตัวอย่าง
color,range,datetime-local
<mark>: องค์ประกอบไฮไลต์ข้อความ- โดยค่าเริ่มต้น Safari จะแสดงเป็นไฮไลต์สีเหลือง
<meter>: องค์ประกอบแสดงค่าการวัด- ใน Safari จะแสดงเป็นสีแดง เหลือง หรือเขียวตามพารามิเตอร์ที่ตั้งไว้
- สามารถกำหนดค่า
optimumได้ - อาจมีประโยชน์กับเดโม visualization เพลงที่ 60fps
<progress>: องค์ประกอบแสดงความคืบหน้า- เป็นแถบความคืบหน้า HTML แบบเนทีฟที่กำหนดค่าแบบคงที่หรือสถานะไม่แน่นอนได้
- ใน Safari จะเห็นเป็นสีน้ำเงินเมื่อหน้าต่างทำงานอยู่ และเป็นสีเทาเมื่อไม่ทำงาน
- โดยปกติจะอิงตามสีเน้นของระบบ และสามารถตั้งค่าด้วยพร็อพเพอร์ตี CSS
accent-colorได้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เป็นเรื่องแปลกที่บอกว่า HTML คือทางออกของการผูกติดกับระบบนิเวศแบบปิด เพราะบริการแบบปิดเหล่านั้นก็ใช้ HTML อยู่แล้ว และยังใช้องค์ประกอบเชิงความหมายบางส่วนที่กล่าวถึง รวมถึงพร็อพเพอร์ตีเชิงความหมายของ ARIA ที่ละเอียดกว่าด้วย
ส่วนข้ออ้างที่ว่าอินเทอร์เฟซแบบ ChatGPT คืออนาคตของการเข้าถึงข้อมูลของมนุษย์นั้น แก่นของระบบปัญญาประดิษฐ์อยู่ที่ว่าไม่จำเป็นต้องมีคำอธิบายประกอบพิเศษแบบ “เครื่องอ่านได้” เพื่อประมวลผลอินพุต ChatGPT และโมเดลรุ่นถัด ๆ ไปสามารถสำรวจเว็บไซต์ทั่วไปได้เหมือนมนุษย์ และรู้ได้เองว่ากลุ่มย่อหน้านั้นเป็น “รายการ” หรือไม่ แม้ไม่มีมาร์กอัประบุชัดเจน
สิ่งที่ผู้เขียนอธิบาย สุดท้ายแล้วใกล้เคียงกับ API ที่มีองค์ประกอบเชิงความหมายของ HTML เป็นตัวกลาง แต่ถ้ามี API อยู่แล้ว การเข้าถึงข้อมูลอัตโนมัติก็ไม่จำเป็นต้องใช้โมเดลภาษาขนาดใหญ่ สคริปต์ Python ธรรมดาที่ใช้ Beautiful Soup ก็เพียงพอ แถมยังมีข้อดีคือทำงานเฉพาะในเครื่องได้ด้วย
สุดท้ายสิ่งที่แยกของดีออกจากของแย่คือความซับซ้อนในการ implement เครื่องมืออะไรก็ใช้ให้ดีหรือแย่ได้ทั้งนั้น และมือใหม่ก็อาจสร้างอุบัติเหตุใหญ่ด้วยเลื่อยวงเดือนกับแบตเตอรี่ที่ชาร์จเต็มได้ ช่างฝีมืออาจเลือกไม่ใช้เครื่องมือเลยแล้วไปเคาะด้านข้างแทน กล่าวคือเลือกขัดกับความต้องการทางธุรกิจ
เว็บไซต์ที่ผมทำช่วงหลัง ๆ เป็นงานที่เข้ากันได้ดีที่สุดในบรรดาที่เคยทำมา ผมไม่ใช้ WebSocket แล้ว และไม่พึ่งวิธีที่ JavaScript คุยกับเซิร์ฟเวอร์ทีละชิ้น ๆ อีกต่อไป แม้ปิด JavaScript ทั้งหมดก็ยังใช้ผลิตภัณฑ์ได้ประมาณ 80% ผมไม่เข้าใจว่าทางเลือกทางวิศวกรรมแบบนี้จะไม่ใช่ทางออกต่อการผูกติดกับระบบนิเวศแบบปิดได้อย่างไร
โมเดลภาษาขนาดใหญ่เรียนรู้จากข้อความและซอร์สโค้ด ฯลฯ แต่ในภาวะที่ยังขาดสิ่งที่พอจะเรียกว่าเครื่องมืออนุมาน ผมสงสัยว่ามันจะดูต้นไม้ DOMแล้วรู้จริง ๆ ได้หรือไม่ว่านั่นคืออะไรและทำอะไร DOM ไม่ใช่ข้อความ และจากผลของการ bundling หรือการแยกเป็นคอมโพเนนต์ ก็ยากจะถือว่าเป็นซอร์สโค้ดที่มีโครงสร้างดี ฟังดูแทบจะเหมือนกับพูดว่า “โมเดลภาษาขนาดใหญ่สามารถดูไฟล์ .exe ใด ๆ แล้วผสานใช้งานได้ทันที”
ผมก็สนใจคล้ายกัน แต่เป้าหมายคือการ crawl และเสิร์ชเอนจินเกิดใหม่ ถ้าต้องรันทุกหน้าใน headless browser ก่อนทำดัชนี อุปสรรคในการเข้าสู่ตลาดของเสิร์ชเอนจินใหม่ก็จะสูงขึ้นมาก
ประโยคแรกของบทความคือ “การมาถึงของปัญญาประดิษฐ์ที่ใช้โมเดลภาษาขนาดใหญ่ ทำให้ semantic HTML สำคัญกว่าที่เคย” แต่ผมกลับคิดว่าประโยค “การมาถึงของปัญญาประดิษฐ์ที่ใช้โมเดลภาษาขนาดใหญ่ ทำให้ semantic HTML สำคัญน้อยกว่าที่เคย” ปกป้องได้มากกว่าเสียอีก
Semantic Web ล้มเหลวไปแล้ว และที่มาแทนคือ Google ทุ่มเงินมหาศาลกับฮิวริสติกสารพัดที่ผนวกปัญญาประดิษฐ์ระดับดีที่สุดในยุคนั้นเข้าไป ยิ่งปัญญาประดิษฐ์ดีขึ้น ความสามารถในการดึงข้อมูลจากสิ่งที่ปนเปมั่ว ๆ ก็ยิ่งสูงขึ้น และถ้าสิ่งปนเปมั่ว ๆ แบบนั้นเพียงพอ ความพยายามที่ผู้คนยอมลงแรงก็คงหยุดแค่นั้น โดยหลักการแล้ว สุดท้ายทั้ง Semantic Web และกองฮิวริสติกต่างก็จะถูกแทนที่ด้วยปัญญาประดิษฐ์
อีกเรื่องที่สำคัญคือ ตอนแรกเขียนว่า LLM แต่หลังจากนั้นเปลี่ยนไปใช้คำทั่วไปอย่าง AI โมเดลภาษาขนาดใหญ่ไม่ใช่ปัญญาประดิษฐ์ทั้งหมด เป็นเพียงสายหนึ่งที่กำลังร้อนแรงในตอนนี้ และก็ไม่ใช่สายร้อนแรงสุดท้ายด้วย การมองอนาคตโดยสมมติว่าโมเดลภาษาขนาดใหญ่จะเป็นคำตอบสุดท้ายของปัญญาประดิษฐ์ไปอีกหลายสิบปีไม่ใช่เรื่องดี
ถ้าเป้าหมายคือให้ส่วนที่เกี่ยวข้องของคอนเทนต์ถูกจัดทำดัชนีและติดอันดับได้ดีพอ ก็อาจมองได้ว่าแรงจูงใจให้ยอมรับ semantic HTML อย่างเต็มที่ยังไม่มากพอ
แต่ถ้าเป้าหมายเปลี่ยนจาก “ติดอันดับ” เป็น “ทำให้โมเดลภาษาขนาดใหญ่ดึง nuance และ texture ของคอนเทนต์ออกมาได้มากที่สุด” แรงจูงใจในการใช้องค์ประกอบบางอย่างให้ดีขึ้นก็อาจเพิ่มขึ้น เว็บไซต์ที่ทำแบบนั้นอาจมีอิทธิพลต่อผลลัพธ์ของโมเดลภาษาขนาดใหญ่มากกว่า
มันให้ความรู้สึกเหมือนความต่างระหว่างพูดให้ดังพอจะได้ยิน กับพูดให้ชัดพอจะเข้าใจ
ผมได้ยินว่ามีการเปิดตัวหน้าผลลัพธ์ใหม่ที่ใส่ Bard เข้าไป แต่ไม่รู้เพราะนิสัยเมินโฆษณาหรือเพราะยังไม่ออกในพื้นที่ของผม ผมเลยเหมือนยังไม่เคยเห็น คงต้องไปลองค้นดู
ในหัวผมเคยค่อนข้างอยู่ฝั่ง Semantic Web แต่ถ้าเครื่องเข้าใจความปนเปนั้นได้พอประมาณจริง ๆ คำถามว่าทำไมต้องเหนื่อยลงแรงก็ถูกต้อง
ยังมีโปรเจกต์ที่อ้างว่า knowledge graph หรือสินทรัพย์ข้อมูลอื่น ๆ ช่วยให้ปัญญาประดิษฐ์ค้นหาองค์ความรู้ที่ “จริงแท้” ได้ ส่วนตัวผมคิดว่าควรพัฒนาวิธีให้ปัญญาประดิษฐ์สร้างสินทรัพย์ข้อมูลของตัวเองได้มากกว่า น้ำหนักของโครงข่ายประสาทก็เป็นสินทรัพย์แบบนั้นอย่างหนึ่ง
ปัญหาเรื่องความจริงยังคงยากมาก เราจะบอกปัญญาประดิษฐ์ได้อย่างไรว่าองค์ความรู้หนึ่งน่าเชื่อถือกว่าอีกองค์ความรู้หนึ่ง? แน่นอนว่ามนุษย์ก็มีปัญหาเดียวกัน
องค์ประกอบ HTML ส่วนใหญ่เหล่านี้แทบไม่เคยได้ยินมาก่อนเลย และรู้สึกน่าเสียดายอยู่ไม่น้อย เพราะของพวกนี้น่าจะช่วยได้มากในการยุติระบบนิเวศแบบ “ทุกอย่างต้องใช้ JavaScript”
อย่างน้อยก็ช่วยพา JavaScript กลับไปอยู่ในตำแหน่งที่ใกล้กับเจตนาเดิม คือเป็นเครื่องมือสำหรับเพิ่มลูกเล่นหรือการโต้ตอบเล็กน้อย ไม่จำเป็นต้องเป็นสิ่งทดแทนมาร์กอัปทั้งหมดและเป็นผู้จัดการ DOM ทั้งชุด
เบราว์เซอร์ในฝันของฉันอาจเป็นอะไรคล้าย visurf https://sr.ht/~sircmpwn/visurf/ โดยที่เอนจิน Netsurf ภายในได้รับการอัปเดตให้รองรับ HTML+CSS สมัยใหม่ที่รวมองค์ประกอบเหล่านี้ด้วย ด้วยเบราว์เซอร์แบบนั้น น่าจะสร้าง เว็บขนาดเล็ก ที่แทบไม่ใช้ JavaScript ได้ ทำให้การเข้าถึงดีขึ้นเพราะไปรบกวน screen reader, ธีมระบบ, คีย์ลัด ฯลฯ น้อยลง ใช้ทรัพยากรน้อยกว่าเครื่องจักร JavaScript หนัก ๆ ที่ทดแทนได้มาก และยังดูเหมือนทำสิ่งส่วนใหญ่ที่คาดหวังจากเว็บแอประดับกลางในปัจจุบันได้ ส่วนของอย่าง WebGL ก็เปิด Firefox เอาได้ แต่ตัวอย่างเช่น ไคลเอนต์ Matrix อาจใช้ JavaScript เพียงเล็กน้อยสำหรับเว็บซ็อกเก็ตและการเข้ารหัสแบบ end-to-end ก็พอ
ความสามารถในการขยายก็แทบไม่มี พอต้องทำอะไรซับซ้อนขึ้นนิดเดียว สุดท้ายก็ต้องทิ้งแล้วเริ่มใหม่ด้วย JavaScript อยู่ดี ถ้าอย่างนั้นเริ่มด้วย JavaScript ตั้งแต่แรกดีกว่า ฝั่งนั้นทำงานได้ดี ให้สิทธิ์ควบคุมเต็มที่ และทำงานเหมือนกันในทุกระบบ
สุดท้ายคอมโพเนนต์เพิ่มเติมพวกนี้ก็กลายเป็นความเทอะทะที่ทุกเบราว์เซอร์ต้อง implement แต่ไม่มีใครใช้
datalistครั้งแรกคิดว่า “ว้าว นี่มัน game changer” พฤติกรรมเหมือนกันในแต่ละเบราว์เซอร์ แต่หน้าตาเป็นของแต่ละเบราว์เซอร์ล้วน ๆ และสไตล์ด้วย CSS ไม่ได้บางครั้งเห็นแค่ข้อความของข้อมูล บางครั้งเห็นทั้งข้อความและแอตทริบิวต์
valueด้วย ดังนั้นแทนที่จะเลือก “Atlanta” กลายเป็นเลือก “234290780 Atlanta” คือเลือกทั้ง ID และค่าไปพร้อมกันในพฤติกรรมการคลิกก็เอาแค่ ID ออกมาโดยตรงไม่ได้ ต้องเอาทั้งหมดมาแล้ว parse ID เอง รู้สึกเหมือนเป็น องค์ประกอบที่ถูกปล่อยทิ้งไว้ เฉย ๆ
บทความลิงก์ไปที่ MDN และ MDN ก็ถือว่าเป็นแหล่งอ้างอิงสั้น ๆ ที่มีประโยชน์ที่สุด แน่นอนว่ายังมีสเปก WHATWG HTML ด้วย และถ้ามันใหญ่เกินไป ก็ยังมีไวยากรณ์รูปแบบ SGML DTD สำหรับสแนปช็อต WHATWG HTML 2021·2023 รวมถึงไวยากรณ์ตระกูล HTML 5.x รุ่นเก่า
[1]: https://sgmljs.net/docs/html200129.html
อยากเชื่อใน semantic web และอยากเชื่อว่าเบราว์เซอร์สามารถให้โมดูลพื้นฐานที่ดีพร้อมสไตล์เริ่มต้นที่โอเคได้ แต่ตอนนี้คงต้องยอมรับว่ามันไม่เป็นแบบนั้น
แค่การติด label ให้
inputก็ต้องคิดแล้วว่าทำไมไม่เป็นแอตทริบิวต์ ต้องใช้เป็น wrapper หรือควรวางเป็น sibling ที่มีแอตทริบิวต์for=ก็ยังไม่แน่ใจ นี่เป็นแค่ยอดภูเขาน้ำแข็งเท่านั้น แต่ละแท็กต้องเรียนประวัติการพัฒนาทั้งหมด แล้วค้นใหม่อีกว่าวิธีที่ถูกต้องในยุคนี้คืออะไรเราอาจมีของดีได้ แต่ตอนนี้คงต้องสงบใจแล้วปล่อยวาง
แน่นอนว่ามีส่วนแปลก ๆ และมุมขรุขระอยู่บ้าง แต่ถ้านักพัฒนาเว็บทุกคนใช้ semantic HTML ได้อย่างเต็มที่ JavaScript ในเบราว์เซอร์ก็คงน้อยลงมาก บั๊กด้าน accessibility ก็คงลดลง และเวลาสเปกต้องแก้หรือทดแทนจุดแปลก ๆ เหล่านี้ ก็น่าจะมีคนจับตามองมากขึ้น
แอตทริบิวต์
labelน่าจะหมายถึงเนื้อหาแบบข้อความธรรมดา ซึ่งดูจำกัดเกินไปHTML มีประวัติที่ซับซ้อนและหลายชั้นสมกับที่ถูกใช้มาหลายทศวรรษ ถึงอย่างนั้นช่วงหลังก็ไม่ได้เปลี่ยนไปมาก และด้วย MDN ก็ทำให้เรียนรู้ได้ค่อนข้างพอว่า HTML5 ทำอะไรได้บ้าง และเจาะลึกเพิ่มเมื่อต้องการได้ง่าย
labelไว้หลังแท็กinputเพื่อให้ใช้ CSS pseudo-class เลือกและจัดสไตล์ label ตามสถานะของ input ได้แน่นอนว่าไม่ว่าจะเป็นระบบ publishing แบบใด หรือจริง ๆ แล้วระบบใดก็ตาม ถ้าจะใช้อย่างมีประสิทธิภาพก็ต้องเรียนรู้วิธีใช้องค์ประกอบพื้นฐานที่มันมีให้ ดังนั้นนี่ไม่ใช่ปัญหาเฉพาะของ semantic web
ใช้
detailsบ่อยมากเวลา debug Go HTML templateถ้าใส่ข้อมูลไว้ตอนอยู่ในโหมดพัฒนาด้วย
{{if .DevMode}}ตอนมันถูกพับอยู่ก็ไม่ทำให้หน้าเสียหายมากและไม่สะดุดตา แต่พอต้องการก็คลี่ออกมาดูเนื้อหาทั้งหมดได้detailsเกินจำเป็นอยู่หน่อย มันเรียบร้อยมาก แต่ไม่เข้าใจว่าทำไมถึงไม่ถูกใช้มากกว่านี้ใน GitHub Markdown ก็ใช้ได้ และมีคนใช้กับตัวอย่างหรือคำอธิบายแบบ inline ด้วย
บทอ่านและ เดโมแบบอินเทอร์แอคทีฟ ดีมาก
หลังจากลองจับ Flutter มาหลายปี ก็กลับมาถึงข้อสรุปเดิมอีกครั้งว่า ต้องเดิมพันกับ HTML
ชุด Astro / Tailwind / Daisy UI / Alpine.js เหมาะมากสำหรับทำไซต์ HTML ที่ใช้การเรนเดอร์ฝั่งเซิร์ฟเวอร์แบบเรียบง่ายเป็นหลัก แล้วโรยความตอบสนองฝั่งไคลเอนต์เข้าไปเล็กน้อย
ผลลัพธ์คือไฟล์ HTML ที่เรียบง่ายและปกติ ใช้ดูและทำงานได้ดีทั้งบนเว็บเบราว์เซอร์เดสก์ท็อปและ WebView บนมือถือที่ห่อไว้ แอปของผมแทบจะเป็นแบบสแตติก จึงแคชบน CDN ได้ ทำงานออฟไลน์ได้ และการดูซอร์สก็ช่วยให้ดีบักง่ายขึ้น
จุดที่ดีที่สุดคือ ผมมั่นใจได้ว่านักพัฒนาใหม่ ไม่ว่าจะมาจาก React, Angular, PHP หรือ Python พอดูไฟล์บิลด์ 100 บรรทัดสัก 3 นาที ก็จะเข้าใจได้ มันเรียบง่ายจริง ๆ และนั่นแหละที่ดี
ผมคิดว่าปัญหาของ Semantic Web คือ ต่อให้มันง่ายแค่ไหน นักพัฒนาก็ยังปฏิเสธที่จะใช้ให้ถูกต้อง ส่วนขยายเบราว์เซอร์ของผมใช้แท็ก
mainผมเลยคอยสังเกตแท็กนี้เป็นพิเศษ ในเอกสาร MDN ระบุชัดมากว่าควรทำอะไร และตัวเอกสารเองก็แสดงตัวอย่างการใช้งานที่ดีด้วย แต่ไซต์ที่ใช้ถูกต้องมีน้อยมากแม้แต่ไซต์มืออาชีพที่ดูสวยงามก็ยังมักครอบเนื้อหาทั้งหน้าทั้งหมดไว้ในแท็ก
mainรวมถึง navigation, footer อะไรพวกนั้นด้วย ทั้งที่แท็กนี้ควรใช้เฉพาะกับเนื้อหาหลักของหน้าเท่านั้นถ้าแม้แต่องค์ประกอบที่เรียบง่ายขนาดนี้ยังใช้ให้ถูกไม่ได้ ก็ไม่คาดหวังอะไรมากกับองค์ประกอบอื่น ๆ
ของแบบนี้ไม่ควรถูกแสร้งทำว่าเป็นสัญญาข้อตกลง
pกับย่อหน้า แทบทั้งหมดก็คือใช้ถูกแล้ว มันต่างจากอะไรอย่างclass="card"ผมไม่เข้าใจว่าทำไมคนที่เข้าใจเทคโนโลยีสูงจำนวนมากถึงคร่ำครวญเรื่อง ความไร้ประโยชน์ของ Semantic Web หรือความล้มเหลวของมัน เหมือนพูดว่า “อยากให้รถยนต์ประสบความสำเร็จจัง การเดินทางไกลคงสะดวกขึ้น”
แต่ยุคนั้นเคยมีมาแล้ว สิ่งต่าง ๆ ก่อน HTML4 โดยมากก็เป็นแบบนั้น และมันแย่กว่า
ดังนั้นอาจดีกว่าถ้าเครื่องมือนักพัฒนาแสดงคำเตือนหรือข้อผิดพลาดเมื่อมีการใช้งานผิด
น่าสนใจที่คอมเมนต์จำนวนมากที่นี่มองบทความนี้ว่าเป็นบทความ ต่อต้าน JavaScript สำหรับผมกลับมองว่าเป็นเครื่องมือที่มีประโยชน์มากเมื่อใช้ร่วมกับเฟรมเวิร์กที่เน้น TypeScript ซึ่งเราใช้ในฟรอนต์เอนด์ของแอประดับองค์กรสมัยใหม่ เพราะมันเป็นเครื่องมือเนทีฟของ HTML จึงไม่ได้เรียกร้องอะไรเยอะแยะ
ตัวอย่างเช่น แท็ก
meterน่าจะได้มาแทนที่โมดูลโหลดทั้งหมดที่เราใช้ใน React ทันทีที่ผมไปทำงานวันนี้ เพราะมันดีกว่าสิ่งที่ใช้อยู่ตอนนี้มากผมอาจเข้าใจคนอื่นผิด หรืออ่านบทความผิดก็ได้ แต่ถึงกรณีที่ฟรอนต์เอนด์แทบทั้งหมดเป็น TypeScript เหมือนแอปพลิเคชันใหญ่ ๆ ในปัจจุบัน สิ่งนี้ก็ยังน่าสนใจมาก
ตอนนี้มีแอปพลิเคชันใหม่ ๆ ที่สร้างได้ด้วย JavaScript น้อยกว่าเดิมมาก ในแอป TypeScript ระดับองค์กรเดิม ๆ มันอาจเป็นการอัปเกรดแบบแทนที่ของเดิม แต่ความหวังคือในการพัฒนาแอปใหม่ เราจะหลีกเลี่ยงเฟรมเวิร์กระดับองค์กรเหล่านั้นไปได้เลย ฝันไว้บ้างก็ได้ไม่ใช่หรือ?
ไม่ได้อยากลดทอนคุณค่าการพัฒนาเว็บทั้งหมดหรอก แต่บอกตรง ๆ ว่ามันแย่มาก ทำมาตั้งแต่ HTML ดิบ ๆ ไปจนถึงภาษา scripting และ framework หลายปีแล้ว แต่เวลาที่ต้องใช้ทำเรื่องเล็ก ๆ น้อย ๆ มันรู้สึกเหมือนสิ้นเปลืองพลังสมองมหาศาล
ตอนที่ไปพักร้อน แค่อยากหาที่กินที่ดื่ม หรือสถานที่แวะเที่ยวสักวัน แต่เว็บส่วนใหญ่เละเทะ ล้าสมัย หรือไม่ได้อัปเดต ยังมีเว็บอีกมากที่ทำครั้งเดียวแล้วถูกลืมไว้ คงเพราะงบจำกัดจนไม่มีเงินอัปเดต หรือการอัปเดตยากเกินไปในเชิงเทคนิค
ความซับซ้อนของเว็บทำให้ทุกอย่างชะงักงัน สิ่งที่ควรเป็นแค่ข้อความกับรูปภาพไม่กี่หน้า กลับถูกออกแบบเกินจำเป็นและเผาผลาญ CPU cycles มหาศาล แถมมีโอกาสสูงว่าเป็น CMS สำเร็จรูปที่ถูกดัดแปลงจนต้องคอยอัปเดตความปลอดภัยอีก
ล่าสุดดูเว็บโรงหนัง แค่จะไล่ดูหนังไม่กี่เรื่องที่ฉายในสัปดาห์นั้นก็แทบเป็นไปไม่ได้ รู้สึกว่าเอาไปใส่ spreadsheet น่าจะอ่านง่ายกว่า และพอลองดึง JSON จาก API มาดูจริง ๆ ก็อ่านง่ายกว่าด้วย
ส่วนใหญ่เป็นแค่การห่อหุ้มที่น่าเบื่อ เหมือนทาลิปสติกให้หมู เหตุผลหนึ่งที่ Facebook สำเร็จคือ onboarding ง่าย และอีกเหตุผลคือแชร์รูปได้ง่าย WhatsApp กับ Instagram ก็เช่นกัน การเผยแพร่ควรจะง่าย FTP ธรรมดาก็ง่ายเหมือนกัน แต่สำหรับคนทั่วไปแล้วมันมีรอยขาดแปลก ๆ ในกระบวนการใช้งาน ผู้คนต้องการลากแล้ววาง อัปโหลด วางไว้แล้วลืม แก้ไขได้ง่าย ส่วนคนที่ต้องการบริโภคข้อมูล สุดท้ายก็ต้องการแค่แก่นสาร นั่นคือข้อมูลนั่นเอง
สิ่งที่ผู้คนต้องการคือเว็บเพจที่จัดสไตล์ดีและใช้งานได้ ปัญหาคือมี นักออกแบบประสบการณ์ผู้ใช้ ที่มีประสิทธิภาพและมีฝีมือไม่พอ และผู้มีส่วนได้ส่วนเสียในบริษัทเองก็ขาดเซนส์ UX ที่ดีพอ
ดังนั้นการให้แค่ข้อมูลแก่น ๆ จึงกลายเป็นทางเลือกที่ดีกว่าสำหรับผู้ใช้ทั่วไป เมื่อเทียบกับ UX แบบครึ่ง ๆ กลาง ๆ ที่บริษัททั่วไปพอจะจ่ายได้ แม้จะไม่ใช่สิ่งที่ชอบที่สุด แต่มันดีกว่า
{UX แย่} << {ข้อมูลดิบ} < {UX ดี}ทางเลี่ยงที่ WordPress ค้นพบคือทำสไตล์และธีมแบบมืออาชีพ แล้วให้ผู้ใช้ซื้อไปใช้ แต่ก็แก้รสนิยมแย่ ๆ ของผู้มีส่วนได้ส่วนเสียไม่ได้อยู่ดี
ผมมองว่า Facebook สำเร็จเพราะบังคับใช้ UX ที่เป็นมืออาชีพและเป็นมาตรฐาน
{ข้อมูลของผู้คน} + {UX แบบมืออาชีพและเป็นมาตรฐาน} = {ชัยชนะ}ต่อให้ไม่ชอบ UX ช่วงแรกของ Facebook ก็คงพูดยากว่านั่นเป็นงานระดับมือสมัครเล่น ภาพจำทั่วไปต่อ MySpace หรือ Geocities นั้นตรงกันข้ามถ้าอยากหาอะไรอย่างตะแกรงลวด ผมจะถามในกลุ่ม WhatsApp ที่ผมอยู่ก่อน ทั้งกลุ่มครอบครัว เพื่อนบ้าน เพื่อนมัธยม ปกติก็จะได้เบอร์มาสองสามเบอร์ แล้วติดต่อผู้ให้บริการทาง WhatsApp ก็จะได้ข้อมูลล่าสุด
ผู้ให้บริการเหล่านั้นรับภาระเว็บที่อัปเดตตลอดไม่ไหว WhatsApp เองก็มีฟีเจอร์ใส่แคตตาล็อกในโปรไฟล์ และเป็นของบัญชีธุรกิจฟรี
สิ่งที่อยากเห็นคืออะไรทำนอง “Wix Widgets” เป็นวิดเจ็ตเชื่อมต่อข้อมูลที่มีการปรับแต่งประมาณว่าเชื่อมการเรียก REST service แล้วแมป data point เข้ากับการแสดงผลของวิดเจ็ต น่าจะช่วยจัดการความต้องการเว็บภายในที่ทุกบริษัทมีในปัจจุบันได้มากทีเดียว
เว็บเพจ 90–95% ต้องการ ทางแก้แบบเรียบง่าย จริง ๆ
บางทีก็สงสัยว่านี่อาจเป็นแก่นแท้ของ GUI หรือเปล่า คือโครงสร้างที่ต้องสั่งทุกอย่างทีละอย่าง กินรอบการประมวลผลจำนวนมาก และถ้าไม่ทำแบบนั้นก็จะทำงานข้ามแพลตฟอร์มไม่ได้
articleกับsectionแล้วก็ตามแน่นอนว่าโค้ด HTML ดิบ ๆ ก็คงไม่ได้ถูกออกแบบมาให้คนอื่นนอกจากนักพัฒนาอ่านตั้งแต่แรกอยู่แล้ว เรื่องนี้ก็มีส่วนเหมือนกัน
ตื่นเต้นมากตอนรู้ว่ามี modal แบบ HTML ล้วนแล้ว แต่ก็ผิดหวังเมื่อรู้ว่าไม่มีวิธี trigger โดยไม่ใช้ JavaScript HTML ล้วนทำได้แค่ปิด แต่เปิดไม่ได้
https://github.com/whatwg/html/issues/3567
element
dialogเป็นการเพิ่มที่ยอดเยี่ยม และดีใจที่มีการ implement แล้ว แต่ฟังก์ชันหลักบางส่วนยังพึ่ง JavaScript ถ้าจะเปิดdialogต้องตั้งค่า attributeopenด้วย JavaScriptถ้ามีวิธีให้ element
buttonหรือaเปิดกล่องโต้ตอบได้ก็คงดี HTML มีแบบอย่างของการโต้ตอบในหน้าเว็บที่ฝังมาอยู่แล้ว เช่น link สามารถเลื่อนหน้าได้ และ elementdetailsสามารถซ่อน element ไว้หลังการโต้ตอบได้ ดังนั้นถ้า element อื่นในหน้าจะเปิดdialogได้ก็ดูเป็นธรรมชาติเช่น ลองคลิก
?มุมขวาบนที่นี่: https://aavi.xyz/proj/colors/onclickได้ด้วย