Adaptation site mobile

Bonjour,

Même ma belle-mère a une tablette !
Loin d'être expert en CSS, j'ai tout de même décidé de modifier les feuilles de styles de mon site afin de le rendre compatible sur les différents terminaux.

A cet effet, j'ai intégré la fiche : 1177-une-feuille-de-styles-de-base-pour-le-web-mobile à mes feuilles CSS :
feuille style.min.css
feuille galleria.css


Problème sur la page d'accueil :
- format portrait sur smartophone et tablette : la galerie d'images est tronquée
- la police de caractère est trop petite

Problème sur la page interne :
- format paysage sur smartophone et tablette: chevauchement de caractères sur la zone titre
- format portrait le cadre entête est tronqué
- la police de caractère est trop petite

Merci d'avance pour votre aide

mbouchaud a écrit :
Même ma belle-mère a une tablette !

Et bien... en fonction de votre âge à vous on sera plus ou moins impressionné par l'esprit geek de la belle mère

mbouchaud a écrit :
Loin d'être expert en CSS, j'ai tout de même décidé de modifier les feuilles de styles de mon site afin de le rendre compatible sur les différents terminaux.

Contrairement à ce que l'on pourrait croire, rendre responsive un site déjà existant est un exercice plutôt difficile.

mbouchaud a écrit :
A cet effet, j'ai intégré la fiche : 1177-une-feuille-de-styles-de-base-pour-le-web-mobile à mes feuilles CSS...

Ce n'était pas forcément à faire. En effet ce type de feuille de style est prévue pour démarrer un site à partir de zéro, ce qui n'est pas votre cas. Pour vous il vaux mieux retoucher les règles css au cas par cas.

Et dans votre cas justement, l'exercice se révèle extrêmement complexe, suffisamment complexe pour justifier un changement de thème plutôt que le maintient de l'actuel. Vous êtes sur WordPress, les thèmes de qualité abondent sur ce CMS, en trouver un ne serait pas difficile. Une occasion pour vous de remettre à niveau votre site sur le plan graphique.
Modifié par Olivier C (30 Jan 2016 - 10:57)

Merci Olivier C pour les suggestions et le temps passé à analyser le site

Changer de template serait également un exercice assez complexe, car le site ressemble à du wordpress mais tout est géré à la main.

mbouchaud a écrit :
... le site ressemble à du wordpress mais tout est géré à la main.

C'est à dire ? Si une partie du code est injecté en dur c'est peut-être l'occasion de passer à des plugins facilement gérables en back-end, notamment pour le slide.
Modifié par Olivier C (30 Jan 2016 - 11:00)

Olivier C a écrit :

C'est à dire ?

Je n'ai pas de bases de données et j'utilise Notepad++ pour écrire mes pages.

mbouchaud a écrit :
Je n'ai pas de bases de données et j'utilise Notepad++ pour écrire mes pages.

C'est fort dommage, l'intérêt d'utiliser un WordPress s'en trouve ainsi largement diminué, pour ne pas dire réduit à néant...

En ce qui concerne l'aspect màj du temple, c'est effectivement moins pratique.
Erreur de jeunesse, par contre pas de base de données, code plus clean, moins de php et sécurité accrue, ...

Mais c'est pour cela que je le fais manuellement.

Hier, j'ai ajouté une classe appelée container fixant la taille en fonction de l'écran, je trouve déjà une certaine progression. Il faudrait également que la taille des polices soit adaptée à l'écran afin de pouvoir lire sans zoomer. Je n'ai pas trouvé la syntaxe, donc si un membre a une piste je le remercie d'avance.
Modifié par mbouchaud (31 Jan 2016 - 05:39)

Bonjour,

mbouchaud a écrit :
J'ai ajouté une classe appelée container fixant la taille en fonction de l'écran.

Oulala...

Une classe, Php ? (pas brillant)
en JS ? (pire)

Et les media-queries dans l'histoire vous pensez vous en servir à quel moment ?

Excusez moi pour le manque de précision.

J'utilise effectivement des media-queries dans le fichier style.min.css :
@media all and (max-width: 480px) {.hide_phone {display: none !important;}
@media screen and (min-width:480px){.container{width:470px;}}
@media screen and (min-width:640px){.container{width:630px;}}
@media screen and (min-width:767px){.container{width:740px;}}
@media screen and (min-width:800px){.container{width:800px;}}

et j'ai ajouté au sein de mes pages html : <div class="container">

Greg_Lumiere a écrit :
Je m'interroge sur l'utilité (et la fonction) d'une classe qui sert à "fixer la taille" d'un conteneur en fonction de la taille de l'écran.

Cette classe serait-elle destinée à apposer la classe "container" à un contenu généré dynamiquement ?

Je pars dans l'hypothèse d'un contenu statique et je me dis que lorsque la structure en Html est bien conçue, la conteneur globale se distingue de lui-même et n'a pas (forcément) besoin de se voir catalogué dans un classe dédiée.

D'autre part la surcharge du DOM par une division dont l’intérêt ne se limite qu'à identifier le conteneur principal d'une page ne me paraît pas être un choix des plus judicieux.

En effet, il est déjà prévu ce genre de conteneur que nous utilisons tous, soit la balise Body qui comme son nom l'indique indique le corps de page.
Bien sûr, et là encore nous sommes nombreux, notre Body contient tellement d'éléments qu'il peut vite être avantageux de subdiviser ce conteneur général ; mais là encore les spécificités d'Html peuvent nous aider notamment par l'usage de la balise Main ou encore Article/Section qui offrent un support complet des propriétés Css.

Maintenant concernant la lisibilité en fonction de la taille de l'écran, j’ajouterais qu'au delà des media-queries qui sont évidemment indispensables, il est recommandé l'utilisation d'unités relatives.
C'est ce couple media-querie - unité relative qui feront que le design sera adaptatif (ou responsive en anglais).

C'est pourquoi, ne vous offusquez pas, mais je persiste dans ma demande sur l'intérêt de l'utilisation d'une classe programmée pour gérer une taille d'affichage.

Pour l'instant, dans mon imaginaire, j'y vois une classe JS qui passe en sur-couche après la construction du DOM. Sa fonction, toujours dans mon imaginaire, est de dire que quand il rencontre la classe untel, il fixe sa taille à x.

Plus de détails de votre part m'aidera très certainement à comprendre votre orientation et peut-être à pouvoir vous aider d'avantage.

En attendant, bon webdev.

Merci pour ces précisions fort utiles.
De fait, je pense qu'il y a eu ici confusion sur le terme de "classe".
Si je comprend bien la réponse ci-dessus, il s'agit de classes au sens CSS, alors que j'avais plutôt perçu le précédent commentaire comme parlant de classes au sens de la programmation objet.
D'où mon interrogation sur le fait qu'il soit déconseillé d'y recourir, ces classes étant tout à fait adaptées à. PHP et Javascript (entre autre).
La clarification était donc nécessaire, à moins que je ne sois le seul à voir une classe objet là où d'autres voient d'office une classe CSS

Meaculpa, effectivement nous nous sommes mal compris.

Cette histoire de classe étant écartée, nous pouvons revenir à la question principale qui peut-être résumée ainsi : Comment rendre son site (plus) adaptatif.

Pour ce petit récapitulatif, je vais m'appuyer sur les réponses précédentes et ma propre expérience.

Primo on peut établir qu'un design adaptatif se décide en amont de toute personnalisation visuelle. Cela permet d'établir ses points de ruptures et d'imaginer à l'avance le résultat attendu.

Ensuite, comme le souligne Olivier C, l'importation a posteriori de feuille de style pré-fabriquée n'est pas un choix judicieux, il vaudra mieux soit re-travailler le Css déjà en place ou (mieux !) travailler sur un style version 2. Même si l'idée de reprendre un style à zéro peut paraître fastidieuse, la finalité est souvent plus propre, plus concise et mois sujette au bug (de part le gain en cohérence).

On notera aussi l'indispensable obligation d'être forcé à l'utilisation incontournable des média-queries... [Ne devrais-je pas mettre cette phrase en gras ?!]

Mais pas seulement ! L'utilisation d'unité relative va de paire et oblige donc à ne pas fixer les tailles. Imaginer une notation relative revient à imaginer son design, non plus en terme de longueur, mais en terme de proportion.

Ce qui conduit au dernier point (dernier ? à voir!), et nous pouvons remercier juliesunset car je n'y avais pas pensé, soit définir des intervalles de longueur plutôt que des longueurs fixes.
A ce propos, personnellement j'applique ce point avec des pincettes ; je me focalise beaucoup plus sur mes points de ruptures.


Dans votre cas, Sepecat, je ne saurais que trop vous suggérer de tenter de créer un graphisme depuis une page vierge, de reprendre les points précédent et d'ensuite de "pomper" sous forme de dose homéopathique diverses parties de votre (ancien) design (d'autant que cela risque de vous conforter sur vos acquis liés à la maitrise du langage).
Dans le pire des cas, il restera plus aisé de modifier le design actuel que de tenter d'incorporer des bribes provenant d'un tiers. Cela vous évitera à devoir passer en revue l'intégralité de votre Html pour le conformer aux instructions insérées.

Rassurez-vous, dans les deux cas, vous pourrez toujours revenir exposer votre problème
Modifié par Greg_Lumiere (01 Feb 2016 - 16:14)

Merci Greg pour les indications sur la marche à suivre pour adapter mon design au responsive web.
Je suppose que vous faites allusion au portailThot qui, effectivement, n'est ni adaptive, ni responsive ou quelque autre forme que ce soit concernant CSS.
Ma priorité au niveau du générateur se situe pour l'instant dans la production de code HTML le plus conforme possible aux standards.
La génération de la feuille de style CSS n'interviendra qu'en phase II, lorsque tout aura été pleinement validé en HTML.

sepecat a écrit :
Merci Greg pour les indications sur la marche à suivre pour adapter mon design au responsive web.

De rien, c'est avec les meilleurs intentions (pour un web meilleur et pour en apprendre plus).

sepecat a écrit :

Je suppose que vous faites allusion au portailThot qui, effectivement, n'est ni adaptive, ni responsive ou quelque autre forme que ce soit concernant CSS.

Je suis confus, je n'y ai jetté qu'un rapide coup d'oeil

sepecat a écrit :

Ma priorité au niveau du générateur se situe pour l'instant dans la production de code HTML le plus conforme possible aux standards.

Je comprends, je travaille dans cette même démarche, prioriser un code conforme avant l'application de surcouche (qu'elle soit visuelle ou mécanique )

sepecat a écrit :

La génération de la feuille de style CSS n'interviendra qu'en phase II, lorsque tout aura été pleinement validé en HTML.

Oui dans l'idéal mais... non dans la pratique.

Au fil du développement je me suis rendu compte qu'il m'était indispensable de remplacer une section entière car j'avais définis un affichage tabulaire pour un type de donnée. J'avais à peine pensé au rendu visuel sur ordinateur et pas du tout sur écran réduit. Au moment de vouloir personnaliser l'affichage de cette partie, je me suis rendu compte de l'incompatibilité entre le choix fait en amont sur le code statique et l'affichage sur un écran réduit.
Il m'a alors fallut modifier intégralement mon code statique que je m'étais évertuer à rendre le plus conforme et plus accessible possible.

C'est pourquoi je pense qu'avant de poser les premières lignes de codes, il vaut mieux penser, certes à son contenu mais aussi à son rendu. L'un et l'autre définissent les limites des possibilités offertes à postériori.
C'est ce que l'on croise sur la toile dans divers tutoriel écrit sous la forme "avoir une vision globale du projet"

Du coup depuis je divise mon travail sur la partie statique en "zones" ainsi je peux les travailler en toute indépendance.

Je m'éloigne peut-être un peu du sujet de départ mais c'est une partie du jus du fruit de mon apprentissage qui n'est pas à prendre pour parole divine.