Donc ton framework JS qui gère les liens à sa sauce est capable de savoir que j'ai réglé mon navigateur pour que les liens & formulaires d'un domaine donné s'ouvrent tous dans le même onglet? Les liens <a> qu'il va ajouter se comporteront normalement, ok, mais les liens que le framework va "piloter" à sa sauce suivront la bonne règle (aka, celle donnée par l'utilisateur)? Ou genre si je configure les liens vers des images pour qu'elles s'ouvrent dans ma visionneuse habituelle, le framework JS le saura?
Oui, je me focalise sur le problème de la navigation parce que c'est la question de ce topic. Et oui, "les jeux font tous eux-même dans une page à leur sauce", c'est un peu le soucis: la navigation dans le jeu est dictée par le jeu au lieu d'être du ressort du navigateur.
Si on prend l'exemple de DVO (je n'y suis plus mais bon), il ne me semble pas possible d'ouvrir, par exemple, les "pop-in" dans de nouveaux onglets. Ou de faire un "précédent" dans une pop-in. Parce que le site fait les choses à sa sauce JS (franchement, c'est pas le pire).
• Non, ils ne sont pas caduques, mais il me semble que les SDK de dev de jeux hors-navigateur sont plus récents que les technos/frameworks que t'as cité... Donc je ne comprends pas cet argument?!
• T'as le droit, j'ai jamais dit le contraire. Seulement, d'un point de vue d'utilisateur, je trouve cela ch*ant de devoir "réapprendre" à naviguer à chaque site que je visite
• Pour bien des jeux "à formulaires/tableaux", oui, cela convient et c'est adapté. Pour ces jeux qui veulent tout piloter dans leur frame, j'en doute...
• C'est vrai: pourquoi utiliser Inkscape pour dessiner quand on sait coder du SVG/XML... Il me semble aussi avoir vu passer l'argument "quand on fait soit-même des AJAX, le monopage est pourri mais il ne l'est pas quand on apprend le framework 'bidule'" : donc ceux ne connaissant pas déjà ces frameworks devraient plutôt apprendre à utiliser ces SDK plutôt que les frameworks?
• Ca, t'es pas obligé de le faire dans un navigateur: c'est la différence entre un jeu par navigateur (qui s'exécute dans le navigateur) et un jeu par internet (qui utilise le réseau internet). Ton jeu fait par SDK peut très bien se mettre à jour tout seul, et tu te retrouves juste avec un hébergement web statique (cool, c'est moins cher en plus!) hébergeant les ressources du jeu.
Oui, je me focalise sur le problème de la navigation parce que c'est la question de ce topic. Et oui, "les jeux font tous eux-même dans une page à leur sauce", c'est un peu le soucis: la navigation dans le jeu est dictée par le jeu au lieu d'être du ressort du navigateur.
Si on prend l'exemple de DVO (je n'y suis plus mais bon), il ne me semble pas possible d'ouvrir, par exemple, les "pop-in" dans de nouveaux onglets. Ou de faire un "précédent" dans une pop-in. Parce que le site fait les choses à sa sauce JS (franchement, c'est pas le pire).
• Non, ils ne sont pas caduques, mais il me semble que les SDK de dev de jeux hors-navigateur sont plus récents que les technos/frameworks que t'as cité... Donc je ne comprends pas cet argument?!
• T'as le droit, j'ai jamais dit le contraire. Seulement, d'un point de vue d'utilisateur, je trouve cela ch*ant de devoir "réapprendre" à naviguer à chaque site que je visite
• Pour bien des jeux "à formulaires/tableaux", oui, cela convient et c'est adapté. Pour ces jeux qui veulent tout piloter dans leur frame, j'en doute...
• C'est vrai: pourquoi utiliser Inkscape pour dessiner quand on sait coder du SVG/XML... Il me semble aussi avoir vu passer l'argument "quand on fait soit-même des AJAX, le monopage est pourri mais il ne l'est pas quand on apprend le framework 'bidule'" : donc ceux ne connaissant pas déjà ces frameworks devraient plutôt apprendre à utiliser ces SDK plutôt que les frameworks?
• Ca, t'es pas obligé de le faire dans un navigateur: c'est la différence entre un jeu par navigateur (qui s'exécute dans le navigateur) et un jeu par internet (qui utilise le réseau internet). Ton jeu fait par SDK peut très bien se mettre à jour tout seul, et tu te retrouves juste avec un hébergement web statique (cool, c'est moins cher en plus!) hébergeant les ressources du jeu.