Apostando no HTML

• Com a disseminação da IA baseada em grandes modelos de linguagem, o valor do HTML semântico legível por máquinas está crescendo tanto quanto o das telas vistas por pessoas
• Os jardins murados das grandes redes sociais impedem a portabilidade de dados e a interoperabilidade, e tentativas descentralizadas como fediverse, Threads e Bluesky ainda oferecem pouca motivação para atrair usuários comuns
• O HTML moderno já conta com boa parte dos elementos básicos de UI necessários para aplicações web, como <details>, <dialog> e diversos tipos de <input>
• Ao aproveitar os estilos padrão dos navegadores e o modo de leitura, é possível reduzir a dependência excessiva de CSS e JavaScript; tags corretas melhoram a legibilidade por máquinas e a experiência de entrada em dispositivos móveis
• Em um cenário no qual o RSS segue vivo e interfaces no estilo ChatGPT surgem como uma forma de acesso a dados, o HTML estruturado pode ser uma base mais prática do que interfaces centradas em anúncios

---

HTML como interface de dados básica da web

• O surgimento da IA baseada em grandes modelos de linguagem voltou a destacar a importância do HTML semântico
• O núcleo da internet é entregar os dados necessários para que pessoas interajam com o mundo, mas a liberdade do HTML/CSS/JavaScript também tem o outro lado de limitar o acesso aos dados
• As redes sociais das grandes empresas de tecnologia mantêm os usuários presos a plataformas fechadas, em vez de formatos de dados e APIs abertos e acessíveis
  • A interoperabilidade entre plataformas se tornou praticamente difícil
  • O problema fica ainda mais complexo à medida que as empresas evitam facilitar a movimentação de dados
• A instabilidade recente das redes sociais reacendeu o interesse por plataformas descentralizadas como o fediverse
  • O Threads, da Meta, e o Bluesky, criado por Jack Dorsey, promovem a interoperabilidade com o fediverse mais amplo
  • Ainda assim, usuários comuns muitas vezes não escolhem uma nova rede social apenas por esse motivo
• Vale a pena voltar a olhar para o HTML como uma solução já comprovada
  • No passado, era preciso usar bastante CSS para que conteúdo HTML não ficasse ruim no navegador
  • Hoje, muitos elementos de HTML moderno foram adicionados e oferecem a maior parte dos elementos de UI necessários para aplicações web modernas
  • O modo de leitura pode anular o tempo gasto em estilização, e isso pode ser visto de forma positiva
• Tags corretas oferecem um formato fácil de ler por máquinas
  • Isso se torna um motivo mais forte para adotar HTML moderno do que simplesmente economizar tempo de design
  • O RSS continua vivo
  • Interfaces como o ChatGPT também podem se tornar uma forma futura de as pessoas acessarem dados

Elementos HTML úteis ou que valem ser vistos com novos olhos

• Vale a pena conferir a lista completa de elementos HTML da MDN
  • Os exemplos abaixo usam apenas os estilos padrão do navegador, sem estilos separados
  • Dependendo do navegador, podem aparecer de forma bem diferente ou nem ser compatíveis
• <abbr>: elemento para envolver abreviações
  • Pode ser destacado com estilos
  • É útil principalmente para leitura por máquinas
• <datalist>: elemento que fornece uma lista de sugestões de entrada
  • Permite criar uma UI que parece typeahead
  • Não parece haver validação embutida
  • No Safari, é necessário fechar a tag option; se ela não for fechada, não funciona
• <details>: elemento de divulgação expansível e recolhível
  • Pode ser usado como um pequeno dropdown
  • Também aceita estilização intensa
• <dialog>: elemento de caixa de diálogo
  • É um elemento embutido que pode ser aberto e fechado com botões, formulários, atributos e JavaScript
  • Não é exatamente igual a um modal, mas é uma boa base caso você vá criar um
  • Parece ser renderizado acima dos elementos seguintes
• <i> e <em>
  • É importante entender a diferença entre os dois elementos
• <iframe>
  • Foi incluído na lista de exemplos, mas tratado como uma piada
• <input>: elemento de entrada de formulário
  • Entradas devem usar rótulos e tipos adequados
  • Em dispositivos móveis, o sistema operacional abre teclados diferentes conforme o contexto, por isso definir o tipo de entrada é importante
  • A variedade de entradas relacionadas a tempo pode reduzir a necessidade de um date picker separado em JavaScript
  • Os exemplos citam entradas color, range e datetime-local
• <mark>: elemento para destacar texto
  • Por padrão, aparece como destaque amarelo no Safari
• <meter>: elemento para exibir uma medida
  • No Safari, aparece em vermelho, amarelo ou verde de acordo com os parâmetros configurados
  • É possível definir o valor optimum
  • Pode ser útil em uma demo de visualização musical a 60fps
• <progress>: elemento para indicar progresso
  • É uma barra de progresso HTML nativa que pode receber um valor fixo ou um estado indeterminado
  • No Safari, aparece azul quando a janela está ativa e cinza quando está inativa
  • Por padrão, segue a cor de destaque do sistema e pode ser configurado com a propriedade CSS accent-color

[GN⁺]

Opiniões no Hacker News

• É estranho dizer que HTML é a solução para o aprisionamento em ecossistemas fechados. Esses serviços fechados já usam HTML, e também usam alguns dos elementos semânticos mencionados e atributos semânticos ARIA mais sofisticados.
  A afirmação de que interfaces como o ChatGPT são o futuro do acesso humano a dados também esbarra no fato de que o ponto central dos sistemas de inteligência artificial é não precisarem de anotações especiais “legíveis por máquina” para processar entradas. O ChatGPT e modelos posteriores conseguem navegar em sites comuns como uma pessoa, e percebem que um conjunto de parágrafos é uma “lista” mesmo sem marcação explícita.
  O que o autor descreve acaba sendo algo mais próximo de uma API mediada por elementos semânticos do HTML. Mas, se existe uma API, não é preciso um grande modelo de linguagem para acesso automatizado a dados; um script Python comum usando Beautiful Soup já basta, com a vantagem de rodar apenas localmente.

  • Acho que isso reduz demais a questão. Existe “HTML”, e existem sites cujo DOM final só é definido depois que o usuário tenta lê-los por 10 segundos. Entre esses dois extremos, há uma grande diferença em quanto dos recursos do navegador é preciso usar.
    No fim, o que separa o bom do ruim é a complexidade da implementação. Qualquer ferramenta pode ser bem ou mal usada, e um iniciante pode causar um grande acidente com uma serra circular e uma bateria carregada. Um artesão também pode escolher não usar a ferramenta e bater de lado, ou seja, ir contra os requisitos de negócio.
    Os sites que criei recentemente são os mais compatíveis que já fiz. Não uso mais websockets, nem dependo de JavaScript conversando com o servidor em pequenos pedaços. Mesmo com JavaScript totalmente desativado, cerca de 80% do produto pode ser usado. Não entendo como essas escolhas de engenharia não seriam uma solução contra o aprisionamento em ecossistemas fechados.
  • “O ChatGPT e modelos posteriores conseguem navegar em sites comuns como uma pessoa” ainda me parece mais uma afirmação do que algo verdadeiro. Mesmo assim, se for possível, é interessante.
    Grandes modelos de linguagem treinam em texto, código-fonte etc., mas, sem algo que se possa chamar de mecanismo de raciocínio, será que eles realmente conseguem olhar para uma árvore DOM e saber o que ela é e o que faz? O DOM não é texto, e também é difícil considerá-lo código-fonte bem estruturado, já que é resultado de empacotamento e componentização. Soa quase como dizer que “um grande modelo de linguagem consegue olhar para um .exe arbitrário e integrá-lo imediatamente”.
  • Li o objetivo do texto como uma defesa de usar conteúdo semântico legível por máquina sobre HTTP, em vez de, ou além de, um monte de divs só para JavaScript. Assim, agentes automatizados da nova onda, como grandes modelos de linguagem, poderiam extrair facilmente detalhes importantes sem precisar abrir um navegador headless para renderizar a página.
    Tenho um interesse parecido, mas voltado a crawling e novos mecanismos de busca. Se toda página precisar ser executada em um navegador headless antes de ser indexada, a barreira de entrada para um novo mecanismo de busca fica muito mais alta.
  • É uma observação válida. Ironicamente, a principal vantagem da marcação semântica agora parece ter virado uma abstração que facilita o estilo e o controle por desenvolvedores humanos.
  • O ChatGPT realmente consegue fazer isso? Ele faz isso de fato?

• A primeira frase do texto é “Com o surgimento da inteligência artificial baseada em grandes modelos de linguagem, o HTML semântico se tornou mais importante do que nunca”, mas acho que “com o surgimento da inteligência artificial baseada em grandes modelos de linguagem, o HTML semântico se tornou menos importante do que nunca” seria uma frase muito mais defensável.
  A web semântica fracassou, e seu lugar foi ocupado pelo Google gastando enormes quantias em todo tipo de heurística combinada com o que havia de melhor em inteligência artificial na época. Quanto melhor fica a inteligência artificial, maior é sua capacidade de extrair informação até de uma bagunça feita de qualquer jeito; e, se essa bagunça for suficiente, é até aí que as pessoas vão se esforçar. Em princípio, no fim, tanto a web semântica quanto o monte de heurísticas acabam sendo substituídos por inteligência artificial.
  Também é importante notar que o texto usa LLM só no começo e depois muda para o termo genérico IA. Grandes modelos de linguagem não são a totalidade da inteligência artificial; são apenas um ramo em alta no momento, e não serão o último ramo em alta. Não é bom fazer previsões para as próximas décadas assumindo que grandes modelos de linguagem são a resposta final da inteligência artificial.

  • Você acha que a inteligência artificial também vai resolver a acessibilidade web baseada em HTML semântico e ARIA? Se não, ainda precisamos de pessoas para garantir que o conteúdo web seja acessível e, nesse caso, o HTML semântico continua importante.
  • Tenho curiosidade sobre como será a otimização para mecanismos de busca depois dos grandes modelos de linguagem.
    Se o objetivo é que as partes relevantes do conteúdo sejam indexadas bem o bastante para ranquear, pode-se dizer que faltava incentivo para adotar HTML semântico por completo.
    Se o objetivo mudar de “ranquear” para “fazer com que grandes modelos de linguagem extraiam o máximo possível de nuances e textura do conteúdo”, pode haver mais incentivo para usar melhor certos elementos. Sites que fizerem isso podem ter mais influência sobre a saída dos grandes modelos de linguagem.
    Parece a diferença entre falar alto o suficiente para ser ouvido e falar com clareza suficiente para ser entendido.
  • schema.org e Wikidata/Wikipedia ainda não sustentam a maior parte dos resultados enriquecidos de busca do Google?
    Ouvi falar do anúncio da nova página de resultados com Bard, mas, talvez por causa do hábito de ignorar anúncios ou porque ainda não chegou à minha região, acho que não vi; vou ter que procurar.
  • A inteligência artificial parece mágica. Sempre achei a capacidade humana de reconhecimento de padrões algo bastante singular e difícil de replicar. É essa capacidade que usamos ao vasculhar a bagunça de um site e extrair dados de algum jeito.
    Mentalmente, eu estava mais próximo do pessoal da web semântica, mas, se a máquina consegue entender essa bagunça razoavelmente bem, faz sentido perguntar por que se esforçar.
  • Projetos que tentam criar recursos de dados e fazer a inteligência artificial usá-los estão perdendo o ponto central. A própria inteligência artificial é um recurso de dados.
    Há projetos que afirmam que grafos de conhecimento ou outros ativos de dados podem ajudar a inteligência artificial a buscar conhecimento “verdadeiro”. Pessoalmente, acho melhor desenvolver maneiras de permitir que a inteligência artificial crie seus próprios ativos de dados. Os pesos de uma rede neural também são um desses ativos.
    O problema da verdade continua sendo muito difícil. Como podemos informar à inteligência artificial que um conhecimento é mais confiável do que outro? Claro, pessoas também têm o mesmo problema.

• Eu quase nunca tinha ouvido falar da maioria desses elementos HTML, e isso é uma pena. Porque coisas assim poderiam ajudar bastante a acabar com o ecossistema em que “tudo precisa de JavaScript”
  No mínimo, poderiam recolocar o JavaScript em um lugar mais próximo do seu propósito original: um meio de acrescentar um pouco de ornamento ou interatividade. Ele não precisa ser um substituto para toda a marcação nem o gerente de todo o DOM
  O navegador dos meus sonhos talvez fosse algo como o visurf https://sr.ht/~sircmpwn/visurf/, com o motor Netsurf interno atualizado para dar suporte a HTML+CSS moderno, incluindo esses elementos. Com um navegador assim, acho que seria possível criar uma web pequena quase sem JavaScript. Ela teria melhor acessibilidade, por quebrar menos leitores de tela, temas do sistema, atalhos de teclado etc.; usaria muito menos recursos do que engenhocas pesadas em JavaScript que poderiam ser substituídas; e ainda pareceria capaz de fazer a maior parte do que se espera hoje de um web app intermediário. Para coisas como WebGL, bastaria abrir o Firefox, mas, por exemplo, um cliente Matrix talvez precisasse só de um pouco de JavaScript para WebSockets e criptografia de ponta a ponta

  • O problema comum desses componentes embutidos é que é difícil aplicar temas. Quando um componente com estilo Windows 7 aparece no meio de um app moderno, ele incomoda demais
    A extensibilidade também é quase inexistente, então, se você precisar fazer algo minimamente complexo, acaba descartando tudo e recomeçando em JavaScript. Aí é melhor começar em JavaScript desde o início, porque funciona bem, dá controle total e se comporta do mesmo jeito em todos os sistemas
    No fim, esses componentes adicionais viram só inchaço que todos os navegadores precisam implementar, mas que ninguém usa
  • Quando vi datalist pela primeira vez, pensei: “uau, isso muda o jogo”. O comportamento é igual entre navegadores, mas a aparência é totalmente específica de cada navegador e não dá para estilizar com CSS
    Às vezes aparece só o texto dos dados; outras vezes aparecem o texto e o atributo value juntos. Então você não seleciona “Atlanta”, mas “234290780 Atlanta”, ou seja, o ID e o valor juntos
    No comportamento de clique, também não dá para obter só o ID diretamente; é preciso pegar tudo e fazer o parsing do ID. Parece simplesmente um elemento abandonado
  • Talvez você goste disto: http://youmightnotneedjs.com/
  • Não sou contra a ideia geral, mas esses elementos existem há muito tempo. Para que uma crítica ao HTML seja levada a sério, acho que é preciso conhecer o básico
    O texto linka para a MDN, e a MDN costuma ser uma das referências curtas mais úteis. Claro, também existe a especificação HTML da WHATWG e, se ela for abrangente demais, há a gramática em formato SGML DTD para os snapshots WHATWG HTML 2021·2023, além das gramáticas antigas da linha HTML 5.x
    [1]: https://sgmljs.net/docs/html200129.html
  • https://qutebrowser.org

• Quero acreditar na web semântica e quero acreditar que os navegadores poderiam oferecer bons módulos padrão e estilos padrão decentes, mas hoje não é assim, e é preciso aceitar isso
  Mesmo só para associar um rótulo a um input, já é preciso pensar por que isso não é um atributo, e fica difícil ter certeza se ele deve ser usado como wrapper ou como um elemento irmão com o atributo for=. Isso é só a ponta do iceberg. Para cada tag, é preciso aprender todo o histórico de desenvolvimento e pesquisar novamente qual é a forma correta hoje
  Poderíamos ter tido algo bom, mas parece que agora é hora de se acalmar e deixar isso para lá

  • Não sei que ferramentas você usa, então não estou falando de ninguém em específico, mas, se os desenvolvedores web tivessem dedicado ao aprendizado de HTML uma parte do tempo que gastam aprendendo React, Tailwind etc., a web estaria em um estado muito melhor
    Sem dúvida há partes estranhas e arestas, mas, se todo desenvolvedor web soubesse tirar o máximo proveito do HTML semântico, provavelmente haveria muito menos JavaScript no navegador, menos bugs de acessibilidade e mais olhos acompanhando a especificação quando fosse preciso corrigir ou substituir essas esquisitices
  • Se o rótulo de um campo fosse um atributo HTML, os formulários seriam muito menos flexíveis. Isso fundiria dois elementos visuais em um só, dificultando ajustes de apresentação. Pense, por exemplo, em um campo com um rótulo alinhado à direita do lado esquerdo, ou em uma checkbox com o rótulo à direita
    Um atributo label significaria conteúdo em texto puro, o que parece limitado demais
    O HTML tem uma história complexa e várias camadas, como é de se esperar de algo usado há décadas. Ainda assim, ele não mudou tanto recentemente e, graças à MDN, é bem fácil aprender o suficiente sobre o que é possível com HTML5 e se aprofundar mais quando necessário
  • No meu caso, quase sempre quero colocar a tag label depois da tag input. Assim posso usar pseudoclasses CSS para selecionar e estilizar o rótulo de acordo com o estado do input
  • Ter de aprender o significado de cada tag é uma parte essencial de qualquer sistema de marcação semântica. Se você não gosta dessa ideia, então isso é fundamentalmente incompatível com o próprio conceito de web semântica
    Claro que, para usar com eficácia qualquer sistema de publicação — na verdade, qualquer sistema —, é preciso aprender a usar os elementos básicos que ele oferece. Portanto, isso não é um problema exclusivo da web semântica

• Uso bastante details para depurar templates HTML em Go
  Coloco os dados quando estou em modo de desenvolvimento com {{if .DevMode}}; quando está recolhido, ele não estraga muito a página e passa relativamente despercebido, e, quando preciso, abro e vejo o conteúdo inteiro

  • Quando dá, eu abuso um pouco do elemento details. Ele é muito elegante; não sei por que não é mais usado
  • Ele pode ser usado para várias coisas em páginas web, como menus recolhíveis
    Também dá para usar no GitHub Markdown, e há gente que o usa em exemplos ou explicações inline

• Gostei das leituras e das demonstrações interativas
  Depois de mexer com Flutter por alguns anos, cheguei de novo à mesma conclusão. É preciso apostar no HTML
  A combinação Astro / Tailwind / Daisy UI / Alpine.js é boa para criar sites HTML que usam bastante renderização no lado do servidor simples e salpicam um pouco de reatividade no lado do cliente
  O resultado são arquivos HTML simples e decentes, que ficam bons e funcionam bem em navegadores web de desktop e em webviews encapsuladas em mobile. Meu app é praticamente estático, então fica em cache na CDN, funciona offline, e ver o código-fonte facilita a depuração

  • Depois de experimentar vários frameworks e plataformas chamativos, acabei indo para um site estático que usa Alpine.js e Tailwind do mesmo jeito. Foi, de longe, a melhor decisão que tomei até agora
    O melhor é que posso ter certeza de que qualquer novo desenvolvedor, venha de React, Angular, PHP ou Python, vai entender o arquivo de build de 100 linhas depois de olhar por uns 3 minutos. É muito bom por ser realmente simples
  • Acho que exportar para web com Flutter é quase um pesadelo. Da última vez que conferi, a renderização acontecia em um canvas, e não havia markup nenhum
  • Alguém consegue me ajudar a entender a utilidade do Daisy UI? Parece usar classes + folhas de estilo à moda antiga passando pela etapa extra chamada Tailwind
  • Sim, Astro e arquitetura de ilhas são realmente uma delícia de trabalhar

• Acho que o problema da web semântica é que, por mais fácil que ela fique, os desenvolvedores se recusam a usá-la corretamente. Minha extensão de navegador usa a tag main, então venho prestando bastante atenção nela, e a documentação da MDN é muito clara sobre o que fazer, além de a própria documentação mostrar um bom exemplo de uso. Ainda assim, pouquíssimos sites a usam corretamente
  Até sites profissionais sofisticados costumam envolver todo o conteúdo da página dentro da tag main, incluindo navegação, rodapé e coisas do tipo. Essa tag deve ser usada apenas para o conteúdo principal da página
  Se nem um elemento tão simples assim conseguem usar corretamente, não espero muito dos outros elementos

  • É o mesmo tipo de desenvolvedor que usa verbos HTTP de forma errada
    Essas coisas não deveriam fingir que são contratos
  • Todo desenvolvedor que usou a tag p para parágrafos literalmente a usou corretamente. É diferente de algo como class="card"
    Não entendo por que tantas pessoas com alto nível de conhecimento técnico lamentam tanto a inutilidade da web semântica ou seu fracasso. Soa como dizer: “queria que o automóvel tivesse dado certo, viagens longas ficariam mais fáceis”
  • A primeira solução que vem à mente é validação mais rigorosa. Algo como o navegador se recusar a renderizar se a estrutura não estiver correta
    Mas já houve uma época assim. As coisas antes do HTML4 eram em grande parte assim, e era pior
    Então talvez seja melhor que as ferramentas de desenvolvedor emitam avisos ou erros quando houver uso incorreto
  • Não há incentivo nenhum para usar corretamente. Eu também tento usar do jeito certo, mas, fora o tempo gasto decidindo o que cada elemento deveria ser, não houve diferença nenhuma

• É interessante que muitos comentários aqui vejam este texto como um texto anti-JavaScript. Para mim, pelo contrário, ele parece falar de ferramentas extremamente úteis quando usadas junto com os frameworks centrados em TypeScript que usamos nos front-ends modernos de apps corporativos. Justamente por serem ferramentas nativas do HTML, elas não exigem um monte de coisas
  Por exemplo, acho que a tag meter vai substituir todos os módulos de carregamento que usamos em React quando eu chegar ao trabalho hoje. Porque é muito melhor do que o que usamos agora
  Talvez eu tenha entendido mal as pessoas ou lido o texto errado, mas, mesmo quando todo o front-end é praticamente TypeScript, como nas grandes aplicações de hoje, isso é muito interessante

  • Minha esperança é que essas coisas substituam enormes blocos de código JavaScript. Sei que uma web sem JavaScript infelizmente é uma fantasia, mas ao menos dá para remover grandes pedaços e criar uma experiência de usuário mais padronizada, que o sistema possa orientar e moldar
    Há novos aplicativos que podem ser feitos com muito menos JavaScript do que antes. Em apps corporativos TypeScript existentes, isso pode acabar sendo uma atualização in-place, mas a esperança é que, no desenvolvimento de novos apps, seja possível evitar esses próprios frameworks corporativos. Sonhar não custa, não é?

• Não quero menosprezar completamente o desenvolvimento web, mas ele é realmente terrível. Fiz isso por anos, de HTML cru a linguagens de script e frameworks, e o tempo que se leva para fazer coisas triviais parece um enorme desperdício de capacidade mental
  Quando viajei de férias, eu só queria encontrar lugares para comer e beber, ou lugares para visitar por um dia, mas a maioria dos sites era uma bagunça, estava ultrapassada ou não tinha sido atualizada. Ainda há muitos sites feitos uma vez e depois esquecidos. Parece ser porque o orçamento é apertado e não dá para atualizá-los, ou porque atualizá-los é tecnicamente difícil demais
  A complexidade dos sites causa paralisia. O que poderia ser algumas páginas simples de texto e imagens é superprojetado sem necessidade, queimando uma quantidade enorme de ciclos de CPU. Também há boa chance de ter sido feito remendando algum CMS pronto que exige atualizações de segurança
  Recentemente vi o site de um cinema, e era quase impossível até mesmo passar os olhos pelos poucos filmes em cartaz naquela semana. Senti que ficaria mais legível se estivesse em uma planilha e, quando de fato baixei o JSON da API, ele era mais fácil de ler
  A maior parte é uma embalagem cansativa, como passar batom em um porco. Um dos motivos do sucesso do Facebook foi o onboarding fácil, e outro foi a facilidade de compartilhar fotos. O mesmo vale para WhatsApp e Instagram. Publicar precisa ser fácil. FTP simples também é fácil, mas para pessoas comuns há uma ruptura estranha no fluxo de usabilidade. As pessoas querem arrastar e soltar, fazer upload, largar e esquecer, edição fácil. Quem quer consumir dados no fim quer apenas o essencial. Ou seja, os dados

  • Não acho que as pessoas que querem consumir dados queiram apenas os dados essenciais. O leitor médio do HN talvez queira isso, mas uma pessoa média não
    O que as pessoas querem é uma página web bem estilizada e utilizável. O problema é que não há designers de experiência do usuário eficazes e talentosos em número suficiente, e as partes interessadas das empresas também não têm um bom senso de UX
    Por isso, oferecer apenas os dados essenciais acaba sendo melhor para o usuário médio do que a UX ruim que uma empresa média consegue bancar. Mesmo que não seja a preferência, é melhor
    {UX ruim} << {dados brutos} < {boa UX}
    O caminho alternativo que o WordPress encontrou foi criar estilos e temas profissionais e fazer o usuário comprá-los e aplicá-los. Mas isso não resolve o mau gosto das partes interessadas
    Acho que o Facebook teve sucesso porque impôs uma UX profissional e padronizada. {dados das pessoas} + {UX profissional e padronizada} = {vitória}. Pode-se não gostar da UX inicial do Facebook, mas é difícil dizer que era trabalho amador. A percepção geral sobre MySpace, Geocities etc. era o oposto
  • A parte em que você mencionou o WhatsApp acerta no ponto. No país africano onde estou, o WhatsApp é tão popular que as operadoras móveis vendem até pacotes de dados para WhatsApp
    Se eu quiser encontrar algo como tela metálica, começo perguntando nos grupos de WhatsApp de que participo: família, bairro, amigos do ensino médio. Normalmente recebo alguns números e, ao falar com os prestadores de serviço pelo WhatsApp, obtenho informações atualizadas
    Esses prestadores de serviço não têm como bancar um site atualizado. O WhatsApp também tem um recurso para colocar um catálogo no perfil, voltado para contas comerciais gratuitas
  • Por isso, para a maioria dos pequenos comerciantes, recomendo Wix. Os sites ficam todos parecidos? Sim, e isso não é necessariamente ruim. Como é fácil de usar e atualizar, os clientes agradecem por obter as informações atualizadas de que precisam
    O que eu gostaria de ver é algo como “Wix Widgets”: widgets conectados a dados, com customização suficiente para conectar chamadas a serviços REST e mapear pontos de dados para a exibição do widget. Isso ajudaria bastante a lidar com as demandas de sites internos que toda empresa tem hoje em dia
    Em 90% a 95% das páginas web, o que realmente se precisa é de uma solução simples
  • É engraçado ouvir que a plataforma web é o melhor e mais consistente sistema de GUI multiplataforma, mas que construir algo em cima desse sistema é terrível
    Talvez eu me pergunte se isso é a própria natureza das GUIs. Pode ser uma estrutura em que é preciso dar cada instrução uma a uma, que consome muitos ciclos e, caso contrário, não funciona de forma multiplataforma
  • Parte desse problema está no fato de que tags e elementos dentro dos arquivos HTML continuam aumentando. Deixou de ser marcação de documento e virou marcação de página, e fica difícil distinguir onde uma coisa termina e a outra começa. Embora o W3C tenha tentado ao adicionar os elementos article e section
    Claro, o código HTML bruto provavelmente nunca foi feito para ser lido por alguém além de desenvolvedores, então há esse lado também

• Fiquei muito animado com a notícia de que haveria modais em HTML puro, mas me decepcionei ao descobrir que não há como acioná-los sem JavaScript. Em HTML puro, só dá para fechar, não para abrir
  https://github.com/whatwg/html/issues/3567
  O elemento dialog é uma ótima adição, e fico feliz que esteja sendo implementado, mas parte da funcionalidade essencial depende de JavaScript. Para abrir um dialog, é preciso definir o atributo open via JavaScript
  Seria bom se houvesse uma forma de um elemento button ou a abrir uma caixa de diálogo. Já existe precedente para interações de página embutidas no HTML. Por exemplo, links podem rolar a página, e o elemento details pode ocultar elementos após uma interação, então parece natural que outro elemento da página também possa abrir um dialog

  • Não sei se esse objetivo elevado de “apenas HTML” deve significar ampliar os recursos de script do HTML. Se for esse o caso, acho melhor simplesmente usar JavaScript
  • É possível implementar um modal apenas com HTML e CSS, sem JavaScript
    Por exemplo, clique no ? no canto superior direito aqui: https://aavi.xyz/proj/colors/
  • Seria bom se isso viesse embutido no próprio HTML, mas pelo menos o JavaScript necessário não é complicado e pode até ser colocado em um atributo onclick
  • Dá para fazer aparecer ou desaparecer de acordo com o hash atual. Claro que esse método precisa de CSS