Google ドキュメント コンソールのハッキングが 2 ページ表示を取得する間違った方法である理由

だからこそ、このトリックは非常に魅惑的であると同時に、非常に誤解を招きやすいのです。これにより、最初に視覚的な問題が解決され、賢くなったように感じられますが、実際に文書を入力、選択、コメントし、移動するときにエディターがどのように動作するかという難しい部分は手つかずのままになっています。

コンソールハックの前後

Google ドキュメントを疑似 2 ページ レイアウトに強制するブラウザ コンソールのトリックを見たことがあるかもしれません。一見すると便利そうに見えます。ページが並べて表示され、広いモニターでも無駄が少なく感じられます。

その視覚的な印象がすべてのトリックです。これは実際の編集モードではなく、適切な解決策でもありません。これは、画面の外観を変更するための簡単な DOM オーバーライドです。

ハッキングの仕組み

元の 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');

元の書き込みは次のとおりです ジェレミーがコーダーウォールについて語る、ブックマークレットのバージョンはその投稿からリンクされています。

言い換えれば、ハックのほとんどはスタイルのオーバーライドです。 Google ドキュメントに別の編集方法を教えるわけではありません。ブラウザーにインターフェイスを 2 ページのように見えるように描画させるだけです。

適切なページが信頼できないと感じる理由

Google ドキュメントは引き続き、元のレイアウト モデルに基づいてキャレットの配置、ヒット テスト、選択、コメントを計算します。このハックでは、画面上にページが表示される場所のみが再描画されるため、視覚的な結果と編集モデルは乖離します。

• カーソルの位置がずれる場合があります。 クリックや選択は、表示されているテキストと必ずしも一致するとは限りません。
• アクティブな編集は不安定になります: このビューはレビューには問題ありませんが、実際の執筆にはあまり信頼できません。
• コメントとオーバーレイは誤動作する可能性があります。 このトリックは、ドキュメント UI 表面全体を中心に設計されているわけではありません。
• 本質的に壊れやすいものです。 Docs の内部クラス名と構造は、警告なしに変更される可能性があります。

なぜそれが正しい方法ではないのか

このハックにより、一時的には賢いと感じる視覚的な結果が得られますが、実際の執筆ワークフローは毎日の使用に耐える必要があります。カーソルの安定性、予測可能な選択、コメントが配置されるべき場所に配置されること、その日 10 回目の編集後でも理解できるレイアウトが必要です。

コンソールのトリックは製品の機能ではないため、テストに失敗します。 DOM操作です。ワークフローとして扱うと、弱点がすぐに現れます。

ハックがまだ役立つ場合

自分のマシン上で簡単な読み取り専用デモだけが必要な場合は、このハックを試してみるのも楽しいでしょう。ただし、日常的な執筆、改訂、共同作業の場合は、レイアウト ネイティブのワークフローを使用する方が安全な選択です。

それは心に留めておくべきラインです: 楽しいデモ、悪い習慣。実際に作業しようとしている場合は、信頼できるタイプによって完全にブロックされたり、Google がクラス名を変更したりエディタを再度リフローしたりした瞬間に動作が停止する可能性があるトリックに依存すべきではありません。

問題は脆弱性だけではありません。それは信頼でもあります。執筆ワークフローは、可能な限り最高の方法で退屈に感じられるものでなければなりません。レイアウトのトリックによって、テキストをクリックしたり選択したりする前に躊躇してしまう瞬間、それはすでに役に立つものから気を散らすものへと一線を超えています。

結論

コンソールのトリックは賢いデモであ​​り、信頼できる編集画面ではありません。毎日信頼できる Google ドキュメントを並べて使用したい場合は、代わりに DocDocDoc を使用してください。

素早い答え

興味があれば、視覚的な実験としてこのハックを一度試してみてください。執筆、改訂、または共同作業を行おうとしている場合は、そこで停止してください。ペイント レイヤを変更するだけのトリックは、ライブ ドキュメントでは決して適切な答えにはなりません。

より良い質問は、ハッキングによって画面の見た目が変わるかどうかではありません。より良い質問は、それが文書を完成させるのに役立つかどうかです。実際には、答えはノーです。これは表示する場合にのみ役に立ち、実際の編集には役に立ちませんでした。

人々が実際に追い求めているもの

このハックを検索する人のほとんどは、実際には CSS を探しているわけではありません。彼らは、Google ドキュメントの単一ページの感覚から解放されることを求めています。彼らは、ページをより広く見せ、次のページが視界に留まり、編集プロセス全体が窮屈に感じられないことを望んでいます。

まさにそれが、このハッキングが注目を集める理由だ。本当の苦情に答えてくれるようです。ただし、視覚的なレイヤーを変更するだけであるため、毎日の執筆ワークフローに必要な安定性を提供することはできません。

参考文献とさらなる読み物

• coderwall.com/p/qvdxia/2-page-view-in-google-docs
• Side-by-side 拡張機能の 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