Petite info récupérée sur le web via mon butineur préféré :
" La version 1.0 de son navigateur remporte déjà un énorme succès, mais
la Fondation Mozilla ne compte pas s'arrêter en si bon chemin. Ainsi, la
version 1.1 de FireFox devrait sortir en mars prochain. Il s'agira pour
la communauté du libre de disposer d'un logiciel amélioré, corrigé des
quelques bugs répertoriés dans la version 1.0. Cependant, aucune
nouvelle fonctionnalité ne devrait être ajoutée au navigateur.
Les fans de FireFox peuvent obtenir plus d'informations sur cette future
version sur le site (en anglais) :
Parce que quand c'est un plugin, tu ne peux pas le mélanger avec toutes les autres technologies XML gérées par le navigateur...
Fabrice Bonny
Xavier Robin wrote:
Euh... que veux-tu dire ? Que tu n'as jamais du télécharger le plugin Flash ? Qui n'a jamais pesté au départ contre un site qui nécessitait Flash ?
Il y a eu une course à la mise à jour mais si Flash n'avait pas été livré avec MSIE, il n'aurait sans doute pas décoller.
Et celui-là c'est Real qui est en train de se l'approprier. On voit déjà plein (façon de parler) de fichiers SMIL encapsulés dans des fichiers ..rm et les protocoles real (rstp ou un truc du genre) qui font qu'il est obligatoire de passer par Real pour les lire.
Rien n'empêche les développeurs d'être un peu moins couillons et de faire de vrais fichiers SMIL. Real Player et son pendant GPL Helix Player savent les lire, non?
Si un standard ouvert passe par un plugin, c'est parce qu'il n'a pas été implémenté dans le navigateur, pas parce qu'il est fondamentalement différent de n'importe quelle autre standard. On pourrait très bien imaginer un plugin CSS pour les navigateurs ne le supportant pas. Mais ça n'aurait aucun sens vu que les navigateurs le supportent pas trop mal.
Disons que mon approche est plus pragmatique. Si Mozilla, Opera ou Safari supportent SVG en natif tant mieux, mais tant que MSIE ne le comprendra pas, le format restera dans les cartons. Et avant que MSIE bouge, tous les éditeurs auront tous eu le temps de faire un plugin. :-(
-- Fabrice Bonny
http://openweb.eu.org/ http://opquast.org/
Xavier Robin wrote:
Euh... que veux-tu dire ? Que tu n'as jamais du télécharger le plugin
Flash ? Qui n'a jamais pesté au départ contre un site qui nécessitait
Flash ?
Il y a eu une course à la mise à jour mais si Flash n'avait pas été
livré avec MSIE, il n'aurait sans doute pas décoller.
Et celui-là c'est Real qui est en train de se l'approprier. On voit déjà
plein (façon de parler) de fichiers SMIL encapsulés dans des fichiers
..rm et les protocoles real (rstp ou un truc du genre) qui font qu'il
est obligatoire de passer par Real pour les lire.
Rien n'empêche les développeurs d'être un peu moins couillons et de
faire de vrais fichiers SMIL. Real Player et son pendant GPL Helix
Player savent les lire, non?
Si un standard ouvert passe par un plugin, c'est parce qu'il n'a pas été
implémenté dans le navigateur, pas parce qu'il est fondamentalement
différent de n'importe quelle autre standard. On pourrait très bien
imaginer un plugin CSS pour les navigateurs ne le supportant pas. Mais
ça n'aurait aucun sens vu que les navigateurs le supportent pas trop mal.
Disons que mon approche est plus pragmatique. Si Mozilla, Opera ou
Safari supportent SVG en natif tant mieux, mais tant que MSIE ne le
comprendra pas, le format restera dans les cartons. Et avant que MSIE
bouge, tous les éditeurs auront tous eu le temps de faire un plugin. :-(
Euh... que veux-tu dire ? Que tu n'as jamais du télécharger le plugin Flash ? Qui n'a jamais pesté au départ contre un site qui nécessitait Flash ?
Il y a eu une course à la mise à jour mais si Flash n'avait pas été livré avec MSIE, il n'aurait sans doute pas décoller.
Et celui-là c'est Real qui est en train de se l'approprier. On voit déjà plein (façon de parler) de fichiers SMIL encapsulés dans des fichiers ..rm et les protocoles real (rstp ou un truc du genre) qui font qu'il est obligatoire de passer par Real pour les lire.
Rien n'empêche les développeurs d'être un peu moins couillons et de faire de vrais fichiers SMIL. Real Player et son pendant GPL Helix Player savent les lire, non?
Si un standard ouvert passe par un plugin, c'est parce qu'il n'a pas été implémenté dans le navigateur, pas parce qu'il est fondamentalement différent de n'importe quelle autre standard. On pourrait très bien imaginer un plugin CSS pour les navigateurs ne le supportant pas. Mais ça n'aurait aucun sens vu que les navigateurs le supportent pas trop mal.
Disons que mon approche est plus pragmatique. Si Mozilla, Opera ou Safari supportent SVG en natif tant mieux, mais tant que MSIE ne le comprendra pas, le format restera dans les cartons. Et avant que MSIE bouge, tous les éditeurs auront tous eu le temps de faire un plugin. :-(
-- Fabrice Bonny
http://openweb.eu.org/ http://opquast.org/
Fabrice Bonny
Pierre Goiffon wrote:
??? Et pourquoi donc ?
Je suis très étonné qu'un membre du petit club de ceux qui ont compris la différence XHTML/HTML demande ça... ;-)
Imaginons que je veuille mettre du SVG direct dans ma page (disons pour ne pas dissocier un texte et un graphique via 2 fichiers). En XHTML, je peux via des namespaces faire un ilot SVG directement dans le code:
<h3>Un joli graphique</h3> <svg:...>
Ce serait supporté par une implémentation native, pas par un plugin.
-- Fabrice Bonny
http://openweb.eu.org/ http://opquast.org/
Pierre Goiffon wrote:
???
Et pourquoi donc ?
Je suis très étonné qu'un membre du petit club de ceux qui ont compris
la différence XHTML/HTML demande ça... ;-)
Imaginons que je veuille mettre du SVG direct dans ma page (disons pour
ne pas dissocier un texte et un graphique via 2 fichiers). En XHTML, je
peux via des namespaces faire un ilot SVG directement dans le code:
<h3>Un joli graphique</h3>
<svg:...>
Ce serait supporté par une implémentation native, pas par un plugin.
Je suis très étonné qu'un membre du petit club de ceux qui ont compris la différence XHTML/HTML demande ça... ;-)
Imaginons que je veuille mettre du SVG direct dans ma page (disons pour ne pas dissocier un texte et un graphique via 2 fichiers). En XHTML, je peux via des namespaces faire un ilot SVG directement dans le code:
<h3>Un joli graphique</h3> <svg:...>
Ce serait supporté par une implémentation native, pas par un plugin.
-- Fabrice Bonny
http://openweb.eu.org/ http://opquast.org/
Pierre Goiffon
"Fabrice Bonny" a écrit dans le message de news:41aa466c$0$10775$
??? Et pourquoi donc ?
Imaginons que je veuille mettre du SVG direct dans ma page (disons pour ne pas dissocier un texte et un graphique via 2 fichiers). En XHTML, je peux via des namespaces faire un ilot SVG directement dans le code:
<h3>Un joli graphique</h3> <svg:...>
Ce serait supporté par une implémentation native, pas par un plugin.
Oh, OK, un plugin n'utilise que ce qu'il y a dans <object> Merci à tous les 2 de la précision
"Fabrice Bonny" <fbonny@club-internet.fr> a écrit dans le message de
news:41aa466c$0$10775$7a628cd7@news.club-internet.fr
???
Et pourquoi donc ?
Imaginons que je veuille mettre du SVG direct dans ma page (disons
pour ne pas dissocier un texte et un graphique via 2 fichiers). En
XHTML, je peux via des namespaces faire un ilot SVG directement dans
le code:
<h3>Un joli graphique</h3>
<svg:...>
Ce serait supporté par une implémentation native, pas par un plugin.
Oh, OK, un plugin n'utilise que ce qu'il y a dans <object>
Merci à tous les 2 de la précision
"Fabrice Bonny" a écrit dans le message de news:41aa466c$0$10775$
??? Et pourquoi donc ?
Imaginons que je veuille mettre du SVG direct dans ma page (disons pour ne pas dissocier un texte et un graphique via 2 fichiers). En XHTML, je peux via des namespaces faire un ilot SVG directement dans le code:
<h3>Un joli graphique</h3> <svg:...>
Ce serait supporté par une implémentation native, pas par un plugin.
Oh, OK, un plugin n'utilise que ce qu'il y a dans <object> Merci à tous les 2 de la précision
