• HTML Is Actually a Programming Language. Fight Me | WIRED
    https://www.wired.com/story/html-is-actually-a-programming-language-fight-me

    In fact, HTML is the most significant computing language ever developed. Underestimate it at your peril.

    Image of html knitting the globe on an old school computer
    ILLUSTRATION: SAMUEL TOMSON

    Are you a coder? Please take our new survey (it’s short and fun) about how you use AI at work.

    HTML is deceptive. It looks easy. And easy HTML is easy. With a few tags you can write your name on a webpage, make it bigger or smaller, add “is awesome” in bold or italics, and even—for those of us who came of age in better times—make it blink or scroll across the screen.

    Because HTML looks easy and lacks features like formal conditional logic and Turing-completeness, it’s often dismissed as not a programming language. “That’s not real code; it’s just markup” is a common refrain. Now, I’m no stranger to the austere beauty of the command line, from automating scripts to training machine-learning models. But underestimating HTML is a mistake.

    HTML is the most significant computing language, programming or otherwise, ever developed. Every other programming language has to grapple with how HTML has redefined computing over the past 30-plus years. So many “pure” programming languages automate the production of more and more HTML.

    When haters deny HTML’s status as a programming language, they’re showing they don’t understand what a language really is. Language is not instructing an interlocutor what to do in a way that leaves no room for other interpretations; it is better and richer than that. Like human language, HTML is conversational. It is remarkably adept at adapting to context. It can take a different shape on any machine, from a desktop browser or an e-reader screen to a mobile app or a screen reader for the blind (so long as that device is built to present hypertext).

    HTML is somehow simultaneously paper and the printing press for the electronic age. It’s both how we write and what we read. It’s the most democratic computer language and the most global. It’s the medium we use to connect with each other and publish to the world. It makes perfect sense that it was developed to serve as a library—an archive, a directory, a set of connections—for all digital knowledge.

    Like many readers my age, I encountered HTML in 1994, during those heady days when Netscape’s browser brought the web to much more of the world. In my case, the internet was available on just a few machines at my high school—I didn’t have a computer at home, let alone dial-up—but I quickly made myself an amateur expert in navigating the strange new space that Tim Berners-Lee and his colleagues had brought into being.

    An older friend showed me how he built his own homepage, complete with animated “under construction” GIFs, an interactive Magic 8-Ball, and a handful of bandwidth-devouring photos. Since I didn’t have an email address, he set up a text entry field on his site where I could send him messages, with stern instructions that the textbox was “only for TIM.” He’d post his own responses directly on the website, so I (and theoretically anyone) could read them when I next got access to a machine. This is what passed for information security for two low-risk targets in those days.

    The idea that you could build something fun for your friends, but potentially anyone in the world could discover it, was intoxicating. So was the language itself. Most raw HTML then was easy for humans, even newcomers, to understand. You didn’t need a primer in formal logic to grasp that most tags needed to be opened and closed (like parentheses in a math statement or ordinary sentence) to function as intended. And you didn’t need to be a mischief-minded teenager to see the possibilities in what happened when HTML “broke.”

    To learn any programming language is to learn how to debug it. But a malformed command in Python usually returns an error message that keeps the code from running, not something that fails brilliantly yet monstrously, outpacing its creators’ intentions. With HTML, we are all Doctor Frankenstein.

    One of my favorite websites of all time is the Embroidery Troubleshooting Guide. These days it’s available only via the Internet Archive, unless (like me) you have a local copy. At the top, it looks like a typical, if somewhat old-fashioned, small-business website. But when you glance down, you immediately notice something strange about it. The text, all center-aligned in alternating red and blue Arial, gradually gets bigger and bigger, with phrases forced to wrap lines or reach the edge mid-word, filling up the screen like Alice trying to squeeze through smaller and smaller doors in Wonderland.

    When you view the source code (have any other programs made it so easy to view source like a website?), you’ll quickly discover what’s gone wrong. Each line of centered text begins with <h2> or <h3> header tags that never close. Each header tag—which only establishes a relative size, not an absolute one, part of the semantic richness of the web’s flexible grammar—builds on the last, creating progressively larger nesting dolls. The tag designed for defining textual hierarchy runs amok, creating chaos. The fact that the words themselves are about how and why threads can break makes it poetry.

    On its own, the Embroidery Troubleshooting Guide would be a clever enough piece of found conceptual art. But by viewing the source, downloading the file, and replacing the instructions for troubleshooting common sewing problems with any text you like, you can make that artwork your own. I like to put in my favorite poetry, decontextualizing it and forcing myself to read it with new eyes.

    “Broken” sites like these upend the great achievement of semantic HTML. As it developed, semantic HTML increasingly separated structure from presentation: Instead of <i> tags, which strictly specify that a text be presented in italics, we use <em> tags to identify emphasis (or <cite> tags for titles of books or movies, etc.). These elements can then be presented as italics on a computer screen but be read with a different intonation by a screen reader. The Embroidery Troubleshooting Guide hijacks a semantic tag and makes it present something unexpected. The same building blocks that allow a single website to be displayed responsively on a tiny phone or enormous television screen can make a website fundamentally undisplayable. This is delightful.

    I appreciate the utility of content management systems and complex sites that generate HTML dynamically, but there’s a joy in building sites out of simple HTML files you can edit by hand. I still edit my own website this way, tidying it up so I can see every tag, section, and paragraph break. I even love editing my own ebooks, turning PDFs into nicely formatted HTML-based EPUB files that never get published to anyone: my own private library of self-contained websites. During the height of the pandemic, editing these files and their style sheets by hand was a balm.

    Ultimately, even as HTML has become the province of professionals, it cannot be gatekept. This is what makes so many programmers so anxious about the web, and sometimes pathetically desperate to maintain the all-too-real walls they’ve erected between software engineers and web developers. But people who write HTML know that hierarchies were made to be blown up. All it takes is a tag that doesn’t close where you’d expect it to.

    What other programmers might say dismissively is something HTML lovers embrace: Anyone can do it. Whether we’re using complex frameworks or very simple tools, HTML’s promise is that we can build, make, code, and do anything we want.

    #HTML #Proud_to_be_a_web_developper

  • The untold history of web development:
    https://functional.cafe/@juliobiason/111613996060167180

    The untold history of web development:

    1990: HTML invented
    1994: CSS invented to fix HTML
    1995: JS invented to fix HTML/CSS
    2006: jQuery invented to fix JS
    2010: AngularJS invented to fix jQuery
    2013: React invented to fix AngularJS
    2014: Vue invented to fix React & Angular
    2016: Angular 2 invented to fix AngularJS & React
    2019: Svelte 3 invented to fix React, Angular, Vue
    2019: React hooks invented to fix React
    2020: Vue 3 invented to fix React hooks
    2020: Solid invented to fix React, Angular, Svelte, Vue
    2020: HTMX 1.0 invented to fix React, Angular, Svelte, Vue, Solid
    2021: React suspense invented to fix React, again
    2023: Svelte Runes invented to fix Svelte
    2024: jQuery still used on 75% of websites

    (by @fireship_dev on Birdsite)

  • Lighthouse overview - Chrome Developers
    https://developer.chrome.com/docs/lighthouse/overview

    Est-ce que vous avez une opinion à propos de cet outil ?

    Je me contente toujours de validator.w3.org et de Lynx (en plus de Firefox, Chrome et Safari sous des OS divers) pour tester mes sites. C’est déjá assez coûteux quand tu fabriques du code propre (validator) et des pages facilement accessibles (des textes bien structurés, pas de menus interminables en haut de page, des alt/titre pour les images et vidéos, des liens parlants etc.). Avec l’inspecteur de code de Firefox et les autres outils (SPIP) je me sens à l’aise, alors quel argument est-ce qu’il y a pour ajouter Lighthouse à ma boîte d’outils (dans ungoogled Chromium ) ?

    Je m’en fous du nombre de visiteurs répertoriés car je ne travaille plus du tout pour les commerciaux, et toute la magie noire SEO ne m’intéresse plus que pour m’amuser.

    Merci pour vos idées.

    Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, SEO, and more.
    Lighthouse logo

    You can run Lighthouse in Chrome DevTools, from the command line, or as a Node module. You give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page did. From there, use the failing audits as indicators on how to improve the page. Each audit has a reference doc explaining why the audit is important, as well as how to fix it.

    You can also use Lighthouse CI to prevent regressions on your sites.

    #web #www #html #css #javascript #SPIP

    • Je les utilise. Par habitude j’utilise plutôt la version Web PageSpeed Insights :
      https://pagespeed.web.dev
      mais il me semble que ce sont exactement les mêmes indicateurs.

      En gros de base on obtient des scores très corrects avec un SPIP bien configuré. Et ça indique comment faire pour passer à plus de 90/100 relativement facilement.

      Un intérêt : c’est souvent utile pour montrer à un client que ce qu’il réclame, ça va faire « du mal » à son site. Parce qu’expliquer « nan mais faut pas faire ça, c’est un mauvais usage du Web », tous les clients s’en foutent, il y a forcément un petit cousin, une boîte de comm, un spécialiste de je-ne-sais-quoi qui va revenir à la charge pour lui expliquer que « si si, c’est ça qu’il faut faire ». Alors tu fais un coup de PageSpeed sur ta version, tu fais conserve une copie d’écran, ensuite tu implémentes le truc en question, ou bien tu vas sur une page qui l’a déjà implémenté, et tu fais passer PageSpeed là-dessus, et tu montres les scores qui passent en dessous des 50/100 et les voyants qui deviennent rouges, c’est généralement très convaincant… :-)

    • Ah, c’est un truc pour les pros. Je ne me considère pas comme faisant partie de cette catégorie de créateurs de sites. #merci @arno

      Pour moi qui ne fait des sites web que pour des « clients » qui me font confiance et qui ne se laissent pas influencer par les « petits cousins » cela veut dire que oui, c’est utile mais ...
      – c’est l’outil que j’utiliserai après tous les autres tests
      – s’il y aura un problème de rapidité d’affichage que je n’arriverai pas à cerner.
       :-)

  • Performance #web : l’intégrateur, ce héros

    J’ai envie de pousser un concept absolument nouveau : l’amélioration progressive (ah pardon on me dit que ça date de 2003). Au minimum c’est la clé d’un premier affichage éclair car on peut se passer de #JavaScript quelques secondes.
    Puis abordons le gros sujet des images : comment les charger rapidement, sans toucher aux fichiers eux-même ? Il y a eu quelques nouveautés ces deux dernières années, mais on va voir que même sur des choses que l’on peut croire acquises comme le lazy loading, il y a quelques pièges qui peuvent être contre-productifs.
    Enfin terminons avec un petit résumé sur les polices : elles tapent dans l’œil mais il faut en garder le contrôle si l’on veut un bon CLS (une des métriques Google dont on va reparler).

    Article intéressant sur les optimisations au moment de l’#intégration web. Ça parle (un peu) performance mais surtout #UX, #ergonomie, #HTML, #CSS, #javascript...

    https://www.24joursdeweb.fr/2021/performance-web-lintegrateur-ce-heros

    • Ya des gens qui trouvent ça enthousiasmant, comme plein de techniciens qui sont à fond dans leur petite spécialité technique, mais moi ça me terrifie, ça devrait pas exister du temps à passer sur ça :D

      Et surtout encore moins devoir s’en préoccuper à chaque intégration (plutôt que ce soit les gens qui font le CMS, langage de template, plugins de lazy, etc, et qu’ensuite pour un site précis à intégrer on n’y pense presque plus).

    • Oui, l’article est intéressant en tant que ressources, pour choisir les plugins qu’on utilise (par ex Adaptive images qui gère le WebP et le lazy loading nativement), faire ses boilerplates persos (préchargement des polices et font-display: swap;), les optimisations côté CMS (chargement JS en asynchrone)... etc, évidemment dans l’idée d’automatiser au maximum.

      Et aussi, se rendre compte que #SPIP gère une bonne partie de tout ça <3

  • tgalopin/html-sanitizer : Sanitize untrustworthy HTML user input
    https://github.com/tgalopin/html-sanitizer

    Un remplaçant potentiel pour la lib « safehtml » embarquée dans SPIP (plugin-dist https://git.spip.net/spip/safehtml) qui commence à poser des problèmes de compatibilité avec les usages du HTML 5 (entre autre les attributs data-truc)

    Voir aussi le plugin HTML-purifier : https://git.spip.net/spip-contrib-extensions/htmlpurifier
    et la discussion en cours sur le sujet : https://git.spip.net/spip/spip/issues/3926

    #SPIP #safehtml #HTML-sanitizer #HTML-purifier

  • Those #HTML #Attributes You Never Use — Smashing Magazine
    https://www.smashingmagazine.com/2022/03/html-attributes-you-never-use

    With no value, the download attribute forces the linked page to be downloaded. Alternatively, you can provide a value which the browser uses as the suggested file name for the downloaded resource.

    <a href="/example.pdf" download="my-download.pdf">Download File</a>

    ...

    The disabled attribute for the <fieldset> element, to easily disable multiple form elements simultaneously;

    Ha ben tiens...

  • Je crois que c’est mon plus beau #shameless_autopromo : on vient d’effectuer avec Mosquito la mise en ligne des Très Riches Heures du Duc de Berry, qualifié de « Joconde des manuscrits », 206 feuillets réalisés au cours du XVe siècle, conservé au château de Chantilly :
    https://les-tres-riches-heures.chateaudechantilly.fr

    Initialement nous avions réalisé une table tactile installée dans la bibiothèque du château. Table que j’avais évidemment codée en #HTML5, et motorisée par #SPIP. Comme le résultat a beaucoup plu, on nous a dans un deuxième temps demandé de réaliser une version « Web » responsive. (Ça a été une gageure, à la fois côté technique et ergonomique.)

    Le principe a consisté à présenter le manuscrit sous forme de « livre » dont les pages se tournent de manière fluide, mais le contenu de chaque page devant être une image en « méga-zoom », et dotée de points d’intérêt (hotspots) donnant des explications supplémentaires. Évidemment les scripts de « tourne-pages » ne sont pas conçus pour faire ce genre de chose, et afficher des centaines d’images « méga-zooms » interactives n’est pas non plus totalement anodin, si on veut que l’ensemble reste fluide. Mais au final, ça fonctionne bien…

    Une autre caractéristique, plus technique, était que je voulais pouvoir gérer intégralement les contenus et les images dans SPIP, notamment sans devoir fabriquer « manuellement » les tuiles des images méga-zoom (qui existent en version « une page » et en version « double-page ») sur l’ordinateur. Là les images méga-zooms sont fabriquées automatiquement sur le serveur, depuis #SPIP et les hotspots sont directement définis dans mon interface. Ce qui permet de lier directement la gestion des hotspots et les tuiles méga-zooms, sans risque de travailler sur des versions différentes des images.

    Et de manière désormais habituelle sur mes contenus de ce genre : c’est instantanément multilingue (on change de langue à l’endroit même où l’on se trouve, sans rechargement de contenus).

    C’est donc un travail dont je suis particulièrement content, ce n’était pas gagné d’avance d’arriver à une interface fluide et responsive, une gestion des contenus relativement simple (tout se passe dans une interface SPIP), à partir d’une interface initialement conçue pour un grand écran de taille fixe, entièrement tactile, avec derrière un PC avec un SSD ultra-rapide et une carte graphique de compétition (un des rares avantages de développer sur Mac : au moins je n’ai pas une carte graphique de compétition, ça oblige à optimiser un peu le truc…).

    Et évidemment, c’est gratifiant d’avoir travaillé sur la mise en ligne d’un des plus beaux chef-d’œuvre du monde.

    • Le musée Condé (Château de Chantilly) propose l’exploration numérique gratuite des « très riches heures du duc de Berry » – Club Innovation & Culture CLIC France
      http://www.club-innovation-culture.fr/musee-conde-domaine-chantilly-exploration-numerique-gratuite

      Une campagne de reproduction à très haute définition a en effet été menée en partenariat avec l’Agence photographique de la Réunion des Musées Nationaux – Grand Palais. Les images réalisées par le photographe Michel Urtado permettent de voir, jusqu’au moindre détail, les touches de pinceau des peintres.

      Suite à cette campagne de photographies, la société Mosquito a développé une application de découverte qui a été testée durant l’année 2021 par les visiteurs au sein du Cabinet des livres du château.

      Le dispositif, constitué d’un logiciel éprouvé, d’une interface intuitive (sous la forme d’un feuilletoir numérique) et de la possibilité de visionner les 412 pages et quelque 130 enluminures à l’aide d’un puissant zoom, a remporté l’adhésion enthousiaste du public qui a rarement l’occasion d’appréhender un aussi magnifique manuscrit médiéval.

      En 2022, le feuilletoir devient donc web responsive (accessible sur smartphone, tablette ou pc ) et surtout il est accessible à chacun, en tout lieu connecté.

      L’internaute peut aisément comprendre la structure du livre, le contenu des textes, le sens des images grâce à des textes focus clairs et discrets. Les commentaires peuvent être désactivés pour feuilleter le livre de manière autonome.

      L’application est facile d’appréhension, simple à utiliser, multilingue. Elle continuera à être mise à jour au fil des remarques des internautes et de l’avancée des recherches.

      « De quoi faire rayonner comme jamais les Très Riches Heures et aussi saluer leur découvreur et donateur, Henri d’Orléans, duc d’Aumale ! » se félicite le musée de Condé.

    • Les Très Riches Heures du Duc de Berry | Communication Arts
      https://www.commarts.com/webpicks/les-tres-riches-heures-du-duc-de-berry

      As part of the renovation of the library of the Château de Chantilly, where the manuscript is kept, we took the opportunity to create mediation and presentation tools that equaled the work of art’s mastery. As part of a vast program that included a digital photography campaign, a digital leaflet and interactive installation by experiential interactive design studio Mosquito at the Château, this website by Mosquito and digital design studio 23FORWARD puts a multilingual version of the Très Riches Heures installation on the web.

  • En juin 2021, nous avons livré avec Mosquito une table interactive pour présenter le Concorde au musée de l’Air et de l’Espace du Bourget.

    https://vimeo.com/512931837

    L’interface principale est une vue 3D en temps réel, que l’on peut manipuler, du Concorde. Le rendu est aussi réaliste que possible. Des hotspots dans l’espace permettent de déclencher des compléments d’information, avec animations 3D precalculées.

    Évidemment c’est du #HTML5 motorisé par #SPIP. C’est le premier projet que j’ai réalisé entièrement en 3D avec A-Frame, et beaucoup de réglages et d’essais pour trouver les bons formats de fichier et les bons réglages d’éclairages pour obtenir un rendu satisfaisant du Concorde.

    #shameless_autopromo

  • Je suis très en retard sur mes #shameless_autopromo

    En mai 2021, avec Mosquito, on a livré une table interactive présentant la collection de maquettes du XIXe siècle de l’Amiral Pâris, au musée de la Marine de Port-Louis, en face de Lorient :

    https://vimeo.com/552374272

    Évidemment c’est du #HTML5 sous #SPIP. L’originalité ici, c’est que l’interface principale de consultation est en 3D sous A-Frame.

    Comme le résultat a bien plu, le musée nous a demandé de réaliser une déclinaison pour le Web :
    https://musee-marine-multimedia.fr/paris

    C’est la même base que la table tactile, mais avec un jeu de squelettes adaptés pour être responsive (même si le smartphone n’est pas forcément le support idéal).

  • 2022 s’annonce plutôt bien du côté du #CSS ! 🥳🥳🥳

    Quelqu’un a déjà testé les color-function() ?
    https://www.bram.us/2021/12/27/css-in-2022/#the-hotlist--color-functions

    Quand ce sera bien opérationnel, ça me facilitera beaucoup les choses avec la personnalisation qu’on propose à nos clients.

    J’espère aussi que les #viewport units mettront fin aux soucis #Safari sur #smartphone
    https://www.bram.us/2021/12/27/css-in-2022/#the-hotlist--viewport-units

    Vous avez repéré quoi en particulier ?

    #integration #integrationWeb #ui #HTML #responsive #variables

  • Le #no-code, nouveau sésame pour les non-initiés à la #programmation  ?

    Le mouvement no-code est devenu en trois ans une vraie alternative à la programmation. Des solutions comme #Bubble, #Webflow, #Airtable, #Glide permettent de créer un #site_web ou une #appli_mobile sans pour autant être un développeur confirmé.

    En gros,

    Cette nouvelle méthode va aider à décharger ces ingénieurs de l’écriture de codes à faible valeur ajoutée, une tâche qu’ils considèrent comme ingrate et qu’ils ont tendance à saboter.

    https://usbeketrica.com/fr/article/le-no-code-nouveau-sesame-pour-les-non-inities-a-la-programmation

    donc ils créent des outils à « forte valeur » ajoutée pour que les utilisateurs et utilisatrices finales sabotent eux-même leur code, c’est ça ? Car j’ai du mal à croire que des applis #wysiwyg produisent un code aussi propre qu’un être humain qualifié. Sans parler de l’accompagnement.

    Bref, c’est encore une fois sur le marché lowcost que ça tire vers le bas...

    #développement #webdev (no-)#html #no_code

    • Toujours cette idée de nouveauté qu’elle est neuve et que c’est un nouveau sésame… C’est juste qu’on en a toujours bouffé sur le Web de ces promesses avec Dreamweaver, Director, Flash… depuis les années 90.

      Un aspect vraiment flippant de ces trucs, c’est qu’on continue de fabriquer des jeunes professionnels dont on a encouragé l’incompétence informatique, et qui vont en chier toute leur vie dans des boulots de merde où il n’y a pas d’argent à gagner.

      30 ans après, on continue à fabriquer des graphistes, designers, photographes… fiers d’avoir une maîtrise totalement superficielle de leurs outils informatiques. Des gens qui ensuite se lancent sur le marché en étant à la fois moins efficaces et moins « innovants » (y compris sur leur cœur de métier, c’est-à-dire les créations graphiques et visuelles) que leurs concurrents, et vont dépendre de prestataires informatiques qui vont la leur faire à l’envers systématiquement.

      L’impossibilité de défendre ton boulot, parce qu’il est toujours plus ou moins approximatif/amateur au moment du rendu, et les clients seront souvent insatisfaits, parce que la fin de la prestation est toujours bordélique (ça marche pas, ça marche pas bien, personne ne sait pourquoi parce que personne n’a la moindre compétence…). Donc végéter dans des petits boulots mal rémunérés et peu gratifiants.

      Et évidemment l’impossibilité de survivre quand le seul logiciel Wysiwyg que tu maîtrises disparaît (le massacre quand Flash a disparu, le massacre quand ton client peut s’acheter pour 5 dollars un template tout fait et que tu ne peux proposer rigoureusement aucune valeur ajoutée par rapport à ça…).

      Ça fait 30 ans que je vois passer des gens qui galèrent parce qu’on leur a fait miroiter qu’ils pourraient devenir des professionnels avec des outils Wysiwyg, et qu’une fois sur le marché professionnel, c’est une catastrophe et ils sont cantonnés comme tu dis au low-cost, où il y aura toujours quelqu’un d’encore moins cher, et pas forcément plus incompétent (genre à se retrouver au bout de 5 ou 10 ans sur une « place de marché » en ligne en concurrence avec des boîtes low-cost installées en Inde).

  • Paged.js — About Paged.js
    https://www.pagedjs.org/about

    Paged.js is a free and open source JavaScript library that paginates content in the browser to create PDF output from any HTML content. This means you can design works for print (eg. books) using HTML and CSS!

    Une librairie javascript pour paginer le HTML pour générer du PDF « joli »

    – le repo Gitlab : https://gitlab.pagedmedia.org/tools/pagedjs
    – la documentation : https://www.pagedjs.org/documentation
    – les spécifications CSS « Paged Media Module Level 3 » supportées : https://www.pagedjs.org/documentation/cheatsheet
    – une étude de cas complète pour la création/mise en page d’un livre : https://polylogue.org/apres-la-page-la-double-page
    – rendu testable sur https://printcss.live

    #Pagedjs #pagination #générateur_PDF #PDF #javascript

  • Cartographie radicale - Nepthys ZWER, Philippe REKACEWICZ - Éditions La Découverte
    https://www.editionsladecouverte.fr/cartographie_radicale-9782373680539

    La première information que je retiens du livre est le fait qu’il est possible de se révolter contre la politique des géants du numérique.

    Prologue

    À l’orgiine de ce bouleversement, il y eut un « carambolage » historique et technique. À la fin des années 1980, deux sociétés américaines se partageaient l’essentiel du marché des logiciels de dessin vectoriel que les cartographes utilisaient pour la cartographie de presse et d’édition Adobe (Illustrator) et Macromedia (Freehand).

    Il existait quelques autres applications, beaucoup moins pratiques et performantes pour le design, utilisées surtout dans le monde de la recherche scientifique. Dès 1990, alors que l’essentiel des designers, cartographes, illustratrices et illustrateurs avaient adopté Adobe, nous avions fait te choix de numériser nos idées cartographiques » avec le logiciel Freehand, que nous trouvions plus ergonomique. Mais, en 2005, un accord fut signé entre les deux géants, et la société Adobe devint propriétaire du logiciel Freehand, auquel elle fit subir une lente agonie pour finalement le faire disparaître en 2008.

    Cela signifiait la perte d’années d’investissement et d’apprentissage et un retour à la case départ, avec la perspective de réinvestir du temps dans un apprentissage technique. Nous étions en colère d’être soudain victimes du phénomène que nous avions justement à coeur de cartographier : le grand jeu des fusions-acquisitions et ses conséquences désastreuses !

    Nous avons donc décidé de boycotter les produits Adobe, ce qui signifiait reprendre les crayons de couleur et le papier puisque, dans cette situation monopolistique, les alternatives étaient quasi inexistantes. C’est ainsi que nous avons redécouvert l’acte fondamental de la création cartographique : le dessin.

    Les personnes formées à la cartographie géographique avant l’avènement de l’ère du dessin numérique avaient déjà pris l’habitude de dessiner leurs icées cartographiques, de produire ce qu’il est convenu d’appeler ces « minutes » sous la forme d’esquisses, habitude perdue avec l’arrivée des écrans, des souris et des premières tablettes graphiques.

    Le retour aux crayons et au papier s’avérait finalement être un retour aux sources.

    Est-ce l’écriture « à la main » de code #HTML tel qu’on le pratiquait avec #SPIP constitue un résistance efficace ? Qu’est ce qu’il faudrait entreprendre pour rendre la maîtrise de sa ville au chauffeur de taxi désormais obligé par la loi de suivre les itinéraires imposés un système de navigation peu fiable ? Est-ce qu’on peut se servir partout de l’approche de Pièces et Main d’Oeuvre (@pmo) ? Comment faire que le progrès technologique serve à l’épanouissement de la personne ? Où est-ce que le retour au technonologies anciennes devient réactionnaire ? Où est-ce que le progrès nous rend vulnérables ?

    Je pense qu’il faudrait poser ces questions dans tous les domains dont nous sommes experts tout autant que là où nous avons besoin de reconquérir du terrain perdu dans les batailles du passé.

    P.S. Voici la traduction allemande de l’extrait.

    Prolog

    Die Ursache für diesen Umbruch war ein historischer und technischer „Unfall“. Ende der 1980er Jahre teilten sich zwei amerikanische Unternehmen den größten Teil des Marktes für Vektorzeichensoftware, die von Kartographen für die Druck- und Verlagskartographie verwendet wurde: Adobe (Illustrator) und Macromedia (Freehand).

    Es gab noch einige andere, weitaus weniger praktische und leistungsfähige Anwendungen für Design, die hauptsächlich in der Welt der wissenschaftlichen Forschung eingesetzt wurden. Bereits 1990, als die meisten Designer, Kartographen und Illustratoren auf Adobe umgestiegen waren, entschieden wir uns dafür, unsere kartographischen Ideen mit Freehand zu digitalisieren, da wir dies ergonomischer fanden. Aber 2005 wurde ein Vertrag zwischen den beiden Giganten unterzeichnet. Der Adobe-Konzern wurde Eigentümer der Freehand-Software, und verordnete ihr eine langwierige Agonie, und liess sie schließlich im Jahr 2008 sterben.

    Dies bedeutete für uns den Verlust jahrelanger Investitionen und Lernprozesse und eine Rückkehr zum Startpunkt verbunden mit der Aussicht, erneut Zeit in technisches Lernen investieren zu müssen. Wir waren wütend darüber, dass wir plötzlich Opfer des Phänomens wurden, das wir zu kartieren versucht hatten: Das große Fusions- und Übernahmespiel und seine katastrophalen Folgen!

    Also beschlossen wir, die Produkte von Adobe zu boykottieren, was bedeutete, dass wir zu Papier und Buntstift zurückkehrten, da es nach der Machtübernahme durch die Monopole so gut wie keine Alternativen gab. Auf diese Weise haben wir den grundlegenden Akt der kartografischen Schöpfung wiederentdeckt: das Zeichnen.

    Diejenigen, die vor dem Aufkommen des digitalen Zeichnens in der geografischen Kartografie ausgebildet wurden, waren es gewöhnt, ihre kartografischen Ideen aufzuzeichnen, und sogenannte „Protokolle“ in Form von Skizzen anzufertigen. Diese Praxis ging mit dem Aufkommen von Bildschirmen, Mäusen und den ersten Grafiktabletts verloren.

    Die Rückkehr zu Papier und Bleistift erwies sich schließlich als Rückkehr zu den Wurzeln.

    @nepthys @reka #cartographie #technologie

  • Vizzu Library
    https://vizzuhq.com/index.html

    Vizzu is a free, open-source #Javascript/C++ library utilizing a generic #dataviz engine that generates many types of #charts and seamlessly animates between them. It can be used to create static charts but more importantly it is designed for building animated data stories and interactive explorers as Vizzu enables showing different perspectives of the data that the viewers can easily follow due to the animation.

    Main features:

    – Designed with animation in focus;
    – Defaults based on data visualization guidelines;
    – Automatic data aggregation & data filtering;
    #HTML5 #canvas rendering;
    – Written in C++ compiled to WebAssembly;
    – Dependency-free.

    Via @fil sur github

  • Brython
    https://brython.info

    Brython is designed to replace Javascript as the scripting language for the Web. As such, it is a #Python 3 implementation (you can take it for a test drive through a web console), adapted to the #HTML5 environment, that is to say with an interface to the #DOM objects and events.

    Du python dans le navigateur...

    <html>
    <head>
       <meta charset="utf-8">
       <script type="text/javascript"
           src="https://cdn.jsdelivr.net/npm/brython@3.9.5/brython.min.js">
       </script>
    </head>
    <body onload="brython()">
    <script type="text/python">
       from browser import document
       document <= "Hello !"
    </script>
    </body>
    </html>

    https://brython.info/static_tutorial/en/index.html

  • Recommandations pour l’#intégration d’e‑mails

    Ce document a pour but de présenter plusieurs principes que vous pouvez appliquer pour coder des e‑mails #HTML. Chaque recommandation est objectivement justifiée pour se conformer aux clients de messagerie modernes, et se dégrader gracieusement ailleurs.

    https://github.com/hteumeuleu/email-guidelines/tree/master/translations/fr-FR

    #email #template #intégration_web #web #bonnes_pratiques #guidelines