6P by GN⁺ | ★ favorite | 댓글 1개

CSS transition 속성 지원 (2024년 3월 29일)

  • 이메일 클라이언트에서 CSS transition 속성 지원 현황을 정리한 내용
  • CSS transition 속성은 CSS 속성 값의 변화를 일정 시간에 걸쳐 애니메이션 효과를 주는 기능
  • 아직 이메일 클라이언트에서는 폭넓게 지원되지 않음

CSS text-wrap 속성 지원 (2024년 4월 3일)

  • 이메일 클라이언트에서 CSS text-wrap 속성 지원 현황을 정리한 내용
  • CSS text-wrap 속성은 긴 단어를 어떻게 줄 바꿈 처리할지 지정하는 속성
  • 아직 이메일 클라이언트에서는 폭넓게 지원되지 않음

CSS word-spacing, shape-margin, shape-outside 속성 지원 (2024년 3월 13일)

  • 이메일 클라이언트에서 CSS word-spacing, shape-margin, shape-outside 속성 지원 현황을 정리한 내용
  • CSS word-spacing은 단어 사이의 간격을 조절하는 속성
  • CSS shape-margin과 shape-outside는 이미지나 개체 주변으로 텍스트를 둘러싸는 방식을 지정하는 속성
  • 아직 이메일 클라이언트에서는 폭넓게 지원되지 않음

2024년 3월 Caniemail 업데이트 소식 (2024년 3월 29일)

  • 2024년 3월에 Caniemail 사이트에 추가된 업데이트 내용을 정리한 소식

2024년 2월 Caniemail 업데이트 소식 (2024년 2월 29일)

  • 2024년 2월에 Caniemail 사이트에 추가된 업데이트 내용을 정리한 소식

이메일 클라이언트 CSS 속성 지원 현황

  • 애플 Mail (macOS) : 284개 중 267개 지원
  • 애플 Mail (iOS) : 284개 중 266개 지원
  • 삼성 Email (Android) : 284개 중 239개 지원
  • SFR (Desktop Webmail) : 257개 중 226개 지원
  • WEB.DE (iOS) : 235개 중 222개 지원

Caniemail 사이트 소개

  • @HTeuMeuLeu와 Tilt Studio 팀이 런칭하고 유지 관리하는 사이트
  • @Fyrd의 원래 caniuse.com을 기반으로 하고 @Lensco가 디자인함
  • @M_J_Robbins와 Rebel 팀의 원래 아이디어와 이름을 기반으로 함
  • GitHub의 이메일 개발자 커뮤니티가 데이터 기여를 지원함
  • 문제가 있으면 GitHub에 버그를 보고해 달라고 안내

GN⁺의 의견

  • 이메일 개발자에게 매우 유용한 사이트로, 각 이메일 클라이언트별로 CSS 속성 지원 현황을 한 눈에 파악할 수 있음. 새로운 CSS 속성을 이메일에 적용할 때 호환성 체크에 꼭 필요한 사이트임.
  • 아직 이메일 클라이언트의 CSS 지원이 웹브라우저에 비해 많이 부족한 상황. 애니메이션 관련 속성이나 레이아웃 관련 속성은 거의 지원되지 않고 있어서 이메일 디자인의 한계로 작용하고 있음.
  • 정기적으로 업데이트 소식을 알려주고 있어서, 이메일 개발자들이 최신 정보를 파악하는데 도움이 될 듯함. 다만 업데이트 주기가 너무 짧아서 따라가기 벅찰 수도 있을 듯.
  • 비슷한 사이트로 EmailOnAcid, Litmus 등이 있는데, 이 사이트들은 각 클라이언트에서 렌더링 되는 모습을 미리보기 스크린샷으로 제공한다는 차이가 있음. Caniemail과 함께 활용하면 시너지 효과를 볼 수 있을 듯함.

댓글과 토론

Hacker News 의견들
  • 훌륭한 자료이고, Outlook은 정말 골치 아프며 지원하는 게 너무 적음
    회사 앱 알림용 이메일 템플릿을 만들 때 보통 힘들었는데, 이후 MJML(https://mjml.io/)로 바꾸고 나서 훨씬 잘 풀림
    테스트한 여러 기기에서 결과물이 가장 호환성이 좋아 보였고, Litmus(https://litmus.com)로 다양한 앱과 기기에서 렌더링을 확인함. 다른 스레드에서 나온 https://testi.at/도 써봤고 잘 맞았음

    • MJML이 흥미로워 보임. 조직들이 접근 가능하고 기계가 읽을 수 있는 이메일에 신경 쓸 사업적 이유가 있으면 좋겠음
      HTML 이메일은 IE6 시절 웹처럼 멈춰 있어서, 이미지 태그 목록 이상이 필요한 소수의 이메일 작업에는 Foundation for Emails(https://get.foundation/emails.html)를 써왔고 존재 자체가 고마움
    • MJML은 이 분야에서 단연 최고 도구이고 자주 씀. 2024년에 이메일을 만든다면 HTML 이메일의 큰 골칫거리를 피하거나 줄여주는 중요한 지름길임
    • 이메일 제작에는 react-email(https://react.email)도 추천함. 제공하는 컴포넌트가 충분하고, 예전 이메일 마케팅 시절처럼 다섯 줄마다 태그를 넣어 메일을 만드는 것보다 훨씬 낫다
    • 오늘날 Outlook은 메일의 Internet Explorer 같은 존재인가 봄
  • 이 사이트에 관한 웃긴 일화가 있음. 운영자가 예전에 사용 로그에 사이트 목적을 오해한 사람들이 유명인 이름을 넣고 그들에게 이메일을 보내려 한 흔적이 많다고 했음

    • 처음엔 이게 뭔지 파악하려 했지만 별다른 설명을 못 찾았음. “이메일 콘텐츠용 caniuse 같은 것”이라는데, caniuse가 뭔지 모르면 이해하기 어렵다
      새 서비스를 공개하기 전에 평균적인 사람이 이게 무엇인지 알 수 있는 짧은 설명 섹션을 넣어주면 좋겠음
  • 점수는 낮을수록 좋음. “이메일은 순수 텍스트만 허용하고, 사전 합의 없는 첨부파일은 안 되며, 나머지는 자동 삭제한다”는 정책을 가진 사람들을 꽤 알고 있음

    • 순수 텍스트에서 조금만 확장하는 건 타당함. 장식만의 문제가 아니라 오른쪽에서 왼쪽으로 쓰는 언어, 목록, 링크 같은 용도는 약간의 마크업이 도움이 되고 HTML이면 충분함
      문제는 CSS를 과하게 쓰거나, 아예 JavaScript를 허용하는 데 있음. CSS나 JavaScript 없이 HTML만으로 생긴 이메일 보안 이슈는 떠오르지 않음
    • HTML 버전이 비어 있거나 “부풀어 오른 클라이언트를 쓰지 말라”고만 나오고, 실제 내용은 순수 텍스트 대체 본문에 들어 있는 이메일을 보내는 사람을 최소 두 명 앎
      Thunderbird에서 읽으려면 이메일 원문을 봐야 했던 것 같음
  • 관련 링크들:
    Can I Email? - https://news.ycombinator.com/item?id=27112960 - 2021년 5월, 댓글 273개
    Can I Email: ‘Can I Use’ for email - https://news.ycombinator.com/item?id=20948826 - 2019년 9월, 댓글 196개
    'Can I Use' for Email - https://news.ycombinator.com/item?id=20934601 - 2019년 9월, 댓글 1개

  • 가장 인기 있는 두 클라이언트인 GmailOutlook이 각각 25위와 41위, 즉 최하위권에 있음

    • Gmail이 지원하지 않는 기능을 보면 display: none, 애니메이션, 기타 CSS처럼 이메일에 꼭 들어가야 한다고 보기 어려운 것들이 있음
      기본기는 갖춰져 있으니 높은 순위가 반드시 좋은 목표는 아닐 수 있음
    • 가장 인기 있지만 기능이 부족했던 Internet Explorer가 떠오름
  • 완전한 기능을 갖춘 HTML “문서”는 사실 문서가 아니라 애플리케이션에 가까우니, 메일 클라이언트가 지원을 제한하는 건 말이 됨
    하지만 이런 파편화 때문에 진짜 표준이 있었으면 함. 원격 리소스를 가져오거나 코드를 실행하지 못하는, 공식적인 비애플리케이션 HTML 부분집합이 필요함. 내장 미디어, 애니메이션, 스타일링 등을 갖춘 문서 형식이면 됨

    • 애니메이션과 정적이지 않은 비디오 미디어가 들어가도 “문서”라고 부를 수 있나?
    • 솔직히 남들이 내게 실행할 코드나 가져올 리소스를 보낼 이유는 없음
      광고 기술 업계가 내 이메일을 광고판으로 쓰고 싶어 하는 건 알겠지만, 꺼졌으면 함. 순수 텍스트와 첨부파일이면 충분함
  • 참고로 jsx-email에는 caniemail 데이터셋을 쓰는 CLI 이메일 클라이언트 호환성 검사 기능이 내장돼 있음: https://jsx.email/docs/core/cli#check

  • 모든 이메일 클라이언트가 인식하는 몇 안 되는 CSS 속성만 나열하는 편이 더 유용할 것 같음. 농담이 아니라 진지하게 그렇다
    CanIEmail?의 답은 대체로 “아니오”임

    • https://www.caniemail.com/clients/에서 “check all”을 선택하면 모든 이메일 클라이언트가 지원하는 기능과, 지원이 엇갈리는 기능을 따로 볼 수 있음
      모두 지원되는 것은 대략 border-collapse, font 축약형, list-style-type, 여러 CSS 단위(cm, em, ex, in, mm, pc, %, pt, px), vertical-align, 일부 HTML 요소와 valign 속성, JPG/PNG 이미지 형식 정도로 보임
  • 처음엔 큰 글씨로 “No.”만 보여주는 장난 사이트인 줄 알았음

    • 디자인팀이 이메일 템플릿 업데이트를 요청할 때 보통 내 기본 답도 그거임. “안 됩니다. 기본 서식만요. 좀 과감하게 가고 싶다면 표 정도. 그 이상은 안 됩니다”
  • 이메일의 다크 모드 지원은 IE6 시절부터 코딩해 온 프런트엔드 개발자로서 겪은 일 중 가장 답답한 축에 듦
    기본적으로 라이트 모드 디자인만 구현하고, 엉성한 다크 모드 이메일 클라이언트들이 자동 반전했을 때도 괜찮아 보일 색을 고르는 수밖에 없음
    Gmail은 최악의 사례 중 하나임. 다크 모드에서 직접 색을 고를 방법이 전혀 없음