Por que o hack do console do Google Docs é a maneira errada de obter visualização de duas páginas

É por isso que o truque é tão sedutor e enganoso ao mesmo tempo. Ele resolve primeiro a reclamação visual, o que faz com que pareça inteligente, mas deixa a parte difícil intocada: como o editor se comporta quando você realmente digita, seleciona, comenta e percorre o documento.

Antes e depois do hack do console

Você deve ter visto o truque do console do navegador que força o Google Docs a um layout de pseudo duas páginas. À primeira vista, parece útil: as páginas aparecem lado a lado e um monitor amplo parece menos desperdiçado.

Essa impressão visual é o truque. Não é um modo de edição real e não é uma solução adequada. É uma substituição rápida do DOM que faz com que a tela pareça diferente.

Como funciona o hack

A postagem original do Coderwall por Jeremy no Coderwall descreve o truque como um simples ajuste de CSS: faça com que os contêineres da página preencham a largura, flutuem as páginas para a esquerda e forcem o layout em uma visualização falsa de duas colunas.

(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');

A redação original é de Jeremy no Coderwall, e a versão do bookmarklet está vinculada a essa postagem.

Em outras palavras, o hack é principalmente uma substituição de estilo. Não ensina o Google Docs a editar de forma diferente. Apenas convence o navegador a pintar a interface de uma forma que se pareça mais com duas páginas.

Por que a página certa não parece confiável

O Google Docs ainda calcula o posicionamento do cursor, testes de acerto, seleção e comentários em torno de seu modelo de layout original. O hack apenas repinta onde as páginas aparecem na tela, de modo que o resultado visual e o modelo de edição se distanciam.

• O posicionamento do cursor pode variar: cliques e seleções nem sempre se alinham com o texto visível.
• A edição ativa fica instável: a visualização pode ser boa para revisão, mas menos confiável para escrita real.
• Comentários e sobreposições podem se comportar mal: o truque não foi projetado em torno da superfície completa da interface do usuário do Docs.
• É frágil por natureza: os nomes e a estrutura das classes internas do Documentos podem mudar sem aviso prévio.

Por que não é o caminho certo

O hack oferece um resultado visual que parece inteligente por um minuto, mas um fluxo de trabalho de escrita real precisa sobreviver ao uso diário. Você precisa de estabilidade do cursor, seleção previsível, comentários que cheguem onde deveriam e um layout que permaneça compreensível após a décima edição do dia.

O truque do console falha nesse teste porque não é um recurso do produto. É uma manipulação do DOM. Depois de tratá-lo como um fluxo de trabalho, os pontos fracos aparecem imediatamente.

Quando o hack ainda é útil

Se você só precisa de uma demonstração rápida somente leitura em sua própria máquina, pode ser divertido tentar o hack. Mas para escrita, revisão ou colaboração do dia a dia, um fluxo de trabalho com layout nativo é a escolha mais segura.

Essa é a linha a ter em mente: demonstração divertida, mau hábito. Se você está tentando realmente trabalhar, não deve confiar em um truque que pode ser bloqueado completamente por Trusted Types ou que pode parar de funcionar no momento em que o Google altera o nome de uma classe ou reflui o editor novamente.

O problema não é apenas a fragilidade. Também é confiança. Um fluxo de trabalho de escrita deve ser entediante da melhor maneira possível. No momento em que um truque de layout faz você hesitar antes de clicar ou selecionar um texto, ele já ultrapassou os limites de útil para distrativo.

Resultado final

O truque do console é uma demonstração inteligente, não uma superfície de edição confiável. Se você deseja um trabalho lado a lado do Google Docs em que possa confiar todos os dias, use o DocDocDoc.

A resposta rápida

Se você estiver curioso, experimente o hack uma vez como um experimento visual. Se você está tentando escrever, revisar ou colaborar, pare por aí. Um truque que altera apenas a camada de pintura nunca será a resposta adequada para um documento ativo.

A melhor questão não é se o hack pode fazer a tela parecer diferente. A melhor pergunta é se isso ajuda você a finalizar o documento. Na prática, a resposta é não. Foi útil apenas para visualização, não para edição real.

O que as pessoas estão realmente perseguindo

A maioria das pessoas que procuram esse hack não está realmente procurando CSS. Eles estão procurando um alívio para a sensação de página única do Google Docs. Eles querem que a página pareça mais larga, que a próxima página fique à vista e que todo o processo de edição pareça menos apertado.

É exatamente por isso que o hack chama a atenção. Parece responder à reclamação real. Mas, como altera apenas a camada visual, não pode fornecer a estabilidade que um fluxo de trabalho diário de escrita precisa.

Referências e leituras adicionais

• coderwall.com/p/qvdxia/2-page-view-in-google-docs
• README de extensão lado a lado e problemas conhecidos: github.com/ryanpcmcquen/side_by_side_gdocs
• Fonte do script de extensão (manipulação de DOM/CSS): raw.githubusercontent.com/.../side_by_side_gdocs.js
• Ajuda oficial "lado a lado" do Google (aplicativos do painel lateral, não edição de várias páginas): support.google.com/docs/answer/106237