Safari 27.3에 Adaptive Dark Mode가 도입됩니다

1. kickingvegas1일 전 HN

   참고로, CSS의 light-dark()가 이제 정식 기능이 됐습니다.

   https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/color_value/light-dark

2. kps1일 전 HN

   그리고 :prefers-color-scheme은 주요 브라우저 전부가 7년째 지원하고 있죠.

3. cosmotic1일 전 HN

   윈도 3부터 윈도 7까지는 애플리케이션 개발자가 사용자 인터페이스를 직접 그리지만 않으면 다크 모드가 전반적으로 지원됐습니다. 처음에는 거의 모든 개발자가 시스템 색상을 따랐는데, 이후 25년쯤 지나는 동안 점점 직접 그리는 인터페이스를 구현하기 시작했습니다. 임베디드 IE/mshtml 뷰가 이를 부추겼고, 나중에는 Electron이 훨씬 더 가속했습니다. 결국 시스템 색상 구성표를 지원하는 인터페이스는 사실상 하나도 남지 않았습니다.

4. da_chicken23시간 전 HN

   그렇긴 한데, Win3부터 WinXP까지의 "다크 모드"는 주로 수동 매트릭스 LCD를 지원하려는 용도였어요. 그 화면은 글자를 읽을 만큼 대비가 나오려면 색을 반전시켜야 했거든요. 기본 제공 "고대비" 색상 구성표가 그렇게 지독하게 흉한 이유가 그겁니다.

5. pxoe4시간 전 HN

   윈도 10에는 모든 곳에 적용되는 시스템 전체 다크 모드가 없었기 때문에, 그 끔찍한 "반전" 색상 구성표조차 색을 조금만 손보면(예를 들어 이런 것 https://github.com/nitschis/GreyEveTheme ) 꽤 쓸 만하고 견딜 만했습니다. 적어도 아무것도 없는 것보다는 나았죠. 11에서는 더 이상 문제가 아닙니다.

6. toyg23시간 전 HN

   맞아요, 다크 모드가 "대세"가 됐을 때 제 첫 반응이 "...이거 예전에 이미 있었던 거 아니야?"였어요.

   저는 윈도 98 시절에 테마에 푹 빠져 있었는데, XP 이후로는 마이크로소프트가 테마 지원에 별로 관심이 없다는 게 점점 분명해져서 손을 놓았습니다.

7. Rohansi22시간 전 HN

   직접 그리는 것만이 다크 모드를 망가뜨린 건 아닙니다. 네이티브 위젯의 스타일(색상)을 바꿔서 원하는 모습을 만들 수는 있지만, 제 기억으로는 시스템 색상(테마/모드를 자동으로 따라감)이나 고정 색상 중에서 골라야 했습니다. 일부 애플리케이션이 두 방식을 섞어 쓰는 바람에, 기본 테마에서 다른 테마로 바꾸면 UI가 끔찍해 보였습니다.

8. jansan1일 전 HN

   그리고 크롬에서는 처음부터 고장 나 있었고요.

   https://issues.chromium.org/issues/366412383

9. zamadatix1일 전 HN

   이 부분을 버그라고 부르진 않겠습니다. 운영체제 수준의 선호 설정과 브라우저 수준의 테마가 서로 다를 때 어느 쪽이 "옳은" 처리인지는 사람마다 의견이 다르겠지만요.

   근본적인 문제는 크롬이 운영체제 수준의 설정을 덮어쓸 수 있는 (일반적인) 설정을 아예 제공하지 않는다는 점이지, 선호 설정이 꼭 브라우저 테마를 따라야 한다는 건 아닙니다.

10. omer_balyali1일 전 HN

    그 이슈는 크롬 자체의 모양 설정에 관한 것입니다(내가 아는 한 크롬의 모양을 정하는 설정이지, 웹사이트에 어떻게 적용할지를 정하는 설정이 아닙니다). prefers-color-scheme의 핵심 기능(운영체제 수준 설정을 따르는 것)은 의도대로 동작하고 있어요.

11. jansan1일 전 HN

    prefers-color-scheme이 항상 운영체제 수준 설정을 따라야 한다는 건 사실이 아닙니다. 문서에는 이렇게 나와 있어요. "사용자가 선호를 표현하는 방법은 다양할 수 있다. 운영체제가 제공하는 시스템 전체 설정일 수도 있고, 유저 에이전트가 제어하는 설정일 수도 있다."[1]

    그러면 사용자가 브라우저에서 다크 모드를 설정했다면, 웹사이트에 대한 선호를 명시적으로 표현한 것 아닌가요? 이보다 더 명시적일 수 있는 방법이 있습니까?

    [1] https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme

12. omer_balyali23시간 전 HN

    "운영체제 수준 설정만 따라야 한다"는 뜻으로 말한 게 아닙니다. 제 말은 크롬의 설정은 크롬 자체의 테마가 어떻게 보여야 하는지를 정하는 것이지, 웹사이트용이 아니라는 거예요.

    크롬에는 특정 웹사이트의 색상 구성표를 바꾸는 설정이 이미 있긴 한데, 개발자 도구가 열려 있을 때만 동작합니다(Cmd+Shift+P로 "Toggle CSS media feature prefers-color-scheme"). 그러니까 CSS 구현은 실제로 운영체제 수준 설정보다 UA 수준 선호를 존중하는 셈이죠.

    하지만 다시 말하지만, 크롬에는 개발자에게 준 그 설정 말고는 사용자가 웹을 어떤 색상 구성표로 보고 싶은지 고르는 기능이 없습니다(그래서 버그는 아니고 UX 문제예요. 모양 설정이 무엇을 바꾸는지 사용자에게 분명하게 알려 주지 않으니까요). 솔직히 모든 브라우저에 색상 구성표 설정을 웹사이트에 어떻게 적용할지 정하는 옵션이 생기면 좋겠습니다.

13. omer_balyali22시간 전 HN

    네, 최종 사용자에게 혼란스러운 건 맞아요. 말씀드렸듯이 그 설정 페이지가 무엇을 바꾸는지 분명히 알 수 있도록 UX를 개선해야 합니다.

    그렇지만 처음 댓글에서 크롬의 prefers-color-scheme이 버그라고 하셨는데, 그건 사실이 아닙니다. 의도대로 동작하고, UA 수준 설정과 운영체제 수준 설정을 둘 다 올바르게 따릅니다.

    모양 탭의 설정은 웹을 탐색할 때의 선호 설정이 아닙니다. 많은 앱이 운영체제 설정이 바뀔 때 앱의 모양을 바꿀지(또는 그 설정을 덮어쓸지) 고르는 옵션을 두고 있는데, 크롬은 이 옵션을 그냥 빼고 크롬 UI(앱 UI)가 항상 운영체제 설정을 따르게 하거나 항상 기본 라이트 모드로 두면 됐을 겁니다. 그러지 않고 사용자에게 "크롬 브라우저가 어떻게 보일지"를 고르게 한 것이지, "방문하는 모든 웹사이트가 어떻게 보일지"를 고르게 한 게 아닙니다.

14. jansan23시간 전 HN

    chrome://settings/appearance에서 모양 모드(라이트, 다크, 기기 설정)를 정할 수 있습니다. 모드를 바꾸면 설정 페이지(이것도 웹사이트입니다)가 그 모드로 바뀌니까, 사용자는 당연히 웹 콘텐츠를 표시할 때도 그 모드가 적용된다고 생각하게 되죠.

15. kulahan1일 전 HN

    그러면 결국 어디에서도 지원된 적이 없다는 얘기네요.

    사파리와 파이어폭스는 꽤 작으니까요.

16. akersten1일 전 HN

    CSS 함수 이름을 light-dark로 지은 것 때문에 너무 화가 납니다. 사용자나 사이트가 지정하는 범용 색상 구성표를 허용할 여지를 남겨 둘 수도 있었잖아요. 이 기능 주변의 다른 모든 메커니즘에 답이 바로 거기 있었는데도, 왜 이것들이 이런 구조로 되어 있는지, 왜 "light"와 "dark"가 늘 키워드가 아니라 값이었는지 읽고 생각해 보기만 했어도 됐을 텐데요..:

        - <meta name="color-scheme" content="light dark">
    
    - :root { color-scheme: light dark }
    
    - @media (prefers-color-scheme: dark) { }
    
    - <picture><source media="(prefers-color-scheme: dark)">
    

    .... 그런데 light-dark()가 나왔죠. 명세에서 이렇게 웅장하고 앞을 내다본 부분들 옆에 홀로 서 있는 우스꽝스러운 용 같은 녀석 말이에요.

    기존 사례를 안 봤나요? "이 중에 하나는 다른 것과 다르다"는 게 눈에 안 띄었나요? 이 퍼즐의 다른 조각들은 언젠가 :root { color-scheme: halloween }이나 @media (prefers-color-scheme: supercontrast) 같은 걸 가질 수도 있었는데, 결국 light-dark()를 우리가 영원히 오갈 유일한 두 가지 색상 구성표로 못 박아 버렸네요.

17. omer_balyali21시간 전 HN

    색상 구성표(명도 모드)와 색상 테마(미적 스타일)는 같은 게 아닙니다. 할로윈 테마도 라이트 구성표와 다크 구성표를 가질 수 있어요.

    또 prefers-contrast 미디어 쿼리가 있으니 명도 모드(color-scheme)와 조합해서 halloween-light, halloween-dark, halloween-light-high-contrast, halloween-dark-high-contrast 같은 것도 만들 수 있습니다.

    https://news.ycombinator.com/item?id=47832705

18. Timon311시간 전 HN

    제 생각에는 그렇게 했다면 이 기능이 아무에게도 쓸모없게 되는 완벽한 방법이었을 겁니다. 이런 건 개발자와 사용자 양쪽의 호응이 있어야 하거든요. 모두가 지원하는 대체 색상 구성표 하나를 만드는 일이, 대부분이 신경 쓰지 않는 대체 색상 구성표 n개를 만드는 일보다 천 배는 쉽게 정당화됩니다.

    그리고 함수 이름을 light-dark()로 지은 덕분에 나중에 말씀하신 것 같은 걸 도입할 여지를 분명히 남겨 둔 겁니다. 처음부터 함수 이름을 더 범용적으로 지었다면 앞으로 나올 API의 유연성이 제한됐을 거예요!

19. BoppreH11시간 전 HN

    저는 light-dark가 오히려 마음에 듭니다. 더 길고 포괄적인 다른 방식으로도 할 수 있는 일을, 압도적으로 가장 흔한 사용 사례에 맞춘 단축 표기니까요. 우리 코드의 사마귀(CSS의 미디어 쿼리 블록)를 없애려고 명세에 사마귀(키워드로 된 특정 색상 구성표)를 하나 넣은 셈이죠.

    CSS가 원래 순수하고 우아했던 것도 아닌데, 실제로 쓸모 있는 별난 요소 하나쯤 더하면 어때요?

20. nsoam1일 전 HN

    저는 반대를 원합니다. 난시가 있어서 검은 바탕에 흰 글씨는 읽기 힘들거든요. 사파리가 다크 모드 웹사이트를 라이트 모드로 바꿔 줄 수 있으면 좋겠습니다.

21. jimbobimbo23시간 전 HN

    저도 콘텐츠에 다크 모드가 적용되면 눈이 아픈 건 마찬가지예요. 창 테두리(window chrome)는 어둡게 해서 "묻히게" 하는 게 좋습니다. 두 마리 토끼를 다 잡게 해 주는 유일한 애플리케이션이 파이어폭스입니다. 윈도는 다크로 쓰면서 웹은 라이트 모드로 읽을 수 있거든요.

    윈도도 이 기능을 OS 전체에 훔쳐 갔으면 좋겠어요. 메모장에서 텍스트에 다크를 쓰고 싶지 않은데, 앱별 설정은 보통 앱 전체를 라이트로 바꿔 버리니까요.

22. hjkl015시간 전 HN

    저는 수십 년째 이걸 쓰고 있습니다.

    https://www.squarefree.com/bookmarklets/zap.html

23. cj0022시간 전 HN

    맞아요, 저는 다크 모드 웹사이트를 못 봅니다. 읽고 나면 한동안 잔상이 남거든요. 그래서 다크 모드를 강제하는 사이트에는 그냥 색을 반전시켜 적용하는 Force Light Mode 확장 프로그램을 만들었어요. 사파리 27에는 이제 Siri 확장 빌더 같은 게 있으니, 그걸로 만들어 볼 수도 있을 겁니다.

24. ksec13시간 전 HN

    사파리 팀이 HN을 그렇게 오래 봐 왔고 다크 모드를 10년이나 기다린 끝에, 마침내 한 번에 해결하기로 결심한 것 같아요.

    이 기능은 댕(Dang) 덕분이라고 해야겠네요! :)

    사파리 팀이 앞으로도 사파리를 고치고 개선할 자원을 계속 받았으면 합니다. 마지막 10%를 채우려면 오래 힘든 작업이 필요할 텐데, 새 CEO가 자원을 줄이지 않을까 조금 걱정이에요.

25. greazy1일 전 HN

    다들 Dark Reader 확장 프로그램을 한번 써 보세요. 수년 전부터 적응형 다크 모드를 해 왔고, 사용자 지정도 됩니다. 라이트 모드도 지원하고요. 저는 지금 파이어폭스에서 HN을 보면서 쓰고 있어요!

26. lnvdpwl1일 전 HN

    방금 Dark Reader가 안 되는 걸 알아챘어요. 알고 보니 실수로 "Dark Mode"라는, 악성일 가능성이 있는 복제품을 설치했더라고요. 차단됐고요 :/

27. ckdot1일 전 HN

    그래도 웹사이트 로딩이 엄청 느려지긴 합니다.

28. Telaneo23시간 전 HN

    로딩이 느린 웹사이트가 눈부신 섬광탄보다는 낫죠.

29. Vinnl14시간 전 HN

    참고로, 누가 파이어폭스에 이걸 네이티브로 구현해 보고 싶다면 멘토링을 해 주겠다는 제안이 열려 있습니다. https://bugzilla.mozilla.org/show_bug.cgi?id=1591679#c13

30. chrisra23시간 전 HN

    이런 확장 프로그램은 모든 걸 "읽고 수정"할 수 있다는 점이 걱정이에요. 업무용으로는 쓸 수 없습니다.

Hacker News에서 보기 ↗