ฟีเจอร์สมัยใหม่ของ HTML/CSS ที่หลายคนยังไม่ค่อยรู้จัก

• สาเหตุสำคัญของประสิทธิภาพเว็บไซต์ที่แย่ลงในช่วงหลังคือ การใช้ JavaScript มากเกินไป และสคริปต์ติดตามต่าง ๆ ซึ่งในหลายกรณีสามารถแทนที่ได้ด้วย HTML/CSS เพียงอย่างเดียว
• ฟีเจอร์ที่เพิ่งเพิ่มเข้ามาเมื่อไม่นานนี้ เช่น CSS nesting, relative colors, หน่วย viewport แบบใหม่ (lvh, svh, dvh) ช่วยให้แก้ปัญหาที่แต่ก่อนต้องพึ่งพา JS หรือ preprocessor ได้อย่างง่ายดาย
• CSS ไม่ใช่แค่เครื่องมือจัดสไตล์ธรรมดา แต่เป็นภาษาที่ทรงพลังซึ่งสามารถสร้างได้ตั้งแต่ แอนิเมชัน, การตรวจสอบข้อมูลนำเข้า, ธีม dark mode, ไปจนถึงเมนู accordion
• ในด้านประสิทธิภาพ CSS ยังทำงานด้วยการเร่งผ่าน GPU และทำงานบนเธรดแยก จึง ลื่นไหลและมีประสิทธิภาพกว่า JS สำหรับแอนิเมชันและเอฟเฟกต์เปลี่ยนผ่าน
• ผู้เขียนเน้นว่า CSS ไม่ได้เป็นเพียงเครื่องมือเชิงปฏิบัติ แต่ยังเป็น สื่อของการแสดงออกและศิลปะ และแนะนำให้นักพัฒนาเว็บใช้ศักยภาพของ CSS ยุคใหม่ให้มากขึ้น

---

บทนำ: ความซับซ้อนของเว็บ และความพยายามครั้งใหม่

• หลายเว็บไซต์กำลังเผชิญกับปัญหาประสิทธิภาพและความซับซ้อนจากการใช้ JavaScript framework มากเกินไป
  • แอป React ใช้เวลาหลายวินาทีในการโหลด และ NextJS ก็ก่อให้เกิด hydration error
  • โฟลเดอร์ node_modules กินพื้นที่หลายกิกะไบต์
• แม้ไม่มี JavaScript ก็ยังสามารถสร้างฟังก์ชันที่ทรงพลังได้ด้วย HTML และ CSS เพียงอย่างเดียว
  • นอกเหนือจากรถเข็นช็อปปิงของเว็บอีคอมเมิร์ซที่ซับซ้อนหรือแดชบอร์ดแล้ว JavaScript อาจไม่ได้จำเป็นเสมอไป
• บทความนี้แนะนำ ฟีเจอร์ใหม่ล่าสุด ของ CSS และชวนให้นักพัฒนาสำรวจความเป็นไปได้ที่หลากหลายโดยไม่ต้องพึ่งพา JavaScript เพียงอย่างเดียว

ความเข้าใจผิดและมุมมองต่อ CSS

CSS ยากและใช้งานลำบากจริงหรือ?

• มุมมองเชิงลบต่อ CSS มักเกิดจาก การเรียนรู้พื้นฐานไม่เพียงพอ
  • นักพัฒนาจำนวนมากข้ามพื้นฐานของ CSS แล้วไปโฟกัสที่ JavaScript หรือ TypeScript
  • CSS ไม่ใช่แค่เครื่องมือจัดสไตล์ธรรมดา แต่เป็น ภาษาเฉพาะทาง (domain-specific language) ที่มีความสามารถสูง
• CSS สามารถทำเลย์เอาต์ที่ซับซ้อนได้ง่ายด้วยเครื่องมืออย่าง flexbox
  • ตัวอย่าง: ใช้ display: flex และ justify-content: center เพื่อจัด div ให้อยู่กึ่งกลางได้อย่างง่ายดาย
  • เครื่องมือนักพัฒนา ของเบราว์เซอร์มีวิดเจ็ตสำหรับปรับคุณสมบัติ flexbox แบบมองเห็นได้
• หากเจาะลึกอยู่ฝั่งเดียวเท่านั้น (เช่น JS) และละเลย CSS ก็เป็นธรรมดาที่จะรู้สึกว่ามันเป็นภาระ

ความเจ็บปวดของการเขียน CSS และการเปลี่ยนแปลง

• ในอดีตการเขียน CSS ไม่ได้สะดวกนัก จึงเกิดเครื่องมืออย่าง Sass และ Tailwind ขึ้นมา
  • ตัวอย่าง: ต้องคอยจัดการ selector chain ที่ยาวอย่าง .post > .buttons .like:hover
• ช่วงหลังมีการเพิ่ม ฟีเจอร์ที่ช่วยยกระดับคุณภาพการเขียน (เช่น nesting) ทำให้พัฒนาได้สบายขึ้นด้วย CSS พื้นฐานเพียงอย่างเดียว
  • CSS nesting ช่วยรวมสไตล์ที่เกี่ยวข้องไว้ในที่เดียวและเพิ่มความอ่านง่าย
    • ตัวอย่าง: .post { & > .buttons { .like { &:hover { ... } } } }
    • ความสัมพันธ์ระหว่าง parent-child ชัดเจนขึ้น ทำให้ใช้ชื่อคลาสที่สั้นและเรียบง่ายได้
• relative colors ทำให้การปรับแต่งสีง่ายขึ้น
  • สามารถปรับความสว่างได้ด้วย hsl(from #123456 h s calc(l + 10))
  • ใช้ color-mix() เพื่อผสมสองสีและสร้างสีแบบไดนามิก
• ไวยากรณ์ช่วงของ media query ทำให้ตั้งเงื่อนไขที่เข้าใจง่ายอย่าง (width <= 768px) ได้
• หน่วย lh รองรับการจัดสไตล์ให้สอดคล้องกับความสูงบรรทัด
• พร็อพเพอร์ตี scrollbar-gutter ช่วยแก้ปัญหาเลย์เอาต์ขยับเพราะสกรอลล์บาร์
• Baseline ช่วยรับประกันความเข้ากันได้ของฟีเจอร์กับเบราว์เซอร์หลัก
  • newly available คือฟีเจอร์ที่ทำงานได้ในเบราว์เซอร์รุ่นล่าสุด
  • widely available คือรองรับไปถึงเบราว์เซอร์เมื่อ 2.5 ปีก่อน
  • ตัวอย่าง: CSS nesting ได้รับการรองรับจากทุกเบราว์เซอร์ตั้งแต่เดือนธันวาคม 2023

ทำไมจึงพัฒนาโดยใช้ CSS/HTML เท่านั้น?

• ผู้ใช้บางส่วน ปิดการทำงานของ JavaScript เป็นค่าเริ่มต้น (ด้วยเหตุผลด้านความปลอดภัย ความเป็นส่วนตัว ฯลฯ)
• หากให้บริการเว็บไซต์ด้วย CSS/HTML ล้วน ผู้ใช้เหล่านี้ก็มีโอกาสใช้งานเว็บไซต์ได้มากขึ้น
• ทั้งในมุมของนักพัฒนาและผู้ใช้ การใช้เพียง CSS/HTML มี ข้อดี มากในด้านความเร็ว การเข้าถึง และการใช้ CPU/แบตเตอรี่
  • CSS animation ทำงานบน compositor thread จึงลดภาระของ CPU
  • JavaScript ทำงานผ่าน event loop จึงอาจเกิดความหน่วงเล็กน้อยได้
• การเข้าถึง และ ความสะดวกในการใช้งาน ดีขึ้น
  • เอฟเฟกต์ hover ของปุ่ม, toast animation, การตรวจสอบข้อมูลนำเข้า ฯลฯ สามารถทำได้ง่ายด้วย CSS

ตัวอย่างการใช้งานจริงและฟีเจอร์สำคัญของ CSS

สร้างแอนิเมชันเริ่มต้นที่เป็นธรรมชาติด้วย @starting-style

• ก่อนหน้านี้การทำแอนิเมชันตอนองค์ประกอบปรากฏขึ้นต้องใช้โครงสร้างที่ซับซ้อน เช่น keyframes หรือ JS trigger
• การมาของ @starting-style ทำให้กำหนดสถานะเริ่มต้นได้ง่ายขึ้น และสร้างแอนิเมชันสถานะเริ่มต้นขององค์ประกอบ (เช่น fade-in) ได้สะดวก
  • ตั้งค่าได้ด้วย transition: opacity 1s; @starting-style { opacity: 0; }
  • ทำงานได้โดยไม่ต้องมี @keyframes หรือ JavaScript เพิ่มเติม
• เพียงระบุสถานะเริ่มต้นร่วมกับ transition ก็จะได้แอนิเมชันที่เป็นธรรมชาติ
  • ตัวอย่าง: เปลี่ยนความทึบและตำแหน่งของข้อความ toast ได้อย่างนุ่มนวล

ตั้งค่าธีม dark/light mode ได้ง่าย

• color-scheme: light dark สลับธีมอัตโนมัติตามความชอบของผู้ใช้
• ฟังก์ชัน light-dark(#000, #FFF) ใช้กำหนดสีให้เหมาะกับโหมดสว่าง/มืด
• รองรับการเลือกธีมด้วยปุ่มวิทยุและ selector :has
  • สลับธีมได้ด้วย CSS เพียงอย่างเดียวโดยไม่ต้องใช้ JavaScript
  • จะเพิ่ม JavaScript เพื่อบันทึก/โหลดธีมแบบเลือกใช้ก็ได้

สร้าง UI แบบกำหนดเองด้วย radio/checkbox และ :has, :checked

• อินเทอร์แอ็กชันที่ซับซ้อนอย่างแท็บ, accordion, toggle ก็ ทำได้โดยไม่ใช้ JavaScript
• ปุ่มวิทยุ สามารถจัดสไตล์เองได้ด้วย :checked และ :has
  • ตัวอย่าง: label:has(input:checked) เพื่อกำหนดสไตล์ของปุ่มที่ถูกเลือก
  • ซ่อน input ด้วย opacity: 0 แต่ยังคงการเข้าถึงสำหรับโปรแกรมอ่านหน้าจอไว้ได้
• องค์ประกอบ details เหมาะสำหรับสร้าง เมนู accordion อย่าง FAQ
  • ใช้แอตทริบิวต์ name เพื่อควบคุมให้เปิดได้ครั้งละรายการเดียว
  • สามารถเพิ่มแอนิเมชันตามสถานะ [open] ได้

การตรวจสอบข้อมูลนำเข้าและการสะท้อนสถานะ

• การใช้แอตทริบิวต์ HTML เช่น pattern, required ร่วมกับ CSS pseudo-class (:valid, :invalid, :user-valid ฯลฯ) ช่วยให้ ตรวจสอบแบบเรียลไทม์และแสดงผลตอบกลับทางภาพ ได้
• ปรับปรุงประสบการณ์ผู้ใช้ด้วยการเปลี่ยนสไตล์ outline/border ของช่องกรอกข้อมูล เป็นต้น
• ใช้ แอตทริบิวต์ pattern ของ HTML เพื่อตรวจสอบความถูกต้องของช่องกรอกข้อมูล
  • ตัวอย่าง: \w{3,16} อนุญาตตัวอักษร/ตัวเลข/ขีดล่าง 3–16 ตัว
• ใช้ :valid และ :invalid ของ CSS เพื่อจัดสไตล์ตามสถานะความถูกต้อง
  • :user-valid และ :user-invalid จะใช้สไตล์ก็ต่อเมื่อผู้ใช้ได้ป้อนข้อมูลแล้วเท่านั้น
• ใช้ selector :has เพื่อจัดสไตล์องค์ประกอบอื่นตามสถานะของ input ได้
• ในบางกรณี (เช่น เงื่อนไขอินพุตที่ซับซ้อน) อาจยังต้องใช้ JS แต่ส่วนใหญ่ CSS/HTML ก็เพียงพอ

วิธีใช้หน่วย viewport ให้ถูกต้อง

• หน่วย vw/vh มี ปัญหาความแม่นยำ บนมือถือเมื่อแถบที่อยู่ (navigation bar) ปรากฏหรือซ่อน
• แนะนำให้ใช้หน่วย viewport รุ่นใหม่อย่าง lvh/svh/dvh (largest/smallest/dynamic viewport height)
  • lvh: สำหรับเต็มหน้าจอ (เช่น พื้นหลังเต็มจอ)
  • svh: เหมาะกับปุ่มหรือลิงก์ที่ต้องมองเห็นบนหน้าจอเสมอ
  • dvh: จัดสรรขนาดแบบยืดหยุ่นตามการเปลี่ยนแปลง เช่น การเลื่อนหน้าจอ
• การซ้อนทับของคีย์บอร์ดจัดการได้ด้วยพร็อพเพอร์ตี interactive-widget หรือ VirtualKeyboard API
  • <meta name="viewport" content="width=device-width, interactive-widget=resizes-content">
  • ในเบราว์เซอร์ที่ใช้ Chromium สามารถใช้ navigator.virtualKeyboard.overlaysContent = true

Wishlist ของ CSS (สิ่งที่ยังน่าเสียดายหรืออยากให้มี)

• บล็อกที่นำกลับมาใช้ซ้ำได้: ใช้คลาสอื่นภายในคลาส (เช่น @apply border)
• selector ของ media query ที่รวมกันได้: ผสาน @media กับ class selector
• ตัวแปร nth-child: span { --nth: nth-child(); } สำหรับจัดสไตล์แบบไดนามิก
• selector nth-letter: จัดสไตล์อักษรบางตัวโดยเฉพาะ (เช่น p::nth-letter(2))
• การลบหน่วย: สร้างค่าที่ไม่มีหน่วยด้วย calc(100vw / 1px)
• ฟังก์ชัน image(): รองรับสีสำรองและชิ้นส่วนภาพ
• แท็ก style ภายใน body: หากรองรับเป็นมาตรฐานทางการ จะช่วยบรรเทาปัญหา FOUC

ปิดท้าย: CSS และความเป็นศิลปะของเว็บ

• CSS ไม่ใช่แค่เครื่องมือ แต่เป็นสื่อของ การแสดงออกเชิงสร้างสรรค์
• เครื่องมือ AI หรือ build chain (linter, เครื่องมือ minify) อาจจำกัดความคิดสร้างสรรค์ได้
• CSS ตอบโจทย์ได้พร้อมกันทั้ง ประสิทธิภาพ, การเข้าถึง, และ การแสดงออกทางศิลปะ
• บทความนี้เขียนด้วย HTML/CSS ที่ไม่มี JavaScript ขนาดประมาณ 49kB
  • วิดเจ็ตแบบโต้ตอบและองค์ประกอบภาพทั้งหมดทำขึ้นด้วยมือ
  • ตัวอย่าง: เกมคลิกด้วย CSS แสดงให้เห็นถึงความเป็นไปได้ของ CSS ในฐานะภาษาการเขียนโปรแกรม

[duqduqduq]

เดิมทีผมเป็นฟูลสแตก แต่พอเส้นทางอาชีพสูงขึ้นเรื่อย ๆ โอกาสที่จะได้ทำ FE ก็แทบไม่มีเลย เลยไม่ได้แตะมันมาราว 10 ปี พอดีช่วงหลังมีงานไปบรรยายให้บริษัทแห่งหนึ่ง ก็เลยลองกลับมาดูแบบคร่าว ๆ เพื่อจะแนะนำสั้น ๆ แล้วต้องบอกว่ามันเปลี่ยนไปอย่างน่าทึ่งจริง ๆ ถ้าใช้ร่วมกับ scss ก็ยิ่งสะดวกเข้าไปใหญ่ แต่โลกของ css นี่ก็มีความน่าสนใจแบบแปลก ๆ อยู่เหมือนกัน คือเรียนรู้น่ะง่าย แต่จะใช้ให้เก่งจนเป็นที่ยอมรับได้หรือไม่นั้น ผมว่าขึ้นอยู่กับเซนส์ด้านสุนทรียะและความคิดสร้างสรรค์ของแต่ละคน ในยุคของเว็บที่ให้ความสำคัญกับการใช้งานและการออกแบบมากขึ้นแบบนี้ ก็น่าเสียดายที่คุณค่าของสายพับลิชเชอร์ดูเหมือนจะยังไม่ได้รับการประเมินสูงขึ้นเท่าที่ควร

[ahwjdekf]

ครั้งนี้ลองทำบอร์ดพื้นฐานขึ้นมาโดยใช้ nextjs, authjs, tailwind และ shadcn แบบลุยเองทั้งที่แทบไม่มีพื้นฐานเลยในฐานะงานอดิเรกลองชิมลางเทคโนโลยีพัฒนาเว็บ ... แต่ระดับความยากในการเรียนรู้สูงสุดคือ css นี่แหละครับ

[GN⁺]

ความคิดเห็นจาก Hacker News

• ฉันรู้สึกขอบคุณฟีเจอร์ nesting ที่เพิ่งเพิ่มเข้ามาใน CSS รอบนี้ แต่ถ้ามองภาพรวมแล้ว CSS เป็นภาษาที่แปลกมาก และส่วนตัวคิดว่าเป็นภาษาที่แย่มาก อาจเป็นเพราะฉันใช้มันไม่เก่งเองก็ได้ แต่มันซับซ้อนและรกมาก เหมือนกำลังลองย้ายอักษรรูนลึกลับไปวางไว้ตรงนั้นตรงนี้ ระบบ styling กับ layout ถูกปนกันอยู่ แถม inheritance กับความสัมพันธ์แบบ containment ก็ไม่เหมือนกัน เลยยิ่งสับสน ฉันคิดว่าการเอา styling กับ layout มารวมกันเป็นความผิดพลาด และรู้สึกว่าการเพิ่มฟีเจอร์เข้าไปในระบบที่พังตั้งแต่รากฐานอยู่แล้วคงไม่ใช่ทางแก้

  • ฉันก็หาเลี้ยงชีพด้วย CSS มาตลอด 10 ปีที่ผ่านมาเหมือนกัน แต่ CSS ให้ความรู้สึกเหมือนไม่ได้ถูกออกแบบเป็นภาษามาตั้งแต่ต้น แต่ค่อย ๆ ถูกขยายเพิ่มตามสถานการณ์ มีแต่เอาโมดูลใหม่ไปแปะทับบน property เดิม ๆ จนชนกันหรือแตกต่างกันนิดหน่อย ทำให้ดีบักยาก ยกตัวอย่างเช่น box model กับ flex layout ที่ทำงานต่างกัน หรือ property gap ที่ทำงานต่างกันระหว่าง flex กับ grid (ลิงก์) พอทำ layout เสร็จแล้วก็แทบจะถูกตรึงตายตัวในทางปฏิบัติ เปลี่ยนให้ยืดหยุ่นได้ยากหากไม่มีการ encapsulation ที่ซับซ้อนแบบ native หรือใช้ JS พอเป็นแบบนั้นก็จะเกิดปัญหาอย่างน้ำหนักฟอนต์เปลี่ยนโดยไม่คาดคิด หรือเมนูมือถือไปโผล่บนเดสก์ท็อป
  • ฉันไม่เห็นด้วย เหตุผลที่เรามักเห็นความเห็นเชิงลบเกี่ยวกับ CSS ก็เพราะคนส่วนใหญ่ไม่ได้เรียนมันอย่างถูกต้อง หรือโดยเฉพาะไม่ได้เข้าใจ cascade อย่างแท้จริง ครั้งหนึ่งฉันเคยลงลึกกับสเปก CSS มาก ๆ แล้วทำให้คิดว่ามันเป็นภาษาที่ออกแบบมาได้ค่อนข้างดีสำหรับเป้าหมายในการแยกความหมายของ markup ออกจาก style
  • ฉันคิดว่าเป็นไปไม่ได้ที่จะแยก styling ออกจาก layout ใครก็ตามที่เคยพัฒนา UI จะรู้ว่าสองอย่างนี้ผูกกันโดยเนื้อแท้และพึ่งพากันเอง เช่น ความยาวข้อความหรือขนาดข้อความ overflow, margin, padding ต่างก็ส่งผลต่อกัน ถ้าเปลี่ยน border หรือ spacing ขององค์ประกอบใด พื้นที่ของคอนเทนต์ด้านในก็เปลี่ยนไปด้วย แยกสองอย่างนี้ออกจากกันโดยสมบูรณ์ไม่ได้
  • ฉันคิดว่าปัญหาที่แท้จริงของ CSS คือ Cascading และการพัฒนา frontend สมัยใหม่ส่วนใหญ่ก็วนอยู่กับการพยายามปิดกั้น cascade นี้เอง การทำ UI ให้เป็น component ก็คือตัวอย่างหนึ่ง ส่วน layout ก็เป็นอีกปัญหาหนึ่งต่างหาก และซับซ้อนขึ้นเพราะเรื่อง compatibility ถ้าทุก layout ทำงานด้วย flexbox หรือ grid เป็นค่าเริ่มต้นทั้งหมด และไม่ผสม inline กับ non-inline ไว้ในคอนเทนเนอร์เดียวกัน มันน่าจะดีกว่านี้มาก React Native ทำงานแบบนั้นพอดี และใน React Native style ก็ไม่ cascade เลยจัดการได้ง่ายกว่ามาก
  • ทั้งหมดที่พูดมาก็จริง แต่สิ่งที่เรามีตอนนี้ก็คือสิ่งนี้ ฉันเคยคิดว่าเราน่าจะสร้างโมเดลที่สอดคล้องเชิงแนวคิดมากกว่านี้ แล้ว transpile เป็น CSS ได้ไหม อาจจะใช้ container queries หรือ calc เพื่อทำระบบ layout ที่เป็นระเบียบกว่านี้ในเชิงคณิตศาสตร์ก็ได้ ภาษาพรีโปรเซสเซอร์ในปัจจุบันกลับเหมือนเอาฟีเจอร์ที่ยังไม่สมบูรณ์ไปแปะทับบนแนวคิดที่เดิมก็ยังไม่สมบูรณ์ใน CSS จึงยิ่งทำให้สับสนกว่าเดิม

• สิ่งที่แย่ที่สุดของ CSS คือมีคนจำนวนมากที่ไม่ได้เรียนมันจริง ๆ แค่ถูกบังคับให้ใช้สักวันหนึ่งแล้วก็มีความเห็นแรง ๆ ออกมา

  • ฉันก็เคยมี “วันหนึ่ง” แบบนั้น ตอนทำแอปพอดแคสต์ ฉันอยากทำ footer แบบลอยที่ (1) อยู่ข้างล่างเสมอ (2) มองเห็นได้เสมอ (3) ไม่บังคอนเทนต์ และ (4) ทำได้โดยไม่ต้องใช้แฮ็กพิเศษ แต่กลับพบว่าสิ่งนี้ทำใน CSS ไม่ได้ ระบบที่ยอดเยี่ยมจริง ๆ
  • ฉันเรียน CSS มาเมื่อ 20 ปีก่อน และข้อสรุปของฉันคือเพราะ Cascading นี่แหละ CSS ควรถูกเปลี่ยนชื่อเป็น Crappy Style Sheets เวลาหลายคนทำงานร่วมกัน อาการแบบ “เปลี่ยนอันนี้ตรงนี้แล้วอีกฝั่งพังแบบงง ๆ” เป็นเรื่องปกติ จุดเด่นของมันคือกฎที่ซับซ้อนสำหรับ override กฎอื่น ซึ่งถ้ารากฐานเป็นแบบนั้นก็คงไม่ดี วิธี target แบบซับซ้อนยิ่งซับซ้อนขึ้นเรื่อย ๆ จนสุดท้ายกลายเป็นโค้ดอย่าง .foo > .bar:nth-child(2n) ~ .baz แล้วทีนี้โค้ดของเพื่อนร่วมงานก็พังอีก แค่ layout ง่าย ๆ อันเดียวก็ปวดหัวแล้ว ถึงช่วงหลังจะดีขึ้นมาก แต่ฉันก็ยังคิดว่าโครงสร้างที่ยึด cascade เป็นศูนย์กลางนี่แหละคือปัญหา คำวิจารณ์อื่นอย่างเรื่อง syntax เป็นเรื่องรอง ถ้าใช้งานได้จริงและใช้ได้ง่าย syntax แบบไหนก็พอรับได้ แต่ CSS ไม่เคยเป็นแบบนั้น ฉันไม่คิดว่าการทำ web layout ควรกลายเป็นอาชีพได้เลย
  • สำหรับคำพูดที่ว่า “หลายคนใช้ CSS โดยไม่เรียนมัน” การจะบอกว่าต้องเรียนสเปกมากกว่า 20 ตัวให้หมดก่อนถึงมีสิทธิ์ใช้ มันเป็นท่าทีที่เกินไป เวลาคนใช้เครื่องมือแล้วเจอปัญหา เราควรมองว่าเครื่องมือมีปัญหาหรือไม่ ไม่ใช่ไปโทษคน แทนที่จะบังคับให้ทุกคนใช้เลื่อยอย่างระวัง ก็ควรติดอุปกรณ์นิรภัยให้มัน

• สำหรับบทความนี้ เหตุผลว่า “ผู้ใช้บางคนไม่ต้องการ JavaScript” ฟังดูไม่ค่อยโดนใจฉันเท่าไร ฉันเองก็เป็นผู้ใช้ Arch และชอบทั้ง scripting และ crawling แต่การไปโฟกัสกับสภาพแวดล้อมแบบ “NoScript” ไม่ได้รู้สึกว่าสำคัญอะไรนัก มันเป็นความชอบของคนส่วนน้อยมากจนส่วนใหญ่ละเลยไปได้ ให้ความรู้สึกคล้ายยุคที่พูดกันว่า “10% ยังใช้ IE6” ถึงอย่างนั้นฉันก็คิดว่ายังมีเหตุผลอื่นอีกมากมายที่ทำให้ CSS เหนือกว่า อย่างไรก็ดี นี่ไม่ใช่ประเด็นหลัก แค่รู้สึกว่าโทนโดยรวมมันประมาณนี้

  • สิ่งที่ CSS ทำได้แบบ declarative ภายในไม่กี่บรรทัด ถ้าทำด้วย JS แบบ imperative ก็จะกลายเป็นหลายสิบบรรทัด พร้อมพฤติกรรมเพี้ยน ๆ เพิ่มขึ้น ปัญหาความเข้ากันได้กับ framework และเวลาโต้ตอบที่ช้าลง สภาพแวดล้อม NoScript เป็นแค่ของแถมเท่านั้น จริง ๆ ลึก ๆ แล้วฉันยังคิดถึง DSSSL
  • ในบทความต้นฉบับ ผู้ใช้ที่ไม่ชอบ JavaScript ถูกกล่าวถึงแค่ผ่าน ๆ แต่เนื้อหาส่วนใหญ่โฟกัสที่การแสดงความสามารถของฟีเจอร์ CSS เอง แรงจูงใจอย่างหนึ่งคือประสิทธิภาพก็จริง แต่ฉันคิดว่าการแนะนำเทคนิค CSS เป็นแนวทางที่สร้างสรรค์กว่ามาก
  • ฉันใช้อินเทอร์เน็ตในสภาพแวดล้อม NoScript เป็นปกติ และจะอนุญาตเฉพาะเว็บที่จำเป็นต้องใช้ JS เท่านั้น มันดีต่อประสิทธิภาพ แบตเตอรี่ และความปลอดภัยพอสมควรเลย คุณเคยลองอยู่กับ NoScript เกินหนึ่งสัปดาห์ไหม ก่อนฉันจะลองเองก็คิดเหมือนกันนะ อ้อ ฉันคือผู้เขียนบล็อกโพสต์นี้
  • ฉันไม่คิดว่ากลุ่มผู้ใช้ NoScript จะมีนัยสำคัญมากพอหรือจำเป็นต้องเป็นเป้าหมายหลัก แต่แม้จะไม่ได้พูดตรง ๆ ในส่วนนั้นซึ่งไม่ใช่ผู้เขียนเอง ฉันคิดว่าการเขียนโค้ดให้น้อยลงและพึ่งพาแพลตฟอร์มของเบราว์เซอร์ให้มากขึ้นมีคุณค่ามหาศาล ปล่อยให้เบราว์เซอร์ทำงานให้มากที่สุดเป็นประสิทธิภาพที่สำคัญมากจริง ๆ
  • สำหรับคำกล่าวที่ว่า “ผู้ใช้บางคนไม่ต้องการ JavaScript” ฉันคิดว่าแทบผู้ใช้ทั้งหมดนั่นแหละที่ไม่ต้องการมัน

• ฉันไม่รู้มาก่อนเลยว่า nesting กลายเป็นมาตรฐานทางการแล้ว จนไม่นานมานี้ยังคิดว่าอยู่ในขั้น proposal เท่านั้น CSS มีจุดแปลกเยอะก็จริง แต่ก็รู้สึกได้ว่ามันกำลังค่อย ๆ พัฒนาไปเป็นภาษาที่ดีขึ้นเรื่อย ๆ เหมือน JavaScript ด้วย Flexbox, selector :has และ nesting ทำให้จุดเจ็บปวดหลายอย่างที่เคยมีมานานได้รับการคลี่คลายไปมาก

• ฟีเจอร์ CSS สองอย่างที่อยู่ใน wishlist นั้นมีอยู่ในสเปกแล้ว

  • ตัวแปร n-th child ทำได้ด้วย sibling-index() และ sibling-count() (คำอธิบายบน MDN)
  • บล็อกที่นำกลับมาใช้ซ้ำได้มีอยู่ในร่างสเปก @function และ @mixin (ร่างสเปก, คำอธิบายจาก CSS Tricks)
  • ทั้งสองอย่างถูก implement ใน Chrome แล้วและใช้งานได้

• ฉันคิดว่า syntax ของ CSS แย่มาก ฉันใช้ภาษามา 10–15 ภาษา แต่ CSS อ่านและทำความเข้าใจยากที่สุด ยากกว่า x86 assembly เสียอีก CSS เป็นอินพุตที่ถูก tokenized ล่วงหน้าสำหรับ renderer แต่มันก็ไม่ใช่โทเค็น และแปลกเกินไปสำหรับการเขียนโดยมนุษย์ น่าจะเอาไปใช้เป็นตัวอย่างสอนในทางกลับกันแบบ ASN.1 ใน RFC ว่า “อย่าทำแบบนี้”

  • ฉันสงสัยว่าในบรรดาภาษาเหล่านั้นมี declarative language หรือ domain-specific language อยู่กี่ภาษา การเปรียบ CSS กับ assembly ไม่ค่อยเหมาะ CSS เป็น declarative ส่วน assembly เป็นตรงกันข้าม นักพัฒนา frontend ส่วนใหญ่เองก็ลำบากในช่วงแรกเวลาเปลี่ยนจากภาษาแบบ imperative มาสู่ CSS แต่พอคุ้นเคยแล้วจะดีขึ้น คำศัพท์และแนวคิดของ CSS ส่วนใหญ่มีรากมาจากวงการออกแบบ/สิ่งพิมพ์ ไม่ใช่วงการคอมพิวเตอร์ นักพัฒนาหลายคนพยายามเข้าหา CSS เหมือนเป็นชุดคำสั่งแบบ explicit แต่ CSS เป็นสิ่งที่ property ต่าง ๆ ส่งผลกระทบต่อกันในแบบเฉพาะตัว บาง property ถึงขั้นเปลี่ยนอัลกอริทึม layout ทั้งชุดได้เลย (เกริ่นนำสู่อัลกอริทึม layout ของ CSS)
  • ต่อให้ “ใช้มา 15 ภาษา” ฉันก็ยังคิดว่า CSS รู้ให้จริงนั้นยากมาก ถึงจะเขียนภาษาการเขียนโปรแกรมมาหลายตัว แต่จะไปถึงระดับที่เรียกว่า “รู้จริง” ได้ก็ต้องอาศัยประสบการณ์ภาคปฏิบัติมหาศาล (Illusion of explanatory depth บนวิกิ) วิธีที่ดีที่สุดในการเข้าใจ CSS คือดูผลลัพธ์การเรนเดอร์จริงแล้วประเมินมัน ฉันใช้งานแบบนั้นมาหลายสิบปีแล้ว
  • ฉันก็รู้สึกว่า CSS แย่ที่สุดในชุด HTML/CSS/JS เหมือนกัน
  • ฉันอยากฟังเพิ่มเติมว่าคำว่า “CSS เป็นอินพุตที่ tokenized ล่วงหน้า” หมายถึงอะไรให้ชัดกว่านี้
  • โค้ดอย่าง font-size: 12px ก็ไม่ได้อ่านยากสำหรับมนุษย์เลย ฉันไม่เข้าใจว่าทำไมถึงรู้สึกว่ามันยาก สำหรับฉันมันเรียบง่ายมาก

• ฉันสงสัยว่าตัวอย่าง radio tabs นี้โอเคในแง่ accessibility หรือไม่ ตามมาตรฐาน WAI-ARIA ดูเหมือนว่า attribute aria-selected, tabindex, aria-controls ต้องอัปเดตด้วย JS ตอนเปลี่ยนแท็บ แต่ก็ไม่แน่ใจนัก accessibility มักถูกมองข้ามบ่อย ๆ และบางครั้งคนก็เข้าใจผิดว่าถ้าใช้แค่ HTML/CSS แล้ว accessibility จะดีเองอัตโนมัติ นี่เป็นอีกเรื่องที่ควรคิดให้รอบเมื่อเลือกแนวทาง

  • เท่าที่ฉันทราบ radio tabs นี้ทำงานได้ดีกับ keyboard navigation และ screen reader ด้วย และทำตาม flow การย้ายระหว่างแท็บกับคอนเทนต์ในตัวอย่าง WAI-ARIA (ตัวอย่าง WAI-ARIA) ฉันไม่มีพื้นฐานด้าน accessibility มากนัก แต่พยายามตรวจสอบให้ดีที่สุด และลองทดสอบด้วยเครื่องมือด้าน accessibility หลายตัวด้วยตัวเอง
  • ในต้นฉบับ ผู้เขียนกล่าวถึงเรื่อง accessibility หลายครั้ง และถึงกับพยายามหลบ browser bug ด้วย (เชิงอรรถที่เกี่ยวข้อง)
  • accessibility ของบล็อกโพสต์นี้เอง (โดยเฉพาะเรื่อง contrast) แย่มาก จนในมุมของฉันที่ทำงานเป็นนักพัฒนาเว็บให้กับองค์กรด้านผู้พิการ มันยากที่จะใช้เป็นแหล่งอ้างอิง

• เอฟเฟกต์แบบ interactive แบบนี้ทำได้โดยไม่ต้องใช้ JS เหมือนกัน (หน้าตัวอย่าง)

  • • แอนิเมชันกระดาษโปรย
  • • กล่องแจ้งเตือนที่ปิดได้
  • • เมื่อปิดแจ้งเตือน กระดาษโปรยก็หายไปด้วย
  • • ทำงานแบบแท็บได้ด้วย (แต่ในตัวอย่างนั้นต้องรีโหลดจากเซิร์ฟเวอร์)
  • • ถ้าเพิ่ม JS เข้าไป แอนิเมชันจะลื่นและสมบูรณ์ยิ่งขึ้น

• ในฐานะนักพัฒนาเว็บที่มีประสบการณ์ 10 ปี ฉันรู้สึกว่าบทความแบบนี้จำเป็นต่อการเขย่าความเชื่อมั่นของพวกเรา ชื่อบทความไม่ค่อยดีจนเกือบไม่ได้อ่าน และขอเสริมว่า render แผนที่ด้วย CSS อย่างเดียวทำไม่ได้

  • ถ้าใช้ CSS+SVG ก็ render แผนที่ได้ แน่นอนว่าฟังก์ชันเสริมอย่าง navigation ต้องทำแยกต่างหาก

• อาจเป็นเพราะชื่อ Vega ที่ทำให้มีอคติอยู่บ้าง แต่ฉันชอบเว็บไซต์นี้มาก ดีไซน์โดยรวมก็ดี และเนื้อหาในหน้านี้ก็ยอดเยี่ยมมาก ฉันตั้งใจว่าจะเอาลิงก์นี้ไปแชร์ให้คนทำเว็บต่อ ๆ ไปแน่นอน ฉันก็ชอบ arrupted มากเหมือนกัน และเคยทำผลงานเจ๋ง ๆ มาก่อน เลยดีใจที่คราวนี้ได้เห็นโดเมนคุ้น ๆ ขึ้นมาบนหน้าหลัก