Khuyến nghị về `font-family` trong CSS

 (chrismorgan.info)
1 điểm bởi GN⁺ 12 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi thiết kế web mà tin vào một tên phông cụ thể, giao diện có thể bị vỡ tùy theo nền tảng, mạng hoặc thiết lập bảo mật, nên cần xây dựng font-family với giả định có fallback theo họ chung
  • Với code, artwork hoặc bố cục cần hiển thị đơn cách, bắt buộc phải bao gồm monospace; với serif và sans-serif cũng nên chỉ định kèm nếu muốn đảm bảo đúng họ phông mong muốn
  • Các stack liệt kê dài những phông có vẻ như sẽ có sẵn trên máy cục bộ thường ít mang lại lợi ích thực tế, và giá trị mặc định của họ chung trong trình duyệt đôi khi còn có thể đưa ra lựa chọn tốt hơn
  • Web font chậm hơn so với trường hợp không dùng, lại có thể thất bại khi tải và buộc phải thỏa hiệp với font-display, nên với nội dung, dùng nguyên phông mặc định của người dùng cũng là một lựa chọn thực tế
  • system-ui và ui-* mang tính chất UI ngắn gọn nhiều hơn, nên có thể không phù hợp với nội dung dài và hỗ trợ ngôn ngữ; dùng chúng như phương án thay thế phông mặc định cho nội dung là khá rủi ro

Không tin vào tên phông

  • Không có web safe font nào được cung cấp chung trên mọi nền tảng lớn, nên không nên giả định rằng một tên phông cụ thể lúc nào cũng hoạt động
  • Web font cũng không phải lời giải chắc chắn
    • Tài nguyên phụ không được inline có thể thất bại khi tải vì nhiều lý do mạng
    • Tải phông là một khu vực có lo ngại bảo mật nên có thể bị chặn trong một số môi trường
    • uBlock Origin có nút riêng để vô hiệu hóa phông từ xa
    • Chế độ tiết kiệm dữ liệu của một số trình duyệt có thể chặn việc tải phông, và ngay cả nơi chưa chặn thì cũng có quan điểm cho rằng nên chặn
  • Nếu người dùng không cho phép website tự chọn phông, thì chỉ họ chung là hoạt động
  • Trong JavaScript, nếu dùng document.fonts.load("1em my-web-font"), Promise trả về có thể bị reject
    • Trong 6 năm từ 2020–2025, đã thấy khoảng 4 trường hợp bị vỡ vì vấn đề này, trong đó 2 trường hợp xảy ra vào năm 2025

Nhất định phải chỉ rõ họ thay thế

  • Nếu cần văn bản đơn cách, nhất định phải đưa monospace vào font-family
    • Việc thiếu monospace có thể không lộ ra với nhiều người dùng, nhưng trong một số môi trường sẽ phá hỏng bố cục hoặc ý đồ của tác phẩm
    • Ví dụ, ASCII might fly? của Adel Faure tại thời điểm viết bài thiếu monospace, nên có thể hiển thị ở dạng không đơn cách
  • Với serif hay sans-serif, nếu cần fallback đúng họ phông mong muốn thì cũng nên kèm vào
    • Ví dụ: font-family: Arial, sans-serif;
    • Ví dụ: font-family: Times New Roman, serif;
    • Nếu không thêm, phông mặc định sẽ được dùng, và phông mặc định có thể là serif, nhưng cũng có thể là thứ hoàn toàn khác

Giảm việc liệt kê các phông có lẽ đã được cài sẵn

  • Cách liệt kê dài những phông có vẻ sẽ có trên hệ thống như Arial, Helvetica, Helvetica Neue, Liberation Sans, Noto Sans nhìn chung không giúp ích nhiều
  • Đặc biệt, Arial được xem là không bao giờ là lựa chọn tốt hơn sans-serif
  • sans-serif có thể được diễn giải thành một phông không tệ hơn các phông được liệt kê, và cũng có khả năng chọn được phông tốt hơn
  • Ví dụ khai báo đơn cách từng thấy ngoài thực tế có danh sách dài quá mức
    • font-family: Menlo, Monaco, Lucida Console, Liberation Mono, DejaVu Sans Mono, Bitstream Vera Sans Mono, Courier New, monospace, serif
    • Khai báo này tệ hơn hẳn font-family: monospace, monospace, và monospace có thể được diễn giải thành một phông không tệ hơn danh sách đó
  • Không nhất thiết phải cấm hoàn toàn các phông không phải web font nhưng có tên cụ thể, nhưng tối đa một là hợp lý
    • Georgia) và Times New Roman đều là serif thuộc Core fonts for the Web của Microsoft, nhưng tính chất khác nhau
    • Georgia rộng hơn Times New Roman rất nhiều, nên nếu về mặt phong cách cần đặc điểm đó thì font-family: Georgia, serif là một lựa chọn chấp nhận được
  • modernfontstacks.com và kho lưu trữ đưa ra ý tưởng chọn phông theo từng nền tảng
    • Tuy vậy, chúng bị đánh giá là kê đơn quá nhiều phông có tên cụ thể, và khá nhiều trong số đó tốt hơn là nên bỏ đi
    • Cách xử lý Courier New là sai đáng kể, và hình minh họa trông như được tạo bằng macOS Courier

Lựa chọn chỉ dùng họ chung

  • Nếu đã giảm việc liệt kê phông cài cục bộ, có thể xem lại liệu web font có thực sự cần thiết hay không
  • Web font chậm hơn so với không dùng web font, và có thể tạo ra vấn đề tải
    • Vì thế mới có font-display
    • Nhưng thay vì xử lý các đánh đổi giữa thời gian block·swap, vẽ lại và reflow, cũng có thể chọn dùng nguyên phông mà người dùng đang có
  • Với monospace cũng có thể chọn cách chỉ dùng họ chung
    • Trước đây giá trị mặc định của monospace không tốt, đặc biệt Courier New#Courier_New) của Microsoft bị số hóa sai nên trông như weight 200–250 thay vì 400
    • Sau đó Apple đưa vào Menlo), và trong thời gian giá trị mặc định monospace của trình duyệt chưa được cập nhật, mọi người bắt đầu thêm Menlo vào stack phông
    • Hiện nay mặc định của trình duyệt đều đã tốt hơn, và dù chưa tuyệt vời trong mọi trường hợp thì cũng không còn tệ nữa
  • Có thể bỏ các danh sách như Menlo, Monaco, Consolas, Bitstream Vera Sans Mono, Courier, Courier New và chỉ để lại monospace
  • Việc cố ý đưa Courier New vào stack phông bị đánh giá rất tiêu cực

monospace, monospace và hành vi của trình duyệt

  • Nếu khai báo font-family: monospace; một cách tường minh hoặc ngầm định, font-size mặc định có thể không phải 100% mà là khoảng 81.25%
    • Người dùng có thể thay đổi phông họ chung, cỡ chữ mặc định, và cỡ chữ đơn cách mặc định
  • Nếu trong danh sách có family thứ hai thì hành vi này không xảy ra
    • font-family: my-web-font, monospace; thì ổn
    • font-family: monospace, monospace; cũng ổn
    • Cũng có thể tự chỉ định font-size trực tiếp
  • Lightning CSS có vấn đề làm hỏng monospace, monospace
  • Vấn đề này chỉ ảnh hưởng tới monospace
  • Quan điểm ở đây là muốn thuyết phục trình duyệt bỏ hành vi kích thước riêng cho monospace, có lẽ nâng giá trị khoảng 13px lên khoảng 16px
    • Nơi để đề xuất có thể là CSSWG

Không dùng system-ui và ui-* cho nội dung

  • Phông UI là dành cho văn bản UI ngắn, không phải cho nội dung dài
  • Phông UI có thể không hỗ trợ tốt ngôn ngữ của nội dung
  • Một số người dùng cố ý chọn phông UI hệ thống trông buồn cười, và điều này được cho là khá phổ biến trong một số cộng đồng Android
    • Nếu dùng system-ui, nội dung cũng có thể hiển thị như vậy
  • w3c/csswg-drafts issue #3658 thảo luận nhiều vấn đề của system-ui, và đi đến kết luận rằng system-ui đã bị lạm dụng trên diện rộng
  • mdn/content issue #41244 thêm một note cảnh báo việc dùng quá mức trên MDN
  • system-ui và ui-* từng được dùng như một dạng proxy để có được phông mặc định tốt hơn, nhưng cách dùng đó là không tốt
  • Quan điểm ở đây là system-ui là một sai lầm
    • Đáng ra chỉ nên giữ -apple-system và để BlinkMacSystemFont chuyển sang đó
    • Khi được tiêu chuẩn hóa, các nền tảng khác không có khái niệm tương đương hữu ích, và hiện nay chỉ một số nền tảng mới có
    • Nó bị lạm dụng chủ yếu như cách lách qua việc trình duyệt không cập nhật các giá trị mặc định cũ kỹ của họ chung hiện có
  • ui-serif, ui-sans-serif, ui-monospace, đặc biệt là ui-rounded, được xem là những sai lầm rõ ràng nên bị loại bỏ
    • Trong môi trường không phải của Apple, không nên kỳ vọng chúng sẽ ánh xạ tới bất kỳ phông nào
    • Bản thân khái niệm này chỉ tồn tại trên nền tảng Apple nên lẽ ra không nên được đưa vào tiêu chuẩn
    • Nếu Apple muốn cung cấp chúng thì đáng ra phải ở dạng có tiền tố -apple như -apple-system
  • Có những trường hợp dùng system-ui chính đáng trong web app, nhưng ấn tượng thực tế là nó gần như hoàn toàn bị lạm dụng, và việc can thiệp để loại bỏ cũng có thể không phải ý tệ

Bài viết liên quan

1 bình luận

 
GN⁺ 12 giờ trước
Ý kiến trên Lobste.rs

  • Trên https://lindenii.org họ chọn cách không chỉ định font-family chút nào, để tôn trọng phông chữ mặc định mà người dùng đã chọn trong trình duyệt
    Cá nhân tôi thích sans-serif hơn, nhưng nếu người dùng đang dùng serif làm mặc định thì có vẻ cũng chẳng có lý do gì phải ghi đè
    Tuy vậy, trong các trường hợp như https://runxiyu.org/soc/ta/ nơi buộc phải dùng những ký tự mà đa số phông không có, cuối cùng vẫn phải thêm web font, và kết quả là toàn bộ phần văn bản còn lại cũng bị ép sang sans-serif thay vì dùng mặc định của người dùng
    Tôi không biết có cách nào tốt hơn ngoài việc bọc từng ký tự lạ bằng thứ như <unusual-character> hay không, và cũng mong là có cách nào đó để chỉ định kiểu như “phông chữ mã nguồn mà người dùng ưa thích”
    Mẹo monospace, monospace rất hữu ích, và sự khác biệt về kích thước quả thật khá khó chịu

    • Với vấn đề thứ hai, có lẽ một phương án fallback chấp nhận được là đặt ký hiệu thay thế bằng hình ảnh bên cạnh ký tự đặc biệt
      Các trang danh sách ký tự Unicode thường xử lý theo cách đó
    • Blog của tôi ở https://hauleth.dev cũng làm khá giống vậy, nhưng dùng monospace
      Tôi cũng từng được khen về thiết kế của trang, nhưng thật ra chỉ là lấy một theme Zola rồi giảm bớt CSS và các thành phần tùy biến, nên tôi khá đồng cảm với tinh thần của bài viết này, nhất là với các trang cá nhân
    • Với hướng không chỉ định font-family, tôi nghĩ việc phông mặc định mặc định của trình duyệt chuyển từ serif sang sans-serif có thể lại tốt hơn cho người dùng
      Phần lớn người dùng không tự chọn phông, nên không có cách nào phân biệt giữa “phông do người dùng chọn” và “phông mặc định của trình duyệt”
      Tôi thích serif, nhưng ngày nay có lẽ đa số vẫn chuộng sans-serif hơn
      Trong môi trường của tôi, tôi chặn không cho trang chỉ định phông, và cũng không cài phông CJK tử tế
      Vì ngay cả khi hiện ra các ô như “4E2D” thay cho Hán tự, với tôi nó cũng chẳng có ý nghĩa gì hơn chính cái biểu ý đó
      Phần xử lý fallback phông như vậy là làm khá tốt, nhưng tiếc là không có cách nào chỉ định trực tiếp tên của phông mặc định
      Thay vào đó, dùng JavaScript xem getComputedStyle(document.documentElement).fontFamily trên một tài liệu trống thì tùy theo thiết lập phông nâng cao của tôi sẽ trả về "serif" hoặc "sans-serif"
      Tôi không rõ chính xác “phông ưa thích cho code” ở đây nghĩa là gì, có vẻ họ đang nghĩ tới thứ gì đó ngoài monospace

  • Bài này vẫn chỉ là bản nháp, nên còn khá dang dở, và đang trộn lẫn hai ba mảnh có hình thức khác nhau nên hơi lộn xộn
    Có lẽ về sau nó sẽ dài hơn một trang và mang hình thức khá khác hiện tại, thậm chí một phần có thể trở thành chữ viết tay, hình vẽ tay, và bố cục thủ công
    Dạo này tôi đang tập trung vào việc hiện thực một ngôn ngữ markup nhẹ, và giờ nó gần như đã dùng được, đúng kiểu 90% cuối cùng mãi vẫn chưa xong
    Sau đó tôi sẽ quay lại viết tiếp và công bố

  • Phần nói rằng nếu dùng font-family: monospace; thì font-size mặc định có thể bị đặt thành 81.25% thay vì 100%, còn nếu trong danh sách có phông thứ hai thì chuyện đó không xảy ra, thật sự rất thú vị
    Nghĩa là font-family: my-web-font, monospace; hoặc font-family: monospace, monospace; thì ổn, nhưng có vẻ hiện MDN chưa tài liệu hóa điều này
    Tôi tò mò không biết có ai giải thích được vì sao chuyện này xảy ra và vì sao nó chưa được ghi vào tài liệu không

    • Nếu tôi nhớ không nhầm thì Firefox thực ra không làm việc điều chỉnh cỡ phông này còn Chrome thì có
      Vì thế nó cũng trở thành nguyên nhân gây khác biệt giữa các trình duyệt
    • Có lẽ mục đích là để văn bản đơn cách trông cùng kích thước về mặt thị giác với văn bản thân bài

  • Dù là bản nháp, trong bài vẫn có kiểu lặp lại kỳ lạ như thể một đoạn đã bị copy-paste nguyên xi thành lần thứ hai
    Đặc biệt là vì nó tạo cảm giác như đang chê kiểu phông đơn cách mà tôi thích nên tôi càng thấy khó chịu

    • Vì tôi vẫn đang sắp xếp lại cấu trúc nên những chỗ như vậy vẫn còn
      Nếu đọc kỹ thì có vài mâu thuẫn nhẹ vì tôi đang phân loại phần nào nên để thành khuyến nghị chắc chắn, phần nào nên giữ lập trường tinh tế hơn
      Tôi cũng tò mò không biết phông đơn cách mà bạn thích là gì

  • Một lý do khiến người ta muốn tránh chỉ dùng serif và sans-serif là vì phông serif mặc định thường là Times, mà nhiều khi trông không ổn lắm
    Vì vậy tôi đang chuyển phông thân bài từ serif sang sans-serif

  • Liên quan đến lời khuyên “đừng liệt kê các phông có lẽ đã được cài trong hệ thống” và “với phông đơn cách cũng nên cố chỉ dùng generic family”, trên website của tôi tôi đang cấu hình như sau
    Tôi dùng --sans-serif: Adwaita Sans, Adwaita Sans Bundled, Inter, sans-serif; và --monospace: Iosevka, Iosevka Web, Cascadia Code, monospace;
    Ý định là nếu GNOME đã có cài Adwaita Sans thì dùng phông hệ thống và không tải web font; nếu không có thì dùng web font Adwaita Sans Bundled, còn trong lúc tải thì fallback sang Inter và sans-serif với metric tương đối giống
    Với phông đơn cách cũng tương tự: nếu hệ thống có Iosevka thì dùng, không có thì dùng web font Iosevka Web, và trong lúc tải thì fallback sang Cascadia Code và monospace
    Tôi cũng có tính đến chuyện monospace trên Windows là Consolas nên không đẹp lắm, còn Windows mới thì đã cài sẵn Cascadia Code
    Tôi biết việc Cascadia Code có metric khá khác Iosevka là điều không tốt, nhưng vẫn muốn hỏi xem cách tiếp cận này có ổn không

    • Có thể do tôi gần như không biết gì về lập trình web nên đã bỏ sót một cách tốt hơn để chỉ “tải phông khi hệ thống chưa cài sẵn”

  • Bài viết gọn gàng, và tôi hoàn toàn không biết mẹo monospace, monospace
    Có một lỗi định dạng nhỏ: trên trình duyệt của tôi, văn bản trong đoạn .unimportant nằm phía trước nền vàng nhưng lại chui xuống dưới phần chữ của thanh .status cố định, nên khi cuộn qua đoạn .unimportant trông khá kỳ
    Có vẻ hiệu ứng tương tự cũng xảy ra với watermark DRAFT đặt chéo