เทคนิคแฮ็ก HTML ที่หล่อหลอมอินเทอร์เน็ต
(tedium.co)- นักพัฒนาเว็บยุคแรกพบว่าแต่ละเบราว์เซอร์มี การใช้งานตามมาตรฐานและข้อบกพร่อง ต่างกัน จึงยากที่จะรับประกันเลย์เอาต์และพฤติกรรมที่ต้องการได้อย่างเสถียรด้วย HTML/CSS ที่ถูกต้องตามมาตรฐานเพียงอย่างเดียว
- สภาพแวดล้อมอย่าง Netscape 4, Internet Explorer 5/6/7, Safari/WebKit และ Outlook ทำให้เกิด โค้ดเลี่ยงปัญหาเฉพาะเบราว์เซอร์ ในเรื่อง CSS, ความโปร่งใสของ PNG, คอมเมนต์, selector และพรีวิวอีเมล
- HTML table layout, sIFR, Chrome Frame และ responsive design เป็นตัวอย่างของการนำสิ่งต่าง ๆ มาผสมกันในแบบที่ต่างจากเจตนาเดิม เพื่อก้าวข้าม ข้อจำกัดด้านการออกแบบ และปัญหาเบราว์เซอร์รุ่นเก่า
- การแฮ็กเหล่านี้มีข้อจำกัด เช่น ทำให้การเข้าถึงลดลง โค้ดไม่เป็นมาตรฐาน และพึ่งพา Flash/ปลั๊กอิน แต่ในเวลานั้นถือเป็นวิธีที่ใช้งานได้จริงเพื่อให้ได้ความเข้ากันได้และการแสดงผลทางภาพ
- อุดมคติของมาตรฐานเว็บกับวิธีใช้งานจริงปะทะกันมาโดยตลอด และการเลี่ยงปัญหาซ้ำ ๆ ของนักพัฒนาและนักออกแบบก็ทิ้งอิทธิพลยาวนานต่อเว็บดีไซน์, HTML สำหรับอีเมล และวิธีรองรับมือถือ
การแฮ็ก CSS เพื่อหลบข้อบกพร่องของเบราว์เซอร์
- การแฮ็ก
@importของ Netscape Navigator 4.0 คือวิธีจงใจโหลด CSS ที่ Netscape รองรับไม่ได้ผ่าน@importเพื่อกันไม่ให้เบราว์เซอร์นั้นใช้ สไตล์ขั้นสูง- โครงสร้างคือโหลด CSS พื้นฐานด้วย
<link>และแยก CSS ที่ก้าวหน้ากว่าไปโหลดด้วย@import - CSS Cookbook อธิบายว่าวิธีนี้มีผลเหมือนกับการโหลดไฟล์ CSS ที่ไม่ทำงานใน Netscape แยกเข้ามาด้วย
- Netscape ผลักดัน JSSS แทน CSS และหลังจาก W3C เลือก CSS แล้ว Netscape ก็รีบใช้งาน CSS ใน Netscape 4 ช่วงฤดูร้อนปี 1997
- ใน Netscape 4 หากปิด JavaScript ก็จะมีผลข้างเคียงคือ CSS ถูกปิดไปด้วย
- โครงสร้างคือโหลด CSS พื้นฐานด้วย
- การแฮ็ก CSS สำหรับ Internet Explorer 6 คือการใส่ ขีดล่าง หน้า property เช่น
_widthเพื่อให้มีเพียง IE6 เท่านั้นที่ตีความ declaration นั้น- โมเดลกล่องของ W3C มองว่า
widthไม่รวม border และ padding แต่ Internet Explorer จัดการ padding และ border ต่างออกไป ทำให้เกิดความต่างของเลย์เอาต์ระหว่างเบราว์เซอร์ - ตัวอย่างคือการใช้ declaration ที่ไม่ถูกต้องตาม CSS มาตรฐาน เช่น
width: 300px; _width: 320px; padding: 10px;เป็นค่าปรับแก้สำหรับ IE6 - ยังมีการแฮ็กเฉพาะ IE แบบอื่น เช่น ใส่เครื่องหมายอัศเจรีย์เพิ่มอีกหนึ่งตัวหลัง
!importantเพื่อให้ทำงานต่างออกไปเฉพาะ IE7 ลงไป
- โมเดลกล่องของ W3C มองว่า
บิดโครงสร้างเชิงความหมายเพื่อเลย์เอาต์
- HTML table layout เป็นการแฮ็กตัวแทนที่นำ
<table>ซึ่งเดิมมีไว้แสดง ข้อมูลแบบตาราง มาใช้เป็นเครื่องมือจัดวางหน้าทางสายตา- David Siegel เข้าหาเว็บจากมุมมองของนักออกแบบดั้งเดิม และพยายามสร้างเว็บไซต์ที่ดูดีกว่าเดิม โดยฝืนแนวปฏิบัติที่ปล่อยให้เบราว์เซอร์เป็นผู้กำหนดผลลัพธ์ทางภาพของ HTML
- ใน Creating Killer Web Sites เขาพูดถึงการเลี่ยง structural markup, ใช้รูปภาพสร้างการจัดวางสองมิติ และเมื่อ table ปรากฏขึ้นก็ใช้วิธีใส่ข้อความลงในคอลัมน์
- Jay Hoffman จาก The History of the Web สรุปว่านักบริสุทธิ์นิยม HTML/XML มองการผสมการออกแบบเข้ากับโครงสร้างโค้ดว่าเป็นข้อห้ามสำคัญ
- Table layout ทำให้การเข้าถึงเสียหายและต้องใช้เวลาฟื้นฟู แต่ก็แสดงให้เห็นคุณค่าที่นักพัฒนาสามารถจัดองค์ประกอบเว็บพอร์ทัลในเชิงภาพได้
- Responsive design คล้ายกับ table layout ตรงที่นำเทคโนโลยีเดิมมาผสมในวิธีใหม่ แต่เป็นวิธีเปลี่ยนเลย์เอาต์ให้เข้ากับขนาดหน้าจอ ภายในขอบเขตของมาตรฐานเว็บ
- ในเว็บดีไซน์ช่วงทศวรรษ 2000 การทำ “Holy Grail layout” ที่คอลัมน์ 3 แถวลากยาวไปถึงท้ายหน้าให้สำเร็จด้วย CSS เป็นประเด็นถกเถียงใหญ่
- มีวิธีเลี่ยงหลายแบบ เช่น สร้างคอลัมน์ปลอมด้วยภาพพื้นหลัง และต่อมา CSS ก็รองรับเลย์เอาต์แบบ grid
- เมื่อสมาร์ตโฟนแพร่หลาย ความหมายของเลย์เอาต์ 3 คอลัมน์แบบเดิมก็ลดลง และเกิดสถานการณ์ที่ต้องใช้เงินทำเว็บไซต์มือถือแยกต่างหาก
- Ethan Marcotte เสนอวิธีใช้ media query เพื่อปรับการจัดวางเว็บไซต์ให้เข้ากับรูปแบบหน้าจอในบทความ responsive web design ของ A List Apart
- Responsive design ในเวลานั้นดูเหมือนการแฮ็กที่ใช้ media query ซึ่งยังไม่คุ้นเคย แต่ได้เปลี่ยนเว็บดีไซน์ในระยะยาว
รูปภาพและคอมเมนต์แบบเลี่ยงปัญหาในยุค Internet Explorer
AlphaImageLoaderเลี่ยงปัญหาที่ Internet Explorer 5 และ 6 ไม่รองรับความโปร่งใสของ PNG อย่างถูกต้องด้วยฟิลเตอร์เฉพาะของ Microsoft- Internet Explorer รองรับ PNG ตั้งแต่เวอร์ชัน 4 แต่ในหลายกรณีก็เรนเดอร์ได้ไม่ถูกต้อง และปัญหาใหญ่เป็นพิเศษคือ IE5/IE6 ไม่รองรับ PNG โปร่งใส
- Jeff Starr จาก Perishable Press กล่าวไว้ใน PNG fix for Internet Explorer ว่าโซลูชันในเวลานั้นต้องใช้ฟิลเตอร์ความโปร่งใส AlphaImageLoader เฉพาะของ Microsoft
- ตัวอย่างคือใช้
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(...)กับ IE และใช้ selector[class]เพื่อใส่ภาพพื้นหลังปกติให้เบราว์เซอร์ที่ไม่ใช่ IE - ช่องว่างเล็ก ๆ ของฟีเจอร์เช่นนี้ทำให้นักพัฒนาในช่วงปลายทศวรรษ 2000 และต้นทศวรรษ 2010 ยังต้องคำนึงถึงการแฮ็กเฉพาะเบราว์เซอร์ต่อไป
- Conditional Comments คือ ส่วนขยายคอมเมนต์ HTML ที่ Microsoft สร้างขึ้นเพื่อให้ตัดสินใจได้ว่าจะเรนเดอร์ HTML บางส่วนตามเวอร์ชัน IE หรือไม่
- เมื่อ Internet Explorer ต้องใช้การแฮ็กมากเกินไปในการทำเว็บไซต์ Microsoft จึงนำการแฮ็กอีกแบบหนึ่งเข้ามาเพื่อจัดการการแฮ็กเหล่านั้น
- คอมเมนต์ HTML ซึ่งเดิมไม่ได้มีไว้สำหรับการทำงาน ถูกเปลี่ยนเป็นโครงสร้างที่ทำงานตามเงื่อนไขเวอร์ชัน IE
- เริ่มถูกนำมาใช้ครั้งแรกใน Internet Explorer 5 และในงานออกแบบอีเมลที่ซับซ้อนสำหรับ Microsoft Outlook บน Windows ก็ยังมีกรณีที่จำเป็นต้องใช้
- Jens Oliver Meiert วิจารณ์ไว้ในบทความปี 2007 ว่า conditional comments ทำให้ต้องปรับ HTML ของแต่ละเอกสารหรือเทมเพลตใหม่เมื่อต้องรองรับเวอร์ชัน IE จึงบั่นทอนการแยกโครงสร้างออกจากการนำเสนอ
- Conditional comments ถูกนำออกหลัง IE9 และ conditional compilation ของ JavaScript สามารถใช้เป็นทางเลือกได้
การผสมแบบไม่เป็นมาตรฐานเพื่อฟอนต์ อีเมล และเบราว์เซอร์รุ่นเก่า
- sIFR (Scalable Inman Flash Replacement) เป็นการแฮ็กบน JavaScript ที่เปลี่ยนข้อความเป็น Flash embed เพื่อแสดงฟอนต์ที่ต้องการโดยไม่ถูกจำกัดอยู่กับ web-safe fonts
- Core Fonts for the Web ของ Microsoft ในทางปฏิบัติแล้วสนับสนุนให้ใช้ web-safe fonts ชุดจำกัด และต่อมาก็ถูกยุติ
- เทคนิคทดแทนฟอนต์ยุคแรกเริ่มจากการใช้รูปภาพ แต่มีข้อจำกัดด้านการเข้าถึงและการแสดงผล
- Shaun Inman คิดไอเดียแทนที่ฟอนต์ที่ต้องการด้วยไฟล์ Adobe Flash ขนาดเล็ก และ Mike Davidson ทำให้ฟอนต์ขยายตามความจำเป็นผ่าน sIFR
- Davidson มองไว้ในบทความเปิดตัว sIFR ปี 2004 ว่าปัญหาการส่งแบบอักษร custom ที่ผู้ใช้ไม่ได้ติดตั้งยังไม่ได้รับการแก้ไข
- sIFR เป็นขั้นตอนกลางระหว่างทางไปสู่โซลูชัน web fonts จริง และอยู่ได้ไม่นานเมื่อ Flash ไม่สามารถย้ายไปสู่มือถือได้
- การแฮ็ก preheader text คือวิธีใส่ อักขระซ่อนและอักขระช่องว่าง เพื่อป้องกันไม่ให้บรรทัดพรีวิวของอีเมลไคลเอนต์ดึงข้อความเนื้อหาถัดไปที่ไม่ต้องการมาต่อท้าย
- Preheader คือข้อความสั้น ๆ ที่ปรากฏต่อจากหัวเรื่องในกล่องจดหมายอีเมล และทำหน้าที่คล้ายหัวเรื่องรองของอีเมล
- เนื่องจากอีเมลไคลเอนต์อาจดึงแท็ก HTML หรือเนื้อหาที่ไม่เกี่ยวข้องมาแสดงเป็นพรีวิว จึงต้องแทรกช่องว่างแบบบังคับระหว่าง preheader ที่ตั้งใจไว้กับข้อความถัดไป
- ตัวอย่างที่ Litmus แนะนำ คือการใส่อักขระอย่าง
͏,,,,ซ้ำ ๆ ลงในพื้นที่ที่ใช้display: none,max-height: 0px,overflow: hidden
- Google Chrome Frame เป็นปลั๊กอินเบราว์เซอร์ที่ทำให้ใช้เอนจินเรนเดอร์ของ Chrome ภายใน Internet Explorer ได้ เพื่อให้ใช้ ฟีเจอร์เว็บสมัยใหม่ ได้แม้ในสภาพแวดล้อมที่พึ่งพา IE6
- บางองค์กรย้ายไปยังเบราว์เซอร์สมัยใหม่ได้ยาก เพราะมีฝ่าย IT ที่เข้มงวดและพึ่งพาเทคโนโลยีฐาน IE6
- Google สร้าง Chrome Frame ในปี 2009 เพื่อมอบเอนจินสมัยใหม่ให้ Internet Explorer รุ่นเก่า และช่วยให้นักพัฒนาไม่ต้องทำหลายเวอร์ชันหรือยอมทิ้งฟีเจอร์ใหม่
- ตามบทความประกาศเลิกใช้ Chrome Frame ในเวลานั้นผู้ใช้จำนวนมากยังใช้เบราว์เซอร์ที่ตามหลังฟีเจอร์ล่าสุด
- เครื่องมืออย่าง Google Wave และ YouTube ต้องการฟีเจอร์ HTML5 และการรองรับ IE6 ก็เป็นข้อจำกัดสำหรับ Google
- Chrome Frame อยู่ในตลาดเป็นเวลา 5 ปี และหลังจากช่วงเวลานั้น Chrome ก็กลายเป็นเบราว์เซอร์ที่ครองตลาดอย่างมาก
การรองรับเฉพาะ Safari/WebKit และวิวัฒนาการจริงของเว็บ
- การแฮ็ก selector เฉพาะ WebKit คือวิธีใช้การรองรับ CSS เฉพาะเบราว์เซอร์ เช่น
@supports (-webkit-appearance:none) {}เพื่อให้ใช้ CSS เฉพาะกับเบราว์เซอร์ ตระกูล WebKit เท่านั้น- เมื่อ Safari เปิดตัวครั้งแรก มันมีพื้นฐานจากเอนจินที่มีรากในชุมชนโอเพนซอร์ส และช่วงแรกก็รองรับมาตรฐาน HTML/CSS ได้แข็งแกร่ง
- Apple Mail ใช้ WebKit จึงถูกมองว่าเป็นสภาพแวดล้อมที่โดยทั่วไปทำงานได้ดีในการเขียนโค้ดอีเมล
- เมื่อเวลาผ่านไป ตารางการปล่อย Safari ผูกกับตารางของ Mac และ iOS ทำให้เกิดปัญหาตามหลังอุตสาหกรรม
- นักพัฒนาวิจารณ์ว่า Apple เพิกเฉยต่อบั๊กหรือชะลอฟีเจอร์ที่เสียเปรียบในการแข่งขัน
- ผู้ใช้ Reddit รายหนึ่งเขียนไว้ในโพสต์บ่นเรื่องการพัฒนา Safari ว่าแม้จะ implement API แล้วก็ยังมีบั๊กมาก หรือพังในภายหลัง
- การแฮ็กนี้ยังทำงานกับ Chrome รุ่นแรก ๆ ที่เริ่มต้นจากฐาน WebKit ด้วย
- เจตนาของ HTML กับวิธีใช้งานเว็บจริงต่างกันอย่างมาก และนักออกแบบกับผู้เชี่ยวชาญ UI ได้สร้าง การแสดงออกทางภาพ ขึ้นบนอินเทอร์เน็ต แม้ต้องใช้โค้ดประหลาดก็ตาม
- ตามคำอธิบายของ David Siegel องค์กรมาตรฐานต้องการให้ HTML ทำงานในแบบที่ให้ความสำคัญกับผู้ใช้และโครงสร้างมากกว่าดีไซน์สุดท้าย คล้าย RSS
- โปรโตคอลอย่าง Gopher ที่เกิดขึ้นในช่วงเดียวกันก็ทำงานในแบบที่ไม่ได้รับอิทธิพลจากการออกแบบมากนัก
- แต่ด้วยความสร้างสรรค์ของผู้ใช้อินเทอร์เน็ตและการพึ่งพาภาษาภาพของอินเทอร์เน็ตเชิงพาณิชย์ ปรัชญานั้นจึงไม่กลายเป็นกระแสหลัก
- ใน HTML สำหรับอีเมล แม้แต่การทำกราเดียนต์โปร่งใสที่ง่ายด้วย HTML/CSS มาตรฐานก็ยังทำได้ยาก และการเลี่ยงปัญหาอย่าง glitch ของ HTML table ในคอมเมนต์ StackOverflow เก่า ๆ ก็ยังอาจเป็นวิธีแก้ได้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
การใช้ตารางสำหรับเลย์เอาต์ก็พอเข้าใจได้อยู่
แต่หลังจากตารางตกกระแสไป หลายปีต่อมาก็แทบมีแต่การจัดเลย์เอาต์ด้วย float เท่านั้น ยุคนั้นแหละที่โหดจริง เลยแปลกใจที่ไม่อยู่ในลิสต์
https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
“พร็อพเพอร์ตี float ซึ่งเดิมทีมีไว้เพื่อทำให้รูปภาพลอยอยู่ภายในบล็อกข้อความ กลายเป็นหนึ่งในเครื่องมือที่ถูกใช้บ่อยที่สุดในการสร้างเลย์เอาต์หลายคอลัมน์ของเว็บเพจ พอ flexbox และ grid ปรากฏขึ้น ตอนนี้มันจึงกลับไปสู่จุดประสงค์เดิมแล้ว”
พอใกล้เสร็จแล้วเปิดดูใน IE ดีไซน์ทั้งหน้าพังหมด และกลุ่มลูกค้าเป้าหมายแทบจะแน่นอนว่าเป็นคนใช้ IE สุดท้ายเลยต้องเขียนใหม่เป็นแบบอิงตาราง เป็นวันที่เศร้าจริง ๆ
หลังจากตารางถูกดันออกไป ผมเห็นทีมฟรอนต์เอนด์จำนวนมากเสียเวลาสะสมกันเป็นเดือน ๆ ไปกับลูกเล่น float เพื่อรักษาความเชื่อของพวก “เพียวริสต์” และสร้างเว็บเพจที่เข้าใจยากกว่ามาก จากตรงนั้นได้บทเรียนสำคัญเลย
Joel Spolsky เคยเรียกนักพัฒนาแบบนั้นไว้ในบทความยอดเยี่ยมว่า Architecture Astronauts คือประเภทที่ลืมไปว่างานของตัวเองคือการสร้างซอฟต์แวร์ที่ใช้งานได้จริงด้วยความพยายามให้น้อยที่สุด ผมมองว่าความน่าขันของสเปก EJB รุ่นแรก หรือ AbstractFactoryBuilderConstructor อันเป็นที่ล้อเลียนใน Java ก็เป็นผลงานของคนจำพวกนั้นเช่นกัน
เมื่อเวลาผ่านไป ผมเลยค่อนข้างมองแนวโน้มแบบนี้ออกและถอยห่างจากมัน
https://en.wikipedia.org/wiki/Holy_grail_(web_design)#Faux_c...
.clearfix::after { content: ""; clear: both; display: table; }[1] https://www.w3schools.com/howto/howto_css_clearfix.asp
float ใช้ยากและจัดให้เข้าที่ได้ลำบาก หลายคนเลยกลับไปใช้ตารางเฉย ๆ ซึ่งพูดตรง ๆ ก็โทษไม่ได้
spacer.gif ไม่สมควรได้รับความเคารพบ้างเหรอ?
แน่นอนว่าใน HN ยังมีอยู่ และถูกใส่ไปกับทุกคำขอหน้าเว็บ
https://news.ycombinator.com/s.gif
มีอยู่หลายอย่างที่เคยชอบ
Faux columns ทำให้ดูเหมือนยืดในเชิงภาพ จนไซด์บาร์ดูยาวเท่ากับเนื้อหาหลัก: https://alistapart.com/article/fauxcolumns/
ไปไกลกว่านั้น ยังใช้ 9-patch กับ div 9 ตัว หรือ ตาราง 3x3 เพื่อทำซ้ำพื้นหลังในแต่ละแกนและจำลองเส้นขอบเองได้ด้วย CSS3 มี border-image ขึ้นมาก็ช่วยได้บ้าง แต่สไตล์เส้นขอบแบบนี้เดี๋ยวนี้ไม่ค่อยเป็นที่นิยมแล้ว
มุมโค้งก็ทำด้วย 9-patch ได้ และหลายคนใช้ตัวสร้างเพื่อสร้างหลายองค์ประกอบ แล้วผลิต HTML ที่จำลองมุมโค้ง บทความนี้อธิบายไว้: http://benogle.com/2009/04/29/css-round-corners.html โดยทั่วไปมาร์กอัปที่เพิ่มเข้ามาจะมีจำนวนไบต์มากกว่ารูปภาพ แต่ตอนนั้นมองกันว่าลดจำนวนรอบการร้องขอได้ และทำได้ค่อนข้างง่าย
แม้จะใกล้กับฝั่ง ActionScript มากกว่า แต่ไอเดียเรื่องสไตลิงเหมือนกัน เลยเขียนบทความไว้ด้วย: https://brajeshwar.com/2005/splice9-bitmap-window-resizer-co...
อีกอย่างที่ชอบคือวิธีใช้ cicada principle กับแพตเทิร์นสไตล์พื้นหลังที่ไม่ซ้ำกัน
ถึงอย่างนั้น ผ่านมานานขนาดนี้แล้วก็ยังดูสะอาดตาอยู่
ชอบที่ HN ยังใช้หนึ่งในนี้อยู่จนถึงทุกวันนี้: จัดเลย์เอาต์ด้วยตาราง HTML
ถ้ามองจริงจังกว่านั้น รายการนี้แสดงให้เห็นได้ดีว่าเมื่อพัฒนาโดยไม่มีมาตรฐาน ข้อมูลควบคุมจะถูกเข้ารหัสไว้ในช่องทางข้างเคียงหลายแบบที่ “พอทนได้”
ความสับสนและความเป็นไปได้ที่จะชนกันแบบนี้ทำให้ต้องกลับมามองกระบวนการ W3C ที่บางครั้งถูกดูแคลนเสียใหม่ กระบวนการนี้ผสานวิวัฒนาการเทคโนโลยีเว็บที่ขับเคลื่อนด้วยมาตรฐานเข้ากับนวัตกรรมที่ขับเคลื่อนด้วยเบราว์เซอร์ และปล่อยให้ทั้งสองผลัดกันนำหน้าหรือเดินคู่กันไป
แม้จะถูกล้อเลียนบ่อย ๆ แต่ก็อาจตีความได้ว่าเป็นวิธีที่ยั่งยืนและเสถียรกว่าวิธีเดิม
สงสัยว่าคนที่โจมตี บรรทัดฐานใหม่ระหว่าง W3C กับผู้ขาย จะมีสักกี่คนที่อยากกลับไปสู่ยุคคึกคักที่ “10 แฮ็กประหลาด” เหล่านี้ทำให้นึกถึง
ถ้าสิ่งที่อยากทำไม่ได้ถูกครอบคลุมเป็นฟีเจอร์ ผู้คนก็จะหาทางทำอย่างสร้างสรรค์จนได้ มาตรฐานถ้าไม่สุกงอมพอที่จะจับความต้องการที่อาจเกิดขึ้นทั้งหมดได้ กลับจะสร้างความแข็งตัวและนำไปสู่สถานการณ์แบบนี้ โดยเฉพาะกรณีที่ถูกผูกไว้กับมาตรฐานซึ่งอาจตรงหรือไม่ตรงกับความต้องการก็ได้ อย่างเช่นเว็บ
ในสาขาอื่น ๆ โดยทั่วไปมีตัวเลือกมากพอ และหนึ่งในนั้นก็มักยืดหยุ่นพอที่จะทำงานที่ต้องการได้ ก็แค่เลือกมัน
ถ้าทำงานสายวิจัยมานาน จะพบอย่างน่าประหลาดใจว่าหลายครั้งสิ่งที่อยากทำต้องอาศัยแนวทางเทคนิคแบบแฮ็ก ๆ เพราะมาตรฐานและชุดฟีเจอร์จำนวนมากเกิดขึ้นโดยมีปฏิสัมพันธ์ทางธุรกิจ/ผู้บริโภคที่มีเงินไหลเวียน และระบบรอบ ๆ เป็นศูนย์กลาง
ผู้เล่นจำนวนมากที่พึ่งพาฟีเจอร์ของเบราว์เซอร์ เช่น ผู้ผลิตทีวีที่รันแอปใน WebKit หรือ Chromium เวอร์ชันใดเวอร์ชันหนึ่ง เงียบสนิทในคณะกรรมการมาตรฐาน ดังนั้นในทางปฏิบัติยังไม่ถึงขั้นเป็นการชักเย่อสามฝ่ายระหว่าง Google, Apple, Mozilla ด้วยซ้ำ
สุดท้ายก็ได้ตารางที่อยู่ใน div เพียงแต่เป็นแบบ 12 คอลัมน์เท่านั้น
เพราะผมเรียนมาด้วย HTML 3.2 จึงรู้ดีว่าต้องใช้ความบ้าบอแบบไบแซนไทน์อะไรบ้างเพราะ IE และ Netscape แต่นั่นเป็นทางเลือกของ MS กับ Netscape และแม้ W3C จะมีตัวตนมากกว่านี้ ก็ไม่มีหลักประกันหรือสัญญาณว่า MS กับ Netscape จะทำตามมาตรฐานใหม่
ถึงอย่างนั้นยุคนั้นก็ยังดีกว่าสถานการณ์ขยะ ๆ แบบตอนนี้ที่ถ้าบริษัทใหญ่รายหนึ่งต้องการ เว็บที่เหลือก็ต้องรับภาระ
ดีขึ้นมากจริง ๆ นะ ดีจัง /s
แฮ็กที่ “ชอบที่สุด” ของผมหายไป นั่นคือวิธีเอา หัวข้อสำหรับการเข้าถึง ไปวางไว้ที่ตำแหน่ง
-10000เพื่อไม่ให้เรนเดอร์บนหน้าจอ แต่ให้ screen reader อ่านได้อย่าง
aria-labelเข้ามาแทนการใช้งานบางส่วนของแพตเทิร์นนี้ได้ แต่ไม่ใช่ทั้งหมดไม่มีเรื่อง html5 shiv ที่เคยติดตั้งก่อน CSS ทั้งหมดเพื่อกำจัด quirks ของเบราว์เซอร์
https://paulirish.com/2011/the-history-of-the-html5-shiv/
คิดถึงวันเก่า ๆ อันแสนดีของ GIF โปร่งใส 1×1 พิกเซล ที่ใช้ทำให้เซลล์ตารางอยู่นิ่ง ๆ
https://news.ycombinator.com/item?id=38485665
จำไม่ได้แล้วว่าทำไปทำไม เพื่อให้โหลดเร็วขึ้นหรือเปล่า?
ถ้าจะเพิ่มอีกอย่างจากยุคแรก ๆ ก็คือ การใช้เอนทิตีอักขระช่องว่างไม่ตัดบรรทัด
อย่างแพร่หลายใช้ดันข้อความไปทางขวาหรือซ้ายภายในคอนเทนเนอร์ และเท่าที่จำได้ บางทีก็ใช้เหมือน GIF spacer 1x1 เพื่อทำให้เซลล์ตารางอยู่นิ่ง ๆ บางหน้ามี
เป็นร้อย ๆ ตัว และแทบจะเป็นวิธีสารพัดประโยชน์ในการใส่ margin หรือ paddingบางครั้งก็ไม่รู้ว่านักพัฒนาเว็บยุคใหม่เสียนิสัยเพราะมี CSS Grid และ IE ตายไปแล้ว หรือว่าเราในตอนนั้นต่างหากที่เสียนิสัยเพราะไม่ต้องเจอความซับซ้อนของเฟรมเวิร์กสมัยใหม่กับกระบวนการ build
แต่ทุกวันนี้น่าจะง่ายกว่าจริง ๆ เพราะในเชิงเทคนิคไม่จำเป็นต้องใช้เฟรมเวิร์กสมัยใหม่หรือกระบวนการ build ก็ได้ และด้วย CSS กับ JavaScript สมัยใหม่ ก็สร้างไซต์และแอปที่เมื่อก่อนซับซ้อนได้อย่างง่ายดาย
อุตสาหกรรมนี้ติดนิสัยประดิษฐ์ล้อขึ้นใหม่เรื่อย ๆ ในรูปแบบที่ซับซ้อนกว่าเดิม
ข้อสันนิษฐานที่ดูเป็นไปได้ที่สุดคือเป็นผลข้างเคียงจากการที่เว็บเป็นสายงานที่นักพัฒนาใหม่หรือมีประสบการณ์น้อยเลือกบ่อยกว่า
Responsive design นี่เป็นแฮ็กจริงหรือ? media query ยอดเยี่ยมมาก
การเอา conditional logic ไว้ใน CSS แทนที่จะใส่ใน JavaScript ถือเป็นชัยชนะครั้งใหญ่ โดยเฉพาะเมื่ออยากทำ server-side rendering
คุณสามารถ query คุณลักษณะหลายอย่างของ user agent แล้วส่ง CSS ที่ต่างกันตามผลลัพธ์ได้ การเรียกสิ่งนี้ว่าแฮ็กคือความไม่รู้ และมันเป็นส่วนที่จำเป็นในการสร้าง responsive design