Há muito tempo atrás, em uma internet distante, os desenvolvedores lutaram com tags piscando nas guerras do navegador…
Para aqueles jovens demais para lembrar, as Guerras dos Navegadores provocaram uma investida de tecnologia, entre outras, pelo Netscape e pela Microsoft, resultando na implementação de recursos inúteis porque eram fáceis de usar, e recursos úteis eram acelerados porque eram difíceis. Após a Guerra dos Navegadores, a internet entrou em uma era de estabilidade, com os últimos vestígios da antiga web sendo caçados impiedosamente e destruídos pelo Google.
Os navegadores baseados em Chrome e Chromium têm a maior parte do mercado, e com a nova versão do Edge sendo baseada no Chromium, somente o Firefox é realmente deixado para competir. Já estamos vendo os efeitos disso, e eles não são ideais.
Prepare-se, este vai ter muitos links, e eles são importantes …
A Saga do <std-toast>
Em 12 de junho de 2019, os desenvolvedores do Google solicitaram uma revisão de um novo elemento proposto para HTML. Especificamente, eles pediram ao WICG ( Web Platform Incubator Community Group ), uma comunidade dedicada a fomentar discussões abertas sobre o futuro da Internet como uma plataforma. Ele é executado pelo W3C e, geralmente, é exatamente onde você deve estar perguntando sobre possíveis mudanças na base real da Internet.
No mesmo dia, no entanto, eles anunciaram sua intenção de incluir o elemento no mecanismo de renderização do Blink. Agora, isso não significa que vai acontecer em breve, mas causou alguma consternação significativa.
A IDEIA BÁSICA
Bem, primeiro vamos falar sobre o elemento em si. É uma notificação pop-up. Literalmente, é uma notificação que aparece na parte inferior da tela, como torrada … de uma torradeira ou de cima, como torrada de uma torradeira invertida [sinta-se à vontade para inserir uma piada sobre a Austrália aqui].
Esse elemento de notificação pode aparecer e desaparecer sozinho (o termo usado é “expiração automática” ou pode exigir interação para ser enviado. É basicamente um elemento HTML dedicado apenas às notificações “usamos cookies”.
O HTML básico pode ser escrito como um dos exemplos a seguir:
<std-toast>Hello world!</std-toast><std-toast><p>Hello world!</p></std-toast><std-toast>
<p>Hello world!</p>
<button>Click me!</button>
</std-toast><std-toast>
<p>Hello world!</p>
<a href="https://example.com/" target="_blank">Click me!</button>
</std-toast>OS PROBLEMAS COM <STD-TOAST>
Quero dizer … além do acrônimo infeliz no começo da etiqueta? E o problema de que as torradeiras reais não são, de fato, uma metáfora universal em países com acesso à Internet, como apontado pela sempre brilhante Jen Simmons?
Acredito que novos elementos HTML devem passar por um processo de padrões, ser debatidos por várias partes (não um), ser úteis para a maioria dos sites (pavimentar caminhos) e ser escritos em linguagem que faça sentido para HTML, especialmente para pessoas que não t fala bem o inglês. Então não sobre isso.
Ignorando esses problemas, ainda é necessário que o JavaScript funcione corretamente.
É ainda mais irritante que o brinde seja fundamentalmente um elemento de interface do usuário efêmero que está além do layout da página e não pode funcionar sem o JavaScript. Existe algum outro elemento html com essas semânticas? É um precedente realmente estranho.
Um elemento HTML que requer JavaScript. Eu vou dizer mais uma vez para os desenvolvedores do Google: JavaScript quebra, e quebra muito mais do que o HTML / CSS.
Então, é apenas enigmático como o inferno. Quero dizer, é algo que já podemos fazer com a tecnologia existente e implementá-la em HTML não facilita muito isso. Também não é particularmente útil fora de um caso de uso muito restrito. Tudo o que isso faz é tornar as tecnologias subjacentes da Web “mais como aplicativos” e, embora isso não seja estritamente uma coisa ruim, é realmente tudo o que queremos para a Internet?
<brindar> não faz sentido para mim. Isso me lembra de <marquee>, <blink>, e todas as outras tags enganosas de antes nós achamos que deveríamos separar estilo, comportamento e marcação.
Um ponto adicional: mesmo o letreiro e o blink não precisavam de JavaScript para funcionar. Eles eram terríveis de muitas maneiras, mas “trabalhavam” sozinhos.
O PROCESSO DE DESENVOLVIMENTO E REVISÃO
Uma percepção comum é que alguns funcionários do Google tiveram essa ideia e decidiram simplesmente lançá-la em seu mecanismo de navegação, imaginando que todos os outros simplesmente concordariam com isso. Como mencionado anteriormente, toda a situação lembra muito as guerras de navegadores, quando os fornecedores de navegadores criaram elementos proprietários confusos em um esforço para competir.
Linha do tempo: compromisso inicial com o repositório pessoal: 24 de maio comentário de um editor do WHATWG HTML (também funcionário do Google): 28 de maio Intenção de implementar email: 12 de junho Solicitação de revisão do TAG: 12 de junho Primeira menção no WICG: 12 de junho
Padronização da Web de acordo com o Google? “Ninguém fora da minha equipe reviu ou aprovou o explicador em meu repositório privado, mas se implementarmos e estimularmos os desenvolvedores a usá-lo, certamente nossos concorrentes concordarão em implementá-lo [porque nossa dominância de mercado determina o compat]”.
Isso tem incomodado compreensivelmente pessoas que acreditam fortemente em uma abordagem voltada à comunidade para o desenvolvimento de tecnologias tão básicas e abertas quanto o HTML.
Um dos benefícios da padronização por meio dos grupos de trabalho do W3C é a diversidade de insumos. O W3C requer a consideração de todo o feedback, requer consenso para avançar. A diversidade de perspectivas de fornecedores considerou questões , porque diferentes fornecedores têm valores diferentes.
Existe um processo. É bastante formal e claro. Não é novo. Não é uma questão de preferência pessoal nem um “mal-entendido”. Não é um “você diz tomate eu digo tomate”.
https://www.w3.org/2005/10/Process-20051014/tr.html#cfi
Pense em todos os muitos elementos HTML que foram considerados e rejeitados ao longo dos anos – e devemos estar a bordo com o TOAST? Porque alguns caras do Google decidiram que querem. E eles podem. Então não para <footnote> <author> <publication-date> Mas sim para <toast> ???
Mesmo as pessoas que geralmente gostam e apóiam a idéia do elemento std-toast estão insatisfeitas com a forma como foi apresentado à comunidade:
Olha, eu recebo o “Mova rápido! Quebre as coisas! E acho que é exatamente correto que o Google experimente a web. Nós todos devemos! E, novamente, acho que o <toast> é provavelmente uma adição útil ao HTML.
Mas a maneira como o Google passou para apresentá-lo ao mundo revela uma enorme falta de empatia pelos pobres coitados que têm padrões de revisão, por outros navegadores, por usuários e pela comunidade da Web mais ampla.
As implicações
Apesar de tudo o que o Google já fez (por favor, não mate nosso PageRank, obrigado!), Eu sinceramente gostaria de acreditar que esse foi o erro de alguns, ao invés do começo do Google ditando a direção do design e desenvolvimento web. como um todo. Mas se for, temos todo um novo problema em nossas mãos.
A prioridade do Google tem sido, é e sempre estará ganhando muito dinheiro. E quem pode culpá-los? Mas se não tivermos concorrência entre os navegadores, não apenas os navegadores, mas também os mecanismos de renderização do navegador , algumas pessoas aleatórias no Google que não necessariamente refletiram sobre as coisas poderão alterar drasticamente a direção da Web praticamente sempre que gostar.
Eu ainda gosto das coisas que o Google faz, mas vamos ser reais: elas nem sempre tomam as melhores decisões. Eu poderia fazer uma piada sobre o Google+, aqui, ou o Google Buzz, ainda mais malfadado, mas vamos dar uma olhada em algo que afeta mais diretamente os designers e desenvolvedores da web:
Se o Google estivesse encarregado da Plataforma Web, não teríamos o layout de grade CSS. Com a exceção pessoal do @tabatkins , o Google não acreditava no CSS Grid. A Microsoft e a Mozilla implementaram as suas próprias, mas foi a Bloomberg quem financiou a @igaliapara codificar a implementação da Blink.