CSS: ส่วนแย่ ๆ ที่เลี่ยงไม่พ้น

 (matklad.github.io)
2 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การจัดสไตล์หน้าเว็บ สำหรับบล็อกธรรมดาหรือ GUI แบบง่าย ๆ ใช้เพียงชุดย่อยเล็ก ๆ ที่เรียนรู้ได้ก็พอ แต่กับดักอย่าง ค่าตั้งต้นของเบราว์เซอร์ และเลย์เอาต์ อาจนำไปสู่การดีบักหลายวัน
  • หากใช้แท็ก HTML5 เชิงความหมายก่อนและลด wrapper ลง จะทำให้เขียน CSS ให้ทำงานเข้ากับมาร์กอัปที่มีอยู่ได้ง่ายขึ้น
  • CSS layout ไม่มีอัลกอริทึมสากลแบบเดียวที่ใช้ได้ทุกกรณี และต้องใช้แนวทางที่เข้าใจว่าระบบแต่ละแบบอนุญาตให้จัดวางอะไรได้บ้าง
  • box-sizing, margin, font-size, line-height, word-break ทำงานไม่ตรงกับสัญชาตญาณ และการเปลี่ยนแปลงเล็กน้อยอาจลุกลามเป็นปัญหากับการจัดวางทั้งหน้า หรือความสามารถในการอ่านได้
  • สำหรับหน้าเว็บเรียบง่าย CSS reset, classless CSS, flexbox และกฎ responsive ที่ไม่มากเกินไป อาจเป็นจุดเริ่มต้นที่ใช้งานได้จริง

ขอบเขตของการเรียน CSS และมุมมองพื้นฐาน

  • CSS, HTML และ Web API มีขนาดใหญ่มากจนต้องอาศัยความเชี่ยวชาญ แต่สำหรับงานอย่างบล็อกโปรแกรมมิงหรือ GUI แบบง่าย ๆ ชุดย่อยที่เหมาะสมของเว็บยุคปัจจุบันก็เพียงพอแล้ว
  • ยังไม่เคยเจอแหล่งข้อมูลที่สอนเฉพาะชุดย่อยที่จำเป็นสำหรับงานง่าย ๆ แต่พอไล่ตาม MDN ก็จับภาพรวมได้ระดับหนึ่ง
  • ปัญหาคือมีหลุมพรางที่คาดไม่ถึงซึ่งทำให้หน้าเว็บพัง และอาจต้องใช้เวลาหลายวันกว่าจะหาสาเหตุเจอ
  • สไตล์ของเว็บไซต์นี้ประกอบด้วย CSS ที่อ่านรู้เรื่องราว 200 บรรทัด โดยประมาณ

ส่วนที่ดี: HTML เชิงความหมายและ classless CSS

  • แท็กเชิงความหมายของ HTML5

    • คุ้มค่าที่จะไล่ดู Elements Reference ของ MDN และจำนวน element ใน HTML ก็ไม่ได้เยอะมาก
    • แท็กอย่าง main, article, nav, kbd ช่วยให้จัดโครงสร้างหน้าทำได้ง่ายขึ้น
    • ul ใช้ได้กับรายการแทบทุกชนิด เช่น ส่วนต่าง ๆ ของเว็บไซต์ภายใน header > nav
    • details ใช้ทำสารบัญได้ และสามารถดูซอร์สจาก MDN ได้
    • dl และ dt ใช้กับรายการที่เป็นคู่กันได้

  • แนวทางลด wrapper

    • หากดูซอร์สของเว็บไซต์จริง จะเห็น element wrapper ซ้อนกันหลายชั้น จนอาจดูเหมือนว่าเลย์เอาต์ถูกแก้ด้วย wrapper
    • ยังขอไม่ตัดสินจากประสบการณ์กับ CSS ระดับโปรดักชัน แต่การจำกัดตัวเองให้ใช้แค่แท็กเชิงความหมาย แล้วค่อยหา CSS ที่เข้ากับมาร์กอัปนั้น กลับเข้าใจง่ายกว่า

  • Classless CSS

    • ไม่สามารถรีเซ็ตสไตล์ให้เป็นสถานะ “ไม่มีอะไรเลย” ที่เป็นกลางอย่างสมบูรณ์ได้ เพราะแม้แต่ข้อความสีขาวหรือโปร่งใสก็ยังถือว่าเป็นสไตล์
    • หลังจากรีเซ็ตแล้ว ก็สามารถจัดสไตล์ให้ element HTML ทั่วไปได้โดยตรง
    • หากใช้แท็ก main, header, footer, nav ก็สามารถกำหนดเลย์เอาต์ทั้งหน้าได้โดยไม่ต้องใช้ CSS selector มากนัก
    • วิธีนี้ทำให้ CSS ตั้งสมมติฐานกับโครงสร้าง HTML แต่ถ้าเป็น HTML และ CSS ของตัวเอง ก็ยังเปลี่ยนได้เมื่อไม่พอใจกับผลลัพธ์

ส่วนแย่: เลย์เอาต์, ค่าตั้งต้นของเบราว์เซอร์, selector

  • เลย์เอาต์

    • ปัญหาเลย์เอาต์ไม่ใช่เรื่องเฉพาะของเว็บ แต่เป็นปัญหาที่ยากใน GUI framework หลายตัว
    • วิธีวางภาพ raster ขนาดคงที่กับย่อหน้าข้อความอธิบายลงในกรอบสี่เหลี่ยมของหน้าจอ มีได้หลายแบบ
    • GUI ทั่วไปคือโครงสร้างแบบลำดับชั้นของกล่องที่มี “อิสระในการจัดเลย์เอาต์” จำนวนมาก
    • เลย์เอาต์ของแต่ละกล่องส่งผลต่อเลย์เอาต์ของกล่องอื่นทั้งหมด และโดยปกติทุกกล่องควรแนบกันพอดีโดยไม่มีช่องว่างหรือการซ้อนทับ
    • ไม่มีอัลกอริทึมเลย์เอาต์สากลเพียงแบบเดียว แต่ละระบบใช้ heuristic ต่างกัน ตั้งแต่ RectCut ไปจนถึง constraint solvers และ พื้นที่ตรงกลาง ระหว่างสองแบบนั้น
    • แทนที่จะคิดว่า “จะสร้างเลย์เอาต์ในระบบนี้อย่างไร” ควรคิดว่า “เลย์เอาต์แบบไหนที่ระบบนี้อนุญาต”

  • ค่าตั้งต้นของเบราว์เซอร์และ CSS reset

    • แม้เป็น HTML เชิงความหมายที่ไม่มี CSS เบราว์เซอร์ก็ยังใช้สไตล์ตั้งต้น เช่น สี ฟอนต์ ขนาด หัวเรื่องใหญ่ ลิงก์มีขีดเส้นใต้
    • สไตล์ตั้งต้นมีประโยชน์ แต่แต่ละเบราว์เซอร์ต่างกัน และถ้าพึ่งค่าตั้งต้นที่เราไม่ได้เขียนเอง ก็อาจเห็นผลลัพธ์ต่างกันในเบราว์เซอร์อื่น
    • วิธีแก้ทั่วไปคือ CSS reset หรือ normalization ซึ่งเป็นการเขียนกฎแบบ explicit ไว้ต้นไฟล์ CSS เพื่อทับค่าตั้งต้น
    • ปัญหาไม่ใช่ว่าค่าตั้งต้นนั้นแย่ แต่คือมันไม่สอดคล้องกัน
    • ในทางปฏิบัติ ควรเทียบ CSS reset หลายแบบที่มีอยู่เพื่อดูว่าควร override กฎใดบ้าง

  • ควรจัดสไตล์หน้าเว็บหรือไม่

    • แพลตฟอร์มเว็บมีทั้งมุมมองที่เห็นว่าเป็นสื่อภาพที่ยืดหยุ่นและปรับตัวได้ กับมุมมองที่เน้นการส่งต่อเนื้อหาและให้ผู้ใช้ปรับแต่งการแสดงผลเอง
    • โดยปกติ หน้าเว็บที่ไม่มีสไตล์จะใช้งานยากและดูไม่ดี
    • โลกที่หน้าไม่มี CSS แต่ยังอ่านง่ายได้เลยคงจะดีกว่า แต่ในสภาพแวดล้อมปัจจุบัน การใส่สไตล์ให้เนื้อหายังมีประโยชน์
    • ควรเปิดให้ผู้ใช้ขั้นสูงนำ CSS ของตัวเองมาใช้ได้
    • มาร์กอัป HTML ควรสมเหตุสมผล ไม่ควรทำให้ HTML overfit กับ CSS และหน้าเว็บควรใช้ได้ใน reader mode

  • CSS selector

    • CSS พื้นฐานทำงานคล้ายการสืบทอดที่ทรงพลัง โดยองค์ประกอบการออกแบบแต่ละจุดของหน้าอาจได้รับผลจากหลายกฎพร้อมกัน
    • เราสามารถ “monkey patch” element เดิมได้ตลอดเวลาเพียงแค่เติมกฎต่อท้ายในไฟล์ CSS
    • มองว่า CSS selector เป็นการเพิ่มความสามารถในการทำ abstraction บนแกนที่ไม่ค่อยถูกต้อง จึงมีแนวทางที่ใช้ classless CSS กับ inline style แทนได้
    • เครื่องมืออย่าง Tailwind ช่วยลดความไม่สะดวกของการเขียนแบบ inline และ template engine ที่รองรับ JSX หรือ composition ก็ช่วยลด HTML ที่ซ้ำซ้อนได้
    • การใช้ CSS nesting ช่วยลด selector ที่พุ่งไกลเกินไป และจัดสไตล์ในระดับคอมโพเนนต์ได้

โมเดลกล่องและการจัดวาง: box-sizing, margin, flow พื้นฐาน, flexbox

  • box-sizing

    • UI คือสี่เหลี่ยมที่ซ้อนแบบ recursive และเลย์เอาต์คือกระบวนการกำหนดว่าสี่เหลี่ยมแต่ละอันจะอยู่ตรงไหน
    • ในค่าตั้งต้นของ HTML ค่า width และ height ของ element ไม่รวม border กับ padding จึงไม่ค่อยตรงกับสัญชาตญาณ
    • หากเพิ่ม padding ตรงจุดหนึ่ง เลย์เอาต์ทั้งหน้าที่เคยดูสมบูรณ์ในตอนแรกอาจถูกดันเสียรูปแบบอย่างไม่คาดคิด
    • * { box-sizing: border-box; } เหมาะจะเป็นบรรทัดแรกของ CSS reset และทำให้การเพิ่ม border เป็นการเปลี่ยนแปลงเฉพาะจุด

  • margin collapsing

    • ถ้าต้องการระยะห่าง 8px รอบ element บางตัว การใช้ padding อาจทำให้ช่องว่างระหว่าง element ที่ติดกันสองตัวกลายเป็น 16px
    • margin ทำงานโดยรวม margin ของเพื่อนบ้านสองตัวด้วย max แทนการบวกเข้าด้วยกัน
    • margin collapsing มีประโยชน์มาก แต่ก็สร้างพฤติกรรมที่น่าประหลาดใจได้
    • มีมุมมองว่า margin ของลูกอาจทะลุออกไปนอก parent ได้ แต่ความเข้าใจเชิงสัญชาตญาณเกี่ยวกับ margin ก็ยังไม่แน่นพอ
    • บทความของ Julia Evans Moving away from Tailwind, and learning to structure my CSS กล่าวถึงแนวทาง owl selector ที่โดยทั่วไปให้ parent ควบคุม margin ระหว่างลูก แทนการใส่ margin ลงบน element เอง
    • วิธีเพิ่ม margin ให้กับลูกทุกตัวของ section ยกเว้นลูกตัวแรก เข้าใจได้ว่าเป็นไอเดียที่ช่วยลดปัญหา margin
    • ความน่าหงุดหงิดคือความรู้แบบนี้เรียนรู้ได้ยาก หากไม่ได้เป็นนักพัฒนาเว็บมืออาชีพหรือแกะ CSS framework อื่นย้อนกลับ

  • เลย์เอาต์ flow พื้นฐาน

    • อัลกอริทึมเลย์เอาต์พื้นฐานมีที่มาจากรากฐานของ HTML ในฐานะภาษาสำหรับเอกสาร และดูเหมือนจะเหมาะกับกรณีการสร้างเอกสารกระดาษที่มีข้อความและภาพเป็นหลัก
    • สำหรับข้อความเนื้อหา flow พื้นฐานทำงานใกล้เคียงกับสิ่งที่ต้องการจริง
    • แต่ถ้าต้องการควบคุมการจัดวางพื้นที่ของ element บนหน้าโดยตรง ก็ต้องใช้วิธีอื่นที่ไม่ใช่ flow พื้นฐาน

  • flexbox

    • flexbox คือเลย์เอาต์สำหรับวางชุดของ element ในแนวตั้งหรือแนวนอน และปรับตัวตามพื้นที่ที่มี
    • ในอดีต แม้แต่การจัดวางอย่าง “อันนี้อยู่ซ้าย อันนั้นอยู่ขวา” ก็ยังต้องใช้ความรู้ CSS ลึกมาก หรือพึ่ง CSS framework ที่ไม่โปร่งใส
    • flexbox ค่อนข้างซับซ้อนจนยังต้องเปิด MDN ดูเรื่อย ๆ แต่โดยรวมก็พอทำสิ่งที่ต้องการได้สำเร็จ

  • การออกแบบแบบ responsive

    • CSS สมัยใหม่สามารถตรวจสอบขนาดหน้าจอและใส่เงื่อนไขตามข้อจำกัดของ user agent ได้
    • HTML มีความเป็น responsive โดยธรรมชาติ ต่างจาก PostScript หรือ PDF ตรงที่เมื่อขนาดหน้าต่างเปลี่ยน ย่อหน้าจะ reflow ใหม่เองโดยอัตโนมัติ
    • ควรหลีกเลี่ยงกฎ responsive แบบ explicit และปล่อยให้เลย์เอาต์ทำงานอย่างสมเหตุสมผลเอง
    • บล็อกนี้ดูใช้ได้ทั้งบนมือถือ แท็บเล็ต และเดสก์ท็อป โดยไม่มี @media query แบบ explicit
    • แค่ตั้ง max-width ให้คอลัมน์หลักของข้อความเนื้อหาก็เพียงพอแล้ว

ขนาดและข้อความ: พิกเซล, ฟอนต์, line-height, การตัดคำ

  • พิกเซล

    • 1px ทำงานได้ตามที่ต้องการ แต่ไม่ได้หมายถึงพิกเซลจริงหนึ่งจุดของหน้าจอ
    • 1px ใน CSS เป็นหน่วยของ มุมการมองเห็น และถูกออกแบบให้ดูคล้ายกันในเชิงการรับรู้บนทุกหน้าจอ
    • มันถูกแปลงเป็นจำนวนพิกเซลจริงที่ต่างกันตามขนาดหน้าจอ ความหนาแน่นพิกเซล และระยะการมองปกติ
    • ดังนั้นจึงสามารถกำหนดทุกขนาดเป็นพิกเซลได้โดยไม่ต้องคิดเรื่องความหนาแน่นพิกเซลของจอแต่ละแบบแยกต่างหาก
    • หน่วย “จริง” อย่างเซนติเมตรและนิ้วใน CSS ก็ถูกนิยามโดยอิงจากพิกเซล จึงทำงานคล้ายหน่วยเชิงมุม

  • font-size

    • ใน font-size: 16px ค่่า 16px ไม่ใช่ขนาดของ glyph โดยตรง แต่เป็นขนาดของกล่องเสมือนรอบ glyph
    • กล่องนี้ไม่ได้พอดีกับ glyph และขนาด glyph จริงจะแตกต่างกันไปตามฟอนต์
    • font-size-adjust สามารถช่วยให้ font-size สอดคล้องกันมากขึ้นระหว่างฟอนต์ต่าง ๆ
    • ตอนนี้ font-size-adjust ดูเหมือนเป็นฟีเจอร์เฉพาะทางมาก และโดยส่วนตัวอยากวาง font-size-adjust: ex-height 0.53; ไว้ข้าง box-sizing แต่มีหน้าเว็บน้อยมากที่ทำแบบนั้น
    • ค่าตั้งต้นของ font-size ค่อนข้างสอดคล้องกันระหว่างเบราว์เซอร์ โดย 16px เป็นค่าหลักแบบท่วมท้น
    • แต่ 16px อาจดูเล็กได้ขึ้นอยู่กับฟอนต์ และฟอนต์ตั้งต้นบางตัวก็เล็กเป็นพิเศษ
    • บน Apple, font-family: serif ดูเล็กกว่า sans-serif มาก และที่ 16px แทบอ่านไม่สบาย
    • เมื่อกำหนด font-size ใน CSS จะเป็นการปิดการทำงานของกลไกเปลี่ยนขนาดฟอนต์ตั้งต้นของเบราว์เซอร์
    • อย่าสมมติว่าข้อความจะอ่านง่ายโดยอัตโนมัติในค่าตั้งต้น ต้องตรวจสอบกับการตั้งค่าอื่นด้วย
    • หากใช้ font-size-adjust เพื่อลดอิสระและตรึงความหมายของ font-size แล้วดูโอเคกับขนาดฟอนต์ตั้งต้น 16px ก็ถือว่าเสร็จ
    • ถ้าไม่โอเค ก็ควรตั้ง font-size ให้ใหญ่ขึ้น แล้วตรวจอีกทีว่ายังอ่านง่ายใน reader mode หรือไม่

  • line-height

    • แม้ชื่อจะเป็นแบบนั้น แต่ line-height ไม่ได้กำหนดความสูงของหนึ่งบรรทัดโดยตรง
    • line-height คือความสูงของกลุ่ม glyph ที่ตั้งค่าด้วยฟอนต์เดียวกัน
    • ถ้าข้อความทั้งหมดใช้ฟอนต์เดียว ความสูงบรรทัดกับความสูงของกลุ่ม glyph จะตรงกัน
    • แต่ถ้ามีบางคำถูกตั้งเป็นฟอนต์ monospace ก็อาจเกิดผลลัพธ์ที่ต่างจากคาด
    • font-size-adjust ช่วยแก้ขนาด glyph ภายในกล่อง แต่ไม่ได้กำหนดตำแหน่งสัมพัทธ์ของมันไปด้วย
    • เมื่อกลุ่มข้อความจากฟอนต์ต่างกันถูกจัดแนวตั้งให้แชร์ baseline เดียวกัน line-height line-box ของแต่ละกลุ่มจะเหลื่อมกัน
    • ความสูงรวมของบรรทัดอาจเกิดจากการรวมกันแบบสหภาพ และสูงกว่าที่คาดไว้
    • ผลกระทบนี้อธิบายไว้อย่างละเอียดใน Deep dive CSS: font metrics, line-height and vertical-align

  • vertical rhythm

    • vertical rhythm คือแนวคิดที่ทำให้ตำแหน่งบรรทัดระหว่างย่อหน้าสัมพันธ์กันเหมือนเดิม แม้จะมีหัวเรื่อง รูปภาพ ฯลฯ แทรกอยู่
    • มักอธิบายว่าเป็นการจัดให้เหมือนมีเส้นบรรทัดจาง ๆ อยู่ด้านหลังหน้าเว็บ
    • มองว่าไม่ค่อยมีประโยชน์กับเลย์เอาต์แบบคอลัมน์เดียว
    • แต่ในเลย์เอาต์สองคอลัมน์ อาจอยากให้บรรทัดสองฝั่งตรงกัน
    • สำหรับคอลัมน์เดียว การทุ่มความซับซ้อนเพื่อสิ่งนี้ดูไม่ค่อยสมเหตุสมผล

  • word-break

    • ข้อดีของ flow layout คือเมื่อหน้าต่างแคบลง ข้อความจะถูกแบ่งเป็นบรรทัดได้อย่างสวยงามแบบไดนามิก
    • แต่บรรทัดจะตัดได้เฉพาะที่ว่างหรือจุดที่ใส่ hyphen ได้เท่านั้น
    • ส่วนที่ยาวอย่าง inline code หรือ URL อาจไม่ถูกตัดเลย
    • ปัญหานี้ทำให้เกิด horizontal overflow บนอุปกรณ์มือถือ และมักรู้ตัวหลังเผยแพร่ไปแล้ว
    • ไม่มีวิธีวิเศษเพียงข้อเดียวในการแก้ แต่ Against Horizontal Scroll มีเคล็ดลับอยู่หลายข้อ

บทสรุปเชิงปฏิบัติ

  • สำหรับการทำบล็อกเรียบง่าย ควรมีแหล่งข้อมูลที่อธิบายเฉพาะส่วนของ HTML และ CSS ที่เพียงพอแบบกระชับ
  • ปิดท้ายด้วยการขอหนังสือสั้น ๆ สัก 100 หน้า ที่อธิบาย HTML และ CSS ได้พอสำหรับทำบล็อกง่าย ๆ โดยไม่พังเพราะปัญหาอย่าง margin collapsing

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

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

 
GN⁺ 5 시간 전
ความคิดเห็นจาก Lobste.rs

  • เป็นข้อทักท้วงเล็กน้อย แต่คำนิยามของ responsive design คือ “การทำให้เรนเดอร์ได้ดีบนอุปกรณ์และขนาดหน้าต่าง/หน้าจอที่หลากหลาย เพื่อคงการใช้งานและความพึงพอใจ”
    media query หรือ container query เป็นเพียงหนึ่งในเครื่องมือที่ใช้ทำสิ่งนี้เท่านั้น และ responsive design ใกล้เคียงกับวิธีคิดมากกว่าความหมายแบบ “ใช้ media query กับทุกอย่าง”
    ดังนั้นสิ่งที่ “แย่” จึงไม่น่าใช่ responsive design เอง แต่ควรเป็น media query หรือ การใช้ breakpoint มากเกินไป มากกว่า

  • ส่วน “Browser defaults” ชวนให้เข้าใจผิดพอสมควร reset stylesheet กับ normalize stylesheet มีจุดประสงค์และการทำงานต่างกันมาก แต่ในบทความพูดปะปนกัน
    reset ไม่ได้มีไว้เพื่อลบความต่างระหว่างเบราว์เซอร์เป็นหลัก แต่เพื่อลบความต่างตั้งต้นระหว่าง element เช่น padding-inline-start ของ ol หรือหน้าตาพื้นฐานของ button เพื่อให้สร้างสไตล์จากกระดาษเปล่าแทนที่จะต่อยอดจาก user agent stylesheet
    ส่วน normalize เป็นแนวทางที่พยายามทำงานร่วมกับ user agent stylesheet โดยมีทั้งส่วนที่ปรับความต่างระหว่างเบราว์เซอร์ และส่วนที่เปลี่ยนเป็นค่าเริ่มต้นที่มองว่า “สมเหตุสมผลกว่า” ปะปนกันอยู่
    ทุกวันนี้ค่าเริ่มต้นของเบราว์เซอร์แทบไม่มีอะไรต่างกันอย่างมีนัยสำคัญแล้ว ดังนั้นคนเขียนเว็บคอนเทนต์ทั่วไปแทบจะมองข้ามได้ ข้อยกเว้นคือ Chromium has the wrong table border-color, WebKit fixed theirs 1½ years ago, ความต่างของระยะขอบ/ขนาดใน form element บางตัว, appearance, และการจัดสไตล์ <summary> ::marker ของ WebKit
    อีกทั้งยังไม่เห็นด้วยกับ box-sizing: border-box ด้วย border-box เน้น layout ขณะที่ content-box เน้น content จึงมองว่าดีกว่าถ้าให้ parent เป็นคนรับผิดชอบ layout และออกแบบบนฐานของ content เมื่อจัดการสัดส่วนจะต้องใช้ content-box และกรณีที่ border-box มีประโยชน์จริง ๆ ก็ประมาณการทำให้ body เติมเต็ม viewport
    สำหรับ font-size-adjust ก็ยังค่อนข้างกังขา มันเป็นการแทนปัญหาที่รู้จักกันดีด้วยปัญหาที่ผ่านการพิสูจน์น้อยกว่า ซึ่งอาจดีขึ้นเล็กน้อยสำหรับบางคนแต่แย่ลงเล็กน้อยสำหรับอีกบางคน มันแก้ปัญหารากฐานไม่ได้ และบังคับให้ตั้งสมมติฐานเรื่องสัดส่วนและ metric ของฟอนต์ผู้ใช้โดยไม่มีหลักรองรับ
    ประเด็น line-height กับคำว่า “ตั้งเป็นฟอนต์เดียวกัน” ก็ไม่แม่นยำนัก ในความเป็นจริงมันมีทั้งขนาดฟอนต์ การสลับภาษา font-family: monospace, vertical-align, <sup>, <sub>, และ metric ของฟอนต์เข้ามาเกี่ยว จึงยากจะมองว่าเป็นแค่ปัญหาเรื่องฟอนต์เดียวกัน
    margin collapsing ซับซ้อนกว่าที่บทความว่าไว้ แต่ก็ใช้งานได้จริงมากพอสมควร ถ้าใช้ flex หรือ grid กับคอนเทนต์ทั่วไป ก็ต้องคอยปรับ gap หรือ margin อยู่เรื่อย ๆ จนเปราะบางได้ง่าย การใช้ display: flow-root จะช่วยกันไม่ให้ margin ของลูกไปรวมกับ margin ของ parent
    แม้จะไม่เห็นด้วยกับภาพรวมใหญ่เรื่อง responsive design แต่แนวทางที่พยายามลด media query ที่ไม่จำเป็นและไม่ไปสู้กับเบราว์เซอร์นั้นถูกต้อง ถ้าสามารถอธิบายการเปลี่ยน layout โดยยึดจาก content ได้ โดยมากก็จะดีกว่า
    ช่วงหลังมักใช้ การอินเตอร์โพเลตเชิงเส้นด้วย clamp โดยอาศัย viewport unit: margin-inline: --vw-lerp(1rem at 20rem, 2.5rem at 60rem); แล้วขยายเป็น margin-inline: clamp(1rem,1rem + ((2.5 - 1)/(60 - 20)*(100vw - 20rem)),2.5rem);
    ปีที่แล้วได้ implemented this as a LightningCSS visitor ทำให้เมื่อ viewport ต่ำกว่า 20rem จะเป็น 1rem จากนั้นค่อย ๆ เพิ่มอย่างนุ่มนวลจนถึง 2.5rem ที่ 60rem แล้วหยุด โดยไม่ต้องมี breakpoint และยังตอบสนองต่อขนาดฟอนต์ของผู้ใช้ด้วย จึงให้ความรู้สึกที่ดี

    • ไม่แน่ใจว่า font-size-adjust ทำงานแบบนั้นหรือเปล่า ชื่อมันทำให้งง แต่ผมเข้าใจว่า font-size เปลี่ยนขนาด em box ส่วน font-size-adjust เปลี่ยน ขนาด glyph ภายใน em box
      ดังนั้น em กับ rem จะยังเท่าเดิม แต่ ch จะเปลี่ยน ซึ่ง ch เดิมทีก็ขึ้นกับฟอนต์อยู่แล้ว จึงถือว่าเปลี่ยนก็ถูกต้อง
      อยากให้มีคนเขียนเรื่อง font-size-adjust โดยเฉพาะ ไม่ใช่ผู้เชี่ยวชาญเลยจึงไม่ค่อยมั่นใจ แต่เท่าที่เห็นจนถึงตอนนี้มันแทบไม่เป็นที่รู้จัก ทั้งที่ดูเหมือนเป็น การปรับปรุงครั้งใหญ่ มาก แม้จะทำให้ฟอนต์สองชุดเข้ากันได้อัตโนมัติในทุกบริบทไม่ได้ แต่แค่ปรับให้ขนาด x ตรงกันแทนที่จะยึด em box ก็ดูจะครอบคลุมฟอนต์/บริบทได้ 90%

  • ใจความของบทความดี และมุมมองจากคนที่ไม่ได้จมอยู่กับ HTML/CSS แบบเต็มตัวก็สำคัญ แต่หลายสิ่งที่ถูกเรียกว่า “แย่” นั้นอาจดีได้ขึ้นกับบริบท
    CSS selector ใช้เกินเลยได้ง่าย แต่ไม่ได้แย่โดยเนื้อแท้ แทนที่จะสรุปแบบ A หรือ B อาจกำหนดกฎ/selector ทั่วไปไว้ แล้วค่อยโปรยคลาสแบบอิงข้อยกเว้นหรือ utility class เมื่อจำเป็น
    ในบทความเองก็มีตัวอย่าง selector ที่ดีอยู่:

    section > *+* {  
  margin-top: 1rem;  
}

    media query เองก็อาจไม่จำเป็น ถ้าแก้ได้ด้วย container queries
    CSS อาจให้ความรู้สึกว่ามีพื้นที่ผิวมหาศาล แต่เพราะมันถูกใช้แพร่หลายและทำอะไรได้มาก จึงมีความเห็นที่ขัดแย้งกันบ่อย ถึงอย่างนั้นก็ควรมองด้วยว่า CSS พัฒนาไปไกลแค่ไหนแล้ว และเมื่อยอมรับแนวคิดต่าง ๆ ได้ ก็ทำอะไรได้มากด้วยโค้ดที่ค่อนข้างน้อย
    ถ้าอยากเรียนเพิ่ม https://every-layout.dev/ ช่วยให้เข้าใจได้ดีทีเดียวว่าองค์ประกอบต่าง ๆ ใน CSS ทำงานเข้าหากันอย่างไร

    • ขอสนับสนุนคำแนะนำ Every Layout อีกเสียง ผมก็ยังไม่ได้ชอบ CSS อยู่ดี และโดยส่วนตัวยังคิดว่า cascade มีปัญหาในเชิงโมเดล layout แบบพื้นฐาน แต่ตอนนี้มันก็ทำให้ดูใช้ได้และ responsive ได้พอสมควรแล้วทั้งบนเดสก์ท็อปและมือถือ
      จุดที่เริ่มเข้าใจ web layout จริง ๆ คือเมื่อได้ตระหนักว่าเว็บไซต์ที่ดีนั้นโดยพื้นฐานแล้วเป็น การออกแบบแนวตั้ง element ควรถูกซ้อนเรียงจากบนลงล่างเป็นค่าเริ่มต้น และควรออกแบบหน้าจอมือถือก่อน แล้วค่อยขยายสำหรับหน้าจอใหญ่เป็นโบนัส

  • เห็นด้วยกับข้ออ้างนี้ได้ยาก CSS nesting เป็นแค่ syntactic sugar และไม่ได้ช่วยหลีกเลี่ยงปัญหา selector ที่เฉพาะเจาะจงเกินไปอย่างมีนัยสำคัญ
    เมื่อ 15 ปีก่อนก็ใช้การซ้อน selector ใน Sass กันเยอะมาก และสุดท้ายก็ค่อย ๆ ได้ข้อสรุปร่วมกันว่า มันเท่ากับเอา CSS selector ไปผูกกับโครงสร้าง HTML แน่นเกินไปจนเข้ามัดขาตัวเอง
    กับดักของ nesting มักยังไม่แสดงตัวชัดในช่วงต้นของโปรเจกต์ ในระยะ greenfield ที่ส่วนใหญ่กำลังสร้างฟีเจอร์ใหม่ การเขียน CSS แบบนี้ดูดีมาก
    แต่พออีกไม่กี่เดือนต่อมาเริ่มแก้ layout ครั้งใหญ่และรีดีไซน์ องค์ประกอบ wrapper ใน HTML ก็ย้ายตำแหน่งกันไปหมด และการปรับ CSS ให้ตามทันจะให้ความรู้สึกเหมือนกิน LSD แล้วพยายามแก้ Rubik's Cube
    คิดว่าจุดสูงสุดของการจัดการ selector specificity คือการกดให้ส่วนใหญ่เป็น selector แบบง่าย ๆ คือมีแค่คลาสเดียว แล้วใช้ selector แบบผสมหรือ combinator selector อย่าง a:hover แค่เล็กน้อย นี่คือสาย BEM, OOCSS และหลังจากนั้นความสนใจก็ย้ายไปหาเครื่องมือฝั่ง JS อย่างรวดเร็ว

  • เป็นบทความที่น่าสนใจ แต่ดูเหมือนผู้เขียนจะใช้ nested selector ใน ตำแหน่งที่แทบไม่มีประโยชน์

    header { /* Site Header */  
  margin-bottom: 2rem;  
  & nav { /* ampersand redundant here? */  
    /* Styles, specific to nav in the Header. */  
  }  
}
    • บางคนมองว่าการเปิดให้ละ & ได้เป็นความผิดพลาด และเลยใช้ & ตลอดเวลา ซึ่งก็เป็นจุดยืนที่สมเหตุสมผลพอควร
      ส่วนตัวผมยังสองจิตสองใจ ตอนแรกก็คิดว่าเป็นความผิดพลาด แต่ในกรณีที่เขียนสไตล์ไปกองหนึ่งแล้ว แค่ครอบด้วย header { … } ก็ทำให้ขอบเขตแคบลงได้ มันก็สะดวกดี อยากให้ at-rule ที่ไม่ได้อิงกับ selector อย่าง @keyframes เขียนข้างในนั้นได้ด้วย

  • อันนี้พูดตรง ๆ ว่าเป็นคำแนะนำที่แย่มาก ผมชอบงานเขียนของ Maklad นะ แต่ชิ้นนี้ดูชัดเจนว่าเขียนโดย คนที่ไม่เคยใช้ CSS แบบมืออาชีพ
    แทบทั้งหมดเป็น bad practice แบบสมัครเล่นที่คนเขียน CSS ระดับมืออาชีพหลีกเลี่ยงกัน

    • ถ้าจะอธิบายให้ชัดขึ้น สำหรับมือสมัครเล่น สิ่งที่ต้องออกแบบหลัก ๆ คือ content box CMS จะปล่อยพวกย่อหน้า การเน้นข้อความ ลิงก์ รายการ ออกมา แล้วเวลาส่วนใหญ่ก็หมดไปกับการจัดสไตล์สิ่งเหล่านั้น
      พอจัดสไตล์สิ่งพวกนี้โดยไม่ใช้ selector ก็เลยไปแต่ง <main> หรือ <nav> แบบไม่ใช้ selector ด้วย
      แต่ในงานระดับมืออาชีพ เวลาที่ใช้กับการออกแบบ content box มีน้อยมาก ทำครั้งหนึ่งช่วงต้นโปรเจกต์ แล้วหลังจากนั้นก็แค่ค่อย ๆ แก้บั๊กเล็ก ๆ
      เวลาส่วนใหญ่หมดไปกับการสร้าง custom component หรือ reusable component ซึ่ง reusable component นั้นยากกว่า และในทางปฏิบัติก็เหมือนกำลังสร้าง Bootstrap เวอร์ชันเฉพาะของไซต์นั้นเอง
      ส่วน custom component นั้นง่ายกว่า แต่โค้ดจะเยอะขึ้น และต้องมีกลยุทธ์อย่าง BEM, OOCSS, utility class แบบ Tailwind ฯลฯ เพื่อไม่ให้มันไปรบกวน component อื่นโดยไม่ตั้งใจ
      สรุปคือแต่ละเทคนิคเหมาะกับ ขนาด งานที่ต่างกัน ถ้าวิธีเขียน CSS แบบมืออาชีพดูเหมือนไร้ประโยชน์ ก็อาจเป็นเพราะคุณกำลังแก้ปัญหาคนละสเกลกันอยู่
    • ในบทความก็พูดไว้ตรง ๆ ว่า “ไม่เคยเขียน production CSS มาก่อน”
      ถึงอย่างนั้นก็เห็นด้วยกับ Bad: Wrappers เคยเห็นทั้งคนที่เป็นผู้เชี่ยวชาญ CSS เขียนทั้งเว็บไซต์ไว้ในไฟล์เดียวหรือสองไฟล์ และคนที่ใช้ CSS ปริมาณมหาศาล
      เส้นทางแบบหลังมักลงเอยด้วยการใช้แนวทางที่ ผิดทาง อย่าง BEM เพื่อมาจัดการ CSS จำนวนมาก

  • ดูเหมือนในบทความจะมีคำแนะนำที่ขัดกันเอง
    มีทั้ง Good: Classless CSS และ Bad: CSS selectors แต่ถ้าจะใช้ classless CSS ก็ยิ่งต้องพึ่ง CSS selector มากขึ้น
    ดูเพิ่ม: https://www.keithcirkel.co.uk/css-classes-considered-harmful/

  • แนวคิด vertical rhythm แบบ “เหมือนมีสมุดบรรทัดล่องหนอยู่หลังหน้าเว็บ” ทำได้สบายด้วยค่า EM
    ถ้าผสมฟอนต์หลายแบบเข้าด้วยกัน มันอาจแกว่งนิดหน่อยเพราะ metric ของฟอนต์ต่างกัน แต่ถึงตอนนั้นก็ยังใช้ align-items: baseline ของ flex ได้