Apostando por HTML

• A medida que se expande la IA basada en grandes modelos de lenguaje, también aumenta el valor del HTML semántico que las máquinas pueden leer tanto como la pantalla que ven las personas
• Los jardines cerrados de las grandes redes sociales bloquean la movilidad de datos y la interoperabilidad, y hasta intentos descentralizados como el fediverse, Threads y Bluesky tienen pocos incentivos para atraer a usuarios comunes
• El HTML moderno ya cuenta con bastantes elementos básicos de UI necesarios para apps web, como <details>, <dialog> y varios tipos de <input>
• Si se aprovechan los estilos predeterminados del navegador y el reader mode, se puede reducir la dependencia excesiva de CSS y JavaScript, y usar las etiquetas correctas mejora la legibilidad para máquinas y la experiencia de entrada en móviles
• En un contexto donde RSS sigue vivo y las interfaces tipo ChatGPT están surgiendo como forma de acceder a los datos, el HTML estructurado puede ser una base más práctica que las interfaces centradas en publicidad

---

HTML como interfaz de datos base de la web

• La aparición de la IA basada en grandes modelos de lenguaje vuelve a poner en primer plano la importancia del HTML semántico
• La esencia de internet es entregar los datos que las personas necesitan para interactuar con el mundo, pero la libertad de HTML/CSS/JavaScript también tiene el otro lado de limitar el acceso a los datos
• Las redes sociales de las grandes tecnológicas mantienen a los usuarios dentro de plataformas cerradas en lugar de priorizar formatos de datos y APIs abiertos y accesibles
  • La interoperabilidad entre plataformas se ha vuelto, en la práctica, muy difícil
  • El problema se complica aún más porque las empresas no quieren facilitar el movimiento de datos
• La inestabilidad reciente de las redes sociales ha reactivado el interés por plataformas descentralizadas como el fediverse
  • Threads de Meta y Bluesky, creado por Jack Dorsey, promueven la interoperabilidad con el fediverse más amplio
  • Aun así, muchas veces los usuarios comunes no eligen una red social nueva solo por esas razones
• Vale la pena volver a mirar HTML como una solución ya probada
  • Antes había que usar mucho CSS para que el contenido HTML no se viera mal en el navegador
  • Ahora se han agregado muchos elementos HTML modernos que ofrecen la mayoría de los componentes de UI necesarios para aplicaciones web modernas
  • El reader mode puede neutralizar el tiempo invertido en estilizar, y eso se puede ver de forma positiva
• Las etiquetas correctas ofrecen un formato fácil de leer para las máquinas
  • Es una razón más fuerte para adoptar HTML moderno que simplemente ahorrar tiempo de diseño
  • RSS sigue vivo
  • También es posible que interfaces como ChatGPT se conviertan en la forma futura en que las personas accedan a los datos

Elementos HTML útiles o que vale la pena mirar de nuevo

• Vale la pena revisar la lista completa de elementos HTML de MDN
  • Los ejemplos de abajo usan solo los estilos predeterminados del navegador, sin estilos adicionales
  • Según el navegador, pueden verse muy distintos o incluso no estar soportados
• <abbr>: elemento para envolver abreviaturas
  • Se puede destacar aplicando estilos
  • Es útil sobre todo para la lectura por máquinas
• <datalist>: elemento que ofrece una lista de sugerencias de entrada
  • Puede crear una UI parecida al typeahead
  • No parece tener validación integrada
  • En Safari hay que cerrar la etiqueta option; si no se cierra, no funciona
• <details>: elemento desplegable/plegable
  • Puede usarse como una especie de pequeño dropdown
  • También admite bastante personalización de estilo
• <dialog>: elemento de diálogo
  • Es un elemento integrado que puede abrirse y cerrarse con botones, formularios, atributos y JavaScript
  • No es exactamente lo mismo que un modal, pero si vas a hacer uno, puede servir como base
  • Parece renderizarse por encima de los elementos siguientes
• <i> y <em>
  • Conviene conocer la diferencia entre ambos elementos
• <iframe>
  • Está incluido en la lista de ejemplos, pero se trata más como una broma
• <input>: elemento de entrada de formularios
  • Hay que usar etiquetas y tipos adecuados para cada entrada
  • En móviles, el sistema operativo abre teclados distintos según el contexto, así que especificar el tipo de entrada es importante
  • La variedad de entradas relacionadas con tiempo puede reducir la necesidad de un date picker en JavaScript
  • Se mencionan como ejemplo las entradas color, range y datetime-local
• <mark>: elemento para resaltar texto
  • En Safari se muestra por defecto como un resaltado amarillo
• <meter>: elemento para mostrar una medición
  • En Safari se muestra en rojo, amarillo o verde según los parámetros configurados
  • Se puede establecer un valor optimum
  • Puede ser útil para una demo de visualización musical a 60fps
• <progress>: elemento para mostrar progreso
  • Es una barra de progreso HTML nativa que puede tener un valor fijo o un estado indeterminado
  • En Safari se ve azul cuando la ventana está activa y gris cuando está inactiva
  • Por defecto sigue el color de énfasis del sistema, y se puede configurar con la propiedad CSS accent-color

[GN⁺]

Opiniones de Hacker News

• Es raro decir que HTML es la solución al lock-in de ecosistemas cerrados. Esos servicios cerrados ya usan HTML, y también usan algunos de los elementos semánticos mencionados y atributos semánticos ARIA más sofisticados.
  La afirmación de que interfaces como ChatGPT son el futuro del acceso humano a los datos también pasa por alto que lo central de los sistemas de inteligencia artificial es que no necesitan anotaciones especiales “legibles por máquina” para procesar la entrada. ChatGPT y los modelos posteriores pueden navegar sitios web normales como lo haría una persona, y darse cuenta de que un grupo de párrafos es una “lista” sin marcado explícito.
  Lo que describe el autor termina pareciéndose más a una API mediada por elementos semánticos de HTML. Pero si existe una API, no hace falta un modelo de lenguaje grande para acceder a datos de forma automática; alcanza con un script común en Python usando Beautiful Soup, con la ventaja de que se ejecuta solo localmente.

  • Creo que eso reduce demasiado el problema. Está “HTML”, y también hay sitios web cuyo DOM final solo se define después de que el usuario intenta leer durante 10 segundos. Entre esos dos extremos hay una gran diferencia en cuánta funcionalidad del navegador se necesita.
    Al final, lo que separa lo bueno de lo malo es la complejidad de implementación. Cualquier herramienta se puede usar bien o mal, y un principiante puede causar un desastre con una sierra circular y una batería cargada. Un artesano incluso puede optar por no usar la herramienta y golpear al costado, es decir, oponerse a los requisitos de negocio.
    Los sitios web que hice últimamente son los más compatibles de todos los que he creado. Ya no uso websockets ni dependo de que JavaScript converse con el servidor por fragmentos. Incluso con JavaScript completamente desactivado, se puede usar alrededor del 80% del producto. No veo cómo esas decisiones de ingeniería no serían una solución al lock-in de ecosistemas cerrados.
  • “ChatGPT y los modelos posteriores pueden navegar sitios web normales como lo haría una persona” todavía me suena más a una afirmación que no es cierta. Aun así, si fuera posible, sería interesante.
    Los modelos de lenguaje grandes se entrenan con texto, código fuente, etc., pero me pregunto si realmente pueden mirar un árbol DOM y saber qué es y qué hace, sin algo que podamos llamar un dispositivo de razonamiento. El DOM no es texto, y debido al bundling y la componentización, tampoco es fácil verlo como código fuente bien estructurado. Suena casi como decir que “un modelo de lenguaje grande puede mirar un .exe arbitrario e integrarse con él de inmediato”.
  • Leí la intención del artículo como una propuesta de usar contenido semántico legible por máquina sobre HTTP, en lugar de, o además de, montones de divs exclusivos para JavaScript. Así, los agentes automáticos como la nueva ola de modelos de lenguaje grandes podrían extraer detalles importantes fácilmente sin lanzar un navegador headless para renderizar la página.
    Tengo un interés parecido, pero mi objetivo es el crawling y los motores de búsqueda emergentes. Si antes de indexar cada página hay que ejecutarla en un navegador headless, la barrera de entrada para un nuevo motor de búsqueda sube mucho.
  • Es una observación válida. Irónicamente, el principal beneficio del marcado semántico ahora parece haberse convertido en una abstracción que facilita a los desarrolladores humanos aplicar estilos y control.
  • ¿De verdad ChatGPT puede hacer eso? ¿Lo hace realmente?

• La primera oración del artículo dice: “Con la llegada de la inteligencia artificial basada en modelos de lenguaje grandes, el HTML semántico se ha vuelto más importante que nunca”, pero creo que sería mucho más defendible decir: “Con la llegada de la inteligencia artificial basada en modelos de lenguaje grandes, el HTML semántico se ha vuelto menos importante que nunca”.
  La web semántica fracasó, y su lugar lo ocupó Google gastando enormes cantidades de dinero en todo tipo de heurísticas con la inteligencia artificial de mejor nivel de la época. Cuanto mejor se vuelve la inteligencia artificial, más capaz es de extraer información incluso de un revoltijo hecho de cualquier manera; y si ese revoltijo alcanza, la gente no va a esforzarse más que eso. En principio, tanto la web semántica como las pilas de heurísticas terminan siendo reemplazadas por inteligencia artificial.
  También es importante que al principio use LLM y luego cambie al término general AI. Los modelos de lenguaje grandes no son toda la inteligencia artificial; son solo una rama que está de moda ahora, y no serán la última rama de moda. No conviene proyectar las próximas décadas asumiendo que los modelos de lenguaje grandes son la respuesta final de la inteligencia artificial.

  • ¿Estás pensando que la inteligencia artificial también va a resolver la accesibilidad web basada en HTML semántico y ARIA? Si no, seguimos necesitando personas para garantizar que el contenido web sea accesible, y en ese caso el HTML semántico sigue siendo importante.
  • Me pregunto cómo será la optimización para motores de búsqueda después de los modelos de lenguaje grandes.
    Si el objetivo era que las partes relevantes del contenido se indexaran y posicionaran suficientemente bien, se puede decir que no había suficiente incentivo para adoptar por completo el HTML semántico.
    Si el objetivo cambia de “posicionarse” a “hacer que un modelo de lenguaje grande extraiga al máximo los matices y la textura del contenido”, podría aumentar el incentivo para usar mejor ciertos elementos. Los sitios web que lo hagan podrían tener mayor influencia sobre la salida de los modelos de lenguaje grandes.
    Se siente como la diferencia entre hablar lo suficientemente fuerte para que te oigan y hablar lo suficientemente claro para que te entiendan.
  • ¿schema.org y Wikidata/Wikipedia no siguen sosteniendo la mayor parte de los resultados enriquecidos de búsqueda de Google?
    Escuché que anunciaron una nueva página de resultados con Bard, pero no creo haberla visto, quizá por mi costumbre de ignorar anuncios o porque todavía no salió en mi región, así que tendré que buscarla.
  • La inteligencia artificial se siente como magia. Siempre pensé que la capacidad humana de reconocimiento de patrones era bastante única y difícil de replicar. Usamos esa capacidad al revisar el revoltijo de un sitio web y extraer datos de algún modo.
    Mentalmente estaba más cerca del bando de la web semántica, pero si las máquinas pueden entender ese revoltijo más o menos bien, tiene sentido preguntar por qué habría que esforzarse tanto.
  • Los proyectos que intentan crear recursos de datos y hacer que la inteligencia artificial los use están perdiendo de vista lo esencial. La inteligencia artificial misma es un recurso de datos.
    También hay proyectos que sostienen que los grafos de conocimiento u otros activos de datos pueden ayudar a la inteligencia artificial a buscar conocimiento “verdadero”. Personalmente, creo que es mejor desarrollar formas de permitir que la inteligencia artificial cree sus propios activos de datos. Los pesos de una red neuronal también son uno de esos activos.
    El problema de la verdad sigue siendo muy difícil. ¿Cómo podemos indicarle a una inteligencia artificial que cierto conocimiento es más confiable que otro? Por supuesto, las personas tenemos el mismo problema.

• Casi no había oído hablar de la mayoría de estos elementos HTML, y es una lástima. Porque cosas así podrían ayudar bastante a terminar con el ecosistema de “todo necesita JavaScript”
  Como mínimo, podrían devolver JavaScript a un lugar más cercano a su intención original: un medio para agregar un poco de adorno o interactividad. No tiene por qué ser el reemplazo de todo el marcado ni el administrador completo del DOM
  El navegador con el que sueño quizá se parezca a visurf https://sr.ht/~sircmpwn/visurf/, con el motor interno de Netsurf actualizado para soportar HTML+CSS moderno, incluidos estos elementos. Con un navegador así, creo que se podría construir una web pequeña casi sin JavaScript. Tendría mejor accesibilidad al romper menos los lectores de pantalla, los temas del sistema, los atajos de teclado, etc.; usaría muchos menos recursos que esos pesados artefactos de JavaScript que podrían reemplazarse; y aun así parece que permitiría la mayor parte de lo que hoy esperamos de una app web de nivel medio. Para cosas como WebGL, uno puede abrir Firefox, pero, por ejemplo, un cliente de Matrix podría necesitar solo un poco de JavaScript para websockets y cifrado de extremo a extremo

  • El problema habitual de estos componentes integrados es que es difícil aplicarles temas. Si en medio de una app moderna aparece un componente estilo Windows 7, distrae muchísimo
    También casi no tienen extensibilidad, así que en cuanto necesitas hacer algo apenas complejo, terminas tirándolo y empezando de nuevo con JavaScript. En ese caso, conviene más empezar con JavaScript desde el principio: funciona bien, te da control total y se comporta igual en todos los sistemas
    Al final, estos componentes adicionales quedan como hinchazón que todos los navegadores deben implementar pero que nadie usa
  • Cuando vi datalist por primera vez pensé: “guau, esto cambia las reglas del juego”. Su comportamiento es igual entre navegadores, pero su apariencia es completamente propia de cada navegador y no se puede estilizar con CSS
    A veces solo se ve el texto de los datos, y a veces se ven juntos el texto y el atributo value. Así que no terminas eligiendo “Atlanta”, sino “234290780 Atlanta”, es decir, el ID junto con el valor
    En el comportamiento al hacer clic tampoco puedes obtener directamente solo el ID; tienes que tomar todo y parsear el ID. Se siente simplemente como un elemento abandonado
  • Quizá te guste esto: http://youmightnotneedjs.com/
  • No estoy en contra de la idea general, pero estos elementos existen desde hace mucho. Creo que, para que una crítica a HTML se tome en serio, hay que conocer lo básico
    El texto enlaza a MDN, y MDN suele ser la referencia breve más útil. Por supuesto también está la especificación HTML de WHATWG y, si es demasiado enorme, existen gramáticas en formato SGML DTD para los snapshots WHATWG HTML 2021·2023 y también las antiguas gramáticas de la familia HTML 5.x
    [1]: https://sgmljs.net/docs/html200129.html
  • https://qutebrowser.org

• Quiero creer en la web semántica, y quiero creer que los navegadores pueden ofrecernos buenos módulos predeterminados y estilos base decentes, pero ahora mismo no queda más que aceptar que no es así
  Incluso algo tan simple como ponerle una etiqueta a un input te obliga a preguntarte por qué no es un atributo, y tampoco es fácil tener certeza de si debe usarse como wrapper o como un hermano con el atributo for=. Eso es solo la punta del iceberg. Para cada etiqueta hay que aprender toda su historia de desarrollo y volver a investigar cuál es la forma correcta hoy
  Podríamos haber tenido algo bueno, pero parece que ya toca calmarse y soltarlo

  • No sé qué herramientas usas, así que no lo digo por nadie en particular, pero si los desarrolladores web hubieran dedicado al aprendizaje de HTML aunque fuera una parte del tiempo que dedican a aprender React, Tailwind, etc., la web estaría en un estado mucho mejor
    Sin duda hay partes raras y aristas ásperas, pero si todos los desarrolladores web supieran aprovechar al máximo el HTML semántico, probablemente habría mucho menos JavaScript en los navegadores, menos bugs de accesibilidad y más ojos atentos cuando la especificación tuviera que corregir o reemplazar esas rarezas
  • Si la etiqueta de un input hubiera sido un atributo de HTML, los formularios habrían sido mucho menos flexibles. Se estarían fusionando dos elementos visuales en uno, lo que dificultaría ajustar la presentación. Por ejemplo, piensa en un input con una etiqueta alineada a la derecha a su izquierda, o en un checkbox con la etiqueta a la derecha
    Un atributo label implicaría contenido de texto plano, lo cual se ve demasiado restrictivo
    HTML, como algo usado durante décadas, tiene una historia compleja y varias capas. Aun así, últimamente no ha cambiado mucho y, gracias a MDN, es bastante fácil aprender qué se puede hacer con HTML5 y profundizar más cuando hace falta
  • En mi caso, casi siempre quiero poner la etiqueta label después de la etiqueta input. Así, con pseudoclases de CSS, puedo seleccionar y estilizar la etiqueta según el estado del input
  • Tener que aprender el significado de cada etiqueta es una parte esencial de cualquier sistema de etiquetado semántico. Si no te gusta esa idea, entonces chocas de raíz con la idea misma de la web semántica
    Por supuesto, para usar con eficacia cualquier sistema de publicación —de hecho, cualquier sistema— hay que aprender a usar los elementos básicos que ofrece. Así que este no es un problema exclusivo de la web semántica

• Uso mucho details para depurar plantillas HTML de Go
  Si meto datos en modo desarrollo con {{if .DevMode}}, cuando está plegado no rompe demasiado la página y no llama mucho la atención; cuando lo necesito, lo despliego y puedo ver todo el contenido

  • Siempre que puedo, abuso un poco del elemento details. Es muy prolijo; no sé por qué no se usa más
  • Puede servir para muchos usos, como menús plegables en páginas web
    También se puede usar en GitHub Markdown, y hay gente que lo usa para ejemplos o explicaciones en línea

• Me gustaron las lecturas y las demos interactivas
  Después de tocar Flutter durante unos años, volví a llegar a la misma conclusión. Hay que apostar por HTML
  La combinación Astro / Tailwind / Daisy UI / Alpine.js es buena para crear sitios HTML que usan mucho renderizado del lado del servidor simple y salpican un poco de reactividad del lado del cliente
  El resultado son archivos HTML simples y sanos, que se ven bien y funcionan bien en navegadores web de escritorio y en WebViews móviles envueltas. Mi app es básicamente estática, así que se cachea en un CDN, funciona sin conexión y ver el código fuente facilita la depuración

  • Después de probar varios frameworks y plataformas vistosos, al final terminé igualmente con un sitio estático que usa Alpine.js y Tailwind. Fue, por lejos, la mejor decisión que tomé hasta ahora
    Lo mejor es que puedo estar seguro de que cualquier desarrollador nuevo, venga de React, Angular, PHP o Python, va a entender un archivo de build de 100 líneas en unos 3 minutos. Me encanta que sea realmente simple
  • Exportar a web con Flutter me parece casi una pesadilla. La última vez que revisé, el renderizado ocurría en un canvas y no había nada de markup
  • ¿Alguien puede ayudarme a entender la utilidad de Daisy UI? Parece como usar clases + hojas de estilo a la vieja usanza, pero pasando por el paso adicional de Tailwind
  • Sí, Astro y la arquitectura de islas son realmente un placer para trabajar

• Creo que el problema de la web semántica es que, por más fácil que se vuelva, los desarrolladores se niegan a usarla correctamente. Mi extensión de navegador usa la etiqueta main, así que la he estado observando de cerca, y la documentación de MDN es muy clara sobre lo que hay que hacer, además de que la propia documentación muestra un buen ejemplo de uso. Aun así, muy pocos sitios la usan bien
  Incluso sitios profesionales muy elaborados suelen envolver todo el contenido de la página, incluida la navegación y el footer, dentro de la etiqueta main. Esta etiqueta debería usarse solo para el contenido principal de la página
  Si ni siquiera pueden usar correctamente un elemento tan simple, no espero mucho de otros elementos

  • Son del mismo tipo que los desarrolladores que usan mal los verbos HTTP
    No deberíamos fingir que estas cosas son contratos
  • Literalmente todos los desarrolladores que usaron la etiqueta p para párrafos la usaron correctamente. No es lo mismo que algo como class="card"
    No entiendo que tantas personas con alto nivel de comprensión técnica lamenten tanto la inutilidad de la web semántica o su fracaso. Suena como decir: “Ojalá el automóvil tuviera éxito, así sería más cómodo viajar largas distancias”
  • La primera solución que se me ocurre es una validación más estricta. Que el navegador se niegue a renderizar si la estructura no es correcta
    Pero esa época existió. En general, las cosas anteriores a HTML4 eran así, y era peor
    Así que quizá sea mejor que las herramientas de desarrollo lancen advertencias o errores cuando se hace un uso incorrecto
  • No hay ningún incentivo para usarlo bien. Yo intento usarlo bien, pero no noté ninguna diferencia aparte del tiempo que pasé decidiendo qué debería ser cada elemento

• Es interesante que muchos comentarios aquí vean este artículo como un texto anti-JavaScript. Para mí, en cambio, parecen herramientas enormemente útiles para usar junto con los frameworks centrados en TypeScript que usamos en frontends de apps empresariales modernas. Precisamente porque son herramientas nativas de HTML y no exigen muchas cosas
  Por ejemplo, la etiqueta meter probablemente reemplace todos los módulos de carga que usamos en React cuando llegue hoy al trabajo. Es mucho mejor que lo que usamos ahora
  Puede que haya entendido mal a la gente o leído mal el artículo, pero incluso cuando casi todo el frontend es TypeScript, como en las aplicaciones grandes de hoy, esto es muy interesante

  • Mi esperanza es que estas cosas reemplacen enormes bloques de código JavaScript. Sé que una web sin JavaScript, por desgracia, es una fantasía, pero al menos se pueden quitar grandes bloques y crear experiencias de usuario más estándar, que el sistema pueda guiar y moldear
    Están surgiendo nuevas aplicaciones que pueden construirse con mucho menos JavaScript que antes. En las apps empresariales TypeScript existentes podría ser una actualización in situ, pero la esperanza es que en el desarrollo de apps nuevas se pueda evitar ese tipo de frameworks empresariales por completo. Uno puede soñar, ¿no?

• No quiero desmerecer por completo el desarrollo web, pero de verdad es horrible. Lo hice durante años, desde HTML puro hasta lenguajes de scripting y frameworks, y la cantidad de tiempo que se tarda en hacer cosas triviales se siente como un enorme desperdicio mental.
  Cuando me fui de vacaciones, solo quería encontrar lugares para comer y tomar algo o sitios para visitar por el día, pero la mayoría de los sitios estaban hechos un desastre, eran viejos o no estaban actualizados. Todavía hay muchos sitios que se hicieron una vez y quedaron olvidados. Parece que es porque el presupuesto es ajustado y no alcanza para actualizarlos, o porque actualizarlos es técnicamente demasiado difícil.
  La complejidad de los sitios provoca parálisis. Algo que podría ser unas pocas páginas simples de texto e imágenes está innecesariamente sobrediseñado y quemando una enorme cantidad de ciclos de CPU. También es muy probable que esté construido retocando un CMS prefabricado que necesita actualizaciones de seguridad.
  Hace poco estaba viendo el sitio de un cine, y era casi imposible siquiera revisar las pocas películas que daban esa semana. Sentí que sería más legible ponerlo en una hoja de cálculo y, de hecho, cuando descargué el JSON desde la API, era más fácil de leer.
  La mayor parte es un empaque cansador, como ponerle lápiz labial a un cerdo. Una de las razones por las que Facebook tuvo éxito fue el onboarding fácil, y otra fue que compartir fotos era sencillo. Lo mismo pasa con WhatsApp e Instagram. Publicar tiene que ser fácil. Incluso FTP simple es fácil, pero para la gente común hay una desconexión rara en el proceso de uso. La gente quiere arrastrar y soltar, subir, dejarlo ahí y olvidarse, y editar fácilmente. Quienes quieren consumir datos al final solo quieren lo esencial: los datos.

  • No creo que quienes consumen datos quieran solo los datos esenciales. El lector promedio de HN quizás sí, pero la persona promedio no.
    Lo que la gente quiere son páginas web bien estilizadas y utilizables. El problema es que no hay suficientes diseñadores de experiencia de usuario efectivos y talentosos, y a los stakeholders de las empresas también les falta buen criterio de UX.
    Por eso, ofrecer solo los datos esenciales termina siendo mejor para el usuario promedio que el UX mediocre que puede pagar una empresa promedio. Aunque no sea lo que prefiera, es mejor.
    {mal UX} << {datos en bruto} < {buen UX}
    El atajo que encontró WordPress fue crear estilos y temas profesionales y permitir que los usuarios los compraran y aplicaran. Pero eso no puede arreglar el mal gusto de los stakeholders.
    Creo que Facebook tuvo éxito porque impuso un UX profesional y estandarizado. {datos de la gente} + {UX profesional y estandarizado} = {victoria}. Puede no gustarte el UX inicial de Facebook, pero es difícil decir que fuera un trabajo amateur. La percepción general de MySpace o Geocities, entre otros, era la opuesta.
  • La mención de WhatsApp da en el clavo. En el país africano donde estoy, WhatsApp es tan popular que las operadoras móviles incluso venden paquetes de datos para WhatsApp.
    Si quiero encontrar algo como malla metálica, primero pregunto en los grupos de WhatsApp en los que estoy: familia, vecinos, amigos de la secundaria. Normalmente recibo algunos números, y al contactar por WhatsApp a los proveedores del servicio obtengo información actualizada.
    Esos proveedores no pueden costear un sitio web actualizado. WhatsApp incluso tiene una función para poner un catálogo en el perfil, y es para cuentas comerciales gratuitas.
  • Por eso recomiendo Wix a la mayoría de los pequeños negocios. ¿Todos los sitios se ven parecidos? Sí, y no necesariamente es malo. Como es fácil de usar y actualizar, los clientes agradecen tener la información actualizada que necesitan.
    Lo que me gustaría ver es algo como “Wix Widgets”: widgets conectados a datos, con un nivel de personalización como conectar llamadas a servicios REST y mapear puntos de datos a la visualización del widget. Sería bastante útil para cubrir las necesidades de sitios web internos que hoy tienen todas las empresas.
    El 90–95% de las páginas web realmente necesita una solución simple.
  • Es gracioso que nos digan que la plataforma web es el mejor y más consistente sistema GUI multiplataforma, pero que construir algo sobre ese sistema sea horrible.
    Quizás esto sea la esencia de las GUI. Tal vez por diseño hay que dar cada instrucción una por una, consumen muchos ciclos y, si no, no funcionan de forma multiplataforma.
  • Parte de este problema está en que las etiquetas y elementos dentro de los archivos HTML siguen aumentando. Pasó de ser marcado de documentos a ser marcado de páginas, y es difícil distinguir dónde termina una cosa y empieza la otra. Aunque el W3C intentó resolverlo agregando los elementos article y section.
    Claro que, para empezar, el código HTML en bruto probablemente nunca estuvo pensado para que lo leyera alguien que no fuera desarrollador, así que también está eso.

• Me emocionó mucho la noticia de que habría modales en HTML puro, pero me decepcionó descubrir que no hay forma de activarlos sin JavaScript. Con HTML puro solo se pueden cerrar, no abrir.
  https://github.com/whatwg/html/issues/3567
  El elemento dialog es una gran incorporación y me alegra que se esté implementando, pero parte de su funcionalidad central depende de JavaScript. Para abrir un dialog, hay que establecer el atributo open con JavaScript.
  Sería bueno que hubiera una forma de que un elemento button o a pudiera abrir un cuadro de diálogo. Ya hay precedentes de interacciones de página incorporadas en HTML. Por ejemplo, los enlaces pueden desplazar la página, y el elemento details puede ocultar elementos después de una interacción, así que parecería natural que otro elemento de la página pudiera abrir un dialog.

  • No sé si el noble objetivo de “solo HTML” debería significar extender HTML con capacidades de scripting. Si ese fuera el caso, creo que sería mejor simplemente usar JavaScript.
  • Se puede implementar un modal solo con HTML y CSS, sin JavaScript.
    Por ejemplo, haz clic en el ? de la esquina superior derecha aquí: https://aavi.xyz/proj/colors/
  • Sería bueno que estuviera integrado en el propio HTML, pero al menos el JavaScript necesario no es complejo y también se puede poner en el atributo onclick.
  • Se puede hacer que se muestre u oculte según el hash actual. Claro que ese enfoque sí requiere CSS.