Journal JS dans linuxfr ?

Posté par . Licence CC by-sa.
Tags : aucun
1
30
août
2019

Salut à tous,

J'aimerais faire des dépêches avec un contenu animé interactif sur linuxfr.

Pour cela j'utilise Sozi. Il est déjà possible d'utiliser des images svg, sur le site. Je trouve que cela serait une très bonne chose de pouvoir exécuter le JS de sozi de manière, d'une part à promouvoir ce logiciel vraiment sympa et d'autre part d'avoir un contenu vraiment sympa.

Si vous voulez voir ce que cela donne, vous pouvez aller voir
3D Tomographic case | YaDICs
, cliquez sur la figure en dessous de "3D correlation diagram"

Je pense que cela permettrait des contenus de très haute valeur ajoutée sur ce site. En tout cas, personnellement j'en ferais très bon usage.

J'imagine qu'il y a des risque de sécurités qui sont effrayant, mais ne pensez vous pas que cela vaille le coup ?

Cela me permettrait de finir ma vielle dépêche en très peu de temps, car framapic ayant fermé, j'ai perdu toutes mes images …tout refaire pour gérer l'aspect interactif via des gifs, ne me motive pas trop, j'en ai pour une journée de taf, et je ne l'ai pas en ce moment …

  • # Peut-être, seulement pour les dépêches

    Posté par . Évalué à 5. Dernière modification le 30/08/19 à 18:48.

    Je pense qu’on peut limiter les dégâts si on ne permet d’utiliser JavaScript (et du HTML / CSS arbitraire, tant qu'à faire) que sur les dépêches (qui sont relues et modérées), et avec activation par un clic. Là, je n’y vois aucun inconvénient, autre qu’il faudra des modérateurs capables et ayant le temps de réviser le code, pourvu qu’un maximum de choses continuent à fonctionner sans, et que pour la plupart des contenus, on puisse comprendre sans.

    Les journaux et entrées de forum n’étant pas modérés à priori, ça ne me paraît pas être une bonne idée de permettre d’utiliser JavaScript là.

    Une proportion non nulle de visiteurs du site bloquent JavaScript par défaut¹, il faut que ces gens se rendent compte qu’ils doivent activer JavaScript s’ils veulent voir le contenu.

    Si vous voulez voir ce que cela donne, vous pouvez aller voir ici cliquez sur la figure en dessous de "3D correlation diagram"

    Ah, il manque un lien ?

    • [^] # Re: Peut-être, seulement pour les dépêches

      Posté par (page perso) . Évalué à 1.

      Une proportion non nulle de visiteurs du site bloquent JavaScript par défaut

      C'et la rentrée, les bonnes habitudes et le pifomètre reviennent ! :-)

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Peut-être, seulement pour les dépêches

        Posté par . Évalué à 8.

        Salut :)

        C'et la rentrée, les bonnes habitudes et le pifomètre reviennent ! :-)

        Môssieur,

        La pifométrie est très bien définie, normalisée même, dirais-je à vue de nez.

        Alors je crois que vous vous mettez le doigt dans l'oeil en supposant qu'elle est partie en vacances.

        Pour preuve, de mon côté, 0 filtres javascripts. En extrapolant, il en reste toujours 0.

        Bien cordialement,

        _kaos_

      • [^] # Re: Peut-être, seulement pour les dépêches

        Posté par . Évalué à 3.

        J'en ai fait partie à un moment, donc j'aurais pu affirmer avec exactitude qu'il y a une proportion non nulle de gens bloquant JavaScript sur LinuxFR. Ce n'est plus le cas cependant (le site est strictement meilleur avec JavaScript), mais du coup je ne peux plus rien affirmer :-)

    • [^] # Re: Peut-être, seulement pour les dépêches

      Posté par . Évalué à 2.

      Oui, je suis d'accord avec toi, juste pour les dépêche, cela suffit. Comme cela demande pas mal de temps à faire, les introduire dans un travail structuré comme une dépêche, serait l'idéal, et permettrait au modérateurs de valider. C'est un bon compromis.

      Tu peux aller sur ce site et voir les "cases".

      Le copier/coller ne suffit pas …

    • [^] # Re: Peut-être, seulement pour les dépêches

      Posté par (page perso) . Évalué à 3.

      autre qu’il faudra des modérateurs capables et ayant le temps de réviser le code, pourvu qu’un maximum de choses continuent à fonctionner sans, et que pour la plupart des contenus, on puisse comprendre sans.

      Outre que le fait que tous les membres de l'équipe de modération ne sont pas capables de faire le boulot, ça va ralentir la parution des dépêches. Cela fait donc deux gros inconvénients supplémentaires.

      OS préféré Mageia 6 et Mageia 7, CMS préféré SPIP, suite bureautique préférée LibreOffice, logiciel de dessin préféré Inkscape.

      • [^] # Re: Peut-être, seulement pour les dépêches

        Posté par . Évalué à 3.

        C'est vrai, mais ça ne ralentirait la parution que des dépêches utilisant le JS, pas des autres, donc si je le fais j'en accepte les règles, non ?

        • [^] # Re: Peut-être, seulement pour les dépêches

          Posté par . Évalué à 6.

          ça ne ralentirait la parution que des dépêches utilisant le JS, pas des autres,

          Ah bon ? C'est amusant ton raisonnement. Globalement, a moins d'ajouter un modérateur qui sera dédié à la modération de ces dépèches, l'ensemble de l'édition des dépèches sera ralentie par le surplus de travail.

          • [^] # Re: Peut-être, seulement pour les dépêches

            Posté par . Évalué à 1.

            Oui, tu as raison, mais on pourrait par exemple, déjà accepter le JS de sozi qui est un logiciel libre, cela permettrait de pouvoir l'utiliser.

            De la même manière mettre un iframe de site dont on sait que cela ne représente pas de dangers, youtube par exemple permettrait de mettre facilement des vidéos.

            Tout ça en respectant les standard du web. Après il suffit de devoir cliquer sur l'élément avec un message sur la dangerosité du JS, cela éviterait aux modérateurs de devoir analyser le code. Après il y a même des malware sur dans des images, du coup ou s'arrête la prudence …

            • [^] # Re: Peut-être, seulement pour les dépêches

              Posté par . Évalué à 1.

              Après il y a même des malware sur dans des images, du coup ou s'arrête la prudence …

              Attention que le lien qu tu as partagé parle de trojans qui lisent des commandes cachées dans des images (via stéganographie), pas d'exploit/payload dans des images (ça existe ?).

              • [^] # Re: Peut-être, seulement pour les dépêches

                Posté par (page perso) . Évalué à 4.

                pas d'exploit/payload dans des images (ça existe ?).

                Oui, il y a eu déjà plein de faille dans les libs qui décodent les différents formats d'image.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Peut-être, seulement pour les dépêches

              Posté par (page perso) . Évalué à 4.

              Oui, tu as raison, mais on pourrait par exemple, déjà accepter le JS de sozi qui est un logiciel libre, cela permettrait de pouvoir l'utiliser.

              Je n'ai pas regarder le js de sozi mais a priori, il permet de faire pas mal de modification, ce qui en fait un bon vecteur d'attaque.

              près il suffit de devoir cliquer sur l'élément avec un message sur la dangerosité du JS, cela éviterait aux modérateurs de devoir analyser le code.

              Si c'est pour mettre un warning "ne cliquez pas ici", je ne suis pas sûr que ce soit pertinent. Autant renvoyer sur un autre page.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Peut-être, seulement pour les dépêches

              Posté par (page perso) . Évalué à 9.

              De la même manière mettre un iframe de site dont on sait que cela ne représente pas de dangers, youtube par exemple permettrait de mettre facilement des vidéos.

              [NON]

              * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

  • # Mauvais exemple

    Posté par (page perso) . Évalué à 10.

    Si vous voulez voir ce que cela donne, vous pouvez aller voir ici
    cliquez sur la figure en dessous de "3D correlation diagram"

    Je suis allé à l'endroit que tu indiques (j'ai récupéré le lien dans la section du forum).
    J'ai cliqué là où tu dis.
    --> l'animation n'apporte strictement rien, et l'ergonomie est merdique

    Il faut un meilleur exemple :-)

    • [^] # Re: Mauvais exemple

      Posté par . Évalué à 4.

      Désolé, mais à part utiliser un CMS, je n'ai pas d'autres compétences. Donc je fais avec ce que j'ai.

      Je trouve que de proposer un schéma en vectoriel et pouvoir zoomer dessus est très intéressant.
      Mais en effet, les goûts et les couleurs …

      • [^] # Re: Mauvais exemple

        Posté par . Évalué à -2.

        Mais en effet, les goûts et les couleurs …

        Ici si tu écoutes l'esprit créatif des trolls, tu te retrouves avec un classeur A4.

        C'est pas mal l'idée des images vectorielles pour accompagner un article. On peut en faire des animations (dans le même genre que gif et flash) ?

        • [^] # Re: Mauvais exemple

          Posté par . Évalué à 2.

          oui, avec sozi

          tu fais ton pdf avec n'importe quel logiciel, et tu l'animes avec sozi.

        • [^] # Re: Mauvais exemple

          Posté par (page perso) . Évalué à 6.

          SVG permet de faire des animations sans recourir à des scripts et notamment sans JavaScript.

          Voir par exemple la page 404 que le projet ZeMarmot a contribué à GIMP y a des années déjà : https://www.gimp.org/jenesuispasla

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: Mauvais exemple

            Posté par . Évalué à 1.

            Wow c'est ce que je cherchais merci !

          • [^] # Re: Mauvais exemple

            Posté par . Évalué à 3.

            Et il y a des outils pour faire ça sans coder ?

            • [^] # Re: Mauvais exemple

              Posté par (page perso) . Évalué à 4.

              Pas en Libre, malheureusement, aux dernières nouvelles. Nous avons fait cette animation "à la dure", c'est à dire que les dessins sont faits dans Inkscape, mais sont animés en éditant ensuite le SVG dans un éditeur de texte.

              Bon ça fait quelques années, mais je n'ai entendu parler d'aucun logiciel libre qui ait ajouté la prise en charge du SVG animé depuis.

              Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

              • [^] # Re: Mauvais exemple

                Posté par . Évalué à 2.

                En plus j'ai l'impression, que de mettre en place des zoom sur un poster, via cette technique, risque d'être très difficile …

              • [^] # Re: Mauvais exemple

                Posté par (page perso) . Évalué à 3.

                Je vois qu'il existait un module pour synfig: https://wiki.synfig.org/Sif2svg

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Mauvais exemple

            Posté par (page perso) . Évalué à 9.

            Ton lien est mort : 404 file not found.

            • [^] # Re: Mauvais exemple

              Posté par (page perso) . Évalué à 4.

              J'hésite: est-ce une blague de ta part ou bien tu n'as pas bien lu mon commentaire?… 😛

              Bon au cas où, je tombe dans le piège quand même. Oui c'est normal, puisque comme je disais, c'est une animation en SVG visible seulement sur les pages en erreur 404 (a.k.a. liens morts). J'ai donc mis un lien vers une page qui n'existe pas exprès (note le nom de la page: https://www.gimp.org/jenesuispasla; j'aurais aussi bien pu donner: https://www.gimp.org/youplaboum) pour permettre aux gens de voir cette animation.

              Donc sur gimp.org, quand vous ouvrez n'importe quelle page en 404, vous verrez un petit Wilber (mascotte/logo de GIMP) qui marche jusqu'au milieu de page, et essaie d'ouvrir l'en-tête mais n'y parvient pas, et est alors dépité. 😢

              Ensuite peut-être ne vois-tu pas l'animation. Dans ce cas, je suppose que tu as un des rares navigateurs qui ne prend pas en charge les animations SMIL (c'est à dire soit Opera Mini, soit IE, les 2 seuls qui ne savent pas lire les SVGs animés en SMIL à ce jour, du moins d'après les infos trouvées, ou une version pas à jour d'un autre navigateur).

              Dernier cas: peut-être faisais-tu bien une blague et avais-tu bien compris que oui cette page est 404, et oui c'est normal, non c'était pas une erreur, car c'est bien ainsi qu'on peut voir notre SVG animé. 😃

              Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

              • [^] # Re: Mauvais exemple

                Posté par . Évalué à 2.

                Est-ce qu'il n'était pas question de déprécier le support SMIL de Chrome ? Ont-ils changé d'avis ?

                La raison était que CSS Animation saylfutur. Apparemment CSS Animations serait mieux supporté maintenant que SMIL ?

                • [^] # Re: Mauvais exemple

                  Posté par (page perso) . Évalué à 6.

                  La dépréciation de SMIL n'a pas fait long feu et a été annulée par Google. J'en parlais déjà dans un article linuxfr en 2016, comme quoi les rumeurs ont la vie dure et la moindre action un peu médiatisée peut porter sérieusement atteinte à la réputation d'un projet.

                  Donc non SMIL n'est pas dépréciée et a un fort support par tous les navigateurs majeurs de nos jours (c'est d'ailleurs marrant, car lors du retour de SMIL chez Google en 2016, les ingénieurs justifiaient leur vision surtout par la faible prise en charge; cet argument est clairement non recevable de nos jours).

                  Je ne suis pas toutes les évolutions en détails, donc je ne suis pas sûr si c'est toujours le cas, mais globalement le problème majeur avec les alternatives (du type animation par CSS) était qu'il n'était pas possible de faire tout ce qu'on pouvait faire avec CSS comparé à ce que SMIL proposait. Ceux qui essayaient donc de mettre CSS en avant le faisait en proposant une alternative moins performante, et par conséquent n'étaient finalement probablement pas eux-même des utilisateurs.

                  Personnellement j'apprécie surtout l'animation en SMIL pour les cas où je considère l'animation comme faisant partie intégrante de l'image. C'est par exemple le cas de notre petite animation 404 du site GIMP. C'est vraiment une petite animation auto-contenue. Elle ne réagit pas à des évènements particulier ou à une intéraction du visiteur. Elle joue quand on ouvre la page, c'est tout.
                  Et donc on peut télécharger cette animation en un fichier .svg unique que l'on peut ainsi rejouer en local par exemple. L'extension SMIL fait partie intégrante du fichier (c'est du XML contenu dans le SVG même). Si l'animation avait été gérée dans un fichier CSS séparé, en téléchargeant le SVG, non seulement je risque d'avoir un contenu tout autre à ce que je m'attends (avec des bouts d'images statiques, probablement dans des positions étranges), mais en plus je n'aurais pas dû tout les informations de timing et de mouvement.
                  J'apprécie donc que SMIL soit fait pour être intégré et qu'il permette d'avoir des animations tout en un. De la même façon que je pouvais télécharger un GIF animé, ou maintenant une animation WebP en un fichier, ou bien une vidéo, mon SVG est un seul fichier.

                  Note: on sait que CSS peut aussi être intégré dans le document XML, mais on sait aussi que ce n'est pas recommandé; CSS est vraiment destiné à la gestion du style d'un document dans un fichier séparé. Mais théoriquement, oui il est aussi possible d'intégrer le CSS pour faire une image vectorielle animée auto-contenue de cette manière. Je prends avance sur les possibles réponses qu'on pourrait me faire. Ahahah!

                  Je pense qu'il faut distinguer 2 types d'usage de SVG: SVG comme une image (ou image animée) et SVG comme un élément de markup.

                  1. Dans le premier cas, le SVG est son propre conteneur et n'intéragit pas vraiment avec le reste de la page. On peut d'ailleurs même l'utiliser dans une balise <img> et il n'y a alors aucune différence entre votre fichier SVG et toute image de type PNG ou JPEG (hormis que le SVG se redimensionnera sans perte de qualité). Pour un tel cas, je préfère clairement SMIL.

                  2. Dans le second cas, le SVG est du markup, au même titre que HTML. D'ailleurs on peut même intégrer le markup SVG à l'intérieur de la page HTML plutôt que dans son propre fichier, au besoin. On peut par exemple imaginer vouloir utiliser du SVG pour des éléments de menu ou d'interface de la page en général. On peut aussi vouloir animer ces menus vectoriels avec des règles CSS en fonction des clics du visiteur. Dans ce cas, très clairement, cela doit être fait en CSS (je ne suis même pas sûr que ce soit faisable en SMIL d'ailleurs). Ce ne sont clairement pas des animations en tant qu'animation, mais des animations pour styler des éléments de contenu. On pourrait d'ailleurs imaginer retirer ce CSS sans casser la page, ou bien le changer pour un CSS personnel (ce que les gens sur linuxfr font pas mal!). Ne pas oublier une règle du CSS bien fait: le CSS est fait pour styler un contenu, pas pour être le contenu; donc le contenu doit être lisible et utilisable même sans CSS! C'est clairement le cas pour un CSS qui animerait des éléments d'interface, par exemple des fondus, juste pour faire joli par exemple (cette animation est totalement superflue et n'est pas utile en soi; le menu est juste une liste de liens qui doit pouvoir marcher sans joli design et sans animation).

                  Par contre dans le cas d'une animation dont le seul but est l'animation elle-même (comme dans notre page 404): retirer les règles de l'animation enlève tout intérêt au fichier.

                  Donc non SMIL est encore bien vivant, et a une très bonne prise en charge (entre SMIL et CSS animation, le seul navigateur qui prend en charge CSS animation et pas SMIL est apparemment IE, or le développement de IE est abandonné et même Microsoft en déconseille l'utilisation). Et j'espère bien que ça continuera ainsi. 😃

                  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

  • # Sécurité, accessibilité, légèreté

    Posté par (page perso) . Évalué à 10.

    Linuxfr est un des rares sites non pollués du web. C'est bien qu'il reste ainsi. Si tu veux proposer du contenu différent, pourquoi ne pas héberger la partie js ailleurs et faire un lien ?

    Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Sécurité, accessibilité, légèreté

      Posté par . Évalué à 3.

      Oui, c'est évidemment une bonne solution, cependant elle ne permet pas une lecture continue. Dans un processus didactique, il est important de pouvoir associer du texte au contenu graphique.

      Je me doutais bien qu'il y aurait une majorité de gens qui ne verrait pas cela d'un bon œil, mais je pensais intéressant d'expliquer un cas d'usage qui pourrait illustrer mon propos, et tâter le terrain sur cette idée.

      Est-ce qu'on ne pourrait pas faire un sondage ?

    • [^] # Re: Sécurité, accessibilité, légèreté

      Posté par . Évalué à 3.

      Linuxfr est un des rares sites non pollués du web.

      D'un autre côté, serait-ce étonnant de voir la même fonctionnalité sur LinuxFR que sur plnkr ? (qui permet de partager des exemples de codes avec affichage du résultat (exemple))

      • [^] # Re: Sécurité, accessibilité, légèreté

        Posté par . Évalué à 4.

        D'un autre côté, serait-ce étonnant de voir la même fonctionnalité sur LinuxFR que sur plnkr ?

        Pourquoi faire ?

        • [^] # Re: Sécurité, accessibilité, légèreté

          Posté par . Évalué à 2. Dernière modification le 31/08/19 à 13:58.

          Pourquoi faire ?

          Faciliter le partage de code par l'exemple, la vulgarisation, etc ?
          Après j'ai l'impression que la communauté LinuxFR est déchirée entre d'un côté les étudiants/professionnels et de l'autre les passionnés, qui ont des attentes et envies différentes.

          • [^] # Re: Sécurité, accessibilité, légèreté

            Posté par . Évalué à 3.

            La question que je me pose c'est si réellement la raison d'être de linuxfr est de partager du code. Même si le partage de code sur linuxfr est intéressant, est-ce que ça ne constituerait pas un cout de travail important par rapport au peu de code qui serait partagé ? Je ne dis pas qu'il ne faut pas le faire, simplement que ce serait peut-être beaucoup d'investissement pour une fonctionnalité secondaire du site (a moins que je n'ai pas compris ce que tu veux dire par "partage de code").

            • [^] # Re: Sécurité, accessibilité, légèreté

              Posté par . Évalué à 2. Dernière modification le 31/08/19 à 17:12.

              Je ne dis pas qu'il faudrait cette fonctionnalité, mais que c'est une feature qui ne serait pas disruptive au vu de ce que l'on fait sur LinuxFR.

              Les débats sur le typage dans les langages auraient une autre tronche; peut-être même qu'au lieu de TapTempo on aurait eu des Tétris, jouable par les non-initiés à la programmation (et encore moins à la compilation de 42 langages) 😋

              La question que je me pose c'est si réellement la raison d'être de linuxfr est de partager du code.

              Mon humble point de vue est que LinuxFR est un réseau social. Partant de là, offrir des features capable d'assouvir les besoins de la communauté semble logique.
              Attention, je ne prétends pas connaître les features "qui seraient bien", mais suis étonné qu'il n'y en ai pas plus. (et je trouve dommage parce ca t'oblige à aller sur Reddit, Git[hub|lab], Discorde, qui sont des réseaux sociaux concurrents qui risquent de grignoter "les parts de marché" de LinuxFR)

  • # Heu

    Posté par . Évalué à 8.

    framapic ayant fermé

    ? non.

    • [^] # Re: Heu

      Posté par . Évalué à 3.

      Ha, ok, j'avais lu à une époque qu'ils avaient fermé ce service, my bad.

      Après, j'ai mis trop de temps à finir la dépêche, c'est ma faute. Ceci dit, j'ai les animations, mais pas le temps pour les convertir en gif, trop de taf.

      Cela ne change rien, que pour une présentation de sozi, cela pourrait être cool d'avoir une dépêche qui lui permette de l'utiliser.

  • # lien manquant

    Posté par . Évalué à 2.

    Est-ce qu'un modérateur pourrait rajouter ce lien dans le ici ?

  • # suivi ?

    Posté par . Évalué à 1.

    Il y a une rubrique "suivi" pour ce type de sujets.

  • # Haha j'adore

    Posté par . Évalué à 10.

    J'imagine qu'il y a des risque de sécurités qui sont effrayant, mais ne pensez vous pas que cela vaille le coup ?

    Ça c'est la ligne de dialogue qu'on entend au début de tous les bons vieux nanars de films catastrophe, généralement prononcée par un type très sûr de lui. Et ça marche toujours aussi bien !

    splash!

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.