Javascript dans les jeux : pour ou contre ?

[Caribou]

Ah trop cool merci pour les liens, parce que moi le CSS déjà que je maitrise à peine, alors gérer different explorateur ça devient vite casse-pieds, quand j'ai lu "hack" evidemment ça m'a interessé, toute forme de hack est interessante

Je vais me bookmark tout ça quand je vais attaquer plus serieusement mes feuilles de style, parce que pour l'instant c'est tout batard avec des styles pour chaque page et encore des style="" a certains endroits lol

[TeKRunneR]

Je crois que personne n'en a parlé jusqu'à présent, mais pour moi une des raisons pour lequelles il est très important de faire du JavaScript non-obstrusif (ou bien de laisser la possibilité à l'utilisateur de choisir une interface sans JavaScript, à la manière de gmail), c'est que les anciens navigateurs et ceux installés sur les mobiles ne sont pas les seuls à avoir beaucoup de mal avec le JavaScript : les systèmes de synthèse vocale utilisés par les malvoyants ont encore plus de difficulté.

Alors bon c'est clair que les malvoyants ne composent pas un gros pourcentage des internautes (et c'est sans doute renforcé par le fait que peu de sites leur sont adaptés). Mais autant un gars qui désactive le JavaScript volontairement c'est vrai que c'est un peu tant pis pour lui, autant le malvoyant il a pas le choix, si personne a pensé à lui il l'a profond et il peut rien y faire.

[Mysterarts]

Effectivement, "honte" à nous d'avoir omis ce point, auquel s'attache pourtant énormément le W3C !
J'accorde personnellement de l'importance à cela dans les quelques sites que j'ai fais, (à caractère informatif, descriptif ou explicatif), MAIS dans un jeu en ligne.... désolé, mais il est beaucoup trop compliqué pour la plupart des projets de les rendre accessibles aux malvoyants : imaginez : entre une interface remplis de ressources, de jauges, de cartes etc... et un simple article explicatif : il y a différence !! Croyez bien que j'en suis désolé...

Mysterarts

[Plume]

Erreur ami du soir. Je sais que j'ai été l'un des premiers à parler de ça, maintenant effectivement j'ai peut être omis pour une fois d'en parler sur ce topic. Pour ceux qui se souviennent de certains coups de gueules poussés notamment au niveau du respect de certaines normes que notre consortium préféré s'entête à imposer. Alors ceux qui gueulent, parce qu'on fait chier à déblatérer nos arguments pour le respect des normes, je les .. Bref :motus:

@ tchaOo°

[Plume]

Coucou ^^

Il y a des vérités, mais je pense surtout qu'il faut bien avouer que - dans la majorité des cas - on ne pense pas à développer un jeu pour des personnes qui ont un quelconque handicap, donc à partir je suis même pas sûr qu'on soit en "droit" d'évoquer ces personnes pour argumenter le fait que JS c'est à bannir.
D'ailleurs, ça m'intéresserait de voir un jeu qui est jouable par n'importe qui.

@ tchaOo°

[Anthor]

Personnellement pour éviter les problèmes d'incompatibilité CSS entre les différents navigateurs, j'inclu toujours dans ma feuille de style ces définitions, elles permettent de remettre à zéro les différences de propriétés entre les navigateurs.

Code :

/* Pas de marqueurs de listes, puisque qu'ils sont principalement utilisés pour la sémantique, ils est plus simple de remettre une nouvelle classe aux listes */
ul,ol { list-style:none }

/* On supprime les tailles de polices différentes suivants les navigateurs */
h1,h2,h3,h4,h5,h6,pre,code { font-size:1em; }

/* Suppression de tous les paddings et margins qui sont différents par defaut sur les navigateurs */
ul,ol,li,h1,h2,h3,h4,h5,h6,
pre,form,body,html,blockquote,
fieldset,input,p,dl,dt,dd
{ margin:0; padding:0 }

/* On remet à zéro le line-height */
h1,h2,h3,h4,h5,h6,p {
  line-height: 1.2em;
}

/* On peut mettre une marge par defaut pour différencier les paragraphes, elle devient donc la même sous tous les navigateurs */
p { margin: 10px; }

/* On supprime les bordures bleu sous IE... C'est très laid */
a img,:link img,:visited img { border:none }

Concernant le CSS et le Javascript, il faut bien comprendre qu'ils n'ont pas du tout le même rôle, le CSS permet de mettre en forme la structure xhtml, et le javascript permet entre autre de travailler sur les propriétés CSS des différents éléments.

Le javascript permet dans tous les cas d'optimiser les ressources serveurs, notamment grâce à l'utilisation d'AJAX en récupérant uniquement une petite partie de l'information sur le serveur php, et en la traitant directement chez le client, notamment grâce aux réponses formatter en XML ou JSON qui permettent de passer simplement des instructions ou des variables de php à javascript.
Pour rendre ce code javascript non obstrusif, il faut recharger entièrement la page, traiter l'information, pour enfin recompiler et envoyer la page complète à l'utilisateur.
Les deux fonctions sont exactement les mêmes et seul la façon de les traiter diffère.

Pour ma part, je pars toujours du principe que la page est codée normalement, un clic pour se déplacer renvoi vers la page en prenant en compte l'action du déplacement, puis une fois codée cette page, je lui ajoute la "couche" javascript qui va permettre à 90% des utilisateurs de me faire économiser des ressources et lui de gagner un temps de rechargement plus court, et bien plus dynamique pour son expérience.

Le javascript ne doit pas se substituer aux calculs des pages, il doit juste les rendre plus dynamiques et mieux optimisés, afin de minimiser ces rechargement.

Evidemment cela implique de coder deux fois l'action mais cela permet d'avoir un code qui reste compatible dans toutes les situations.

L'exemple de plus concret reste la validation javascript des formulaires, elles permettent de ne pas recharger la page et donc de gagner gloablement 5-6 requêtes, en laissant au choix l'utilisateur de calculer lui même si le formulaire a lieu d'être envoyé. Mais cette utilisation implique quand même de vérifier le formulaire côté serveur. Puisuqe les données envoyés ne sont jamais sûres à 100%.

En partant de ce principe on arrive facilement à faire des sites qui sont toujours compatibles quel que soit la configuration du client, et qui optimise les ressources du serveur.

Il ne faut juste jamais oublier que la couche javascript ne se substitue pas à la couche php, elle permet juste de rendre l'utilisation client plus agréable. Chaque langage possède une utilisation qui lui est propre, il ne faut pas les substituer mais les faire cohabiter.

[Sephi-Chan]

Personnellement, je suis contre l'utilisation d'une feuille de remise à niveau, d'autant qu'elle est incomplète. Tu ne changes pas grand chose à l'affichage du contenu des balise <pre>, par exemple. De même pour les styles prédéfinis des balises d'emphase (em) et d'insistance (strong).

La seule règle CSS supplémentaire que j'applique toujours, c'est la mise à zéro des marges :

Code :

* {
    margin: 0;
    padding: 0;
}

Concernant Javascript, je suis en grande partie d'accord, notamment sur la mise en place par surcouche.

Les avantages de Javascripts sont indéniables, surtout quand on voit que faire du code compatible n'est pas bien difficile, surtout avec un peu d'expérience (comme le CSS en fait). Par exemple et comme tu l'as dis, citons la vérification de formulaires qui permet de faire en sorte que la majorité des utilisateurs qui remplissent mal un formulaire soient avertis par Javascript.

Au sujet d'AJAX, sa mise en place n'est pas toujours avantageuse. Je veux dire par là qu'il ne faut pas tomber dans l'abus : il ne faut pas vouloir charger le contenu sur demande tout le temps, il peut être préférable de charger une grande quantité de contenu et d'utiliser Javascript pour jouer sur l'affichage sur demande et ainsi simuler le comportement typiquement utilisé avec AJAX.


Sephi-Chan

[Anthor]

Au passage, CSS Zen Garden est très joli c'est vrai, mais pas du tout adapté à la réalisation d'un site dynamique (les titres sont données sous forme d'image).

Les titres restent, le contenu change pour la majorité des jeux (ex de titre : le village, les ressources, rapport d'attaque/de défense, ...)
et puis, avec GD, on peut créer des images dynamiquement (genre, une nouvelle ville aparait, on sauve le nom de la ville avec une police spéciale dans une image

Pour pallier à ce problème, je laisse tous mes titres sur des balises de h2 à h6 (h1 étant reservé à l'entête du site), puis j'ajoute une couche javascript qui modifie ces balises par une image généré par php ( + système de cache ). De cette manière Google et les client n'utilisant pas Javascript peuvent lire le texte en brut alors que le client disposant de javascript verra une image ayant généré le texte avec un police spécifique.

Code :

<script type="text/javascript" src="_js/jquery.js"></script>
<script type="text/javascript">
$(document).ready(function() {
// Titre H2
    $("h2").each(function () {
        $(this).replaceWith("<img src='/_inc/img_h2.php?title="+$(this).html()+"' style='display:block' />");
    });
});
</script>

On pourrait récupérer aussi la largeur de la balise pour générer un fichier faisant la bonne largeur en passant une deuxième variable vers le fichier php.

[Anthor]

Personnellement, je suis contre l'utilisation d'une feuille de remise à niveau, d'autant qu'elle est incomplète. Tu ne changes pas grand chose à l'affichage du contenu des balise <pre>, par exemple. De même pour les styles prédéfinis des balises d'emphase (em) et d'insistance (strong).

La seule règle CSS supplémentaire que j'applique toujours, c'est la mise à zéro des marges :

Code :

* {
    margin: 0;
    padding: 0;
}

Mon but comme je l'ai dit n'est pas de tout mettre a zéro pour les mettre à zéro comme tu le fais, mais de remettre à des valeurs par défaut, des éléments de structure. Seules les balises connus pour poser des problèmes entres les différents navigateurs m'intéressent. Je laisse les balises sémantiques au cas par cas suivant le design du site.
Les balises sémantiques ne déforment par la façon globale dont le site s'affiche, et n'empêche pas non plus l'affichage correcte suivant les navigateurs.

Je préfère laisser les marges par défaut des propriétés servant à la sémantique car si elles sont en retrait c'est qu'il y a une raison pour ça, chaque balise possède sa propre utilité.

Grâce à cette technique, je garde l'affichage par défaut des navigateurs tout en ayant une structure qui fonctionne sur ie6/7, opera et Firefox, sans nécessité de hack dans 95% des cas.

[Sephi-Chan]

Je préfère laisser les marges par défaut des propriétés servant à la sémantique car si elles sont en retrait c'est qu'il y a une raison pour ça, chaque balise possède sa propre utilité.

Tu penses à quelle balise en particulier ?

Pour ma part, je n'ai presque aucun problème à intégrer des design, les incompatibilité qui peuvent exister sont souvent mineures. En fait, développer un site valide contribue beaucoup à sa compatibilité, et le recours aux hacks sont finalement assez rares.


Sephi-Chan