De temps en temps, je regarde, en priant, que le support SVG dans les navigateurs s'améliorent...
Et, c'est toujours la même chose, ou presque: il y a donc Opéra[1]
Et derrière, le reste : Adobe SVG Viewer(qui n'est plus supporté), Webkit[2], FireFox[3],... (pas forcement dans le bon ordre)
J'espère que quelqu'un ici pourra parler du support d'Amaya et de Bantik, car pour ma part, je me suis arrêté à cette page[4].
D'ailleurs sur cette page, on s'aperçoit que pour faire du SVG un minimum compatible, ça va être la lutte (avec des bons gros hacks !)
Voilà, qu'il y a un an environ, un nouveau projet arrive svgweb[5] et le but de ce projet est de faire... du SVG dans du flash.
Ce projet avance vite et marche bien en plus. Mais ressemble, pour moi, à ce qui est le paroxysme de la débilité du web !
Je ne dis pas ça, contre ce projet, qui je pense à le mérite de faire avancer les choses mais je trouve fou dans arriver là par un manque de cohérences et de concertations.
La norme doit dater de 2001, si je ne me trompe pas, et elle n'est toujours pas d'actualité dans nos navigateurs...
De plus, quand je vois qu'Inkscape fait son propre SVG[6] pour pouvoir intégrer des manques à la norme initiale, je me demande qu'elle est le futur du SVG.
Je voulais avoir votre avis et des éclaircissements.
[1] http://www.opera.com/docs/specs/svg/
[2] http://webkit.org/projects/svg/status.xml
[3] http://www.mozilla.org/projects/svg/status.html
[4] http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(S(...)
[5] http://code.google.com/p/svgweb/
[6] http://wiki.inkscape.org/wiki/index.php/InkscapeSVG
Journal Point sur le format SVG
12
déc.
2009
# http://www.codedread.com/svg-support-table.html
Posté par Sonny Piers . Évalué à 7.
[^] # Re: http://www.codedread.com/svg-support-table.html
Posté par skeespin (site web personnel) . Évalué à 2.
Et en plus il faut savoir que même dans les éléments valides (en vert), il y a des différences de rendus (notamment concernant les polices et les filtres) entre les différents moteurs.
J'aurais aimé avoir des retours sur la qualité des libs QtSvg[1], librsvg[2] ou AGG[3] ?
Et aussi si OpenVG[4] fait il vraiment avancer les choses dans ce domaine ?
[1] http://doc.trolltech.com/4.1/qtsvg.html#svg-support
[2] http://librsvg.sourceforge.net/docs/
[3] http://www.antigrain.com
[4] http://www.khronos.org/openvg/
# batik
Posté par wismerhill . Évalué à 2.
Tu peux voir là
http://xmlgraphics.apache.org/batik/status.html
l'état du support du SVG 1.1
[^] # Re: batik
Posté par skeespin (site web personnel) . Évalué à 1.
http://xmlgraphics.apache.org/batik/tools/browser.html
# W3C validator
Posté par viking1404 . Évalué à 4.
Il y a quelques temps je voulais me mettre au svg. Ne trouvant pas de documentation suffisante sur le net j'ai acheté le livre SVG de la collection O'REILLY.
Et bien même avec le livre je me suis bien embêté pour rendre ma pauvre page valide xhtml1.1 strict ! Je ne sais pas ce que ça donne avec l'html 5 et ses nouvelles balises.
# svgweb
Posté par yohann gabory (site web personnel) . Évalué à -2.
Pour ceux qui ont la flemme de lire , l'idée de svgweb est de traduire ton svg en flash pour les navigateurs qui ne supportent pas le svg ( ou mal)
[^] # Re: svgweb
Posté par Samuel (site web personnel) . Évalué à 8.
Par ailleurs, si on traduit le svg en flash, « TOUS » les navigateurs ne supportent pas les svg : seuls ceux sur lequel est installé un plugin flash peuvent l'utiliser.
Perso, je préfère une image SVG (que je peux lire) à une animation flash (que je ne peux visualiser).
[^] # Re: svgweb
Posté par B16F4RV4RD1N . Évalué à 3.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: svgweb
Posté par yohann gabory (site web personnel) . Évalué à 6.
le but du projet n'est pas, comme l'indique le journal de faire du svg dans du flash mais de permettre l'adoption de svg dans le web .
Suit un peu mon raisonnement, puis-je en tant que webdéveloppeur me permettre d'intégrer une technologie supportée par Un seul navigateur ? Donc pour faire de l'animation, je vais me tourner vers une autre technologie (flash par exemple) qui bénéficie d'une assise suffisante en terme de % utilisateurs.
SVGweb me permet d'intégrer du svg dans mes sites et de profiter du flash quand (et seulement quand) le support svg du navigateur est nul ou mauvais.
Je ne trouve pas que c'est la "débilité du web" c'est du pragmatisme et ça me permet de faire du SVG dès maintenant.
Enfin, et c'est justement le but de ce genre de bibliothèque, plus il y aura de site svg, plus les navigateurs tendrons à le supporter, et le supporter de mieux en mieux.
quand à inkscape, en lisant le lien donné par le journal on trouve :
standards-conforming (the SVG standard permits these kinds of extensions)
(donc on reste standard)
inkscape svg is basically the same as plain svg, just with a couple of extra commands (in seperate namespaces) added, which the inkscape tools use to keep track of their work.
donc très clairement un espace de nom pour la tambouille inkscape, pas un "nouveau svg",
c'est standard, c'est autorisé par la norme, on peut même s'en passer, on peut l'ouvrir dans un autre éditeur sans modification de l'affichage.
De plus, le but d'inkscape est clairement indiqué dans le roadmap (http://wiki.inkscape.org/wiki/index.php/Roadmap#Inkscape_Dev(...)
Inkscape 1.00 - Full SVG 1.1 support
Le but d'inkscape est donc d'être 100% standard.
alors quand je lit : De plus, quand je vois qu'Inkscape fait son propre SVG
c'est de la mauvaise foi ou du moquage de bouche
[^] # Re: svgweb
Posté par B16F4RV4RD1N . Évalué à 2.
je pense que l'auteur n'a pas bien lu le lien qu'il pointait (vu qu'il semble par ailleurs favorable au svg), et honnêtement, étant utilisateur de inkscape, je pensais également que le format svg d'inkscape était beaucoup plus modifié que cela (j'ai découvert que ce n'est pas le cas justement en lisant ce lien). Donc c'est plutôt une bonne nouvelle, par contre c'est vrai que, comme j'ai dit dans un autre commentaire (dans le journal sur sozi), même dans les divers projets libres d'éditeurs svg, à l'époque où j'en avais testé plusieurs, il y avait de grosses différences d'interprétations d'un éditeur à l'autre. (peut-être que cela s'est lissé maintenant, mais je n'ai pas retesté, utilisant principalement inkscape)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: svgweb
Posté par KiKouN . Évalué à 1.
Par exemple: une spirale, il n'y pas de norme dans le SVG permettant de faire une spirale d'après des données mathématiques et la spirale apparait comme un chemin dans un svg. Inkscape rajoute dans le svg ces données permettant ainsi de rééditer facilement la spirale par la suite. On se retrouve donc avec un svg avec le chemin de la spirale et les données permettant de la modifiée facilement.
Le problème intervient quand un autre éditeur modifie le SVG. Doit-on lire le chemin de spirale ou les données mathématique pour déssiner la spirale dans inkscape ?
Je rappelle que inkscape enregistre par défaut dans ce format mais propose aussi d'exporter dans un SVG standard.
# Oh non !
Posté par Batchyx . Évalué à -9.
J'veux bien croire que ça puisse être utile, mais au final ça va être comme flash, ça va être complètement inutile dans 99% des cas ou c'est utilisé, mais il faudra quand même se le farcir puisqu'il restera toujours des sites webs incontournables qui seront inutilisable avec SVG désactivé, vu qu'ils seront codés par des développeurs idiots qui ne pensent qu'a eux ...
Et puis je vois vraiment pas pourquoi il faudrai du vectoriel sur le net, y a déjà plus de la moitié des sites webs qui n'ont même pas de design liquide, alors à quoi ça sert d'avoir du vectoriel avec une taille fixe ?
J'espère pas avoir besoin un jour d'un plugin SVGBlock, mais si ça deviens nécessaire, je suis prêt à la coder si ça n'existe pas déjà.
[^] # Re: Oh non !
Posté par barmic . Évalué à 6.
Pour l'animer c'est du javascript, là aussi on utilise du javascript de puis 15 ans sur le web et même si c'est souvent à tord et à travers c'est régulièrement utile.
Pour ce qui est de l'utilité du SVG c'est très simple. Quand tu génère des images de manière automatique tu peut faire de manière très simple pour du SVG. Prenons le cas de mozilla. Lors de la sortis d'un logiciel ils créent des dizaines de versions d'une même image avec juste la langue qui change pour mettre sur leur site. Avec SVG tu peut changer dynamiquement le texte de manière simple.
Autre utilisation c'est bien sur google, avec google map quand tu demande un itinéraire le tracé est dessiné en SVG pour les navigateurs compatibles (en un autre format vectoriel pour IE d'ailleurs).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oh non !
Posté par thedude . Évalué à 4.
Et c'est pas parce que flash est binaire et svg texte que le deuxieme va etre un foudre de guerre.
SVG utilise pour faire ce que fait flash aujourd'hui, a savoir des applis riches, ca va faire pareil que flash a ton cpu: ca va monter dans les tours tres vite.
Parce que de toutes facons, c'est manipule via le meme langage (ou sensiblement le meme), javascript. et que ca sera le meme genre de code qui tournera, donc ya pas de raison que svg soit magiquement 10x plus rapide, sachant qu'adobe a deja fait un travail plus que raisonnable sur sa vm AS.
Bref, l'avantage c'est que ca sera ouvert, mais d'un point de vue perf, meme combat.
[^] # Re: Oh non !
Posté par Brioche4012 (site web personnel) . Évalué à 2.
La norme SVG prévoit qu'il soit animé, mais pas par javascript uniquement. Actuellement, la seule maniere d'animer du svg est de modifier le xml dynamiquement en javascipt (beurk) parce que les programmeurs des navigateurs oueb ne se sont pas sorti les doigts du cul, mais ça peut être implémenté en C ou n'importe quoi d'autre.
En respectant les balises, ça permettrait aussi de compiler l'animation juste a temps, comme ce qui commence à se faire avec javascript, et gagner énormément en performances.
L'ultime problème est qu'on ne peut pas encore facilement faire d'animations en SVG. Mais Inkscape prévoit la création d'animations dans quelques versions. Alors gageons que ce sera une autre paire de manches!
[^] # Re: Oh non !
Posté par yohann gabory (site web personnel) . Évalué à 3.
[^] # Re: Oh non !
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 4.
Sinon niveau "ça rame" il va y avoir bientôt les CSS transitions et animations, créées par webkit et bientôt dans gecko et Opera. J'espère qu'on pourra désactiver ça parce que ça promet d'être relou...
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Oh non !
Posté par thedude . Évalué à 1.
Et qu'est ce que tu crois que le player flash fait, si ce n'est du jit? Et ca bouffe du cpu.
Quand a l'implementer en C, c'est un peu a l'oppose de la philosophie du web, bon courage pour deployer ton anim svg...
[^] # Re: Oh non !
Posté par Batchyx . Évalué à 2.
le SVG c'est du vectoriel, et le vectoriel, c'est lent, tout comme flash. Tu trouve peut être super le fait d'avoir des freezes quand on va sur google maps (ou dès que quelqu'un inclut un google maps quelque part), mais moi pas, surtout sur une config moyenne de maintenant. Faudrai peut être se demander pourquoi flashblock existe. En tout cas il existera un svgblock quand demain toutes les pubs soient en SVG animé et quand ça sera la mode des menus, des bandeaux et des smileys en SVG animé. Faudra pas venir parler d'informatique verte après.
Quand à javascript, il existe depuis 15 ans, mais il aura fallu combien de temps avant qu'on se soucie de son optimisation ? Quand Ajax est (re)devenu à la mode, les PC d'entrée de gamme étaient tous à la ramasse, avec une navigation pas du tout fluide, tout ça pour soit disant "améliorer la navigation".
C'est sur, ça peut être utile, mais dans le cas du texte qui change c'est pas le cas. On n'a pas besoin de vectoriel juste pour pouvoir changer du texte, on peux déjà le faire avec du bitmap des grands mères et du CSS de grand père, c'est peut être moins simple, mais ça marche mieux avec les vieux navigateurs (et les smartphones, accessoirement). Et franchement, je m'appellerait mozilla, je commencerai déjà par faire un site web utilisable quand on zoome le texte avant de m'amuser a mettre du vectoriel dans un bloc de taille fixée en pixels.
[^] # Re: Oh non !
Posté par barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oh non !
Posté par yohann gabory (site web personnel) . Évalué à 2.
Le svg ce n'est que du xml et si c'est sa force, c'est aussi sa faiblesse puisque le logiciel visionneur doit ( aretez moi si je me trompe ) se palucher tous les calculs. Donc plus un SVG contiens de nœud (et une police en contient beaucoup) plus il faut solliciter le proc. Après, si tu me met un svg à 12 millions de nœuds (c'est un exemple) mon navigateur va s'écrouler comme une m...
Mais c'est aussi un faux procès : critique t'on le C parce que mal optimisé il peut mettre à genoux mon ordi ? Il y aura de mauvaises utilisations de svg dans le web et d'autres très belles, les utilisateurs trancherons.
[^] # Re: Oh non !
Posté par barmic . Évalué à 4.
Faire un site en flash est une très mauvaise habitude et ça ne seras pas mieux en SVG. Ce sont des parties du site qui doivent être faites en SVG.
Comme tout technologie il faut savoir l'utiliser avec parcimonie et réfléchir à son utilisation à chaque fois.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oh non !
Posté par Batchyx . Évalué à 2.
[^] # Re: Oh non !
Posté par barmic . Évalué à 3.
le premier fixe est à base de Celeron 441 2.6GHz (c'est du mono core sans hyperthreading)
le second est un MSI Wind de la première génération (atom 270 donc 1.6GHz avec hyperthreading)
Ben sur mon PC fixe ça bronche pas je dirais même qu'il met arrivé d'utiliser des « dock » avec du SVG de partout sans aucun souci.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# 2001
Posté par barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Encore combien de temps ?
Posté par Mat (site web personnel) . Évalué à 2.
Sauf que voilà, ça fait des plombes que ce format existe, et que ce n'est toujours pas répandu.
En 2005, juste après mes études, j'ai bossé sur un projet qui consistait à automatiser la production des pages web du budget de l'État : http://www.performance-publique.gouv.fr/farandole/2010/pap.h(...)
Dans ces pages vous pouvez constater :
* que le rendu est moche (c'est du .doc converti en html)
* que c'est compliqué de trouver quelque chose
* que c'est très hétéroclite
* et que c'est dépourvu de graphiques
Pour les 3 premiers points, rien à voir avec le SVG. Concernant le dernier, j'en suis le premier désolé.
Jeune et fou que j'étais, j'avais développé une extension à la bibliothèque JFreeChart [1] qui faisait en sorte de convertir les graphiques en svg grâce à Batik [2] (dont il est question dans ce journal) en les rendant interactifs avec du javascript.
Par exemple, lorsque l'on passait la souris devant une portion d'un camembert, celle-ci s'agrandissait, et on pouvait cliquer dessus pour se rendre sur la page correspondant au détail.
Ça marchait bien dans firefox et dans ie grâce à Adobe SVG Viewer (qui était encore maintenu, mais qu'il fallait installer comme plugin)
J'avais naïvement espéré contribuer à l'essor de SVG.
Sauf qu'aucun graphique n'a jamais été produit sur le site, ou alors avec autre chose que ma lib. Pourtant je vais vérifier presque tous les ans... Je me suis renseigné après coup, on m'a évasivement répondu qu'ils craignaient que ce ne soit pas lisible par les navigateurs, et voulaient s'épargner la maintenance sur ce point là.
Aujourd'hui je ne peux que me dire qu'ils ont eu raison de ne pas se compliquer la vie avec, vu que c'est encore moins bien supporté dans ie (qui reste malgré tout le navigateur le plus représenté), et c'est supporté de manière non déterministe sur les autres.
C'était il y a 4 ans, et j'ai l'impression que dans les navigateurs, la balise canvas évolue beaucoup plus vite alors qu'elle est arrivée bien après.
[1] http://www.jfree.org/jfreechart/
[2] http://xmlgraphics.apache.org/batik/
[^] # Re: Encore combien de temps ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
Faut pas confondre document et API. http://ljouanneau.com/blog/post/2009/03/26/Differences-entre(...)
De plus, canvas avance plus vite, normal, ce n'est qu'une surface de rendu avec des primitives graphiques de base. Absolument rien à voir avec la spec de SVG qui fait plusieurs centaines de pages. (et donc plus longue et plus complexe à implémenter).
[^] # Re: Encore combien de temps ?
Posté par Mat (site web personnel) . Évalué à 2.
Ce n'était peut être pas bien mis en avant dans mon commentaire précédent, mais pour les charts tu peux les réaliser avec svg ou avec canvas, et dans les 2 cas les rendre interactifs.
Pour l'utilisateur final, il n'y a pas de différence.
[^] # Re: Encore combien de temps ?
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 4.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.