CSS @property และสไตล์รูปแบบใหม่

(ryanmulligan.dev)

2 คะแนน โดย GN⁺ 2024-09-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เมื่อ CSS @property ได้รับการรองรับในเบราว์เซอร์สมัยใหม่โดยรวมแล้ว ทำให้สามารถระบุ ไวยากรณ์, ค่าเริ่มต้น, และการสืบทอดหรือไม่ ให้กับ custom property และให้เบราว์เซอร์ interpolate ค่าต่าง ๆ ได้อย่างเป็นธรรมชาติ
ปุ่ม CTA ตัวอย่างกำหนด --gradient-angle เป็น <angle> เพื่อเปลี่ยนจาก 0deg ไปถึง 360deg และใช้ conic-gradient สร้าง ขอบเงาวาวที่หมุนได้
เอฟเฟกต์เมื่อ hover ถูกจัดทำโดยกำหนดชนิดให้กับ property อย่าง --gradient-percent, --gradient-angle-offset, --gradient-shine เพื่อให้ ความยาวและความสว่างของเงาวาว เปลี่ยนอย่างลื่นไหล
ความเร็วการหมุนใช้วิธีประกาศแอนิเมชันเดียวกันสองครั้ง โดยให้ครั้งที่สองอยู่ในสถานะ ย้อนทิศทาง·หยุดชั่วคราว แล้วเมื่อ hover จะชะลอความเร็วลงครึ่งหนึ่งจากตำแหน่งปัจจุบัน
การนิยาม custom property บนพื้นฐาน @property ทำให้การแสดงผลด้วย CSS ที่ในอดีตทำได้ยากเป็นไปได้ และมีโอกาสนำไปใช้กับแอปพลิเคชันขนาดใหญ่และ design system ได้มาก

แอนิเมชัน custom property ที่ `@property` เปิดทางให้

@property คือกฎที่ใช้ระบุ ไวยากรณ์ที่อนุญาต, ค่าเริ่มต้น, และ การสืบทอดหรือไม่ ให้กับ CSS custom property
เป็นฟีเจอร์ที่เชื่อมโยงกับ CSS Properties and Values API ของ CSS Houdini และล่าสุดรองรับในเบราว์เซอร์สมัยใหม่ทั้งหมดแล้ว
เมื่อเบราว์เซอร์รู้ชนิดของ custom property ก็จะสามารถ interpolate ระหว่างค่าได้ ทำให้สร้าง transition และแอนิเมชันที่ลื่นไหลได้ง่ายกว่าการใช้ตัวแปร CSS ทั่วไปเพียงอย่างเดียว

ขอบเงาวาวแบบหมุนของปุ่ม CTA

ตัวอย่างนี้นำสไตล์ ปุ่ม CTA แบบแวววาวที่พบได้บ่อยบนเว็บมาสร้างด้วย CSS
custom property หลักคือ --gradient-angle โดยประกาศไวยากรณ์ <angle> และค่าเริ่มต้น 0deg ด้วย @property

@property --gradient-angle {
  syntax: "<angle>";
  initial-value: 0deg;
  inherits: false;
}

ด้วยการนิยามนี้ เบราว์เซอร์จึงเปลี่ยนจาก 0deg ไปถึง 360deg ได้อย่างเป็นธรรมชาติ และเรนเดอร์ให้ดูเหมือน conic-gradient กำลังหมุน

@keyframes rotate-gradient {
  to { --gradient-angle: 360deg; }
}

.rotate-gradient {
  background: conic-gradient(from var(--gradient-angle), transparent, black);
  animation: rotate-gradient 10s linear infinite;
}

สามารถดูแนวคิดนี้ด้วยโค้ดขั้นต่ำได้ใน เดโม CodePen

ขอบเงาวาวที่สร้างด้วยเลเยอร์พื้นหลัง

ขอบเงาวาวสร้างโดยใส่ linear-gradient และ conic-gradient ไว้ร่วมกันใน background แล้วกำหนดจุดกำเนิดของพื้นหลังแต่ละตัวให้ต่างกัน
- linear-gradient ใช้ padding-box เพื่อไม่ให้ล้นออกไปยังพื้นที่ขอบ
- conic-gradient ใช้ border-box เพื่อขยายไปถึงพื้นที่ที่เกิดจากความกว้างของขอบ
- เพิ่มขอบโปร่งใส 1px เพื่อเผยให้เห็น conic-gradient ที่กำลังหมุน

.border-gradient {
  background:
    linear-gradient(black, black) padding-box,
    conic-gradient(from var(--gradient-angle), transparent 25%, white, transparent 50%) border-box;
  border: 1px solid transparent;
}

เดโม CTA CodePen แสดงเอฟเฟกต์ปุ่มขั้นสุดท้าย

กราดิเอนต์ที่เปลี่ยนอย่างลื่นไหลเมื่อ hover

ประกาศ syntax ใน @property ให้กับ custom property แต่ละตัวที่จำเป็นสำหรับ transition ตอน hover เพื่อให้เบราว์เซอร์สามารถ interpolate การเปลี่ยนแปลงของค่าได้
พื้นหลังของปุ่มประกอบด้วย linear-gradient ที่ดูแลสีด้านใน และ conic-gradient ที่ดูแลเงาวาวของขอบ
--gradient-percent กำหนดขนาดของพื้นที่เงาวาว และเมื่อ hover จะเปลี่ยนเป็นเปอร์เซ็นต์ที่สูงขึ้น ทำให้ความยาวของเงาวาวยาวขึ้น
--gradient-angle-offset ใช้ปรับมุมของกราดิเอนต์ใหม่ เพื่อไม่ให้เงาวาวดูเด้งไปมาระหว่าง hover
ความสว่างของ --gradient-shine ถูกลดลง เพื่อให้ผสมกับสีไฮไลต์รอบ ๆ ได้เป็นธรรมชาติมากขึ้น

วิธีชะลอความเร็วการหมุนระหว่าง hover

เคล็ดลับ CSS สำหรับชะลอความเร็วการหมุนคือการประกาศแอนิเมชันหมุนเดียวกันสองครั้ง
แอนิเมชันที่สองตั้งเป็น ทิศทางย้อนกลับ แบ่งระยะเวลาเหลือครึ่งหนึ่ง และตั้งสถานะพื้นฐานเป็น paused
เมื่อ hover animation-play-state: running จะเขียนทับ paused ทำให้การหมุนช้าลงเหลือครึ่งความเร็ว
เมื่อจบ hover แอนิเมชันจะไม่กระโดดกลับไปยังตำแหน่งเริ่มต้น แต่จะกลับมาเร็วขึ้นอีกครั้งจากตำแหน่งปัจจุบัน
แอนิเมชันปุ่ม CTA ใช้วิธีนี้เพื่อให้การหมุนและการเคลื่อนไหวยังคงประสานกันแม้เมื่อความเร็วเปลี่ยน

ประกายเล็ก ๆ และไฮไลต์ภายใน

ลวดลายจุดเล็ก ๆ ภายในปุ่มถูกเรนเดอร์โดยสร้างพื้นหลัง radial-gradient บน pseudo-element ::before
--gradient-angle ถูกนำกลับมาใช้ที่นี่ด้วย โดย conic-gradient mask จะหมุนและเผยให้เห็นเพียงบางส่วนของลวดลายจุด
มุมกราดิเอนต์ของ mask ถูก offset 45deg เพื่อให้สอดคล้องกับการหมุนของขอบเงาวาว

.shiny-cta::before {
  mask-image: conic-gradient(
    from calc(var(--gradient-angle) + 45deg),
    black,
    transparent 10% 90%,
    black
  );
}

ใน pseudo-element ::after เพิ่มกราดิเอนต์ที่มีสีไฮไลต์ เพื่อให้หมุนไปพร้อมกับพื้นที่เงาวาว
ไฮไลต์ภายในช่วยเพิ่มความรู้สึกเหมือนแสงไหลอยู่ด้านในปุ่ม

การปรับสี hover และความสมบูรณ์ของงาน

เนื่องจาก ::before และ ::after ของปุ่มถูกใช้อยู่แล้ว จึงห่อข้อความของปุ่มด้วย span
ใส่ box-shadow แบบเบลอที่มีสีไฮไลต์ให้กับหนึ่งใน pseudo-element ของ span และขยายให้เท่าขนาดปุ่ม
เมื่อ hover pseudo-element นี้จะค่อย ๆ ขยายและหดลง สร้างความรู้สึกคล้ายการหายใจอย่างนุ่มนวล
เมื่อผสานกับสีไฮไลต์ที่หมุนอยู่ภายใน ก็ทำให้เอฟเฟกต์ขั้นสุดท้ายของปุ่ม CTA สมบูรณ์

ความเป็นไปได้ที่ต่อยอดไปสู่ design system

การนิยาม custom property อย่างชัดเจนทำให้สามารถใช้เทคนิค CSS ที่จนเมื่อไม่นานมานี้แทบเป็นไปไม่ได้
@property อาจนำไปสู่วิธีเผยแพร่และจัดโครงสร้าง CSS ที่เป็นระบบมากขึ้น
บทความที่เกี่ยวข้องสามารถดูเพิ่มเติมได้ที่ Providing Type Definitions for CSS with @property ของ Stephanie Eckles และ Type safe CSS design systems with @property ของ Adam Argyle
แหล่งอ้างอิงที่รวบรวมไว้ยังมี Animated CSS gradient borders (no JavaScript, no hacks), CSS border animations, @property: Next-gen CSS variables now with universal browser support เป็นต้น

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

GN⁺ 2024-09-05

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

ผมไม่ใช่นักพัฒนาเว็บ แต่เคยทำเว็บไซต์เล่น ๆ โดยไม่ใช้เฟรมเวิร์ก และเคยทำงานพื้นฐานในเว็บเฟรมเวิร์กบางตัว ตอน CSS เพิ่งออกมา ช่วงหนึ่งผมสามารถจำทุกอย่างไว้ในหัวแล้วใช้งานได้
CSS ในตัวอย่าง CodePen แรกดูแทบจะอ่านไม่ออก เหมือนเป็น ไวยากรณ์ลึกลับซับซ้อน และผมก็สงสัยว่าจำเป็นต้องมี ภาษาโปรแกรมมิงสำหรับแอนิเมชัน เล็ก ๆ อยู่ในระบบสไตล์ด้วยหรือเปล่า
รู้สึกว่านี่เป็นสิ่งที่ทำด้วย JavaScript ได้ไม่ใช่หรือ และผมเข้าใจความรู้สึกต่อต้านการใช้ JS ไปทุกที่ แต่ถึงอย่างไรถ้าเป็นภาษาโปรแกรมมิง งานแบบนี้ก็ดูใกล้เคียงกับหน้าที่หลักของมันมากกว่า
- ผมไม่ค่อยเข้าใจความรู้สึกนี้ ถ้าไม่ใช่นักพัฒนาเว็บ โดยเฉพาะนักพัฒนาฟรอนต์เอนด์ ก็คงแทบไม่มีโอกาสต้องสร้างองค์ประกอบ HTML ที่มีเอฟเฟกต์หวือหวาแบบนี้ แล้วทำไมความสามารถขั้นสูงของ CSS ถึงเป็นปัญหา
  แน่นอนว่าทำด้วย JavaScript ก็ได้ และจะวาง canvas แล้วเขียนเอฟเฟกต์บน GPU ด้วย WebGL ก็ยังได้ แต่คุณต้องสร้าง ฟีเจอร์ด้านการเข้าถึง ทั้งหมดของปุ่ม HTML ขึ้นมาใหม่เอง และผมก็สงสัยว่ามันจะง่ายกว่าจริงไหม
- เพราะเรื่อง ประสิทธิภาพ นั่นแหละ ถ้าทำด้วย JS มันต้องรันได้ลื่น ๆ 60 ครั้งต่อวินาที แต่ JS เป็นเธรดเดียว พอ main thread ถูกบล็อกเมื่อไร ก็พลาดเฟรมทันที
  แม้เอนจิน JS สมัยใหม่จะยอดเยี่ยม แต่ก็ไม่ได้มีประสิทธิภาพเท่าโค้ดเนทีฟ ทำให้ใช้ CPU มากขึ้น และสุดท้ายก็ไม่ดีต่อ อายุแบตเตอรี่ ด้วย
- ถ้ามีโอกาสหลีกเลี่ยง JavaScript บนไซต์ได้ ต่อให้ต้องทำงานเพิ่ม ผมก็ยินดี ผู้เข้าชมที่ปิด JavaScript ใช้งานสามารถหลีกเลี่ยง เอ็กซ์พลอยต์และตัวติดตาม จำนวนมากที่รบกวนเว็บในปัจจุบันได้
  ด้วยเหตุผลเดียวกัน ผมจึงรู้สึกขอบคุณไซต์ที่ไม่ได้บังคับใช้ JavaScript
- การต้องใช้ ภาษาโปรแกรมมิงเต็มรูปแบบ เพื่อทำสิ่งที่เกี่ยวกับความสวยงามของหน้าเว็บเท่านั้น ไม่ใช่ความคิดที่ดี
  แพลตฟอร์มโฮสติ้งบางแห่งอนุญาตให้ปรับแต่ง HTML และ CSS ได้ด้วยเหตุผลด้านความปลอดภัย แต่บล็อก JS อย่างเช่น Itch.io ที่ให้ตกแต่งเกมและโปรไฟล์ได้ การใช้ CSS animation ทำให้สร้างเอฟเฟกต์สวย ๆ ได้โดยไม่ต้องให้สิทธิ์เข้าถึง JS ซึ่งสมเหตุสมผลและมีประโยชน์
- ดูเหมือนว่าพอไม่เข้าใจโดเมนของปัญหาดีพอ และไม่รู้ไวยากรณ์ ก็เลยมองสิ่งที่ไม่เข้าใจทันทีว่าเป็น การเปลี่ยนแปลงในทางลบ
ตอนอ่านบทความนี้ ผมรู้สึกเหมือนสมองกำลังต่อต้านแนวคิดที่ไม่คุ้นเคย แนะนำให้อ่าน บทความ MDN ที่ลิงก์ไว้ในประโยคแรกก่อนดูตัวอย่างในบล็อก
@property น่าจะต้องลองจับเองถึงจะเริ่มเข้าใจ และถ้าคุณอยากลดการพึ่งพา JS ขณะสร้าง UI ที่ซับซ้อน การรู้จัก ฟีเจอร์ CSS ที่ซับซ้อน แบบนี้จะเป็นอาวุธที่ทรงพลัง
- อ่านบทความ MDN แล้วก็ยังไม่เข้าใจเลย นี่มันก็คือ ตัวแปร CSS ตรงตัวไม่ใช่หรือ
  ตัวแปร CSS ก็ cascade ได้และถูก override ด้วย class อะไรทำนองนั้นได้อยู่แล้ว และอย่าง bg-opacity ของ Tailwind ก็น่าจะใช้แนวทางแบบนั้นไม่ใช่หรือ
- ผมก็คล้ายกัน บทความนี้อธิบายได้แย่มากจริง ๆ
  ดูจาก MDN แล้ว มันฟังดูแทบเหมือน ตัวแปร CSS แบบเดิม แต่มี scope อยู่ที่องค์ประกอบเฉพาะหรือลูกของมัน และเพิ่มข้อจำกัดที่รู้จักหน่วย CSS อย่างองศาหรือเปอร์เซ็นต์
  ถึงอย่างนั้นผมก็ไม่น่าจะใช้ ประโยชน์เล็ก ๆ แค่นี้ไม่คุ้มกับต้นทุนด้านความซับซ้อนและความเข้ากันได้ และผมพยายามหลีกเลี่ยงไวยากรณ์ใหม่ที่ไม่จำเป็น หลังจาก CSS variables แล้ว ผมก็ไม่ค่อยสนใจฟีเจอร์ใหม่ ๆ ของ CSS มากนัก
- นึกว่าผมเป็นคนเดียวเสียอีก แต่มันรู้สึกไม่คุ้นจริง ๆ
  ผมยังไม่ค่อยเห็นว่ามันมีข้อดีอะไรเหนือกว่าการใช้ CSS transform
ในฐานะคนที่ชอบทำงานกับ CSS แต่ก็ทำงานร่วมกับเพื่อนร่วมงานที่มองว่า CSS ยาก ผมขอแนะนำ ช่อง YouTube ของ Kevin Powell อย่างยิ่ง
เขาเคยพูดถึงฟีเจอร์นี้หลายครั้ง และในวิดีโอที่โพสต์เมื่อหนึ่งสัปดาห์ก่อนก็แสดงฟีเจอร์ที่มีประโยชน์อย่างหนึ่งซึ่ง registered properties ทำให้เป็นไปได้: https://youtu.be/U8NykwZNbGs
ยังมีบทความที่อธิบาย registered properties ด้วยตัวอย่างที่ตามได้ง่ายด้วย: https://moderncss.dev/providing-type-definitions-for-css-wit...
งาน CSS ช่วงหลัง ๆ โดยเฉพาะ Houdini ทำให้ผมตั้งตารอมาก ไม่ได้รู้สึกแบบนี้มานานตั้งแต่ตอนดูหนังสือฟีเจอร์ของ IE 5.5
ตลอด 14 ปีที่ผ่านมา CSS มีฟีเจอร์ใหม่เพิ่มขึ้นมากก็จริง แต่ส่วนใหญ่เป็นสิ่งที่ใกล้เคียงกับฟีเจอร์พื้นฐานที่คาดหวังได้จากสไตล์เฟรมเวิร์ก เช่น ตัวเลือกเลย์เอาต์ใหม่หรือตัวแปร
แต่เหล่านักพัฒนา IE นั้นกล้าลุยจริง ๆ ถึงขั้นทำโค้ด JS เป็นโมดูลแล้วแนบเข้ากับองค์ประกอบผ่าน CSS ได้ ในที่สุดก็รู้สึกเหมือน ฟีเจอร์สุดโต่ง แบบนั้นกำลังกลับมาอีกครั้ง
ตัวอย่าง: https://developer.chrome.com/docs/css-ui/houdini
- ไม่ค่อยแน่ใจว่าการใช้คำว่า “กล้าลุย” ตรงนี้เป็นความหมายเชิงบวกหรือเชิงลบ
- นั่นไม่ใช่วิธีที่ css3pie(http://css3pie.com/) ทำงานหรอกหรือ
เป็นบทความสั้น ๆ ที่ดี ถ้าอยากดูตัวอย่างเพิ่ม โดยเฉพาะตัวอย่างที่ง่ายกว่ามากและช่วยให้จับประเด็นได้เร็ว แนะนำบทความเก่าของ CSS-Tricks
ถึงจะเป็นบทความปี 2021 แต่ยังใช้ได้และทำมาอย่างดี: https://css-tricks.com/exploring-property-and-its-animating-...
โดยเฉพาะตัวอย่าง จอแสดงผลแบบพลิก ที่ตัวเลขสนามบิน/ตัวจับเวลาเปลี่ยนไปมา น่าจะถูกใจ
ผมห่างจากการพัฒนาเว็บไปพักหนึ่ง และใช้เวลานานเกินไปกว่าจะเข้าใจว่าฟีเจอร์นี้ทำอะไรจริง ๆ รู้สึกว่าบทความอธิบายได้ไม่ดีนัก
เท่าที่เข้าใจคือ แทนที่จะใช้ค่าดิบอย่าง 360deg ก็เขียนแบบ from var(--gradient-angle) แล้วค่านั้นจะถูกดึงมาจากจุดที่นิยามไว้ในบล็อก @property --gradient-angle {...} เพื่อแทนค่า
ยังมี inherits: false; ด้วย ซึ่งตัวพฤติกรรมพอเข้าใจ แต่ไม่รู้ว่าทำไมถึงจำเป็น ในเมื่อเราควบคุมการสืบทอดด้วย CSS selector ได้อยู่แล้ว ตอนนี้หมายความว่าควบคุมจากที่อื่นได้ด้วยหรือเปล่า ติดตามยาก
อีกอย่างคือสงสัยว่าทำไมต้องนิยาม type ในบล็อก @property ด้วย ใน CSS ส่วนอื่น ๆ ก็ไม่ได้นิยาม type กัน แล้วเบราว์เซอร์ดูตำแหน่งที่ใช้ @property แล้ว infer เอาไม่ได้หรือ
- ข้อดีที่ใหญ่ที่สุดสำหรับผมคือฟีเจอร์นี้ทำให้ animate ตัวแปร CSS ได้
  เมื่อก่อนตอนทดลองเปลี่ยนดีไซน์ YouTube ให้เหมือนนีออน ผมทำให้สีหลักถูกควบคุมด้วยตัวแปร CSS ตัวเดียว แล้วให้ hue ของมันค่อย ๆ เคลื่อนไปทั่วทั้งสเปกตรัม
  ถ้าไม่มี @property จะ animate ตัวแปร CSS ไม่ได้ ดังนั้นมันไม่ได้แค่เอาตัวแปรมาใช้แทนค่าดิบ แต่ทำให้ animate ตัวแปรนั้นพร้อมกับทุกตำแหน่งที่อ้างถึงตัวแปรนั้นได้ แค่ @keyframes neon-flow { from { --dc-neon-hue: 0; } to { --dc-neon-hue: 360; } } อันเดียว ก็ขยับทั้งสีหลัก เงา และอื่น ๆ ได้ทั้งหมด
  inherits: false ใช้ควบคุมว่า custom property จะสืบทอดอย่างไร จะให้สืบทอดไปยังลูกเหมือน color: red ก็ได้ หรือให้มีผลเฉพาะ element นั้นเหมือน display: flex ก็ได้
  type ดูเหมือนจำเป็นเพื่อให้รู้ตั้งแต่เชิง static ว่าจะ animate อะไร ตัวแปร CSS เป็นอะไรก็ได้ แต่ property ปกติของ CSS อย่าง color นั้นตัว property เองให้ข้อมูล type อยู่แล้ว
  จุดที่น่าสนใจคือ syntax ของ type นี้เหมือนกับ formal syntax ที่เห็นใน MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/color#forma... ให้ความรู้สึกเหมือนเอาส่วนภายในของ CSS มา expose เป็น API ที่นักพัฒนาใช้ได้
- CSS property เองมีอยู่ก่อน @property แล้ว เช่น ประกาศ --my-prop: 10px แล้วนำไปใช้ที่อื่นด้วย var(--my-prop) ได้
  ฟีเจอร์ใหม่อย่าง @property ทำให้กำหนด property ล่วงหน้าได้ว่า ควรรับ syntax type แบบไหน จะสืบทอดค่าจาก parent หรือไม่ และค่าเริ่มต้น initial-value คืออะไร
  ดังนั้นถ้า element ใส่ --my-prop: 5px ให้ property ที่ประกาศเป็นชนิดมุม ค่านั้นก็จะถูกละเลย ก่อนหน้านี้มันจะกลายเป็นค่าที่ valid และอาจทำให้เกิดผลข้างเคียงไม่คาดคิดตามตำแหน่งที่นำไปใช้
  นอกจากนี้ หากเขียนแบบ --my-prop: initial ก็ทำให้ใช้ initial-value ได้โดยไม่ต้องรู้ค่าเริ่มต้นที่แน่นอน
- ขอบคุณสำหรับคำอธิบายนี้ เข้าใจยากจริง ๆ ที่บทความไม่ได้อธิบายว่า @property ทำอะไรหรือใช้อย่างไร
  มันถูกตัวอย่างที่ซับซ้อนเกินไปบังจนหมด
เห็นเว็บไซต์นี้แล้วรู้สึกดีขึ้นมา
เดิมทีผมชอบเล่นกับ CSS อยู่แล้ว แต่พอทำเว็บมานานกว่า 10 ปี และทำงานเกี่ยวกับเว็บเป็นอาชีพ ก็ได้รู้ด้วยว่าผู้คนเกลียด CSS กันแค่ไหน
ผมใช้เวลาได้ไม่รู้จบกับการสำรวจและทดลอง HTML+CSS ที่เขียนเองด้วยมือ และถึงขั้น deploy เพื่อดูว่าบนมือถือจริง ๆ ให้ความรู้สึกอย่างไร ซึ่ง 99% ของสิ่งเหล่านั้นไม่ได้ถูกนำไปใช้ที่ไหนเลย
สำหรับคนส่วนใหญ่อาจเป็นการเสียเวลา แต่เว็บนี้ทำให้วันของผมสดใสขึ้นจริง ๆ
- ผมชอบ CSS มาก ๆ และคิดว่ามันเข้าใจง่ายพอสมควร
  ในช่วง 10 ปีที่ผ่านมามันซับซ้อนขึ้นก็จริง แต่สิ่งที่เราเคยทำเมื่อ 10 ปีก่อน ตอนนี้ทำได้ง่ายขึ้นมาก และโค้ดสมัยนั้นก็ยังทำงานอยู่
- คนที่พูดเสียงดังว่าเกลียด CSS โดยมากคือ คนที่ไม่เข้าใจ CSS
  แต่ก็ไม่เป็นไร ผมเองก็ไม่เข้าใจ APEX หรือ APL หรือเฟรมเวิร์กล่าสุดของวันนี้เหมือนกัน แต่ผมเข้าใจ CSS และเลยค่อนข้างสนุกกับมัน
  บางคนจับทางได้ บางคนจับทางไม่ได้ ปัญหาเกิดขึ้นเมื่อคนที่ไม่ถูกกับ CSS ต้องทำงานกับ CSS เพราะอาชีพ และแน่นอนว่าเขาก็ต้องเกลียดมัน ถ้างานของผมคือดูแลการติดตั้ง Active Directory ผมก็คงเกลียดเหมือนกัน แต่ไม่ได้แปลว่า CSS แย่ในตัวมันเอง
- CSS สนุกเวลานำมาเล่น และฟีเจอร์ใหม่ ๆ ก็น่าลองสำรวจ เพียงแต่ฟีเจอร์ของ CSS บางครั้งให้ความรู้สึกว่าออกมาจากบรรยากาศแบบ “เราจะสร้างอะไรเพิ่มได้อีกนะ?”
  ที่ไหนสักแห่งคงมีฟอรั่มที่ถกกันอย่างจริงจังอยู่ แต่ผมคงพลาดไป
- ตอนนี้ยังค่อนข้างมินิมอล แต่ผมกำลังลองเขียน CSS ด้วยมือมากขึ้น เพื่อให้ได้ความรู้สึกของการทำงานนอกเครื่องมืออย่าง Bootstrap หรือ Tailwind
  ใน production โดยเฉพาะ ผมแทบเขียน frontend ทั้งหมดเป็น JSX มาโดยตลอด แต่หลังจากหลุดเข้าไปในโพรงกระต่ายของงาน web scraping ความเข้าใจเรื่อง selector logic ก็ดีขึ้นมาก
  ความคิดที่ยั่วให้ถกกันอย่างหนึ่งคือ ถ้าในงานจริงเราใช้ semantic elements กันมากกว่านี้ selector logic อาจไม่กลายเป็นเรื่องปวดหัวเท่าตอนนี้ พฤติกรรมที่ HTML ล้วนกำหนดไว้แล้วอย่าง modal ก็ไม่ต้องดูแลเองด้วย
- ทันทีที่ไม่ได้แตะเฉพาะชุดอุปกรณ์·หน้าจอ·เบราว์เซอร์·เวอร์ชันเบราว์เซอร์·OS ของตัวเอง แต่ต้องทำสิ่งที่รองรับได้ค่อนข้างกว้าง การ ละเมิดสเปก เล็ก ๆ น้อย ๆ ก็ชวนหงุดหงิดจริง ๆ
  เมื่อก่อน Microsoft เป็นผู้ละเมิดสเปกที่ขึ้นชื่อที่สุด และตอนนี้ผมมองว่าเป็น Apple
แอนิเมชันพวกนี้ทำให้ทุกอย่างดูเหมือน โฆษณา display ads ยุค 2000 ในความหมายที่แย่นะ
หวังจริง ๆ ว่าสุนทรียะแบบนี้จะไม่กลับมาฮิต
- ผมก็คิดเหมือนกัน ตัวอย่าง CodePen ที่ทำได้ด้วย CSS ล้วน ๆ นั้นน่าสนใจ แต่รู้สึกว่าเยอะเกินไป และถ้าเห็นปุ่ม call-to-action อันแรกบนเว็บไซต์จริง ผมคงคิดว่ามันเชยและน่าอาย
  สิ่งพวกนี้ให้ความรู้สึกแบบ การตลาดและการชักจูง หนักมาก ผมอยากให้เขาปล่อยให้ผมอ่านเว็บแล้วตัดสินใจเองว่าจะทำอะไร ไม่อยากให้มาบังคับดึงสายตาไปยังองค์ประกอบที่ทำเงินและรบกวนการอ่าน
- ตอนแรกผมนึกว่า CodePen กำลังพยายาม upsell ผมอยู่
- สิ่งเหล่านี้เป็นสิ่งที่ทำกันอยู่แล้วในโค้ด native app ดังนั้นบนเว็บก็ควรมีฟีเจอร์ที่สอดคล้องกัน
  ไม่อย่างนั้นทุกคนก็จะไปทำกันใน ระบบนิเวศแบบปิด แทน
PFM หรือคำว่า “Pure Fucking Magic” เป็นความรู้สึกที่ตรงเป๊ะเมื่อเห็นสิ่งที่ทำได้ด้วย CSS animations
แต่เพราะมันถูกออกแบบมาเฉพาะทางมาก ๆ เพื่อ CSS และเพื่อ CSS เท่านั้น เลยเรียนรู้และสร้างภาพในหัวได้ยากกว่าการทำแบบ procedural ด้วย JS ผมคิดแบบนั้นไม่ค่อยออก แค่ตัวเลือกการใช้ CSS flex ก็หนักพอแล้ว
- CSS ให้ความรู้สึกเหมือนเป็น ดินแดนต่างดาว ของตัวเองจริง ๆ การที่ syntax แปลกตาสำหรับนักพัฒนาส่วนใหญ่ก็ไม่ได้ช่วยอะไร
  แต่มันทรงพลัง และทรงพลังอย่างมหาศาลจริง ๆ แถมยังมีประสิทธิภาพมากในเบราว์เซอร์ส่วนใหญ่ นักพัฒนาเว็บแอปส่วนใหญ่อย่างท่วมท้นไม่จำเป็นต้องใช้ 99% ของสิ่งที่ CSS มีให้ แต่การรู้ว่ามีความสามารถแบบนั้นอยู่ก็เจ๋งดี
- ดังนั้นผมเลยจ้าง ดีไซเนอร์ที่เขียน HTML+CSS ได้
  พอผมโยนองค์ประกอบที่ยังไม่มีสไตล์แต่เชื่อมกับ business logic ไว้บนหน้า ดีไซเนอร์ก็จัดสไตล์ได้ตามที่ต้องการ ถ้าจำเป็นค่อยวนปรับ UI ภายหลังได้
- มันเป็น paradigm แบบ declarative เหมือน SQL
  ถ้ามองจากมุม imperative ล้วน ๆ ก็ต้องใช้เวลาอ่านสเปกและทดลองอยู่บ้าง แต่ผมมองว่าเป็นวิธีคิดที่คุ้มค่ามากกว่าการใช้ SQL กับ CSS เสียอีก แน่นอนว่า SQL กับ CSS เองก็คุ้มค่าอยู่แล้ว
- JS เป็นทางเลือกสุดท้ายเสมอ จริง ๆ คือเสมอ ในช่วงไม่กี่ปีมานี้เมื่อฟีเจอร์ CSS เข้ามาในเบราว์เซอร์ส่วนใหญ่ ผมก็ลบ JS ออกจากโค้ดไปเยอะ และชอบทำหน้าให้เป็น JavaScript Zero
  ถ้าแค่ตั้งชื่อฟีเจอร์ CSS “masonry”[1] ให้เสร็จ แล้วทำให้ใช้ได้โดยไม่ต้องมีสคริปต์ ผมคงดีใจมาก
  [1] https://github.com/w3c/csswg-drafts/issues/9733
- ในกรณีนี้ property เป็นส่วนหนึ่งของ CSS Houdini API และทำให้สามารถจัดการ CSS จาก JavaScript ได้ทรงพลังกว่าเดิมมาก
  https://developer.mozilla.org/en-US/docs/Web/API/Houdini_API...
ความกระตือรือร้นที่ผู้เขียนมีต่อชิ้นส่วน CSS ใหม่ ๆ นี้เป็นระดับที่แทบไม่ได้เห็นมาเกือบ 10 ปีแล้ว และนั่นก็ดีมาก
ถ้าผมยังอยู่ในวัย 20 คงใช้เวลาหลายชั่วโมง หลายวัน ลองเล่นกับความเป็นไปได้ของฟีเจอร์นี้ การทำให้บางอย่างทำงานใน CSS เคยเป็นเรื่องสนุก
ตอนนี้มันง่ายขึ้นมากด้วย flexbox, grid และการที่เว็บไซต์กับแอปส่วนใหญ่ทำตามหลักการออกแบบมาตรฐาน ผมมองว่า Web UI ส่วนใหญ่แทบจะเป็น ปัญหาที่แก้ได้แล้ว
- อยากรู้ว่า หลักการออกแบบมาตรฐาน นั้นคืออะไร
- ไม่เข้าใจว่าอะไรที่ถูกแก้แล้ว หมายถึง layout เหรอ?
  ผมยังต้องกลับไปอ่านจุดกำกวมของ flex กับ grid อยู่เรื่อย ๆ การกำหนดตำแหน่งแบบ sticky เป็นหนึ่งในฟีเจอร์ที่มีประโยชน์ที่สุด แต่ถ้ามันใช้ไม่ได้ไม่ว่าด้วยเหตุผลใด การดีบักและเข้าใจสาเหตุนั้นยากมากหรือแทบเป็นไปไม่ได้ เช่นปัญหาว่ามีพาเรนต์ตัวใดตัวหนึ่งมี overflow หรือไม่
  เอกสารที่อธิบาย edge cases แบบนี้ได้ดีก็หายาก และการดีบัก CSS จากซอร์สโค้ดอย่างเดียวโดยไม่ใช้ developer tools นั้นแทบเป็นไปไม่ได้ ต้อง inspect องค์ประกอบตอน runtime
  องค์ประกอบ input แบบ native ส่วนใหญ่ยังปรับสไตล์ได้จำกัดมาก และ native modal กับ popover ก็ต้องรอกันมาหลายปี ครั้งล่าสุดที่เช็กก็ยัง animate ความสูงจาก display: none ไปเป็น block ไม่ได้ด้วยซ้ำ
  ผมสงสัยว่าเราอาจคุ้นชินกับปัญหาต่าง ๆ ของ CSS มากเกินไปจนความรู้สึกวิพากษ์วิจารณ์หายไปแล้วหรือเปล่า

CSS @property และสไตล์รูปแบบใหม่

แอนิเมชัน custom property ที่ @property เปิดทางให้

ขอบเงาวาวแบบหมุนของปุ่ม CTA

ขอบเงาวาวที่สร้างด้วยเลเยอร์พื้นหลัง

กราดิเอนต์ที่เปลี่ยนอย่างลื่นไหลเมื่อ hover

วิธีชะลอความเร็วการหมุนระหว่าง hover

ประกายเล็ก ๆ และไฮไลต์ภายใน

การปรับสี hover และความสมบูรณ์ของงาน

ความเป็นไปได้ที่ต่อยอดไปสู่ design system

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

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

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

แอนิเมชัน custom property ที่ `@property` เปิดทางให้