[Web adaptatif] Quel type choisir ?

[@lucard]

le troisième type ?

Plus sérieusement, à l'heure actuelle, on doit être à au moins 40% des internautes qui utilisent le webmobile en France...

Le façonnage du web s'en est donc trouvé assez chamboulé ces dernière années.
exit les dimensions standards des écrans, et la conception "facile" des sites web.

Le responsive design est devenu un incontournable pour les nouveaux sites, quitte même à en faire trop !?

Cette discussion/débat sera donc sur le web adaptatif (nom français),

quel type de Frameworks utilisez-vous et pourquoi ?
quels sont les avantages-inconvénients ?

bootstrop ? Foundation, Gumby, Skeleton, ou simplement du flex css ?

Dans votre cas, l'adapteriez-vous à votre jeuweb ?
ou simplement pour vos site perso/perso.

j'avoue ne pas connaitre du tout.
et je me baserais sur vos réponses pour commencer à apprendre.
Merci de vos futures réponses.
=)

[niahoo]

Pero j'utilise bootstrap ou semantic.gs.

Pour toute appli web je fais du responsive au maximum, sans me prendre la tête. C'est tellement relou de naviger via mobile sur les sites qui n'en tiennent pas compte.

Pour un jeu type "déclaration d'impôts online" a.k.a "je remplis des formulaires avec des chiffres en guise de gameplay" ça me paraît indispensable.

Pour un jeu un peu plus animé, je dirais qu'il faut soit savoir adapter son interface, la simplifier ou l'enlever (on n'a accès qu'à une partie du jeu), soit décider que le jeu à besoin d'au minimum 460x600 pixels pour tourner (par exemple) et qu'en dessous de ça le CSS n'adapte pas automatiquement l'interface au navigateur.

[Ter Rowan]

pareil que niahoo

[Xenos]

Je suis d'accord avec niahoo aussi, sauf pour bootstrap/semantic.gs (je préfère un flex CSS brutal, SCSS peut être intéressant, mais je préfère attendre les prochaines versions de CSS plutôt que d'insérer des couches... de développement!) et sauf pour la résolution minimale. Si j'ai un vidéo projecteur avec une résolution dégueulasse, interdire de joueur sur cette sale résolution me semble inadapté. D'autant que les résolutions bougent trop et sont trop dépendantes du support (460*600 sur mobile ou sur PC n'a pas la même signification).

Donc, pour les sites/jeux à venir, j'utiliserai du flex CSS, du responsive, et un système de secours sur lequel retomber si l'affichage ne permet pas de jouer via la carte 2D par exemple.

[niahoo]

460*600 sur mobile ou sur PC n'a pas la même signification

C'est à dire ?

Et sinon c'est exactement ce que j'ai dit : si ton jeu tourne pas sur un certain écran tu vire des features :

"système de secours sur lequel retomber" == "adapter son interface, la simplifier ou l'enlever (on n'a accès qu'à une partie du jeu)"

[@lucard]

à cause des PPI différent !
on a, pour 2 écrans ayant la même taille, 2 résolutions différentes, donc 2 tailles d'images différentes...
idem pour 2 écrans de même résolution, on pourra avoir 2 tailles d'écran, donc là encore 2 tailles d'images. (une t'ite image ? )
d'où le :

@media only screen and (-webkit-max-device-pixel-ratio: 1.5),

 only screen and (-o-max-device-pixel-ratio: 3/2),

 only screen and (max--moz-device-pixel-ratio: 1.5),

 only screen and (max-device-pixel-ratio: 1.5) {

  .icon{

    background: url(images/my-icon.png) no-repeat;

  }

[Xenos]

Comme le dit @lucard, à cause du PPI (et j'ajouterai: du dispositif de pointage utilisé).
Une fenêtre réduite en 460x600 sur PC, ou un téléphone tactile à basse résolution (grande dalle genre Iphone mais résolution de Nokia 3210) en 460x600, ou un vidéo projecteur en 460x600 avec un pointeur laser... Ces supports peuvent avoir la même taille d'affichage (en pixels), mais pas du tout la même précision de pointeur, c'est ce que je veux dire par "signification".

Après, soit on peut passer par de l'automatisé (façon @lucard ^^) soit on peut créer une sorte de "banque de skins" (de CSS) et laisser l'utilisateur choisir.

[stefde3]

Après selon l'espace disque de ton hébergeur ou de ta formule, tu peux aussi travailler tes CSS selon le user agent et ainsi afficher un css correspondant aux différents formats, mais ça c'était avant les media queries donc je te suggère quand même les média queries qui sont plus économiques en terme de ressources.

[@lucard]

Je vous remercie déjà pour cette première vague de réponses.

je viens de regarder des exemples de la libraire de bootstrap, y'a pas mal de choix, mais je trouve cela peut-être trop x)
j'aurais peut-être l'occasion d'en utilisé que 5 à 10%.
alors autant s'en inspirer, et créer moi même les imbrications css qu'il me faut.

concernant Flex, j'ai trouvé que peu d'informations le concernant, où alors, pas suffisamment explicite pour comprendre sa pleine utilité.

Je penses donc partir sur un gros Mixe de tout cela, à la fois du media queries, du css3 pure, et lorsque j'en saurais plus, du flex.

je vous encourage donc à continuer vos commentaires, et de poster peut-être quelques exemples.

Merci =)

[Globe]

Salut, personnellement j'ai déjà eu des clients qui ne m'embauchaient que pour refaire leur front-end à cause de la mauvaise utilisation de bootstrap par l'agence web employée en premier lieu. Je m'explique, bootstrap semble être un outil efficace pour qui sait l'utiliser, dans les mains d'un non initié j'ai vu les dégâts, notamment des pages qui galéraient à charger du fait de leur poids (mes pages codées main chargeant jusqu'à 100 fois plus rapidement). Plus précisément, bien que je ne connaisse pas ça me parait quand même un ramassis de mauvaises pratiques ce framework.

Personnellement je travaille tout à la main pour faire mon responsive, après tout est question de conception. J'ai déjà du faire l'intégration responsive cross-browser d'un site qui n'avait pas du tout été réfléchi responsive par le designer, mon fichier css fait plusieurs milliers de lignes pour palier à cette erreur. En revanche lorsque le site est conçu convenablement il devient aisé de l'adapter en responsive, je pense à de nombreux designs ou l'intégralité de mes media-queries représente une centaine de lignes max.

Pour une approche non professionnelle je ne sais pas trop quoi dire de bootstrap, certains frameworks sont utiles mais la plupart de ceux qui fournissent un grid responsive sont des usines à gaz d'après ce que j'ai compris. En revanche dans un contexte pro, je trouve que bootstrap est à proscrire. Pour moi le css c'est comme tout language il faut de la précision, de l'optimisation et de la lisibilité, et les frameworks css lourds sont les ennemis de ces trois caractérstiques.

Ensuite concernant l'accessibilité web on peut parler de l'amélioration progressive ou dégradation élégante ce qui nous emmène à casser les idées reçues du web aujourd'hui. L'amélioration progressive dans le même esprit que l'approche mobile first vise à développer son site de manière à obtenir la meilleur compatibilité cross-platform sans oublier de gérer la désactivation de javascript, les navigateurs antiques... On utilise souvent du nesting appliquant des styles moyennement supportés par les navigateurs à des div qui sont supportés et qui seront chargés en cas de besoin. Ce que j'appelle idées reçues c'est cet amour du HTML5 / CSS3. En passant par le validateur prototype du W3C on peut tester la rigueur de son HTML5, problème principal si on utilise les balises html5 on va vite se retrouver à nester des divs reconnues par les navigateurs anciens. On verra notamment que les balises nav et header ne sont supportées qu'à partir de IE9. On connaît également des incohérences dans les positions sur FF et aussi des erreurs d'inline... Des variations avec la gestion des border, des quirks de Safari...

Niveau cohérence web je trouve ça donc idiot d'utiliser du HTML5 juste pour faire cool ce qui pour avoir un site compatible cross-browser donnerait par exemple <div="#header"><header></header></div>. Là y'a un choix à faire entre modernité et accessibilité. Plus encore, je suis un fervent défenseur du responsive mais il y à des cas ou c'est une erreur. On va décrier les sites qui proposent des sheets différentes en fonction des supports, mais c'est la solution assurée pour certaines interfaces qui doivent juste être totalement repensées pour l'expérience utilisateur plutôt que pour les chevilles du designer. Je pense que certains jeux entreront dans cette catégorie. Quand y'a des milliers de lignes responsive autant charger une sheet différente.

Bon j'ai écrit un sacré pavé mais je parlerais juste rapidement de ma méthode. Lorsque j'ai le choix j'utilise du HTML4 principalement couplé à du CSS2 et 3 appliqué de manière à obtenir un résultat propre peu importe le contexte. Je précède toutes mes interfaces d'un reset.css simple. J'utilise des annulations de liens js pour obtenir une navigation fluide qui sera remplacée par une navigation classique par rechargement en cas de désactivation de js. Ensuite je teste mes travaux sur un navigateur pour mal-voyants pour en juger l'accessibilité pour ces personnes mais aussi pour travailler sur le SEO.
Dans le cadre de ma professionnalisation on pourrait parler de SASS et des préprocesseurs CSS. Des outils très puissants, utiles sur de gros projets. Le sujet divise parmi les designers, je n'ai pas vraiment d'avis sur la question mais sur mes projets perso je n'en vois pas l'utilité si y'a 4 ou 5 codes valeurs que je stockerais en variables je les mémorise quand on travaille 1 mois sur un projet c'est pas si difficile surtout que le css est une pratique solitaire en général.
Enfin je parlerais d'un outil très simple qu'il m'arrive d'utiliser : http://daneden.github.io/animate.css/
Une petite bibliothèque d'animations css très bien faite qui peut éviter pas mal de prises de tête.

Globe qui attend l'adoption de srcset avec impatience =)