Google Docs 콘솔 해킹이 두 페이지 보기를 얻는 잘못된 방법인 이유

그렇기 때문에 그 트릭은 매우 매혹적이며 동시에 오해의 소지가 있습니다. 시각적인 불만 사항을 먼저 해결하여 기발한 느낌을 주지만 어려운 부분은 그대로 유지합니다. 즉, 실제로 문서를 입력하고, 선택하고, 주석을 달고, 이동할 때 편집자가 어떻게 작동하는지입니다.

콘솔 해킹 전과 후

Google 문서도구를 가상의 두 페이지 레이아웃으로 만드는 브라우저 콘솔 트릭을 본 적이 있을 것입니다. 언뜻 보면 유용해 보입니다. 페이지가 나란히 표시되고, 와이드 모니터가 덜 낭비적인 느낌을 줍니다.

그 시각적인 인상이 전부입니다. 실제 편집 모드도 아니고, 적절한 해결 방법도 아닙니다. 화면을 다르게 보이게 만드는 빠른 DOM 재정의입니다.

해킹의 작동 방식

원본 Coderwall 게시물: Coderwall의 제레미 이 트릭을 간단한 CSS 조정으로 설명합니다. 페이지 컨테이너가 너비를 채우고, 페이지를 왼쪽으로 띄우고, 레이아웃을 가짜 2열 보기로 강제 설정합니다.

(function(d,t,z,s) {
      s = d.createElement(t);
      s.innerHTML = z+'-outer{left:0px !important;}'+z+'-outer,'+z+'-inner{width:100% !important;}.kix-page{float:left; width:48% !important;}';
      d.getElementsByTagName(t)[0].parentNode.appendChild(s);
      })(document, 'style', '.kix-zoomdocumentplugin');

원본 글은 다음과 같습니다. Coderwall의 제레미, 북마크릿 버전은 해당 게시물에서 링크됩니다.

즉, 해킹은 대부분 스타일 재정의입니다. Google 문서도구에 다르게 편집하도록 가르치지는 않습니다. 단지 두 페이지처럼 보이는 방식으로 인터페이스를 그리도록 브라우저를 설득할 뿐입니다.

올바른 페이지가 신뢰할 수 없다고 느껴지는 이유

Google 문서도구는 원래 레이아웃 모델에 대한 캐럿 배치, 적중 테스트, 선택 및 설명을 계속 계산합니다. 해킹은 화면에 페이지가 나타나는 위치에만 다시 칠하므로 시각적 결과와 편집 모델이 서로 떨어져 있습니다.

• 커서 배치가 바뀔 수 있습니다. 클릭과 선택이 항상 보이는 텍스트와 일치하는 것은 아닙니다.
• 활성 편집이 불안정해짐: 뷰는 검토용으로 적합하지만 실제 글쓰기에는 덜 신뢰할 수 있습니다.
• 댓글과 오버레이가 오작동할 수 있습니다. 트릭은 전체 Docs UI 표면을 중심으로 설계되지 않았습니다.
• 본질적으로 깨지기 쉽습니다. 내부 Docs 클래스 이름과 구조는 경고 없이 변경될 수 있습니다.

왜 올바른 방법이 아닌가

해킹은 잠시 동안 기발한 느낌을 주는 시각적 결과를 제공하지만 실제 글쓰기 작업 흐름은 일상적인 사용에서도 살아남아야 합니다. 커서 안정성, 예측 가능한 선택, 필요한 위치에 배치되는 주석, 하루에 10번째 편집 후에도 이해할 수 있는 레이아웃이 필요합니다.

콘솔 트릭은 제품 기능이 아니기 때문에 해당 테스트에 실패했습니다. DOM 조작입니다. 워크플로처럼 처리하면 약점이 즉시 나타납니다.

해킹이 여전히 유용할 때

자신의 컴퓨터에서 빠른 읽기 전용 데모만 필요한 경우 해킹을 시도해 보는 것이 재미있을 수 있습니다. 그러나 일상적인 글쓰기, 수정 또는 공동 작업의 경우 레이아웃 기본 작업 흐름이 더 안전한 선택입니다.

명심해야 할 점은 재미있는 데모, 나쁜 습관입니다. 실제로 작업하려는 경우 Trusted Types에 의해 완전히 차단될 수 있거나 Google이 클래스 이름을 변경하거나 편집기를 다시 리플로우하는 순간 동작을 멈출 수 있는 트릭에 의존해서는 안 됩니다.

문제는 취약성뿐만이 아닙니다. 역시 신뢰입니다. 글쓰기 작업 흐름은 가능한 최선의 방법으로 지루함을 느껴야 합니다. 레이아웃 트릭으로 인해 텍스트를 클릭하거나 선택하기 전에 망설이게 되는 순간, 이미 유용한 수준에서 주의를 산만하게 만드는 수준으로 넘어간 것입니다.

결론

콘솔 트릭은 신뢰할 수 있는 편집 표면이 아니라 영리한 데모입니다. 매일 신뢰할 수 있는 Google 문서 작업을 나란히 두고 싶다면 대신 DocDocDoc을 사용하세요.

빠른 답변

궁금하다면 시각적 실험으로 한 번 해킹을 시도해보세요. 글을 쓰거나 수정하거나 공동 작업을 하려는 경우 거기서 멈추세요. 페인트 레이어만 변경하는 트릭은 결코 라이브 문서에 적합한 답이 될 수 없습니다.

더 나은 질문은 해킹으로 인해 화면이 다르게 보일 수 있는지 여부가 아닙니다. 더 좋은 질문은 그것이 문서를 완성하는 데 도움이 되는지 여부입니다. 실제로 대답은 '아니요'입니다. 실제 편집에는 유용하지 않고 보기에만 유용했습니다.

사람들이 실제로 쫓고 있는 것은 무엇인가?

이 해킹을 검색하는 대부분의 사람들은 실제로 CSS를 찾는 것이 아닙니다. 그들은 Google Docs의 단일 페이지 느낌에서 벗어나기를 원합니다. 그들은 페이지가 더 넓어 보이고, 다음 페이지가 눈에 띄고, 전체 편집 과정이 덜 답답해지기를 원합니다.

해킹이 주목받는 이유도 바로 여기에 있다. 진짜 불만에 답하는 것 같습니다. 하지만 시각적인 레이어만 변경하기 때문에 일상적인 글쓰기 작업 흐름에 필요한 안정성을 제공할 수 없습니다.

참고 자료 및 추가 자료

• coderwall.com/p/qvdxia/2-page-view-in-google-docs
• 병렬 확장 README 및 알려진 문제: github.com/ryanpcmcquen/side_by_side_gdocs
• 확장 스크립트 소스(DOM/CSS 조작): raw.githubusercontent.com/.../side_by_side_gdocs.js
• Google의 공식 "병렬" 도움말(여러 페이지 편집이 아닌 측면 패널 앱): support.google.com/docs/answer/106237