주제를 아래로 스크롤할 때 이전 게시글이 페이지에 유지되도록 하는 방법이 있을까요? 현재 방식은 브라우저 내장 페이지 검색 기능을 깨뜨립니다. Discourse의 주제 검색보다 브라우저 검색이 훨씬 간편하거든요. 페이지 어디에서든 Command-F를 눌러 텍스트를 입력하면, 렌더링된 텍스트에서 발생 위치를 빠르게 검색할 수 있습니다. 반면 Discourse의 검색을 사용하려면 맨 위로 스크롤한 뒤 검색 아이콘을 클릭하고, “이 주제” 상자를 확인한 다음 결과를 클릭해 문맥을 봐야 합니다. 다른 결과를 확인하고 싶을 때마다 이 과정을 반복해야 합니다.
이상적으로는 전체 스레드가 로드되도록 하는 것이 좋겠지만, 그렇게 하지 않는 이유도 이해합니다. 적어도 키보드를 이용해 빠르게 맨 아래로 스크롤하여 더 많은 내용을 로드할 수는 있죠. 다만 이렇게 하면 이전에 보았던 게시글이 삭제되어 검색이 불가능해집니다.
키보드의 끝(End) 키를 누르거나, 타임라인 하단의 날짜를 클릭/탭하면 됩니다. 또한 마지막 게시글 시간이나 게시글 수를 클릭하여 하단에서 특정 주제를 직접 입력할 수도 있습니다.
이를 위해 사용할 수 있는 인쇄 전용 특수 경로가 있습니다.
https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889/print
(새 탭에서 열어야 합니다). 이렇게 하면 JS가 없는 뷰로 최대 1,000개의 게시글이 로드됩니다.
“print” 루트는 좋은 시작이지만, 제가 진짜 원했던 것과는 아직 거리가 있습니다.
이전 버전에서는 스크롤을 통해 전체 토픽(또는 특정 순서에 관련 있는 섹션만)을 불러오고, 그 상태를 유지한 채 SingleFile을 사용해 전체 토픽을 아카이브로 내보낼 수 있었습니다. 일반 포럼 페이지와 정확히 동일하게 표시되는 형태였죠. 스크린샷과 비슷하지만, 크기는 더 작고 스크롤 및 확대가 가능하며, 링크는 클릭 가능하고, 이미지는 저장 가능하며, 텍스트는 픽셀이 아닌 실제 텍스트로 표현됩니다. 또한 페이지를 먼저 준비하는 과정도 가능했습니다. 예를 들어 “3개의 답변” 위젯을 펼치거나, 스포일러를 해제하거나, 심지어 답변 위젯에 개인 메모를 첨부해 아카이브의 일부로 표시되지만 실제 포럼에는 게시되지 않도록 하는 것 등이죠. uBlock Origin의 "zapper"를 사용해 저장하려는 토픽의 해당 부분에 관련이 없는 게시물을 제거할 수도 있었습니다… 이렇게 하면 토론을 제가 필요한 정확한 댓글들만으로 정리할 수 있었죠.
그런데 Discourse 업데이트 과정에서 이 기능이 사라졌습니다. 이제 제가 할 수 있는 최선은 한 번에 몇 개의 게시물만 불러오는 것입니다. 브라우저가 허용하는 한도까지 줌을 내리면 화면에 더 많은 게시물을 표시할 수 있을지도 모르지만요.
게시물 언로딩을 멈추도록 강제할 수 있는 방법이 있다면 정말 좋겠습니다. 예를 들어 핫키나 버튼, 혹은 코나미 코드, 뭐든 상관없습니다. 그냥 무언가를 눌러 이 브라우저 탭에서만 화면 밖 게시물을 언로딩하는 자바스크립트 기능을 일시적으로 비활성화할 수 있다면요.
예를 들어, 수년에 걸쳐 이어진 그룹 바이에 대한 12,000개 댓글이 달린 토픽이 있다고 가정해 보겠습니다. 그 중간에 사람들이 원래 주제에서 벗어나 100개의 게시물에 걸쳐 고양이 이야기를 나누고 다시 원래 주제로 돌아간다고 합시다. 저는 고양이 토론의 시작 부분까지 스크롤을 내린 뒤, Discourse에서 “게시물 언로딩 중지” 핫키를 누르고, 아래로 스크롤한 다음, uBlock의 zapper를 사용해 고양이와 관련 없는 게시물을 모두 제거하고, 고양이 토론의 끝까지 스크롤한 뒤, SingleFile 핫키를 눌러 DOM을 .html 파일로 저장할 수 있습니다.
작년까지도 이렇게 할 수 있었습니다. 언제부터 안 되는지 정확히 모르겠습니다. 언로딩 동작은 10년 전부터 이미 존재했던 것 같으니, 아마도 그 동작을 가능하게 했던 것이 버그였을 수도 있겠네요. 하지만 저는 그 버그를 좋아했고, 가끔은 그 기능을 되살릴 수 있으면 좋겠습니다.
이렇게 하면 탭이 훨씬 더 많은 리소스를 소모할 것이라는 점은 알고 있습니다. 괜찮습니다. RAM 사용량을 최소화하는 것보다 "DOM에 더 많은 콘텐츠가 로드되는 것"이 더 중요한 사용 사례가 있으니까요.