為什麼 Google Docs 控制台 hack 是獲得兩頁視圖的錯誤方法
這個駭客作為一個視覺實驗很聰明，但它只是重新繪製了谷歌文件。它不會改變下面的編輯器模型，這就是為什麼佈局看起來正確，但編輯行為仍然感覺錯誤的原因。
這就是為什麼這個技巧如此誘人，同時又如此具有誤導性。它首先解決了視覺上的問題，這讓人感覺很聰明，但它沒有觸及最困難的部分：當您實際鍵入、選擇、評論和瀏覽文件時編輯器的行為方式。
這在目前的 Chrome 和 Google 文件中不再有效
Google 文件現在發送需要受信任類型的內容安全策略，因此小書籤嘗試寫入內部HTML 被阻止。在目前的 Chrome 中，您會看到類似「此文件需要 TrustedHTML
分配”和“無法設定“元素”的“innerHTML”屬性”。
這是瀏覽器和文件的更改，而不是程式碼片段中的拼字錯誤。該頁面現在強制執行更安全的 DOM 策略，因此舊的 DOM 覆蓋甚至永遠不會套用。
即使這確實有效，也只是改變了佈局。它對於查看文件很有用，而不是對於製作 Google 文檔是一個更好的編輯器。
控制台破解之前和之後
| Feature | 控制台駭客 | 文檔文檔文檔 |
|---|---|---|
| 使用支援的編輯器行為 | ✕ | ✓ |
| 保持遊標和註釋位置可預測 | ✕ | ✓ |
| 經受 Google UI 更改而不會造成破壞 | ✕ | ✓ |
| 感覺像是一個產品而不是一個腳本 | ✕ | ✓ |
跳過脆弱的黑客行為。 在專為日常寫作而設計的穩定的並排編輯器中開啟同一個 Google 文件。
您可能已經看到了瀏覽器控制台的技巧，它迫使 Google 文件進入偽兩頁佈局。乍一看，它看起來很有用：頁面並排顯示，而且寬顯示器感覺不那麼浪費。
這種視覺印象就是整個技巧。它不是真正的編輯模式，也不是正確的解決方案。這是一個快速的 DOM 覆蓋，恰好使螢幕看起來不同。
駭客是如何運作的
Coderwall 的原始貼文由 傑里米 (Jeremy) 在 Coderwall 上 將這個技巧描述為一個簡單的 CSS 調整：讓頁面容器填滿寬度，使頁面向左浮動，並強制佈局成為假的兩列視圖。
(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');原來的寫法是 傑里米 (Jeremy) 在 Coderwall 上，並且書籤版本是從該帖子鏈接的。
換句話說，駭客攻擊主要是樣式覆蓋。它並沒有教 Google 文件以不同的方式進行編輯。它只是說服瀏覽器以看起來更像兩個頁面的方式繪製介面。
為什麼正確的頁面感覺不可靠
Google 文件仍然圍繞其原始佈局模型計算插入符位置、命中測試、選擇和註釋。此駭客僅重新繪製頁面在螢幕上出現的位置，因此視覺結果和編輯模型會分開。
- 遊標位置可能會漂移： 單擊和選擇並不總是與可見文字對齊。
- 主動編輯變得不穩定： 該視圖對於複習來說可能很好，但對於真正的寫作來說不太可靠。
- 評論和疊加可能會出現錯誤： 這個技巧並不是圍繞著整個文件使用者介面設計的。
- 它本質上是脆弱的： 內部文件類名稱和結構可能會更改，恕不另行通知。
為什麼這不是正確的方法
這個技巧給你一個視覺效果，讓你感覺很聰明，但真正的寫作工作流程必須能夠適應日常使用。您需要遊標穩定性、可預測的選擇、位於應有位置的註釋以及在當天第十次編輯後仍可理解的佈局。
控制台技巧未通過該測試，因為它不是產品功能。這是一個 DOM 操作。一旦你將其視為工作流程，弱點就會立即顯現出來。
為什麼DocDocDoc不同
- 版面和編輯是一起建構的： 並排視圖不是 docs.google.com 的塗裝。
- 它實際上是可以並排編輯的： 你不會得到 CSS hack 中經常出現的僅限左頁的警告。
- 它更接近支援的路徑： 文件透過官方 Google API 同步，而不是依賴內部 DOM 假設。
- 它添加了有用的附加功能： 原生深色模式、列帶樣式寬度使用和 LaTeX 渲染工作流程。
當駭客仍然有用時
如果您只需要在自己的計算機上進行快速只讀演示，那麼嘗試該技巧可能會很有趣。但對於日常寫作、修訂或協作，佈局本機工作流程是更安全的選擇。
這是要記住的一句話：有趣的演示，壞習慣。如果您嘗試實際工作，則不應依賴可被受信任類型完全阻止的技巧，或者當 Google 更改類別名稱或再次重新排列編輯器時可能停止運行的技巧。
问题不仅仅是脆弱性。這也是信任。寫作工作流程必須以最好的方式讓人感到無聊。一旦佈局技巧讓您在單擊或選擇文字之前猶豫不決，它就已經從有用變成了分散注意力。
真正的佈局是什麼樣的
底線
控制台技巧是一個聰明的演示，而不是一個可靠的編輯介面。如果您想要每天可以信賴的平行 Google 文件工作，請改用 DocDocDoc。
快速回答
如果您好奇，可以嘗試一次作為視覺實驗。如果您正在嘗試寫作、修改或協作，請就此打住。僅更改繪畫層的技巧永遠不會成為即時文件的正確答案。
更好的問題不是駭客是否可以讓螢幕看起來有所不同。更好的問題是它是否可以幫助您完成文件。在實踐中，答案是否定的。它只對查看有用，對真正的編輯沒有用。
人們真正追求的是什麼
大多數搜尋此 hack 的人並不是真正在尋找 CSS。他們正在尋求從 Google 文件的單頁感覺中解脫出來。他們希望頁面看起來更寬，下一頁留在視野中，整個編輯過程感覺不那麼局促。
這正是這次駭客攻擊引起關注的原因。這似乎回答了真正的抱怨。但由於它只改變了視覺層，因此無法提供日常寫作工作流程所需的穩定性。
參考文獻和進一步閱讀
- coderwall.com/p/qvdxia/2-page-view-in-google-docs
- 並行擴展自述文件和已知問題： github.com/ryanpcmcquen/side_by_side_gdocs
- 擴充腳本來源（DOM/CSS操作）： raw.githubusercontent.com/.../side_by_side_gdocs.js
- Google 的官方「並排」幫助（側面板應用程序，而不是多頁編輯）： support.google.com/docs/answer/106237