2 คะแนน โดย GN⁺ 2023-12-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักพัฒนาเว็บยุคแรกพบว่าแต่ละเบราว์เซอร์มี การใช้งานตามมาตรฐานและข้อบกพร่อง ต่างกัน จึงยากที่จะรับประกันเลย์เอาต์และพฤติกรรมที่ต้องการได้อย่างเสถียรด้วย 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 สำหรับ 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 ลงไป

บิดโครงสร้างเชิงความหมายเพื่อเลย์เอาต์

  • 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 ความคิดเห็น

 
GN⁺ 2023-12-03
ความคิดเห็นจาก Hacker News
  • การใช้ตารางสำหรับเลย์เอาต์ก็พอเข้าใจได้อยู่
    แต่หลังจากตารางตกกระแสไป หลายปีต่อมาก็แทบมีแต่การจัดเลย์เอาต์ด้วย float เท่านั้น ยุคนั้นแหละที่โหดจริง เลยแปลกใจที่ไม่อยู่ในลิสต์
    https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
    “พร็อพเพอร์ตี float ซึ่งเดิมทีมีไว้เพื่อทำให้รูปภาพลอยอยู่ภายในบล็อกข้อความ กลายเป็นหนึ่งในเครื่องมือที่ถูกใช้บ่อยที่สุดในการสร้างเลย์เอาต์หลายคอลัมน์ของเว็บเพจ พอ flexbox และ grid ปรากฏขึ้น ตอนนี้มันจึงกลับไปสู่จุดประสงค์เดิมแล้ว”

    • ตอนที่ float เพิ่งออกมาใหม่ ๆ เคยพัฒนาเว็บซ่อมคอมพิวเตอร์ทั้งหมดใน FF
      พอใกล้เสร็จแล้วเปิดดูใน IE ดีไซน์ทั้งหน้าพังหมด และกลุ่มลูกค้าเป้าหมายแทบจะแน่นอนว่าเป็นคนใช้ IE สุดท้ายเลยต้องเขียนใหม่เป็นแบบอิงตาราง เป็นวันที่เศร้าจริง ๆ
    • แค่การเรียก เลย์เอาต์แบบอิงตาราง ว่าเป็นการแฮ็กตั้งแต่แรกก็รู้สึกไม่ดีแล้ว
      หลังจากตารางถูกดันออกไป ผมเห็นทีมฟรอนต์เอนด์จำนวนมากเสียเวลาสะสมกันเป็นเดือน ๆ ไปกับลูกเล่น float เพื่อรักษาความเชื่อของพวก “เพียวริสต์” และสร้างเว็บเพจที่เข้าใจยากกว่ามาก จากตรงนั้นได้บทเรียนสำคัญเลย
      Joel Spolsky เคยเรียกนักพัฒนาแบบนั้นไว้ในบทความยอดเยี่ยมว่า Architecture Astronauts คือประเภทที่ลืมไปว่างานของตัวเองคือการสร้างซอฟต์แวร์ที่ใช้งานได้จริงด้วยความพยายามให้น้อยที่สุด ผมมองว่าความน่าขันของสเปก EJB รุ่นแรก หรือ AbstractFactoryBuilderConstructor อันเป็นที่ล้อเลียนใน Java ก็เป็นผลงานของคนจำพวกนั้นเช่นกัน
      เมื่อเวลาผ่านไป ผมเลยค่อนข้างมองแนวโน้มแบบนี้ออกและถอยห่างจากมัน
    • ที่ว่า “หลายปีที่จัดเลย์เอาต์ด้วย float” นั้นถูกเรียกว่า faux columns และแม้แต่เลย์เอาต์ 3 คอลัมน์พื้นฐานก็ยากมากจนถูกเรียกว่า “จอกศักดิ์สิทธิ์” ของเลย์เอาต์เลยทีเดียว
      https://en.wikipedia.org/wiki/Holy_grail_(web_design)#Faux_c...
    • มันคือ clearfix hack แบบใหม่และทันสมัย ตามชื่อที่ W3Schools ยังเรียกอยู่
      .clearfix::after { content: ""; clear: both; display: table; }
      [1] https://www.w3schools.com/howto/howto_css_clearfix.asp
    • ยุคระหว่างตารางกับ flexbox/grid นั้นลำบากมาก
      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 โดยทั่วไปมาร์กอัปที่เพิ่มเข้ามาจะมีจำนวนไบต์มากกว่ารูปภาพ แต่ตอนนั้นมองกันว่าลดจำนวนรอบการร้องขอได้ และทำได้ค่อนข้างง่าย

    • ทีมเราใช้ วิธี 3x3 เยอะมากจนถึงขั้นทำคอมโพเนนต์สำหรับมันโดยเฉพาะ
      แม้จะใกล้กับฝั่ง ActionScript มากกว่า แต่ไอเดียเรื่องสไตลิงเหมือนกัน เลยเขียนบทความไว้ด้วย: https://brajeshwar.com/2005/splice9-bitmap-window-resizer-co...
      อีกอย่างที่ชอบคือวิธีใช้ cicada principle กับแพตเทิร์นสไตล์พื้นหลังที่ไม่ซ้ำกัน
    • ลองกดเข้า A List Apart แล้วค่อนข้างช็อกที่เฮดเดอร์บนมือถือพัง
      ถึงอย่างนั้น ผ่านมานานขนาดนี้แล้วก็ยังดูสะอาดตาอยู่
    • เทคนิค sliding doors สำหรับมุมโค้งก็ควรพูดถึงด้วย: https://alistapart.com/article/slidingdoors/
    • Faux columns ยังมีชีวิตอยู่บนเว็บไซต์หลักของเราเหมือนเดิม ไม่เคยมีเวลาพอจะเปลี่ยนเป็นอะไรที่ทันสมัยกว่านี้ ;)
  • ชอบที่ HN ยังใช้หนึ่งในนี้อยู่จนถึงทุกวันนี้: จัดเลย์เอาต์ด้วยตาราง HTML
    ถ้ามองจริงจังกว่านั้น รายการนี้แสดงให้เห็นได้ดีว่าเมื่อพัฒนาโดยไม่มีมาตรฐาน ข้อมูลควบคุมจะถูกเข้ารหัสไว้ในช่องทางข้างเคียงหลายแบบที่ “พอทนได้”
    ความสับสนและความเป็นไปได้ที่จะชนกันแบบนี้ทำให้ต้องกลับมามองกระบวนการ W3C ที่บางครั้งถูกดูแคลนเสียใหม่ กระบวนการนี้ผสานวิวัฒนาการเทคโนโลยีเว็บที่ขับเคลื่อนด้วยมาตรฐานเข้ากับนวัตกรรมที่ขับเคลื่อนด้วยเบราว์เซอร์ และปล่อยให้ทั้งสองผลัดกันนำหน้าหรือเดินคู่กันไป
    แม้จะถูกล้อเลียนบ่อย ๆ แต่ก็อาจตีความได้ว่าเป็นวิธีที่ยั่งยืนและเสถียรกว่าวิธีเดิม
    สงสัยว่าคนที่โจมตี บรรทัดฐานใหม่ระหว่าง W3C กับผู้ขาย จะมีสักกี่คนที่อยากกลับไปสู่ยุคคึกคักที่ “10 แฮ็กประหลาด” เหล่านี้ทำให้นึกถึง

    • นั่นน่าจะใกล้เคียงกับ การขาดฟีเจอร์ที่จำเป็น มากกว่าการขาดมาตรฐาน
      ถ้าสิ่งที่อยากทำไม่ได้ถูกครอบคลุมเป็นฟีเจอร์ ผู้คนก็จะหาทางทำอย่างสร้างสรรค์จนได้ มาตรฐานถ้าไม่สุกงอมพอที่จะจับความต้องการที่อาจเกิดขึ้นทั้งหมดได้ กลับจะสร้างความแข็งตัวและนำไปสู่สถานการณ์แบบนี้ โดยเฉพาะกรณีที่ถูกผูกไว้กับมาตรฐานซึ่งอาจตรงหรือไม่ตรงกับความต้องการก็ได้ อย่างเช่นเว็บ
      ในสาขาอื่น ๆ โดยทั่วไปมีตัวเลือกมากพอ และหนึ่งในนั้นก็มักยืดหยุ่นพอที่จะทำงานที่ต้องการได้ ก็แค่เลือกมัน
      ถ้าทำงานสายวิจัยมานาน จะพบอย่างน่าประหลาดใจว่าหลายครั้งสิ่งที่อยากทำต้องอาศัยแนวทางเทคนิคแบบแฮ็ก ๆ เพราะมาตรฐานและชุดฟีเจอร์จำนวนมากเกิดขึ้นโดยมีปฏิสัมพันธ์ทางธุรกิจ/ผู้บริโภคที่มีเงินไหลเวียน และระบบรอบ ๆ เป็นศูนย์กลาง
    • น่าเสียดายที่ทุกวันนี้ W3C และ TC39 ถูก Google ครอบงำอย่างสมบูรณ์ และผลักดันมาตรฐานจำนวนมากโดยแทบสนใจกระบวนการแค่ในเชิงพิธีการ
      ผู้เล่นจำนวนมากที่พึ่งพาฟีเจอร์ของเบราว์เซอร์ เช่น ผู้ผลิตทีวีที่รันแอปใน WebKit หรือ Chromium เวอร์ชันใดเวอร์ชันหนึ่ง เงียบสนิทในคณะกรรมการมาตรฐาน ดังนั้นในทางปฏิบัติยังไม่ถึงขั้นเป็นการชักเย่อสามฝ่ายระหว่าง Google, Apple, Mozilla ด้วยซ้ำ
    • ตลกดีที่บอกว่าตาราง “หายไป” แล้วถูกแทนที่อย่างแพร่หลายด้วย Bootstrap
      สุดท้ายก็ได้ตารางที่อยู่ใน div เพียงแต่เป็นแบบ 12 คอลัมน์เท่านั้น
    • WHATWG ไม่ได้พัฒนาเว็บเพื่อใครเลยนอกจากผลประโยชน์เชิงกำไร
      เพราะผมเรียนมาด้วย HTML 3.2 จึงรู้ดีว่าต้องใช้ความบ้าบอแบบไบแซนไทน์อะไรบ้างเพราะ IE และ Netscape แต่นั่นเป็นทางเลือกของ MS กับ Netscape และแม้ W3C จะมีตัวตนมากกว่านี้ ก็ไม่มีหลักประกันหรือสัญญาณว่า MS กับ Netscape จะทำตามมาตรฐานใหม่
      ถึงอย่างนั้นยุคนั้นก็ยังดีกว่าสถานการณ์ขยะ ๆ แบบตอนนี้ที่ถ้าบริษัทใหญ่รายหนึ่งต้องการ เว็บที่เหลือก็ต้องรับภาระ
      ดีขึ้นมากจริง ๆ นะ ดีจัง /s
  • แฮ็กที่ “ชอบที่สุด” ของผมหายไป นั่นคือวิธีเอา หัวข้อสำหรับการเข้าถึง ไปวางไว้ที่ตำแหน่ง -10000 เพื่อไม่ให้เรนเดอร์บนหน้าจอ แต่ให้ screen reader อ่านได้

    • วิธีนี้กับตัวแปรที่ใกล้เคียงกันยังค่อนข้างพบได้ทั่วไป เพราะยังไม่มีตัวเลือกที่ดีเยี่ยมสำหรับจัดการ ข้อความที่มองไม่เห็นแต่ screen reader เข้าถึงได้ ในทุกกรณี
      อย่าง aria-label เข้ามาแทนการใช้งานบางส่วนของแพตเทิร์นนี้ได้ แต่ไม่ใช่ทั้งหมด
    • ตอนนี้ยังใช้ได้อยู่ไหม? หรือควรใช้ ARIA?
  • ไม่มีเรื่อง html5 shiv ที่เคยติดตั้งก่อน CSS ทั้งหมดเพื่อกำจัด quirks ของเบราว์เซอร์
    https://paulirish.com/2011/the-history-of-the-html5-shiv/

    • ของอย่าง reset, normalize ก็หายไปด้วย
  • คิดถึงวันเก่า ๆ อันแสนดีของ 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

    • การใช้ media query เพื่อรองรับ สื่อ ที่แตกต่างกันดูเหมือนเป็น use case ที่ถูกต้องพอดี
    • ถ้าไม่ได้ query สิ่งที่อยากรู้จริง ๆ แต่ query สิ่งที่บังเอิญสัมพันธ์กับสิ่งที่ต้องการ นั่นแหละถึงจะเป็นแฮ็ก
    • ไม่ใช่แฮ็ก
      คุณสามารถ query คุณลักษณะหลายอย่างของ user agent แล้วส่ง CSS ที่ต่างกันตามผลลัพธ์ได้ การเรียกสิ่งนี้ว่าแฮ็กคือความไม่รู้ และมันเป็นส่วนที่จำเป็นในการสร้าง responsive design