이 커뮤니티와 브라우저 호환성이 곧 종료됩니다. 여기서 계속 참여하려면 브라우저를 업그레이드하거나 자세히 보기를 참조하세요.
참고로 이 배너의 “자세히 보기” 링크가 모든 외부 링크를 새 탭에서 열기 설정을 따르지 않습니다. 현재 탭에서 로드됩니다.
와인은 현재 상당히 잘 개발된 상태라고 생각합니다. 처음에는 주로 게임 커뮤니티에서 시작되었지만, 최근에는 개발 지원(자금)을 받아왔습니다.
면책 조항: 최근 경험은 없습니다.
2개의 좋아요
상대 색상 구문을 어디에 사용하려는 건가요?
더 컴팩트한 스타일시트를 만들려는 건가요?
혹시 상대 색상 구문 사용 계획을 취소해 주실 수 있을까요?
이러한 기능들은 우리가 오늘 바로 사용하고자 하는 것들 중 일부입니다. 유지보수자가 더 이상 지원하지 않는(deprecated) 브라우저들을 제거함으로써, 우리는 다른 것들도 탐구할 수 있게 됩니다. 예를 들어, Import maps | Can I use... Support tables for HTML5, CSS3, etc 와 같은 기능은 이 동일한 변경 사항으로 인해 활성화되며, 이는 사용자의 99%에게 Discourse의 속도를 높일 수 있습니다. 이미 Discourse에서 이미지 압축에 수년 동안 사용되어 온 오프스크린 캔버스(Offscreen canvas)도 이 업데이트를 통해 모든 대상 브라우저에서 사용할 수 있게 됩니다.
9개의 좋아요
여기서도 여전히 같은 상태입니다.
해결책을 찾으신 분이 계신가요?
이미 5~6개의 사용자 에이전트 스푸핑 확장 프로그램을 시도해 보았습니다. 종류는 많지만, 제가 테스트해 본 것들은 실제로 사용하기에 별로 좋지 않았습니다. 그리고 대부분 사이트별로 적용되지 않았습니다.
저는 여전히 Android 9에서 다음이 필요합니다:
- Violentmonkey 확장 프로그램
- Stylus 확장 프로그램
- WebDev 도구
- 링크 텍스트 복사 컨텍스트 메뉴
그리고 Discourse(읽기/쓰기)를 사용할 수 있어야 합니다.
사용자 에이전트 확장 프로그램들을 하나씩 전부 테스트해 봐야 할 것 같습니다… 
우리는 사용자 에이전트를 확인하지 않으므로, 이를 위장하는 것은 도움이 되지 않습니다.
OP에서 언급된 세 가지 기능에 대해서는 기능 감지(feature-detection)를 사용하고 있습니다. 브라우저가 해당 기능을 지원하지 않으면 경고 배너가 표시됩니다.
Kiwi 개발자에게 문제를 보고해 보셨나요? 그들의 Chromium 버전은 상대 색상 구문을 지원해야 하므로, 해당 기능이 비활성화되었을 수 있습니다. 어쩌면 우연히 그렇게 되었을지도요?
5개의 좋아요
아, 좋습니다.
5월 1일 버전에서도 이렇게 될까요, 아니면 버전별로 테스트를 할 건가요?
Kiwi는 더 이상 유지 관리되지 않습니다.
네, Discourse가 검사하는 기존 기능 목록에 이 항목들을 추가할 예정입니다 
1개의 좋아요
이 변경 사항이 99%의 사용자들에게 속도를 높여줄 것이라고 하셨는데, 충분히 이해할 수 있는 부분입니다. 하지만 그 반대편에서는 나머지 1%의 사용자들에게 완전히 접근을 차단한다는 뜻이기도 합니다.
그렇다면 실제로 그 1%에 해당하는 사용자는 몇 명이나 될까요?
백분율로만 들으면 작아 보이지만, 실제 숫자가 생각보다 크다는 이유로 여기에 공개하기가 부담된다면, 그들을 정말로 접근을 차단할 정도로 미미한 존재로 볼 수 있는지에 대해 다시 한번 생각해 볼 가치가 있을 것입니다.
4개의 좋아요
내 컴퓨터 대부분은 최신 기종이지만, 업그레이드가 불가능한 한 대에서 이 메시지가 떴습니다.
최소 요구 사양은 계속 높아질 수밖에 없겠지만, 가능하면 비지원 브라우저에서도 최소한의 기능을 사용할 수 있도록 깔끔한 폴백을 마련해 주셨으면 합니다. 모든 bells and whistles(추가 기능)을 쓸 수는 없더라도, 로그인, 게시물/스레드 보기 및 생성 정도는 할 수 있도록요.
6개의 좋아요
왜?? 이건 제3국에 사는 사람들을 향한 차별이야!
인터넷을 망가뜨리지 마, 35년 동안이나 존재해 온 거잖아!
1개의 좋아요
제게는 이 문제가 Discourse보다 훨씬 더 큰 사안으로 보입니다. 이는 하드웨어, 운영체제, 웹 브라우저 벤더들이 지원, 업데이트, 업그레이드를 너무 일찍 중단하는 문제입니다. 업데이트 비용은 최소한의 금액으로 유지되어야 하며, 이를 통해 모든 사용자가 업데이트를 받을 수 있어야 합니다.
Discourse를 비롯한 다른 소프트웨어(앱 포함) 개발자들은 우리가 살고 있는 생태계의 손에 완전히 맡겨져 있는 셈입니다.
8개의 좋아요
다만, 내 (Android) 브라우저에서 차단할 첫 번째 사이트는 Discourse가 될 겁니다.
커뮤니티의 피드백과 Windows 7/8에 미치는 영향에 대해 수집한 추가 정보를 바탕으로, 2025년 7월 예정된 다음 Discourse 안정판 릴리스 이후로 이 변경 사항을 연기하기로 결정했습니다. 이를 통해 커뮤니티와 사용자들이 변경 사항에 대비할 수 있는 시간이 3개월 더 주어집니다.
또한, 자체 호스팅 관리자들이 커뮤니티를 안정판 브랜치로 전환할 수 있는 선택지를 제공합니다. 해당 브랜치는 2026년 초에 나올 다음 릴리스까지 구형 브라우저에서도 계속 작동합니다.
새로운 기술을 계속 추진할 수 있도록, 우리의 신규 “Horizon 테마”는 이미 이러한 최신 브라우저 기능 중 일부를 사용하고 있습니다. Horizon을 사용하는 사이트에서는 구형 브라우저를 사용하는 사용자에게 이미 기본 HTML 뷰가 표시되고 있습니다.
해당 내용을 반영하여 원본 게시글(OP)을 업데이트하겠습니다. 
15개의 좋아요
좋습니다. 이러한 도입 사례들을 접근성과 포용성의 문제로 바라봐 주시기를 권유할 수 있을까요? (즉, Discourse 팀에게요)
4개의 좋아요
감사합니다.
해당 기간 동안, 모든 기능을 포함하지는 않더라도 게시글 작성과 스레드 시작, 그리고 읽기 기능은 유지되는 Discourse 버전을 계속 제공해 주실 것을 고려해 주시기 바랍니다. 이는 구형 장비에서도 계속 사용할 수 있도록 하기 위한 것입니다.
3개의 좋아요
감사합니다! 확실히 도움이 되며, 패닉을 줄여줍니다.
하지만:
이 두 가지도 여전히 매우 유효한 지적입니다.
많은 사람들이 주장하는 것은 X 기능이 Y 버전에서 Z 시간 동안 지원되어야 하느냐 마느냐가 아니라, Discourse가 **적절한 기능 저하(graceful degradation)**를 제공해야 한다는 것입니다. 초기 포럼들이 제공했던 것과 같은 단순한 HTML + HTTP POST 모드 같은 것이죠. 이상적으로는 새로운 기능, 특히 외형적인 변경보다, 그리고 성능 최적화보다도 이것이 우선시되어야 합니다.
Discourse 사용자는 커뮤니티와 새로운 기능 사이에서 선택을 강요받아서는 안 됩니다 — 그리고 이 부분은 분명 문화적 문제이기도 합니다. 개발자들은 “조금 빠르게, 너무 빠르게는 아니고, 몇 가지는 깨뜨리되 너무 많이 깨뜨리지는 않는” 방향을 원하고 싶어 보입니다. 소프트웨어 회사로서는 완전히 합리적인 입장이지만, 이것이 반드시 Discourse 커뮤니티들이 원하는 입장과 같지는 않습니다. 어떤 커뮤니티는 더 빠르게 움직이고 싶어 하고, 다른 커뮤니티는 훨씬 느리게 움직이거나 아예 움직이지 않는 것을 선호할 것입니다.
제게 있어, 오늘날의 Discourse는 이미 "충분히 좋다"고 생각합니다. 호스팅 고객들이 향후 10년간 새로운 기능이 추가되지 않고, 중요한 보안 수정만 이루어지는 장기 지원(LTS) 브랜치를 선택할 수 있는 옵션이 있다면, 새 버전이 10배 더 빠르더라도 저는 그걸 선택할 것입니다. 저는 생존자들에게 더 빠르고 화려한 경험을 제공하기 위해 사용자를 점차 잃어가는 것보다, 모두가 사용할 수 있는 느린 포럼을 훨씬, 훨씬 더 원합니다.
하지만 모든 사람이 동의하지는 않을 것입니다. 개발자(제 생각에는)와 다른 Discourse 커뮤니티 모두에게 그 속도는 너무 느릴 것입니다… 이는 전적으로 그들의 사용자 및 기기 인구통계에 달려 있습니다. 예를 들어, 노년층을 위한 포럼은 AI 포럼과 같은 기능을 추구하지 않을 것입니다.
하지만 그들은 서로 그렇게 싸울 필요가 없어야 합니다. 이는 상호 배타적인 목표가 아닙니다. 적절한 기능 저하는 웹의 초기 시절부터 기본 원칙이었으며, Discourse는 이미 충분히 헤드리스(다양한 API와 Discorkie와 같은 제3자 구현으로 입증됨)하여 “단순 HTML” 모드를 제공하여 기본적인 읽기 + 게시 기능을 지원할 수 있어야 합니다. 화려한 테마가 필요하지도, 무한 페이지네이션이 필요하지도, 심지어 편집과 알림 및 기타 모든 좋은 기능이 반드시 필요하지도 않습니다. 사람들이 포럼의 의도된 기능인 읽기와 게시를 여전히 사용할 수 있는 기본적인 사용 가능한 경험만 있으면 됩니다. 90년대 유즈넷 스타일의 UX보다 더 많은 것을 제공하지 않아도, 완전히 차단당하는 것보다는 낫습니다. 개발 시간이 조금 더 들면, vBulletin 스타일의 PHP 시대 UI를 제공할 수 있고, 이는 (7월에 여전히 볼 수 있을) “죄송합니다, 더 이상 게시할 수 없습니다” 상황보다 여전히 큰 개선이 될 것입니다.
제 생각에 Discourse는 무엇보다 커뮤니티에 관한 것(이거나, 그래야 합니다). 더 이상 기술 데모가 아니며, 제 개인적 선호는 그것이 거의 변하지 않는 "안정적이고 지루한 소프트웨어"로 여겨지는 것이지만… 개발자와 다른 Discourse 커뮤니티가 그렇게 원하지 않을 수 있다는 것은 이해합니다. 괜찮습니다. 이는 은행 메인프레임이 아니니까요 
하지만 반대로, 끊임없는 브라우저 개선(이는 결코 끝나지 않을 것입니다)을 추구할 필요도 없습니다. 이 두 극단 사이에서, 기본 HTML 모드는 사용자가 브라우저가 구식이 된 후에도 오랫동안 게시를 계속할 수 있게 해 주며, 동시에 사용자가 대체할 무언가를 가질 수 있기 때문에 메인 브랜치에서 더 빠른 기능 개발을 가능하게 합니다.
보너스로, 실제로 원하는 시간 창 기반 개발(예: “2년 이내의 브라우저 또는 caniuse 95% 기준까지 지원할 것입니다”)을 실제로 타겟팅할 수 있게 해 줄 수 있습니다. 이는 하드웨어 + OS + 브라우저 + 포크의 모든 조합에 걸쳐 개별 기능을 체리피킹하는 대신입니다. 그 타겟보다 오래된 사용자도 기본 HTML 모드를 통해 게시할 수 있지만, 최신 테마, _____, ______, _____ 등을 사용할 수는 없을 것입니다(이것은 괜찮은 일입니다. 아마 그들은 그런 것에 관심이 없을 테니까요). 이는 모든 기능을 모든 브라우저와 교차 확인해야 하는 부담에서 벗어나게 해 줍니다… 사용자가 어떤 화려한 기능을 사용할 수 없다면, 그것은 정말로 새로운 브라우저로 업그레이드하는 것이 그들에게 달려 있을 것입니다. 하지만 적어도 그들은 그들의 커뮤니티에서 쫓겨나지는 않을 것입니다.
9개의 좋아요
이 부분은 확실하지 않습니다(스크립트 소스를 알지 못하기 때문이죠), 하지만 수년 동안 브라우저 로딩 시 간단한 테스트를 수행하여 브라우저가 해당 버전을 지원할 수 있는지에 따라 자동으로 한 버전을 선택하는 사이트를 여러 번 본 적이 있습니다. 그리고 보통 이 과정은 투명하게 이루어져 사용자가 그 프로세스를 인식하지도 못합니다.
Discourse에는 이미 구형 브라우저를 배제하지 않는 작동하는 버전(지금 사용 중인 버전)이 있으므로, 스크립트 로딩 시작 부분에 단일 테스트를 추가하고 테스트의 통과 또는 실패에 따라 로드되는 부분을 조건부로 설정하는 것은 충분히 쉬울 것입니다. 예를 들어 "테스트 통과 시 모든 새 기능이 포함된 버전을 로드하고, 테스트 실패 시 구버전을 로드"하는 방식이죠… 많은 다른 사이트들이 수년 전부터 이미 이렇게 하고 있는데, 왜 Discourse에서는 불가능해야 하는가요?
2개의 좋아요
방금 해본 재미있는 실험:
Windows XP의 IE 6에서 TLS 오류 발생
같은 Windows XP에서 여전히 이를 지원하는 브라우저(Supermium) 사용
같은 Windows XP, 이제 r3dfox 사용
15개의 좋아요
업데이트와 지연에 대해 감사드립니다. 하지만 이 결정의 근거에 대해 후속 질문이 있습니다.
커뮤니티와 사용자들이 변경 사항에 대비할 시간을 더 주겠다고 언급하셨습니다. 이는 1%의 주요 장애물이 브라우저나 OS를 업데이트할 시간의 부족이라는 것을 의미합니다. 그 가정을 뒷받침하는 데이터는 무엇인가요?
만약 그 1%의 다수가 단순히 미루는 것이 아니라 하드웨어나 OS의 제한으로 인해 업데이트할 수 없는 상황이라면, 카트오프를 몇 달 늦춘다고 해서 실제로 도움이 되지 않습니다. 핵심 문제를 해결하지 않고 단순히 문제를 미루는 것뿐입니다.
따라서 더 많은 시간이 영향을 받는 사용자의 수를 현저히 줄일 것이라는 강력한 데이터가 없다면, 이 변경 사항은 돌아올 수 없는 상당한 수의 사람들을 여전히 배제하게 될 것입니다.
그 1%에 대해 데이터가 실제로 무엇을 보여주는지에 대한 명확한 답변을 부탁합니다.
2개의 좋아요