Pues eso. Que aprovechamos la resaca de San Juan para celebrar que este modesto blog le ha dado su vigesimotercera vuelta al sol. Comenzamos antes de que WordPress se llamara WordPress, en el alojamiento de miarroba.com (siguen vivos, y dice su web que se pusieron en marcha en el 2000).
En cualquier caso, que happy birthday to us, que esperamos seguir aquí el año que viene y que muchas gracias a los cuatro lectores regulares del blog :-).
PS Inspirándome en el blog de Dani Latorre (que «solo» cumple veinte años) me he ido a archive.org a buscar la captura más vieja que tienen de obm, y ahí tenéis, en todo su «esplendor», la primera entrada de obm, tal y como se veía en 2009 (ha llovido), con esa plantilla emulando las pestañas del Chrome de la época.
Qué nostalgia los 700 lectores en Feedburner (Feedly que estamos al borde de los 200, pero no es lo más creíble del mundo, opino) y la lista de entradas más populares (que, mucho me temo que, si tuviésemos estadísticas fiables, seguirían estando ahí)…
Este episodio de Vergecast (maravillosamente titulado, por cierto) con John Gruber, el creador de Markdown (entre otras cosas), y el siempre interesante Anil Dash me lleva a hacer una entrada de esas de «señor mayor gritándole al sol», y es que debo ser el único ser humano al que Markdown no le parece una buena idea [en muchos de los casos en los que se usa actualmente].
(Markdown es un sistema para marcar texto ideado por Gruber para poder poner **negritas**, __cursivas__ y hacer otros cambios tipográficos sin morir en el intento en los inicios de la blogocosa, con el beneficio adicional de que, si se te muestra sin procesar, no se pierde gran cosa.)
La cuestión, claro, es que ahora el sistema se ha hecho más ubicuo que el agua (bueno, casi :-P). Markdown **era** necesario, y sigue siendo útil en algunos muchos casos (por ejemplo, para los que detestamos profundamente que en el correo haya cualquier cosa que no sea texto plano). Pero me alegra que hasta el propio Gruber esté de acuerdo conmigo en que en la actualidad se usa demasiado Markdown (somos dos, al menos, pero no sé yo si seremos muchísimos más de dos, y el mercado, claramente, mete Markdown hasta en la sopa sin que haya grandes protestas).
Gruber comenta cómo, hace mucho, muchísimo tiempo (en una galaxia muy muy lejana) para poner unas negritas había que recurrir a poner una etiqueta HTML escrita a mano, cosa que era cualquier cosa menos amigable (i) en ausencia de editores ni mínimamente adecuados y (ii) siendo el HTML un lenguaje maravilloso pero que no ganará ningún premio por lo compacto y que requiere millones de caracteres (o casi) para cualquier marcado. Y también comenta cómo el tema de los editores se ha resuelto bastante desde entonces y que ahora mismo escribir **esto** cuesta el mismo esfuerzo que pulsar una combinación de teclas para poner negritas (y quitarlas después). Y coincido con él. Pero.
Es la semántica, amigos.
En un texto moderno, estamos bastante acostumbrados a que dentro de un párrafo se destaquen textos con negritas y con cursiva. Nada nos impide cambiar el color del texto, o de su fondo, usar otra tipografía, o subrayarlo (bueno, esto último sí nos lo limita bastante la voluntad de que el texto continúe siendo legible, y por eso cuesta verlo más que en el caso de los enlaces), pero lo habitual son negritas y cursivas.
Pero la cantidad de significados que tienen esas negritas y cursivas es más que considerable: uno puede usar las cursivas para dar énfasis, pero también para referirnos a títulos de obras o poner extranjerismos, por ejemplo. Y las negritas se usan para dar un énfasis más fuerte que el de las cursivas, pero también lo he visto yo usado para marcas comerciales, por ejemplo. Nuestro cerebro, que es muy apañado, procesa y decide. Pero en este mundo nuestro, no debería ser demasiado complicado hacer explícita esa semántica. Y, es más, HTML lo permite bastante: tenemos elementos para dar énfasis (em y strong), pero también tenemos el elemento cite, el atributo lang o los pobres b e i, que ya no saben ni ellos para qué deberían usarse (y code, claro, como habéis podido comprobar, os hayáis dado cuenta o no, igual que os ha pasado con s hace un par de párrafos ;-)). Que em, cite e i se muestren por defecto en cursiva, que a strong y b les toque la negrita, que al pobre lang no suela hacerle caso nadie (qué poco habría costado que cualquier cosa marcada con un idioma diferente al del documento raíz se mostrase en cursiva por defecto, oiga) y que a code le toque una tipografía monoespaciada está bien (o no), pero nada nos impide elegir cualquier otra forma de formatear cada elemento. ¿Queréis los anglicismos resaltados en inglés? Feel free (pero yo no voy a hacerlo). Os dejo también que le cambiéis el aspecto a s, a del y hasta a ins, pero andad con cuidado, que es fácil hacerse daño. Con la tontería, sí que hay semántica en el marcado de texto de HTML, ¿eh?
¿Que quién se va a tomar la molestia? Pues somos pocos los que nos hemos tomado la molestia de instalar un plug in en WordPress para marcar el idioma de un fragmento sin tener que poner a mano un span lang="en"… pero haberlos haylos. Y si estas cosas viniesen por defecto, pues igual más gente lo haría, quién sabe.
¿Veis esos «Add HREFLANG Attribute» y «Add LANG Attribute«? Si los queréis en vuestro editor de WordPress, Juiz Lang Attribute.
¿Que qué ganamos? Tampoco tanto, cierto es… pero qué poco costaría y, en un mundo en que cada vez las máquinas nos hablan más, que el lector de pantalla no nos ponga énfasis en lo que es el título de una obra, o que sepa cambiar al idioma correcta para leernos una cita sin traducir de Shakespeare o de Molière, estaría bien, ¿no? Y, en cualquier caso, a un editor le cuesta lo mismo trabajar en Markdown que en HTML, y este último da más juego1.
Pues eso, que no es que andemos cortos de elementos semánticos. Y no debería costar mucho poder asignar teclas rápidas para las cosas que usemos más. Pero, en la práctica, la batalla está perdida con los editores de texto.
Un editor «wysiwyg». Y no uno cualquiera: el de WordPress.
Y es que me da igual que hagáis ctrl+b o cmd+i para poner negritas y cursivas (¿De verdad me había olvidado de kbd? Imperdonable, lo sé.), que vuestros editores HTML os van a clavar un strong o un em, respectivamente, y se van a quedar tan anchos, a pesar del crimen de lesa semántica, y si se les confunde con un limitado editor de Markdown, pues qué se le va a hacer.
Más de mil palabras para básicamente quejarme de algo que ni es tan importante ni se va a solucionar. Profundamente señor, profundamente cincuentón, sí. Disculpen las molestias.
(Y todo esto, lo sé, sin hablar de LaTeX, que es muy presentacional para muchas cosas y del que no me quejo… pero porque no me han dado la ocasión. En mi mundo, las fórmulas matemáticas se escribirían en MathML semántico :-P.)
Sí, es cierto: Markdown puede extenderse… pero si lo extiendes, vas a perder buena parte del espíritu original. ↩︎
La primera, la declaración de Leiden sobre matemáticas e IA, con el soporte de la International Mathematical Union, que dice que cuidado con la IA. No dice que la IA no pueda suponer grandes avances (que los ha habido) en el campo, pero sí que está rompiendo cosas (más detalles en el New York Times y en Ars Technica). Mencionan, por ejemplo, que los colosos de la IA no son nada transparentes en el proceso (actualmente las matemáticas de primerísimo nivel son una cosa sorprendentemente abierta), y eso es realmente problemático. Pero me quedo, sobre todo, con otra de las cosas que destacan: los modelos de lenguaje están haciendo que alguien sin conocimientos pueda producir un intento de resolver un problema clásico extremadamente verosímil, sea correcto o no… y que esto está haciendo que los departamentos de matemáticas del mundo se vean inundados de demostraciones que, lamentablemente, se demuestran erróneas casi siempre… pero no sin consumir una cantidad de horas más que notable. Uno recuerda la época en que era extraño que pasara un año en ningún departamento de matemáticas sin que se recibiese una demostración del (mal llamado) teorema de Fermat, y no quiero ni imaginarme cómo debe ser la situación actual, en que no se puede descartar lo que te llegue, porque quién sabe… pero de momento estamos restando muchísimas más horas que las que sumamos.
Segunda noticia, que Ladybird, un navegador web alternativo en fase de desarrollo, anuncia que deja de aceptar pull requests, y que solo los mantenedores del proyecto podrán introducir cambios en el código fuente. Y que no se habilitará ninguna vía alternativa. Van de camino a su primera alfa y necesitan un proceso más estricto, con un modelo de seguridad más claro y un grupo más reducido de responsables. La aparición de las herramientas de IAg, dicen, rompe la antigua premisa de que un gran parche implicaba un gran esfuerzo y buena fe por parte del autor.
Y tercera, que Matt Mullenweg anuncia que WordPress.org pone en marcha una iniciativa de seguridad, de nuevo motivada por el avance constante de la IAg y el aumento de ataques en la cadena de suministro. Buscan encontrar el equilibrio entre lanzar las actualizaciones de seguridad lo más rápido posible, pero reteniéndolas el tiempo suficiente para garantizar que no han sido comprometidas. A partir de ahora, cualquier versión nueva de un plug-in deberá esperarse “hasta 24 horas” antes de distribuirse mediante las actualizaciones automáticas, de modo que tanto el equipo humano de revisión como “Gandalf”, un nuevo bot basado en IA, puedan analizar a fondo los cambios, y dicen que esperan reducir el plazo a pocos minutos.
Y la cuestión, claro, es que ya no hay que «hacer los deberes» para lanzar unas cuantas páginas de texto, una (presunta) demostración matemática o un parche para un software, con buena o mala fe, y los editores del mundo se ven inundados. En un primer momento puedes suponer que es falta de un buen proceso para recoger y estudiar el alud, pero estamos llegando (hemos llegado, estoy casi seguro) al momento en que ni los mejores embalses pueden luchar contra la riada, y eso está teniendo efectos secundarios que pueden llegar a ser devastadores, tanto en los momentos en que una buena actualización se quede atrapada en el proceso como en aquellos en que una mala se cuele por el filtro.
Pues eso, solo una nota breve para quienes uséis Mastodon y Bluesky y estéis desquiciados porque no encontráis un buen cliente para usar ambos en el móvil…
Hasta ahora Openvibe era mi cliente favorito, pero no podía recomendarlo porque no tenía soporte para bookmarks. Afortunadamente, lo acaban de añadir, o sea que ahora es, claramente, el cliente.
La interfaz de Openvibe no es ninguna revolución… ni falta que le hace.
También soporta Threads y Nostr, pero en mi caso he tenido algún problemilla con el soporte de Threads, que no ha sido especialmente traumático porque apenas uso la red, y no gasto Nostr.
Con el soporte para bookmarks han aprovechado para sacar una versión Pro, que es necesaria si quieres usar más de dos cuentas. No es mi caso, pero como (i) está bien ser agradecido y (ii) hacían un descuento a los que ya éramos usuarios, con el que queda en 20 eurillos al año, me he animado a suscribirme, de momento por ese año.
Openvibe está disponible tanto para Android como para iOS, y tenéis toda la información y los enlaces a la descarga de la aplicación en la plataforma correspondiente en openvibe.social.
Inauguramos serie de entradas pseudoregulares (espero) en obm: cosillas que he ido leyendo y me han hecho gracia, en general alrededor del diseño y el desarrollo web. A ver cuánto dura la cosa…
El 25 de mayo, el artículo Responsive Web Design, de Ethan Marcotte, cumplía los 16 años. Qué viejos somos. El propio Marcotte nos recordaba lo que escribió sobre el tema cuando «solo» tenía diez años.
Para los que tiráis de WordPress, el 25 de mayo en Freelandev repasaban las novedades que trae la 7.0. Aquí el enlace al episodio.
El 29 de mayo, Rachel Andrew daba su repaso mensual en web.dev a las novedades de la plataforma web. Lo más destacado, que entran en el «baseline» una pseudoclase nueva y container queries por el nombre del contenedor y por custom properties (variables, vaya).
Dejo para el final los contenidos con/sobre IA, y así quien no quiera leer estas cosas puede ahorrárselas fácil.
El 26 de mayo en el podcast de Syntax hablaban de decisiones que, por mucho que vayas a tirar de agentes para tu proyecto, deberías tomar tú antes de dejarles que se pongan a ello: el esquema de la base de datos, las estrategias de validación, el enrutado, el flujo de autenticación, metodología CSS y framework de interfaz de usuario y el tipo de comunicación entre front y back.
Antes de eso, el 5 de mayo (ordeno en el orden en que yo encontré / leí las cosas), Addy Osmani hablaba desu repo Agent Skills en GitHub. Me fascinan estos repositorios porque, con sus problemas, son recopilatorios de buenas prácticas que, me da la impresión, o no se hacían o no se hacían con tanto cariño y esmero cuando el objetivo era educar humanos, y no agentes (seré muy feliz si se me corrige). En cualquier caso, tanto la entrada de blog como el repo me parecen una lectura muy interesante.
