6 điểm bởi GN⁺ 2024-05-07 | 1 bình luận | Chia sẻ qua WhatsApp

Hỗ trợ thuộc tính CSS transition (29 tháng 3, 2024)

  • Nội dung tổng hợp tình trạng hỗ trợ thuộc tính CSS transition trong các email client
  • Thuộc tính CSS transition là tính năng tạo hiệu ứng hoạt ảnh cho sự thay đổi giá trị của thuộc tính CSS trong một khoảng thời gian nhất định
  • Hiện vẫn chưa được hỗ trợ rộng rãi trong các email client

Hỗ trợ thuộc tính CSS text-wrap (3 tháng 4, 2024)

  • Nội dung tổng hợp tình trạng hỗ trợ thuộc tính CSS text-wrap trong các email client
  • Thuộc tính CSS text-wrap là thuộc tính chỉ định cách xử lý xuống dòng đối với các từ dài
  • Hiện vẫn chưa được hỗ trợ rộng rãi trong các email client

Hỗ trợ các thuộc tính CSS word-spacing, shape-margin, shape-outside (13 tháng 3, 2024)

  • Nội dung tổng hợp tình trạng hỗ trợ các thuộc tính CSS word-spacing, shape-margin, shape-outside trong các email client
  • word-spacing là thuộc tính điều chỉnh khoảng cách giữa các từ
  • shape-marginshape-outside là các thuộc tính chỉ định cách văn bản bao quanh hình ảnh hoặc đối tượng
  • Hiện vẫn chưa được hỗ trợ rộng rãi trong các email client

Tin cập nhật Caniemail tháng 3 năm 2024 (29 tháng 3, 2024)

  • Tin tổng hợp các nội dung cập nhật được thêm vào trang Caniemail trong tháng 3 năm 2024

Tin cập nhật Caniemail tháng 2 năm 2024 (29 tháng 2, 2024)

  • Tin tổng hợp các nội dung cập nhật được thêm vào trang Caniemail trong tháng 2 năm 2024

Tình trạng hỗ trợ thuộc tính CSS của các email client

  • Apple Mail (macOS): hỗ trợ 267 trên 284 thuộc tính
  • Apple Mail (iOS): hỗ trợ 266 trên 284 thuộc tính
  • Samsung Email (Android): hỗ trợ 239 trên 284 thuộc tính
  • SFR (Desktop Webmail): hỗ trợ 226 trên 257 thuộc tính
  • WEB.DE (iOS): hỗ trợ 222 trên 235 thuộc tính

Giới thiệu về trang Caniemail

  • Trang do @HTeuMeuLeu và đội ngũ Tilt Studio ra mắt và duy trì
  • Dựa trên caniuse.com gốc của @Fyrd và được @Lensco thiết kế
  • Dựa trên ý tưởng và tên gọi ban đầu từ @M_J_Robbins và đội ngũ Rebel
  • Cộng đồng nhà phát triển email trên GitHub hỗ trợ đóng góp dữ liệu
  • Hướng dẫn báo lỗi trên GitHub nếu có vấn đề

Ý kiến của GN⁺

  • Đây là một trang rất hữu ích cho các nhà phát triển email, giúp nhìn nhanh tình trạng hỗ trợ thuộc tính CSS của từng email client. Khi áp dụng thuộc tính CSS mới vào email, đây là trang gần như bắt buộc để kiểm tra khả năng tương thích.
  • Hiện mức độ hỗ trợ CSS của email client vẫn còn kém khá xa so với trình duyệt web. Các thuộc tính liên quan đến animation hoặc layout hầu như không được hỗ trợ, tạo thành giới hạn cho thiết kế email.
  • Trang thường xuyên đăng tin cập nhật, nên có vẻ sẽ hữu ích để các nhà phát triển email nắm bắt thông tin mới nhất. Tuy vậy, chu kỳ cập nhật khá ngắn nên cũng có thể hơi khó theo kịp.
  • Có các trang tương tự như EmailOnAcid, Litmus, nhưng khác ở chỗ các trang này cung cấp ảnh chụp xem trước cách render trên từng client. Nếu dùng cùng với Caniemail thì có thể tạo hiệu quả cộng hưởng.

1 bình luận

 
GN⁺ 2024-05-07
Ý kiến trên Hacker News
  • Đây là một tài liệu rất tuyệt, và Outlook thực sự rất đau đầu vì hỗ trợ quá ít
    Trước đây tôi thường khá vất vả khi tạo mẫu email cho thông báo của ứng dụng công ty, nhưng sau khi chuyển sang MJML(https://mjml.io/) thì mọi thứ dễ thở hơn hẳn
    Trong số nhiều thiết bị tôi đã thử nghiệm, kết quả cho thấy nó có vẻ tương thích tốt nhất, và tôi dùng Litmus(https://litmus.com) để kiểm tra việc render trên nhiều ứng dụng và thiết bị khác nhau. Tôi cũng đã dùng https://testi.at/ được nhắc tới ở luồng khác và thấy khá ổn

    • MJML trông khá thú vị. Giá mà các tổ chức có lý do kinh doanh để quan tâm hơn tới email có thể truy cập được và máy có thể đọc được
      Email HTML vẫn bị mắc kẹt ở thời web thời IE6, nên với số ít tác vụ email cần nhiều hơn một danh sách thẻ hình ảnh, tôi vẫn dùng Foundation for Emails(https://get.foundation/emails.html) và biết ơn vì nó tồn tại
    • MJML rõ ràng là công cụ tốt nhất trong mảng này và tôi dùng nó thường xuyên. Nếu bạn tạo email vào năm 2024, đây là lối tắt quan trọng để tránh hoặc giảm bớt những cơn đau đầu lớn của email HTML
    • Tôi cũng khuyên dùng react-email(https://react.email) để làm email. Bộ component mà nó cung cấp là đủ dùng, và tốt hơn rất nhiều so với thời làm email marketing trước đây khi phải nhét thẻ vào cứ mỗi năm dòng
    • Có vẻ như ngày nay Outlook là Internet Explorer của thế giới email
  • Có một giai thoại buồn cười về trang này. Người vận hành từng nói rằng trong log sử dụng trước đây có rất nhiều dấu vết cho thấy có người hiểu nhầm mục đích của trang, nhập tên người nổi tiếng vào và định gửi email cho họ

    • Ban đầu tôi cũng cố tìm hiểu xem cái này là gì nhưng không thấy giải thích nào rõ ràng. Nó được gọi là “một kiểu caniuse cho nội dung email”, nhưng nếu không biết caniuse là gì thì khá khó hiểu
      Trước khi công bố một dịch vụ mới, sẽ tốt hơn nếu có một phần mô tả ngắn để người bình thường cũng hiểu nó là gì
  • Điểm càng thấp thì càng tốt. Tôi biết khá nhiều người có chính sách kiểu “email chỉ được phép là văn bản thuần túy, không chấp nhận tệp đính kèm nếu không được thỏa thuận trước, và mọi thứ khác sẽ bị tự động xóa”

    • Mở rộng một chút từ văn bản thuần túy là hợp lý. Đây không chỉ là vấn đề trang trí; với những thứ như ngôn ngữ viết từ phải sang trái, danh sách, hay liên kết thì một chút markup sẽ hữu ích, và HTML là đủ
      Vấn đề nằm ở việc lạm dụng CSS, hoặc thậm chí cho phép JavaScript. Tôi không nghĩ ra vấn đề bảo mật email nào phát sinh chỉ từ HTML mà không có CSS hay JavaScript
    • Tôi biết ít nhất hai người gửi email mà phiên bản HTML hoặc để trống, hoặc chỉ hiện dòng “đừng dùng client phình to”, còn nội dung thực tế thì nằm trong phần thay thế dạng văn bản thuần túy
      Hình như để đọc trên Thunderbird thì phải xem nguyên văn email
  • Các liên kết liên quan:
    Can I Email? - https://news.ycombinator.com/item?id=27112960 - Tháng 5 năm 2021, 273 bình luận
    Can I Email: ‘Can I Use’ for email - https://news.ycombinator.com/item?id=20948826 - Tháng 9 năm 2019, 196 bình luận
    'Can I Use' for Email - https://news.ycombinator.com/item?id=20934601 - Tháng 9 năm 2019, 1 bình luận

  • GmailOutlook, hai client phổ biến nhất, lần lượt đứng thứ 25 và 41, tức là gần cuối bảng

    • Nếu nhìn vào những tính năng mà Gmail không hỗ trợ, có những thứ như display: none, animation, và các CSS khác vốn không hẳn là thứ bắt buộc phải có trong email
      Những phần cơ bản thì nó vẫn đáp ứng, nên thứ hạng cao chưa chắc đã là mục tiêu tốt
    • Điều này gợi nhớ đến Internet Explorer, phổ biến nhất nhưng lại thiếu tính năng
  • Một “tài liệu” HTML đầy đủ tính năng thực ra gần với một ứng dụng hơn là một tài liệu, nên việc các mail client hạn chế hỗ trợ là điều hợp lý
    Nhưng vì sự phân mảnh này, tôi ước gì có một tiêu chuẩn thực sự. Cần có một tập con HTML phi ứng dụng chính thức, không thể tải tài nguyên từ xa hoặc thực thi mã. Chỉ cần là một định dạng tài liệu có media nhúng, animation, styling, v.v.

    • Nếu có animation và video không tĩnh thì còn có thể gọi đó là “tài liệu” nữa không?
    • Thành thật mà nói, chẳng có lý do gì để người khác gửi cho tôi mã có thể chạy hoặc tài nguyên cần tải về
      Tôi hiểu ngành ad-tech muốn biến email của tôi thành bảng quảng cáo, nhưng mong là điều đó biến mất đi. Văn bản thuần túy và tệp đính kèm là đủ rồi
  • Nhân tiện, jsx-email có tích hợp sẵn tính năng CLI để kiểm tra khả năng tương thích của email client bằng bộ dữ liệu caniemail: https://jsx.email/docs/core/cli#check

  • Có lẽ sẽ hữu ích hơn nếu chỉ liệt kê số ít thuộc tính CSS mà mọi email client đều nhận ra. Tôi nói nghiêm túc chứ không đùa đâu
    Câu trả lời của CanIEmail? nhìn chung là “không”

    • Nếu chọn “check all” tại https://www.caniemail.com/clients/ thì có thể xem riêng các tính năng được mọi email client hỗ trợ và các tính năng có mức hỗ trợ khác nhau
      Những thứ được tất cả hỗ trợ có vẻ đại khái là border-collapse, dạng rút gọn font, list-style-type, nhiều đơn vị CSS (cm, em, ex, in, mm, pc, %, pt, px), vertical-align, một số phần tử HTML và thuộc tính valign, cùng định dạng ảnh JPG/PNG
  • Lúc đầu tôi tưởng đây là một trang đùa chỉ hiện chữ “No.” thật to

    • Đó thường cũng là câu trả lời mặc định của tôi khi đội thiết kế yêu cầu cập nhật mẫu email. “Không được. Chỉ định dạng cơ bản thôi. Nếu muốn liều hơn một chút thì dùng bảng. Hơn nữa là không được”
  • Hỗ trợ dark mode cho email là một trong những trải nghiệm gây bực bội nhất mà tôi từng gặp với tư cách là một lập trình viên frontend đã code từ thời IE6
    Về cơ bản chỉ có thể triển khai thiết kế light mode, rồi chọn màu sao cho khi các email client dark mode làm đảo màu tự động một cách vụng về thì trông vẫn chấp nhận được
    Gmail là một trong những ví dụ tệ nhất. Hoàn toàn không có cách nào để tự chọn màu trong dark mode