Hello.

I am Paul Kinlan.

A Developer Advocate for Chrome and the Open Web at Google.

Wood Carving found in Engakuji Shrine near Kamakura

Paul Kinlan

Trying to make the web and developers better.

RSS Github Medium

Sakura

Paul Kinlan

Me disseram que mais especificamente que isso é 'Yaezakura'

Read More

Debugging Web Pages on the Nokia 8110 with KaiOS using Chrome OS

Paul Kinlan

Esta postagem é uma continuação da postagem sobre a depuração de KaiOS device with Web IDE , mas, em vez de usar o macOS, agora você pode usar o Chrome OS (m75) com o Crostini. Eu estou cribbing do KaiOS Environment Setup que é um bom começo, mas não o suficiente para começar com o Chrome OS e Crostini. Abaixo está o guia aproximado que eu segui. Certifique-se de que você está usando pelo menos o Chrome OS m75 (atualmente o canal de desenvolvimento a partir de 15 de abril) e, em seguida:

Read More

New WebKit Features in Safari 12.1 | WebKit

Paul Kinlan

Grandes atualizações para o mais recente Safari!

Eu pensei que este foi um anúncio muito grande, e o oposto do Google, que há pouco tempo disse que o Google Pay Lib é a maneira recomendada de implementar pagamentos … Quero dizer, não é um milhão de milhas de distância, o Google Pay é construído no topo Pedido de pagamento, mas não é PR primeiro.

Payment Request is now the recommended way to pay implement Apple Pay on the web.

Read full post .

E meu recurso favorito, dada a minha história com o Web Intents.

Web Share API

The Web Share API adds navigator.share(), a promise-based API developers can use to invoke a native sharing dialog provided the host operating system. This allows users to share text, links, and other content to an arbitrary destination of their choice, such as apps or contacts.

Agora, apenas para obter a API do Target de compartilhamento e somos um vencedor! :)

Offline fallback page with service worker

Paul Kinlan

Anos atrás, fiz algumas pesquisas sobre como os aplicativos nativos responderam à falta de conectividade de rede. Embora eu tenha perdido o link para a análise (eu poderia jurar que estava no Google+), a narrativa abrangente era que muitos aplicativos nativos estão inextricavelmente ligados à internet e que eles apenas se recusam a funcionar. Parece um monte de aplicativos web, o que os diferencia da web é que a experiência ainda era 'on-brand', Bart Simpson diria que você precisa estar online (por exemplo), e ainda para o Na grande maioria das experiências na web, você obtém um 'Dino' (veja chrome: // dino).

Estamos trabalhando no Service Worker há muito tempo e, embora vejamos cada vez mais sites com páginas controladas por um Service Worker, a grande maioria dos sites nem sequer tem uma experiência básica de fallback quando a rede não é acessível.

Eu perguntei ao meu bom amigo, Jake, se temos alguma orientação sobre como construir uma página genérica de retorno, supondo que você não queira criar uma primeira experiência totalmente off-line, e em 10 minutos ele a criou. Check it out .

Para simplificar, colei o código abaixo porque ele tem apenas 20 linhas. Ele armazena em cache os ativos off-line e, para cada busca que é uma busca de 'navegação', ela verifica se há erros (por causa da rede) e, em seguida, renderiza a página off-line no lugar do conteúdo original.

addEventListener('install', (event) => {
  event.waitUntil(async function() {
    const cache = await caches.open('static-v1');
    await cache.addAll(['offline.html', 'styles.css']);
  }());
});

// See https://developers.google.com/web/updates/2017/02/navigation-preload#activating_navigation_preload
addEventListener('activate', event => {
  event.waitUntil(async function() {
    // Feature-detect
    if (self.registration.navigationPreload) {
      // Enable navigation preloads!
      await self.registration.navigationPreload.enable();
    }
  }());
});

addEventListener('fetch', (event) => {
  const { request } = event;

  // Always bypass for range requests, due to browser bugs
  if (request.headers.has('range')) return;
  event.respondWith(async function() {
    // Try to get from the cache:
    const cachedResponse = await caches.match(request);
    if (cachedResponse) return cachedResponse;

    try {
      // See https://developers.google.com/web/updates/2017/02/navigation-preload#using_the_preloaded_response
      const response = await event.preloadResponse;
      if (response) return response;

      // Otherwise, get from the network
      return await fetch(request);
    } catch (err) {
      // If this was a navigation, show the offline page:
      if (request.mode === 'navigate') {
        return caches.match('offline.html');
      }

      // Otherwise throw
      throw err;
    }
  }());
});

Isso é tudo. Quando o usuário está online, ele verá a experiência padrão.

E quando o usuário estiver offline, ele receberá a página de fallback.

Eu acho este script simples incrivelmente poderoso, e sim, enquanto ele ainda pode ser melhorado, eu acredito que mesmo apenas uma simples mudança na maneira como falamos com nossos usuários quando há um problema com a rede tem a capacidade de melhorar fundamentalmente a percepção da web para usuários em todo o mundo.

** Atualização ** Jeffrey Posnick kinldy me lembrou sobre o uso do Pré-carregamento de Navegação para não ter que esperar pela inicialização do SW para todas as solicitações, isso é especialmente importante se você estiver controlando apenas solicitações de rede failed.

testing block image upload

Paul Kinlan

Este é apenas um teste para ver se recebi o upload da imagem corretamente. Se você ver isso, então sim eu fiz :)

Read More

Editor.js

Paul Kinlan

Eu atualizei pelo editor Hugo para tentar usar o EditorJS como, bem, o editor do blog.

Workspace in classic editors is made of a single contenteditable element, used to create different HTML markups. Editor.js workspace consists of separate Blocks: paragraphs, headings, images, lists, quotes, etc. Each of them is an independent contenteditable element (or more complex structure) provided by Plugin and united by Editor’s Core.

Read full post .

Eu acho que funciona.

Eu lutei um pouco com a base de código, os exemplos usam todos os módulos ES, no entanto, o NPM dist é todo produzido no código II ES5. Mas uma vez que superei esse obstáculo, foi muito fácil construir uma interface de usuário que parece um pouco mais com mídia.

Debugging Web Pages on the Nokia 8110 with KaiOS

Paul Kinlan

Nós temos feito muito desenvolvimento em feature phones recentemente e tem sido difícil, mas divertido. O mais difícil é que no KaiOS achamos impossível depurar páginas da web, especialmente no hardware que tínhamos (o Nokia 8110). A Nokia é um ótimo dispositivo, é construído com KaiOS que sabemos que é baseado em algo semelhante ao Firefox 48, mas está bloqueado, não há modo de desenvolvedor tradicional como você entrar em outros dispositivos Android, o que significa que você não pode conectar o Firefox WebIDE facilmente.

Read More

Object Detection and Augmentation

Paul Kinlan

Eu tenho tocado muito com o Shape Detection API no Chrome e eu realmente gosto do potencial que ele tem, por exemplo, um QRCode detector muito simples que escrevi há muito tempo tem um polyfill JS, mas usa a API new BarcodeDetector() se estiver disponível.

Você pode ver algumas das outras demos que construí aqui usando os outros recursos da API de detecção de formas: Face Detection , Barcode Detection e Text Detection .

Fiquei agradavelmente surpreso quando tropecei no Jeeliz no fim de semana e fiquei incrivelmente impressionado com o desempenho de seu kit de ferramentas - sabendo que estava usando um Pixel3 XL, mas a detecção de rostos pareceu significativamente mais rápida do que é possível com a API FaceDetector .

Checkout some of their demos .

Isso me fez pensar muito. Esse kit de ferramentas para Detecção de Objetos (e outros) usa APIs amplamente disponíveis na Web, especificamente acesso à câmera, WebGL e WASM, que, ao contrário da API de Detecção de Forma do Chrome (que é apenas no Chrome e não consistente em todas as plataformas em que o Chrome está) ) pode ser usado para criar experiências ricas facilmente e alcançar bilhões de usuários com uma experiência consistente em todas as plataformas.

Aumento é onde fica interessante (e realmente o que eu queria mostrar neste post) e onde você precisa de bibliotecas de middleware que estão chegando agora à plataforma, podemos construir os divertidos aplicativos de filtro de face sem os usuários instalarem aplicativos MASSIVE que coletam uma enorme quantidade de dados do dispositivo do usuário (porque não há acesso subjacente ao sistema).

Fora das demonstrações divertidas, é possível resolver casos de uso muito avançados de forma rápida e simples para o usuário, como:

  • Seleção de texto diretamente da câmera ou foto do usuário
  • Tradução ao vivo de idiomas da câmera
  • Detecção Inline QRCode para que as pessoas não precisem abrir o WeChat o tempo todo :)
  • Auto extrair URLs do site ou endereço de uma imagem
  • Detecção de cartão de crédito e extração de números (faça com que os usuários se inscrevam em seu site com mais rapidez)
  • Pesquisa visual de produtos na aplicação Web da sua loja.
  • Pesquisa de código de barras para mais detalhes do produto em seu aplicativo da web de lojas.
  • Recorte rápido de fotos de perfil no rosto das pessoas.
  • Recursos simples do A11Y para permitir que o usuário ouça o texto encontrado nas imagens.

Eu passei apenas 5 minutos pensando nesses casos de uso - eu sei que há muito mais -, mas me ocorreu que não vemos muitos sites ou aplicativos da web usando a câmera, em vez disso, vemos muitos sites perguntando por eles. os usuários fazem o download de um aplicativo, e acho que não precisamos mais fazer isso.

** Atualização ** Thomas Steiner em nossa equipe mencionou em nosso bate-papo da equipe que parece que eu não gosto da API atual do ShapeDetection . Eu adoro o fato de que essa API nos dá acesso às implementações nativas de envio de cada um dos respectivos sistemas, no entanto, como escrevi em The Lumpy Web , os desenvolvedores da Web desejam consistência na plataforma e há vários problemas com a API de detecção de forma que podem ser resumido como:

  1. A API é apenas no Chrome
  2. A API no Chrome é muito diferente em todas as plataformas porque suas implementações subjacentes são diferentes. O Android só tem pontos para pontos de referência como boca e olhos, onde o macOS tem contornos. No Android o TextDetector retorna o texto detectado, onde como no macOS ele retorna um indicador 'Presença de Texto' … Isso sem mencionar todos os bugs que o Surma encontrou.

A web como plataforma de distribuição faz tanto sentido para experiências como essas que acho que seria negligente não fazê-lo, mas os dois agrupamentos de questões acima me levam a questionar a necessidade de longo prazo de implementar todos os recursos em a plataforma web nativamente, quando pudemos implementar boas soluções em um pacote que é enviado usando os recursos da plataforma hoje, como WebGL, WASM e no futuro Web GPU.

De qualquer forma, eu amo o fato de que podemos fazer isso na web e eu estou olhando para a frente para ver sites enviados com eles.

Got web performance problems? Just wait...

Paul Kinlan

Eu vi um tweet de um bom amigo e colega, Mariko , sobre testes em uma série de dispositivos de baixo custo, mantendo você realmente ancorado.

O contexto do tweet é que estamos vendo como é o desenvolvimento da Web ao criar para usuários que vivem diariamente nessas classes de dispositivos.

A equipe está fazendo muito trabalho agora neste espaço, mas passei um dia construindo um site e foi incrivelmente difícil fazer qualquer coisa funcionar em um nível um pouco razoável de desempenho - aqui estão alguns dos problemas que encontrei:

  • Esquisitices na porta de visualização e misteriosa reintrodução de 300ms de atraso de clique (pode funcionar).
  • Enormes repaints de tela inteira, e é lento.
  • Rede é lenta
  • A memória é restrita e os GCs subsequentes bloqueiam o thread principal por vários segundos
  • Execução JS incrivelmente lenta
  • A manipulação de DOM é lenta

Para muitas das páginas que eu estava criando, mesmo em uma conexão rápida, as páginas demoravam vários segundos para serem carregadas, e as interações subsequentes eram simplesmente lentas. Foi difícil, envolvi tentar obter o máximo possível do tópico principal, mas também foi incrivelmente gratificante em nível técnico ver mudanças nos algoritmos e na lógica que eu não teria feito em todo o meu desenvolvimento tradicional da Web, rendimento grandes melhorias no desempenho.

Não sei o que fazer a longo prazo, suspeito que uma grande quantidade de desenvolvedores com quem trabalhamos nos mercados mais desenvolvidos terá uma reação: "Não estou construindo sites para usuários em [inserir país x]" e De alto nível, é difícil argumentar com essa afirmação, mas não posso ignorar o fato de que 10 milhões de novos usuários estão chegando à computação todos os anos e eles usarão esses dispositivos e queremos que a Web seja a * plataforma * de escolha para conteúdo e aplicativos para que não fiquemos felizes com o rise of the meta platform .

Precisamos continuar pressionando o desempenho por muito tempo. Continuaremos criando ferramentas e orientações para ajudar os desenvolvedores a carregar rapidamente e ter interfaces de usuário suaves :)

Browser Bug Searcher

Paul Kinlan

Eu estava apenas refletindo sobre algumas das work our team has done e encontrei um projeto de 2017 que Robert Nyman e Eric Bidelman criaram. Browser Bug Searcher! .

É incrível que, com apenas algumas teclas, você tenha uma excelente visão geral dos seus recursos favoritos em todos os principais mecanismos de navegação.

Source code available .

Isso realmente destaca um dos problemas que tenho com os rastreadores de bugs crbug e webkit, eles não têm uma maneira simples de obter feeds de dados em formatos como RSS. Eu adoraria poder usar o meu agregador topicdeck com categorias de bugs, etc, então eu tenho um painel de todas as coisas que eu estou interessado em com base nas informações mais recentes de cada um dos rastreadores de bugs.

Github's Web Components

Paul Kinlan

Eu estava procurando por um editor de markdown rápido em https://www.webcomponents.org/ para que eu pudesse facilitar a postagem neste blog e me deparei com um conjunto de componentes por github .

Eu sabia que eles tinham o <time-element> mas eu não sabia que eles tinham um conjunto tão bom e simples de elementos úteis.

London from Kingscross

The GDPR mess

Paul Kinlan

A forma como nós (como indústria) implementamos o consentimento do GDPR é uma bagunça. Não sei por que alguém escolheria outra coisa senão "Usar apenas cookies necessários", no entanto, eu realmente não posso dizer a diferença entre uma ou outra opção e o compromisso de qualquer escolha, para não mencionar que posso verificar que é apenas usando apenas os cookies necessários.

Read More

Brexit: History will judge us all

Paul Kinlan

A história julgará a todos nós nesta confusão, e espero que seja um estudo de caso para todos sobre os efeitos do nacionalismo, do interesse próprio, da arrogância colonial, da celebridade-bafoonery.

Filhos da puta.

File Web Share Target

Paul Kinlan

Eu sempre disse que para os aplicativos da web competirem efetivamente no mundo dos aplicativos, eles precisam estar integrados em todos os lugares que os usuários esperam que os aplicativos sejam. A comunicação entre aplicativos é uma das principais peças que faltam na plataforma da Web e, especificamente, um dos principais recursos ausentes é o compartilhamento em nível nativo: os aplicativos da Web precisam conseguir o data out of their silo em outros sites e aplicativos da Web; eles também precisam receber os dados de outros aplicativos e sites nativos.

Read More

Testing-file-share-target-from-camera

Paul Kinlan

Isso está testando o compartilhamento diretamente do aplicativo da câmera. Parece que funcionou :)

Read More

testing-file-share-target

Paul Kinlan

Este é um teste da API de segmentação de compartilhamento no Android e sua capacidade de compartilhar arquivos. Se você ver algo aqui, então tudo é bom :)

Read More

Ricky Mondello: Adoption of Well-Known URL for Changing Passwords

Paul Kinlan

Recentemente Ricky Mondello, do time Safari, compartilhou uma nota sobre como o Twitter está usando a especificação ./well-known/change-password.

I just noticed that Twitter has adopted the Well-Known URL for Changing Passwords! Is anyone aware of other sites that have adopted it?

Twitter’s implementation: https://twitter.com/.well-known/change-password; Github’s: https://github.com/.well-known/change-password; Specification :https://github.com/WICG/change-password-url

Read full post .

O recurso passou completamente por mim, mas é uma boa ideia: dado um arquivo em um local bem conhecido, o navegador pode oferecer uma interface do usuário que permita a rápida redefinição da senha sem ter que navegar pela interface do usuário complexa dos sites.

A especificação é enganosamente simples: o arquivo conhecido simplesmente contém a URL para direcionar o usuário para quando ele deseja executar a ação. Isso me levou a pensar, podemos oferecer mais desses recursos:

  • Um local bem conhecido para modelos de consentimento baseados em GDPR (consentimento do cookie) - os proprietários do site podem oferecer um link para a página em que um usuário pode gerenciar e potencialmente revogar todos os cookies e outros itens de consentimento de dados.
  • Um local bem conhecido para o gerenciamento de permissão do navegador - os proprietários de sites podem oferecer um local rápido para que os usuários possam revogar permissões para itens como localização geográfica, notificações e outras primitivas.
  • Um caminho bem conhecido para exclusão e alterações de conta
  • Um caminho bem conhecido para o gerenciamento de assinaturas de listas de discussão

A lista continua … Eu realmente gosto da idéia de arquivos de redirecionamento simples para ajudar os usuários a descobrirem ações comuns do usuário, e de uma maneira de o navegador aparecer.

pinch-zoom-element

Paul Kinlan

Jake e a equipe criaram esse elemento personalizado bastante impressionante para gerenciar o zoom de pinch em qualquer conjunto de HTML fora da própria dinâmica de zoom de pinça do navegador (pense no zoom da viewport móvel). O elemento foi um dos componentes centrais que precisávamos para o aplicativo squoosh que criamos e lançamos no Chrome Dev Summit (… eu digo "lançado no Chrome Dev Summit" - Jake estava mostrando para todos no Dia do Desenvolvedor do Google na China mesmo que o resto da equipe estivesse sob embargo;) …)

install: npm install --save-dev pinch-zoom-element

<pinch-zoom>
  <h1>Hello!</h1>
</pinch-zoom>

Read full post .

Acabei de adicioná-lo ao meu blog (demorou apenas alguns minutos), você pode conferir na minha seção ' life ' onde eu compartilho fotos que tirei. Se você estiver em um dispositivo habilitado para toque, poderá aumentar rapidamente o zoom no elemento, se estiver usando um trackpad que possa manipular entradas de vários dedos que funcionem também.

Esse elemento é um ótimo exemplo do motivo pelo qual eu amo os componentes da web como um modelo para a criação de componentes da interface do usuário. O elemento pinch-zoom é de pouco menos de 3kb nas dependências wire (descompactado) e mínimas para compilar e faz apenas um trabalho excepcionalmente bem, sem vincular qualquer lógica de nível de aplicativo personalizado que dificultaria o uso (eu tenho alguns pensamentos sobre lógica de UI vs Componentes lógicos de aplicativos que compartilharei com base nos meus aprendizados do aplicativo Squoosh).

Eu adoraria ver elementos como estes obter mais consciência e uso, por exemplo, eu poderia imaginar que este elemento poderia substituir ou padronizar a funcionalidade de zoom de imagem que você vê em muitos sites de comércio e para sempre tirar essa dor dos desenvolvedores.