คำแนะนำเกี่ยวกับ CSS `font-family`

 (chrismorgan.info)
1 คะแนน โดย GN⁺ 12 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หากออกแบบเว็บโดยเชื่อชื่อฟอนต์เฉพาะมากเกินไป ดีไซน์อาจพังได้ตามแพลตฟอร์ม เครือข่าย และการตั้งค่าความปลอดภัย ดังนั้นควรเขียน font-family โดยตั้งอยู่บนสมมติฐานว่าจะมี generic family fallback
  • สำหรับโค้ด งานอาร์ตเวิร์ก หรือเลย์เอาต์ที่ต้องการการแสดงผลแบบความกว้างคงที่ ต้องใส่ monospace ไว้เสมอ และถ้าต้องการให้ serif กับ sans-serif รับประกันตระกูลฟอนต์ที่ต้องการ ก็ควรระบุไว้ด้วยเพื่อความปลอดภัย
  • การทำสแตกด้วยการไล่รายชื่อฟอนต์ที่น่าจะมีอยู่ในเครื่องยาว ๆ มักได้ประโยชน์ไม่มาก และ ค่าเริ่มต้นของ generic family ในเบราว์เซอร์อาจเลือกตัวที่ดีกว่าได้ด้วยซ้ำ
  • เว็บฟอนต์ช้ากว่าการไม่มีเว็บฟอนต์ และยังสร้างปัญหาโหลดไม่สำเร็จรวมถึงทางเลือกแบบประนีประนอมของ font-display ดังนั้นสำหรับคอนเทนต์ การใช้ ฟอนต์เริ่มต้นของผู้ใช้ ตรง ๆ ก็เป็นตัวเลือกที่ใช้งานได้จริง
  • system-ui และ ui-* มีลักษณะเหมาะกับข้อความ UI สั้น ๆ มากกว่า จึงอาจไม่เหมาะกับคอนเทนต์ยาวและการรองรับภาษา และเสี่ยงหากใช้เป็นตัวแทนฟอนต์เริ่มต้นสำหรับคอนเทนต์

อย่าเชื่อชื่อฟอนต์มากเกินไป

  • ไม่มี web-safe font ที่มีให้เหมือนกันบนทุกแพลตฟอร์มหลัก ดังนั้นไม่ควรสมมติว่าชื่อฟอนต์ใดชื่อหนึ่งจะใช้งานได้เสมอ
  • เว็บฟอนต์ก็ไม่ใช่คำตอบที่แน่นอน
    • รีซอร์สย่อยที่ไม่ได้ inline อาจโหลดไม่สำเร็จได้จากหลายเหตุผลทางเครือข่าย
    • การโหลดฟอนต์เป็นพื้นที่ที่มีข้อกังวลด้านความปลอดภัย จึงอาจถูกบล็อกในบางสภาพแวดล้อม
    • uBlock Origin มีปุ่มเฉพาะสำหรับปิดใช้งานฟอนต์จากระยะไกล
    • โหมดประหยัดข้อมูลของบางเบราว์เซอร์อาจบล็อกการโหลดฟอนต์ และแม้กรณีที่ยังไม่บล็อก ก็ควรบล็อกด้วยซ้ำตามมุมมองนี้
  • หากผู้ใช้ไม่อนุญาตให้เว็บไซต์เลือกฟอนต์เอง จะใช้งานได้เพียง generic family เท่านั้น
  • หากใช้ document.fonts.load("1em my-web-font") ใน JavaScript Promise ที่คืนกลับมาอาจ reject ได้
    • ในช่วง 6 ปีระหว่าง 2020–2025 มีเคสที่พังเพราะปัญหานี้ประมาณ 4 ครั้ง และในนั้น 2 ครั้งเกิดขึ้นในปี 2025

ต้องระบุตระกูล fallback เสมอ

  • ถ้าต้องการข้อความแบบความกว้างคงที่ ต้องใส่ monospace ลงใน font-family เสมอ
    • การขาด monospace อาจไม่ปรากฏให้ผู้ใช้ส่วนใหญ่เห็น แต่ในบางสภาพแวดล้อมอาจทำให้เลย์เอาต์หรืองานที่ตั้งใจไว้เสียไป
    • ตัวอย่างเช่น ASCII might fly? ของ Adel Faure ตอนเขียนบทความนี้ยังไม่มี monospace จึงอาจแสดงผลแบบไม่ใช่ความกว้างคงที่ได้
  • สำหรับ serif หรือ sans-serif ก็ควรใส่ไว้เช่นกันหากต้องการ fallback ของตระกูลฟอนต์ที่ต้องการ
    • ตัวอย่าง: font-family: Arial, sans-serif;
    • ตัวอย่าง: font-family: Times New Roman, serif;
    • ถ้าไม่ใส่ ระบบจะใช้ฟอนต์เริ่มต้น ซึ่งอาจเป็น serif หรืออาจเป็นอย่างอื่นไปเลยก็ได้

ลดการไล่รายชื่อฟอนต์ที่น่าจะติดตั้งอยู่

  • การไล่ฟอนต์ที่น่าจะมีในระบบยาว ๆ เช่น Arial, Helvetica, Helvetica Neue, Liberation Sans, Noto Sans โดยทั่วไปไม่ได้ช่วยมากนัก
  • โดยเฉพาะ Arial ผู้เขียนมองว่าไม่มีกรณีไหนที่เป็นตัวเลือกดีกว่า sans-serif
  • sans-serif อาจถูกตีความเป็นฟอนต์ที่ไม่แย่ไปกว่าฟอนต์ที่ระบุไว้ และยังมีโอกาสถูกเลือกเป็นฟอนต์ที่ดีกว่าด้วย
  • ตัวอย่างการประกาศฟอนต์แบบความกว้างคงที่ที่พบจริงมีรายการยาวเกินจำเป็น
    • font-family: Menlo, Monaco, Lucida Console, Liberation Mono, DejaVu Sans Mono, Bitstream Vera Sans Mono, Courier New, monospace, serif
    • การประกาศนี้แย่กว่า font-family: monospace, monospace อย่างชัดเจน และ monospace อาจถูกตีความเป็นฟอนต์ที่ไม่แย่ไปกว่ารายการทั้งหมดนี้
  • ไม่จำเป็นต้องห้ามใช้ฟอนต์แบบมีชื่อที่ไม่ใช่เว็บฟอนต์ทั้งหมด แต่เหมาะจะมี ไม่เกินหนึ่งตัว
    • Georgia) และ Times New Roman ต่างก็เป็น serif ใน Core fonts for the Web ของ Microsoft แต่มีคาแรกเตอร์ต่างกัน
    • Georgia กว้างกว่า Times New Roman มาก ดังนั้นถ้าต้องการคุณลักษณะนี้เชิงสไตล์ font-family: Georgia, serif ก็ถือเป็นตัวเลือกที่ยอมรับได้
  • modernfontstacks.com และที่เก็บโค้ด มีไอเดียการเลือกฟอนต์ตามแพลตฟอร์ม
    • อย่างไรก็ตาม มีการแนะนำฟอนต์แบบมีชื่อมากเกินไป และหลายตัวควรถูกตัดออกจะดีกว่า
    • การจัดการกับ Courier New ผิดพลาดอย่างมาก และภาพประกอบดูเหมือนสร้างด้วย macOS Courier

ทางเลือกของการใช้แต่ generic family

  • เมื่อคุณลดการไล่รายชื่อฟอนต์ที่ติดตั้งในเครื่องแล้ว ก็อาจกลับมาทบทวนได้ว่าเว็บฟอนต์จำเป็นจริงหรือไม่
  • เว็บฟอนต์ช้ากว่าการไม่มีเว็บฟอนต์ และอาจสร้างปัญหาเรื่องการโหลด
    • นี่จึงเป็นเหตุผลที่มี font-display
    • แต่แทนที่จะต้องจัดการกับการประนีประนอมระหว่างช่วง block·swap การวาดใหม่ และ reflow ก็สามารถเลือกใช้ฟอนต์ที่ผู้ใช้มีอยู่แล้วตรง ๆ ได้
  • แม้แต่ monospace ก็เลือกใช้เฉพาะ generic family ได้
    • ในอดีตค่าเริ่มต้นของ monospace ไม่ค่อยดี โดยเฉพาะ Courier New#Courier_New) ของ Microsoft ที่ถูกดิจิไทซ์อย่างผิดพลาดจนดูเหมือนมีน้ำหนัก 200–250 มากกว่า 400
    • ต่อมา Apple เปิดตัว Menlo) และในช่วงที่ค่าเริ่มต้น monospace ของเบราว์เซอร์ยังไม่อัปเดต ผู้คนก็เริ่มใส่ Menlo ลงในฟอนต์สแตก
    • ปัจจุบันค่าเริ่มต้นของเบราว์เซอร์ดีขึ้นหมดแล้ว แม้จะไม่ได้ยอดเยี่ยมทุกกรณี แต่ก็ไม่ได้แย่อีกต่อไป
  • จึงสามารถทิ้งรายการอย่าง Menlo, Monaco, Consolas, Bitstream Vera Sans Mono, Courier, Courier New แล้วเหลือแค่ monospace ได้
  • การใส่ Courier New ลงในฟอนต์สแตกอย่างจงใจถูกประเมินในแง่ลบอย่างมาก

monospace, monospace และพฤติกรรมของเบราว์เซอร์

  • หากระบุหรือใช้ font-family: monospace; แบบชัดเจนหรือโดยนัย font-size เริ่มต้นอาจไม่ได้เป็น 100% แต่เป็น 81.25%
    • ผู้ใช้สามารถเปลี่ยนฟอนต์ generic family ขนาดตัวอักษรเริ่มต้น และขนาดตัวอักษรแบบความกว้างคงที่เริ่มต้นได้
  • ถ้ามี family ตัวที่สองอยู่ในรายการ พฤติกรรมนี้จะไม่เกิดขึ้น
    • font-family: my-web-font, monospace; ใช้ได้
    • font-family: monospace, monospace; ก็ใช้ได้
    • หรือจะกำหนด font-size เองโดยตรงก็ได้
  • Lightning CSS มีปัญหาที่ทำให้ monospace, monospace พัง
  • ปัญหานี้กระทบเฉพาะ monospace
  • ผู้เขียนอยากผลักดันให้เบราว์เซอร์เลิกพฤติกรรมเรื่องขนาดของ monospace และน่าจะปรับค่าที่น่าจะเป็น 13px ให้ขึ้นมาเป็น 16px
    • สถานที่เสนออาจเป็น CSSWG

อย่าใช้ system-ui และ ui-* กับคอนเทนต์

  • ฟอนต์ UI มีไว้สำหรับข้อความ UI สั้น ๆ ไม่ใช่สำหรับ คอนเทนต์ยาว
  • ฟอนต์ UI อาจรองรับภาษาของคอนเทนต์ได้ไม่ดี
  • ผู้ใช้บางคนตั้งใจเลือกฟอนต์ระบบ UI ที่ดูตลก ๆ ไว้เอง และว่ากันว่าพบได้ค่อนข้างบ่อยในบางคอมมูนิตี้ Android
    • ถ้าใช้ system-ui คอนเทนต์ก็อาจหน้าตาเป็นแบบนั้นด้วย
  • w3c/csswg-drafts issue #3658 พูดถึงปัญหาหลายอย่างของ system-ui และสรุปว่า system-ui ถูกนำไปใช้ผิดวัตถุประสงค์อย่างกว้างขวาง
  • mdn/content issue #41244 เพิ่มโน้ตเตือนเรื่องการใช้งานมากเกินไปใน MDN
  • system-ui และ ui-* ถูกใช้เหมือนเป็น proxy เพื่อให้ได้ฟอนต์เริ่มต้นที่ดีกว่า แต่การใช้แบบนี้ไม่ดี
  • ผู้เขียนมองว่า system-ui เป็นความผิดพลาด
    • ควรเหลือเพียง -apple-system และให้ BlinkMacSystemFont เปลี่ยนมาเป็นตัวนั้น
    • ตอนที่ทำให้เป็นมาตรฐาน แพลตฟอร์มอื่นยังไม่มีแนวคิดที่เทียบเท่ากันและมีประโยชน์ ส่วนตอนนี้บางแพลตฟอร์มจึงค่อยมีขึ้นมา
    • ผู้เขียนมองว่าการใช้งานส่วนใหญ่เป็นการใช้ผิดวัตถุประสงค์เพื่อเลี่ยงปัญหาที่เบราว์เซอร์ไม่ยอมอัปเดตค่าเริ่มต้นเก่าของ generic family
  • ui-serif, ui-sans-serif, ui-monospace และโดยเฉพาะ ui-rounded ถูกมองว่าเป็นความผิดพลาดชัดเจนที่ควรถูกถอดออก
    • นอกสภาพแวดล้อมของ Apple ก็ไม่ควรคาดหวังว่าจะถูกแมปไปยังฟอนต์ใดเลย
    • แนวคิดนี้มีอยู่เฉพาะบนแพลตฟอร์ม Apple จึงไม่ควรถูกใส่ไว้ในมาตรฐาน
    • หาก Apple จะให้มาก็ควรเป็นรูปแบบมีคำนำหน้า -apple เหมือน -apple-system
  • มีกรณีใช้งาน system-ui กับเว็บแอปที่สมเหตุสมผลอยู่บ้าง แต่ความรู้สึกคือในทางปฏิบัติแทบทั้งหมดถูกใช้ผิดวัตถุประสงค์ และการแทรกแซงเพื่อนำออกก็อาจไม่ใช่เรื่องเลวร้าย

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

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

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

  • ที่ https://lindenii.org เลือกแนวทาง ไม่กำหนด font-family ไปเลย เพื่อเคารพฟอนต์เริ่มต้นที่ผู้ใช้เลือกไว้ในเบราว์เซอร์
    โดยส่วนตัวฉันชอบ sans-serif มากกว่า แต่ถ้าผู้ใช้ตั้งค่า serif เป็นค่าปริยายอยู่ ก็ไม่เห็นเหตุผลว่าทำไมต้องไปเขียนทับ
    แต่ในกรณีที่ต้องใช้ตัวอักษรที่ฟอนต์ส่วนใหญ่ไม่มี เช่น https://runxiyu.org/soc/ta/ ก็เลี่ยงไม่ได้ที่จะต้องใส่เว็บฟอนต์ และผลก็คือข้อความส่วนที่เหลือทั้งหมดถูกบังคับให้เป็น sans-serif แทนค่าปริยายของผู้ใช้ด้วย
    นอกจากจะห่ออักขระแปลก ๆ แต่ละตัวด้วยอะไรอย่าง <unusual-character> ก็ไม่แน่ใจว่ามีวิธีที่ดีกว่านี้ไหม และคงจะดีถ้ามีวิธีกำหนดอะไรอย่าง “ฟอนต์สำหรับโค้ดที่ผู้ใช้ชอบ” ได้
    ขอบคุณสำหรับเทคนิค monospace, monospace ด้วย เรื่องความต่างของขนาดนี่ทำให้งงพอสมควร

    • สำหรับปัญหาข้อที่สอง การแสดง ภาพทดแทน ข้างอักขระพิเศษอาจเป็น fallback ที่ใช้ได้
      เว็บไซต์ที่ทำรายการอักขระ Unicode ก็จัดการแบบนั้น
    • บนบล็อกของฉัน https://hauleth.dev ก็ทำคล้ายกัน แต่ใช้ monospace
      เคยมีคนชมดีไซน์เว็บนี้เหมือนกัน แต่จริง ๆ คือเอาธีม Zola มาใช้แล้วลด CSS กับองค์ประกอบคัสตอมลงเท่านั้น ดังนั้นโดยเฉพาะกับหน้าเว็บส่วนตัว ฉันค่อนข้างเห็นด้วยกับประเด็นของบทความนี้
    • ฝั่งที่เลือก ไม่กำหนด font-family เลย มองว่าคงจะดีกับผู้ใช้มากกว่าถ้าฟอนต์เริ่มต้น ตามค่าปริยายจริง ๆ ของเบราว์เซอร์เปลี่ยนจาก serif เป็น sans-serif
      ผู้ใช้ส่วนใหญ่ไม่ได้เลือกฟอนต์เอง จึงไม่มีทางแยกได้ว่าอะไรคือ “ฟอนต์ที่ผู้ใช้เลือก” กับ “ฟอนต์ค่าปริยายของเบราว์เซอร์”
      ถึงฉันจะชอบ serif แต่ทุกวันนี้คนส่วนใหญ่น่าจะชอบ sans-serif มากกว่า
      ในสภาพแวดล้อมของฉัน ฉันบล็อกไม่ให้หน้าเว็บกำหนดฟอนต์ และก็ไม่ได้ติดตั้งฟอนต์ CJK ที่ดี ๆ ด้วย
      เพราะถึงจะแสดงกล่องเขียนว่า “4E2D” แทนตัวอักษรจีน สำหรับฉันมันก็มีความหมายไม่ต่างจากอักษรภาพนั้นอยู่ดี
      ระบบ fallback ฟอนต์แบบนั้นทำได้ดีแล้ว แต่น่าเสียดายที่ไม่มีวิธีระบุชื่อฟอนต์ค่าปริยายโดยตรง
      แต่ถ้าใช้ JavaScript ดู getComputedStyle(document.documentElement).fontFamily ในเอกสารว่าง จะเห็นเป็น "serif" หรือ "sans-serif" ตามการตั้งค่าฟอนต์ขั้นสูงของฉัน
      ไม่แน่ใจเหมือนกันว่า “ฟอนต์ที่ชอบสำหรับโค้ด” หมายถึงอะไรกันแน่ ดูเหมือนจะหมายถึงอย่างอื่นที่ไม่ใช่ monospace

  • บทความนี้ยังเป็น ร่าง อยู่ เลยยังไม่สมบูรณ์มาก และดูเป็นการเอาเศษชิ้นส่วนจากหลายรูปแบบมาปะปนกันอยู่สองสามอย่าง จึงค่อนข้างรก
    สุดท้ายแล้วน่าจะยาวเกินหนึ่งหน้า และอาจออกมาในรูปแบบที่ต่างจากตอนนี้มาก บางส่วนอาจเป็นลายมือ ภาพวาดมือ หรือเลย์เอาต์ทำมือด้วย
    ช่วงนี้กลับไปโฟกัสกับการทำ lightweight markup language แทน ซึ่งตอนนี้เกือบใช้งานได้แล้ว แบบที่รู้สึกว่า 90% สุดท้ายนั้นไม่เคยเหลือน้อยลงเลย
    จากนั้นค่อยกลับมาเขียนบทความและเผยแพร่อีกที

  • ตรงที่บอกว่าใช้ font-family: monospace; แล้ว font-size อาจถูกตั้งค่าปริยายเป็น 81.25% แทน 100% แต่ถ้ามีฟอนต์ตัวที่สองในรายการจะไม่เกิดปัญหานั้น น่าสนใจมาก
    แปลว่า font-family: my-web-font, monospace; หรือ font-family: monospace, monospace; ใช้ได้ แต่ดูเหมือน MDN ยังไม่ได้บันทึกเรื่องนี้ไว้ในเอกสารตอนนี้
    เลยสงสัยว่ามีใครอธิบายได้ไหมว่าทำไมถึงเป็นแบบนี้ และทำไมถึงยังไม่ได้ถูกทำเป็นเอกสาร

    • ถ้าจำไม่ผิด Firefox ไม่ได้ทำ การปรับขนาดฟอนต์ นี้จริง ๆ แต่ Chrome ทำ
      เลยกลายเป็นสาเหตุหนึ่งของความไม่สอดคล้องกันระหว่างเบราว์เซอร์
    • เป็นไปได้ว่าตั้งใจให้ข้อความแบบ fixed-width ดู มีขนาดทางสายตาเท่ากัน กับข้อความเนื้อหาปกติ

  • ถึงจะเป็นร่าง แต่ก็มี การซ้ำแบบแปลก ๆ ที่เหมือนคัดลอกทั้งเซกชันแล้ววางซ้ำเป็นครั้งที่สอง
    โดยเฉพาะเพราะมันให้ความรู้สึกเหมือนบอกว่าฟอนต์ fixed-width ที่ฉันชอบนั้นไม่ค่อยดี เลยยิ่งสะดุดตา

    • ยังอยู่ระหว่างจัดโครงสร้างใหม่ เลยยังมีส่วนแบบนั้นหลงเหลืออยู่
      ถ้าอ่านละเอียดจะเห็นว่ากำลังแยกแยะว่าอะไรควรเป็นคำแนะนำที่ชัดเจน และอะไรควรใช้จุดยืนที่ละเอียดอ่อนกว่านั้น จึงมีความขัดแย้งเล็ก ๆ อยู่บ้าง
      อยากรู้ว่าฟอนต์ fixed-width ที่คุณชอบคืออะไร

  • เหตุผลหนึ่งที่ทำให้ไม่อยากใช้แค่ serif กับ sans-serif คือฟอนต์ serif ค่าปริยายมักเป็น Times ซึ่งบางครั้งก็รู้สึกว่าไม่ค่อยดี
    เพราะแบบนั้นฉันจึงกำลังย้ายฟอนต์เนื้อหาจาก serif ไปเป็น sans-serif

  • เกี่ยวกับคำแนะนำว่า “อย่าไล่รายชื่อฟอนต์ที่น่าจะมีติดตั้งในระบบ” และ “แม้แต่ fixed-width ก็ควรใช้แค่ generic family ถ้าเป็นไปได้” บนเว็บไซต์ของฉันตั้งค่าไว้ประมาณนี้
    ใช้ --sans-serif: Adwaita Sans, Adwaita Sans Bundled, Inter, sans-serif; และ --monospace: Iosevka, Iosevka Web, Cascadia Code, monospace;
    เจตนาคือ ถ้า GNOME มี Adwaita Sans ติดตั้งอยู่แล้ว ก็จะใช้ฟอนต์ระบบและไม่ต้องดาวน์โหลดเว็บฟอนต์ แต่ถ้าไม่มี ก็จะใช้เว็บฟอนต์ Adwaita Sans Bundled และระหว่างโหลดจะ fallback ไปที่ Inter กับ sans-serif ซึ่งมี metrics ใกล้เคียงกัน
    ฝั่ง fixed-width ก็เหมือนกัน คือถ้าระบบมี Iosevka ก็ใช้ไปเลย ถ้าไม่มีค่อยใช้เว็บฟอนต์ Iosevka Web และระหว่างโหลด fallback ไปที่ Cascadia Code กับ monospace
    ยังคิดเผื่อด้วยว่า monospace บน Windows เป็น Consolas ซึ่งไม่ค่อยถูกใจ และ Windows รุ่นใหม่ก็มักติดตั้ง Cascadia Code มาแล้ว
    ฉันรู้ว่า Cascadia Code มี metrics ต่างจาก Iosevka มาก ซึ่งน่าจะเป็นข้อเสีย แต่อยากรู้ว่าคนอื่นมองแนวทางนี้อย่างไร

    • ฉันแทบไม่มีความรู้ด้านเว็บโปรแกรมมิงเลย อาจกำลังพลาดวิธีที่ดีกว่าในการระบุว่า “ให้ดาวน์โหลดฟอนต์เฉพาะเมื่อไม่มีติดตั้งในระบบ” ก็ได้

  • เป็นบทความที่อ่านลื่นดี และฉันไม่เคยรู้เทคนิค monospace, monospace มาก่อนเลย
    มีปัญหาเรื่องฟอร์แมตเล็กน้อยคือ ในเบราว์เซอร์ของฉัน ข้อความในย่อหน้า .unimportant อยู่บนพื้นหลังสีเหลืองก็จริง แต่กลับไปซ้อนอยู่หลังข้อความของแถบ .status ที่ตรึงไว้ ทำให้ตอนเลื่อนผ่านช่วง .unimportant ดูแปลก ๆ
    ดูเหมือนจะมีปัญหาคล้ายกันกับ ลายน้ำ DRAFT แบบทแยงด้วย