Talvez você, como eu, nunca tenha se atentado a isto, então comecemos esta notícia com um teste: pegue seu iPhone ou iPad (acho que a essa altura já podemos ignorar o iPod touch?). Abra um site no Safari e simplesmente role a página — sinta como ela se comporta com o movimento do seu dedo, perceba a “Física” por trás daquele pedaço de software. Agora repita esse teste em qualquer outra área do iOS, como uma playlist do Apple Music ou uma conversa no iMessage.
Notou a diferença? Pois é.
Este comportamento é fruto de uma decisão plenamente intencional tomada pela Apple há muito tempo, nos primórdios do seu sistema operacional móvel. Não há razões oficiais quanto a isso, mas se este que vos escreve pode arriscar um palpite, provavelmente o comportamento está relacionado à maneira que interagimos com uma página na web versus a maneira que interagimos com uma longa lista de músicas ou mensagens ou o que for — no primeiro caso, a interação é com todo o conteúdo, então a inércia da rolagem é maior e a página não pula várias linhas com um deslize do dedo; já no segundo, geralmente o usuário procura por um item específico e rola indefinidamente até achá-lo, portanto, a inércia pode ser menor.
Já estão sentindo-se Ph.Ds em Física depois do parágrafo anterior? Pois segurem este raciocínio por alguns instantes, porque não é exatamente deste assunto que viemos aqui tratar hoje.
No último sábado, John Gruber escreveu alguns parágrafos no Daring Fireball sobre o Google AMP (Accelerated Mobile Pages), o projeto de código aberto da gigante de Mountain View que transforma páginas de conteúdo majoritariamente textual (como esta exata postagem que você lê neste instante) em artigos instantâneos, com formatação própria e anúncios inteligentes — mais ou menos como os Instant Articles do Facebook.
Numa atitude provavelmente inédita, em vez de fazer o produto dos outros adequar-se ao seu estilo, a Apple vai adequar o seu estilo ao produto dos outros.
Basicamente, Gruber odeia o AMP — segundo ele, o projeto fere todos os princípios da web aberta que há tanto são pregados pelos especialistas da área ao colocar nas mãos de uma gigante (o Google, no caso) responsabilidades que não cabem a ela: as de publicação e editoração de conteúdos online — e da consequente administração dos lucros referentes à publicidade atrelada a eles. Esta é uma discussão importantíssima, mas para outro momento — o fato é que Gruber criticou também vários aspectos práticos das AMPs, como o fato de que elas quebram o recurso de Modo de Leitura do Safari e, adivinhem, que elas bagunçam todo o sistema de rolagem do navegador móvel.
Você pode tentar encontrar uma página gerada pelo AMP para testar por si mesmo, mas o 9to5Mac já fez um vídeo bastante esclarecedor sobre as diferenças de rolagem de uma página normal para uma página “acelerada pelo Google” no navegador móvel da Maçã (spoiler: as AMPs rolam quase como os outros elementos do sistema, mais fluidas e com menos inércia).
As críticas de Gruber, naturalmente — sendo ele um dos mais notáveis comentaristas do universo Apple e do mundo da tecnologia como um todo —, rodaram o mundo e chegaram à própria equipe de desenvolvimento do AMP. Um detalhe, em particular, incomodou o time: a rolagem “diferente” proporcionada pelas páginas “aceleradas” não era responsabilidade dos desenvolvedores, e sim graças a um comportamento do próprio iOS: sem entrar muito em detalhes técnicos, as páginas AMP empregam um código chamado overflow
, que é um comando CSS o qual permite que caixas (<div>
) dentro dos navegadores rolem independentemente (veja aqui, no quadrado azul). No Safari, esta rolagem em overflow
ocorre da forma que é comum no resto do sistema, com menos inércia.
A equipe do Google, então, entrou em contato com a Maçã para tentar mudar este comportamento, e a resposta de Cupertino foi provavelmente a mais inesperada possível. Citando a postagem da equipe do Google no Hacker News:
A resposta da Apple foi (surpreendentemente) que eles farão a rolagem padrão do Safari ser como a rolagem em
overflow
. Então, na próxima versão do Safari, todas as páginas rolarão exatamente como as páginas AMP. Esperamos que o Gruber esteja feliz. 🙂
Então é isso: numa atitude provavelmente inédita, em vez de fazer o produto dos outros adequar-se ao seu estilo, a Apple vai adequar o seu estilo ao produto dos outros. Obviamente, não estou querendo sugerir que a Maçã tomou a decisão de mudar o comportamento de rolagem do Safari somente após e por conta do contato da equipe do AMP — esta mudança provavelmente já estava sendo planejada há bastante tempo, e as correspondências só serviram para que o mundo saiba disso um pouco antes da hora. Ainda assim, não deixa de ser um detalhe curioso.
Restam apenas duas perguntas. A primeira é a razão de a Apple ter decidido pela mudança. Como o usuário Om2 — que parece trabalhar no desenvolvimento do Safari — acrescentou no mesmo fórum do Hacker News, o motivo parece ser só um: consistência.
No Safari atual do iOS, a rolagem das páginas é inconsistente em relação à rolagem no restante do sistema. Esta é uma decisão intencional que foi feita há muito tempo. Apesar disso, áreas
overflow
são consistentes com o restante do sistema, e portanto inconsistentes com a rolagem padrão das páginas no Safari. Isto é semi-acidental. Analisando as taxas de rolagem, nós percebemos que a razão original não compensava mais, portanto esta mudança, que remove todas as inconsistências: https://trac.webkit.org/changeset/211197/webkitTer toda a rolagem consistente é muito bom depois que você se acostuma com isso.
A segunda questão que fica é, naturalmente, quando os usuários verão estas mudanças nos seus dispositivos. Não há uma resposta clara em relação a isso, mas a proximidade da WWDC (e, consequentemente, da apresentação do iOS 11) nos leva a crer que a Maçã está planejando incluir as mudanças na próxima grande atualização do seu sistema. Claro que eles não reservarão um segundo sequer da keynote para falar de um detalhe tão minucioso, mas provavelmente aqueles de olhos mais apurados poderão ver algo neste sentido naqueles famosos slides:
Fiquemos ligados…