Super l’idée d’une taxe, hein ? Elle va financer les photographes, les auteurs, vous croyez ?
Non ! Elle va financer les comités d’ayants-droits (comme d’habitude) et tuer les photographes et les auteurs, vu que Google refusera dès-lors d’indexer leurs sites (puisqu’il leur faudra payer).
Les photographes (comme tous les sites web qui l’autorisent) profitent gratuitement de l’indexation de votre site par Google, non ?
Et bah la gratuité, c’est du vol, selon les ayants-droits !
Ils préfèrent payer Google pour être dans l’index du site le plus visité au monde ?
Ce député et les ayants-droits prouvent encore une fois qu’ils n’ont rien compris à Google et à internet.
Le problème c’est que les internautes n’ont jamais appris (n’ont jamais été éduqué à ça, en fait) à citer leur sources et à vérifier que la source est exploitable et sous quelles conditions (de la simple citation à la rémunération), y compris pour les images et n’importe quel média. Faut peut-être débuter par là, non ?
La solution ? Si vous êtes un internaute ou un éditeur de site web comme moi, sachez que certains photographes publient toute ou partie de leurs créations sous une licence permissive (Creative Commons, généralement) qui autorise leur réutilisation gratuitement, y compris parfois pour un usage commercial. Tout ce qui est demandé, c’est de citer l’auteur et de faire un lien : c’est ce que je fais dans tous mes articles, vu que je n’aurais jamais les moyens de payer des images non-gratuites, mon blog ne me rapportant rien financièrement.
Les tickets de train ou de concerts qui sont à imprimer chez soi, c’est pratique (quand ils ne sont pas surtaxés). Par contre ils sont souvent bourrés de publicité, ce qui est moche et surtout finit par coûter cher en encre déjà cher.
Ceci avait d’ailleurs agacé un sénateur qui avait demandé au gouvernement de faire quelque chose. Malheureusement, ce dernier, voyant là quelque chose de pratique pour le con-sommateur, a décidé de ne rien faire (ce qui est peut-être mieux : ils auraient pu empirer la situation).
Il y a quand même un moyen de virer cette publicité à la con : éditer le PDF avant de l’imprimer.
Pour cela, vous pouvez utiliser la suite Libre Office (anciennement OpenOffice.org) et son éditeur Draw (logiciel libre et gratuit, pour Windows, Mac et Linux).
Draw peut en effet éditer les PDF et je vais vous montrer comment faire.
Je prends ici l’exemple d’un e-billet de la SNCF (ou de Capitain-Train, peu importe), mais ça doit marcher avec toute sorte de billet, et même avec toute sorte de fichiers PDF.
Premièrement, commencez par ouvrir le PDF avec LibreOffice Draw :
Ensuite, sélectionnez à la souris d’un coup toute la partie contenant la publicité. N’hésitez pas à sélectionner de façon très large : il faut que les éléments soient bien dans la sélection :
Relâchez la souris une fois la zone de publicité sélectionnée. Il suffit maintenant de supprimer tout ça avec la touche « Suppr » du clavier et le tour est joué :
Pour finir, il faut exporter le document modifié au format PDF, avec le bouton prévu à cet effet, et de l’enregistrer sous le nom que vous voulez.
Voilà, votre billet de train est désormais imprimable sans aucune pub.
Pour aller plus loin, vous pouvez supprimer les couleurs, ajouter des notes à vous (trajet, adresses, etc.), mais conservez bien le flashcode et les informations du trajet.
Ce que je fais en plus bien souvent c’est que j’ouvre à la fois le billet aller et celui de retour, et que je met les deux billets sur une seule feuille (en sélectionnant tout le haut du billet de retour et en le copiant-collant à la place de la pub sur le billet de l’aller).
Autrement, vous pouvez toujours commencer par imprimer la page et éteindre l’imprimante (ou annuler l’impression) une fois que la partie utile est imprimé et avant que la publicité ne soit encore sur la feuille. C’est moins propre, mais ça marche.
Je viens de mettre en ligne la dernière version majeure de Blogotext. Elle est disponible sur sa page habituelle.
La charte graphique de Blogotext 3 est complètement refondue pour un style Google Material.
C’est le design utilisé par Google dans ses applications Android, mais aussi dans Android lui-même et la plupart de ses sites web.
Si j’ai choisit ce thème, c’est que je le trouve particulièrement pratique et joli, à la fois sur un mobile et sur ordinateur.
J’ai respecté au mieux les recommandations de Google pour ce thème, tout en l’adaptant pour convenir à Blogotext (tous les cas n’étant pas étudiés dans les recommandations).
Bien que les spécifications du Material Design soient faites par Google, Blogotext ne contacte à aucun moment leurs serveurs et tous les fichiers sont dans l’archive (polices, icônes…).
Ce n’est pas la seule nouveauté, bien-sûr : j’ai corrigé un grand nombre de bogues, un peu partout et j’ai refondu partiellement la gestion des fichiers & images ainsi que le lecteur RSS.
Concernant la compatibilité CSS, Blogotext 3 est compatible avec Firefox, Chrome, Opera 15+, Vivaldi. Microsoft Edge / IE11 sont compatibles hormis le glisser-déposer des fichiers. Les versions mobiles de Chrome, Opera et Firefox fonctionnent également sans soucis avec un thème entièrement responsive.
Au niveau du serveur, il faut toujours PHP 5.3 minimum ainsi que quelques bibliothèques particulières (listées ici).
Les anciens thèmes pour Blogotext devraient fonctionner sans problèmes. Consultez tout de même la note de version si vous mettez à jour depuis une version 2.x.
Dans la création de pages web, on lit souvent qu’il faut mettre les fichiers CSS dans head, au début du document HTML et qu’il faut mettre le JavaScript à la fin. Bien rarement par contre il est dit pourquoi.
Schématisation en 3D des éléments d’une page web.
Lors du processus d’affichage d’une page web, la première phase consiste au téléchargement de la page web : le document HTML ainsi que les images, mais aussi les feuilles CSS de styles et les scripts JS liés.
Le contenu HTML, c’est ce qu’on voit : le texte, les images, les champs de recherche, etc. Les styles CSS, c’est comment le HTML sera vu : disposition, couleurs polices et taille du texte, couleur du fond de la page.
Le CSS et le HTML sont donc nécessaires à l’affichage de la page web et donc au visiteur qui souhaite lire votre site. Les scripts JS, en revanche, ce sont des instructions destinées au navigateur, pas à l’internaute. Le navigateur les traite en tâche de fond et l’utilisateur de voit pas de différence s’ils sont là où pas (normalement).
Le problème, c’est la capacité du JS de modifier le HTML et le CSS. Du coup, le navigateur qui reçoit une page HTML+CSS n’aura en réalité la totalité de la page web qu’une fois qu’il aura terminé d’exécuter les scripts JS. Avant cela, il ne peut (presque) rien faire : il va bien commencer à afficher les différents éléments de la page (menu, titres, liens…) mais si le JS supprime le menu entre temps, il devra tout recommencer.
La solution du navigateur pour le problème du JS ?
Commencer d’effectuer le rendu (l’affichage) de la page et mettre ce rendu en pause quand il détecte un script JS : à ce moment là, il doit télécharger tout le script JS et l’exécuter entièrement (ce qui a des chances de modifier le HTML et le CSS, souvenez-vous) avant de reprendre de rendu (et au besoin le recommencer, si le JS a beaucoup modifié le HTML ou le CSS).
Le fait pour le navigateur d’avoir à se mettre en pause lorsqu’il rencontre un script, nous fait dire que le JS est bloquant.
Le CSS, le HTML et même les images sont non-bloquant : le navigateur peut continuer à décoder la page web même quand il est encore en train de télécharger du CSS, par exemple. Il peut donc télécharger du CSS en parallèle avec le HTML. Une fois qu’il a tout le CSS, il commence le rendu tel qu’il est décrit par le CSS. Le décodage du HTML, lui, se poursuit durant tout ce temps.
Un document HTML simple, sans CSS ni JS, s’affiche quand même : c’est le rendu par défaut d’une page web : le fond est blanc, le texte est noir et tous les éléments sont à la suite les uns des autres. Bref, c’est moche, mais ça reste lisible.
Mon site tel qu’il s’affiche sans les styles CSS.
Le navigateur, quand il reçoit le document HTML, commence par effectuer le rendu par défaut. Lorsqu’il reçoit le CSS, ce rendu par défaut continu (de façon à ce que la page soit lisible — même si c’est moche). Le rendu par défaut est stoppé quand tout le CSS est arrivé : à ce moment là, c’est le rendu tel qu’il est décrit dans le CSS qui est appliqué : les couleurs, les fonds, les bordures, les ombres… tout ça est alors affiché. Le traitement du CSS ne bloque pas le téléchargement du reste du contenu de la page.
Pour l’instant je n’ai pas vraiment répondu à la question « pourquoi mettre le JS à la fin et le CSS au début ? », mais j’y viens.
On sait que l’affichage des données (texte, images…) dans la page web commence dès que le HTML est en train d’être téléchargé : ceci permet à l’internaute d’accéder à l’information contenue dans la page le plus rapidement possible, même si le CSS et le JS ne sont pas encore arrivés. Une fois que tout le CSS est obtenu, l’information est alors restructurée, organisée sur la page et coloriée.
Lorsque le navigateur reçoit un script JS, l’affichage est mis en pause : le JS doit finir de s’exécuter avant que l’affichage puisse continuer.
L’intérêt de placer le CSS en haut et le JS en bas se trouve à ce niveau.
Si on met le CSS en haut, c’est pour que l’affichage « colorié » se fasse le plus vite possible : pour que la page web soit « jolie » et « organisée » tout de suite, avant que l’utilisateur ne puisse se trouver face à une page web dans son rendu par défaut. Cela tombe d’ailleurs bien : le téléchargement du CSS n’est pas bloquant : l’information dans la page web continue d’arriver pendant ce temps : l’affichage de la page web n’est pas ralentie par le CSS. C’est juste mieux de l’avoir avant, pour que l’affichage se fasse directement comme la page doit être, sans à avoir un rendu par défaut entre-temps.
Parallèlement si on met le JS en bas du document, toute l’information contenue dans la page web sera déjà affichée (car déjà téléchargée et déjà rendue à l’écran). Au moment où le navigateur rencontre le JS, l’écran ne sera pas tout vide ni tout blanc : l’internaute pourra commencer à lire la page web pendant que le navigateur traite le script JS et effectue les derniers changements.
Si on mettait le JS tout en haut, la page n’aurait encore aucune donnée que l’affichage et le téléchargement seraient déjà bloqués : l’internaute n’aurait alors qu’une simple page blanche et rien à lire. Si le script est gros, cela peur prendre plusieurs secondes. Si ça ne semble pas long dit comme ça, croyez-moi, ça l’est : si toutes les pages web mettaient 2 secondes de plus pour s’afficher, vous le verriez très rapidement. Placer le JS en haut n’est donc pas génial, car il oblige le navigateur à tout mettre en pause et l’internaute à attendre devant une page vide.
Mettre le CSS en bas de la page n’est pas avantageux non plus : le CSS n’est pas bloquant. Il peut être téléchargé en parallèle avec le reste. Si on le met en bas de la page, il sera téléchargé en dernier et tout seul, donc sans tirer profit de la possibilité de télécharger deux choses en même temps. De plus, tout le document HTML sera déjà là mais affiché avec le rendu par défaut du navigateur, donc tout moche. Si l’internaute a déjà commencé à lire, il verrait alors la page se modifier sous ses yeux à l’instant même où tout le CSS aura fini de télécharger et que le rendu se fasse.
Il convient donc naturellement de mettre le CSS le plus tôt possible dans la page (dans le head) pour tirer profit du téléchargement en parallèle du CSS avec d’autres ressources et pour que le rendu se fasse directement de façon voulue ; et il faut placer le JS en bas du document pour que quand le navigateur le trouve, tout le reste de la page soit déjà affiché à l’écran et que l’internaute puisse commencer à lire votre page pendant le traitement du script JS par le navigateur en tâche de fond.
Je ne comprends toujours pas en quoi utiliser mon téléphone ou mon ordinateur justifie que je donne de l’argent pour France 3. Ça n’a aucun sens.
Est-ce qu’un éleveur d’oies touche de l’argent grâce à un impôt sur les perceuses ? Non. Alors qu’ils aillent se faire foutre avec leur « extension de la redevance ». Internet n’est pas la télé.
S’ils veulent faire payer ça, soit ils mettent un abonnement équivalent à la redevance sur un sorte de Netflix pour les chaînes publique (la télé en somme, où payent ceux qui veulent, donc comme maintenant), soit qu’ils incluent un impôt pour tous les foyers, sans dire que c’est spécifiquement pour l’audiovisuel public.
Après tout, y a pas non plus de « redevance éclairage public » ou « redevance espaces verts », pour lesquelles ont serait exonéré si on ne sortait jamais la nuit où si on n’entraient jamais dans un parc.
Mais mettre un impôt sur les ordis pour financer la télé, c’est juste débile.
C’est de nouveau en débat :