websigns a écrit:

1/ J'ai été étonné de constater qu'aucun des thèmes que j'ai pu essayer (sylvia, clear, dark, expo, gally/graphite, Luciano Amodio, pure grey, simple grey, sobre et mon préféré Stripped) n'était pas "passé" à l'HTML5.
Non que se soit indispensable car tout fonctionne bien sans mais ne serait ce que pour la structuration qu'apporte les nouvelles balises je trouve que ce serait une bonne idée (voir Wordpress à ce propos).
[on en est pas loin en plus avec des choses comme : <div id="the_page"><div id="theHeader">

La question que je me pose, c'est quelle est la compatibilité avec les navigateurs ?

Il y a encore pas mal de gens qui visitent les sites avec de vieux navigateurs (en particulier avec des ordinateurs de boulot... dans ma boite on est passé de ie6 à ie8 il y a 6 mois par exemple, et encore, partiellement).

Un site photo, les gens qui vont venir le voir et chez qui ça va mal s'afficher, vont forcément accuser le site et non leur navigateur.

websigns a écrit:

2/ Ne serait il possible de lancer une "uniformisation" de la structure HTML des thèmes ?
En développant mon petit script de redimensionnement des images je me suis demandé ce que ça donnait sur d'autres thèmes (ceux ci dessus). Et là, déconvenue : il y a beaucoup trop de structure HTML différentes et il faudrait presque tenir compte de chacune !
Je comprends bien que pour avoir de la diversité il faut que les auteurs de thèmes soient libres mais c'est clairement dommage si ce sont les auteurs de plugins qui en pâtissent.

Le problème c'est que vraiment personnaliser un thème avec uniquement du CSS, c'est impossible.
(en tous cas je n'y arrive pas ;) )

Alors effectivement, il y aura toujours quelques incompatibilité entre des thèmes et des plugins... c'est aussi à la personne qui monte le site de choisir ce qui est le plus important pour lui.
Parfois il devra changer de thème, parfois il devra renoncer à un plugin.

Parfois c'est aussi assez facile pour le plugin de s'adapter, parfois pour le thème (je l'ai fait quand j'ai pu avec stripped)


Pour le reste, ce que tu proposes c'est un peu, en quelques sorte, un retour à la séparation template / thème qu'il y avait avant, j'ai l'impression.

Ce qui avait d'ailleurs des avantages, mais qui était beaucoup moins souple pour les dévelppeurs de thèmes.
Je ne pense pas, en particulier, que j'aurais développé stripped si on en était resté à ce système.
Et clairement, je n'aurais pas pu développer le thème non plus si je m'étais cantonné à un cadre strict.

Pour la difficulté de développer un thème... oui, ça n'est pas simple, clairement (mais la grosse difficulté vient surtout de la façon d'afficher différente sur chaque navigateur, et plus si on rajoute les différents OS qui ont tous des spécificités en particulier sur les polices).
C'est ça qui m'a fait perdre le plus de temps sur stripped, si j'avais du développer uniquement pour mon PC sous firefox... ça aurait été beaucoup plus simple.

Je précise aussi que je suis parti de 0 connaissance en css / php / jquery / html etc... donc pour quelqu'un qui maitrise au départ ces concepts, c'est sans doute beaucoup plus facile à faire.

Pour un passage à l'HTML5 :
je conseil la lecture approfondie du site fr.html5boilerplate.com
Ce n'est pas seulement une réponse à ce problèmes mais à bien d'autres.
> un fichier .htaccess bien optimisé permettrait, sur certains hébergement, un net gain de vitesse de chargement (pas chez Free hélas)
> la feuille de style homogénéiserait le rendue sur l'ensemble des navigateurs et simplifierait la personnalisation du design.
> idem pour modernizr qui résout le problème de la compatibilité ascendante. Au besoin d'autres scripts comme IE9.js peuvent compléter.
On voit bien qu'il est faisable de "corriger" du code moderne pour des navigateurs obsolètes appeler à disparaitre. Le contraire oblige à une correction continue et ce en se passant des avantages des technos modernes. Bofbofbof.
Par ailleurs la mise à jour ou le changement vers un navigateur ressent est gratuit même avec MS (!).
Je suis pour le prosélytisme quand il tend uniquement vers un plus grand confort de toutes façons |-)
D'ailleurs Zaphod tu sites le passage rescent à IE8, mais c'est déjà bien ! C'est à partir de cette version qu'on peut discuter si je puis dire.

Ok le changement de matériel c'est une autre limonade mais être à la fois en pointe sur les supports de type smartphone ET compatible IE6 ça tient plus du grand écart schizophrène que de la compatibilité raisonnée. Il faut faire un choix. Et honnêtement la tendance va vers la modernisation, il n'y a qu'à voir les thèmes Wordpress, plateforme qui est nettement plus exigeante et plus répandue.

J'ai parlé de template commun. En fait l'idée essentiel serait il me semble, et ça rejoint l'HTML5 par l'existence des nouvelles balises plus explicites (header, footer, nav, ...), de créer une base "obligatoire" de nommage des objets incontournables utilisé par Piwigo.
Pour mon petit plugin j'ai bien bataillé pour comprendre comment être compatible avec un maximum de thèmes les plus courants.
-> Grosse perte de temps et code nettement plus complexe.

Zaphod a écrit:

Parfois il devra changer de thème, parfois il devra renoncer à un plugin

Ben oui mais non ! C'est le cas actuellement et ce qui motive entre autres cette discussion. Et justement je pense qu'il est faisable de corriger cette tendance.
En imposant un minimum commun et en utilisant des technos (citées ci dessus) "aplanissant" les problèmes on tendra vers moins de code, un codage plus facile, moins d'incompatibilité entre thèmes/plugins ("et vice versaaaaaa").
Enfin disons que c'est le but à atteindre.
Disons aussi que ça me semble partiellement assez facile et partiellement très compliqué.

Un élément qui apporterait une nette amélioration dans ce sens serait l'existence d'une vrais documentation avec notamment un index complet et à jour des fonctions et classes, Smarties et PHP, existantes disponibles propre à Piwigo.
Et nettement plus d'exemples (à jour !) pour expliquer comment s'en servir parceque l'un sans l'autre ne mène pas loin.
Le fichier "event_list.php" accessible par le plugin event lister est un bon début mais voilà ...
La "lecture" du fichier "functions_user.inc.php " n'est pas d'une aide suffisante non plus.
Bref : où est l'info ?!
Je sais qu'on pousse, et c'est assez rare pour être plébiscité, à pauser des questions sur le forum mais, bénévolat oblige, ça ne vient pas toujours et il s'agit de réponses très ciblées, peu réutilisables.
[tiens à propos, et ma question ? http://fr.piwigo.org/forum/viewtopic.php?id=21716]
Quant à retrouver parmi ces millier de réponses la bonne si tant est qu'elle existe ... Arg !

Vous allez me dire "azi ! faisais le toi la doc !" Ok c'est un gros boulot, voir énormissime.
Mais quel temps gagné ensuite ! Au lieu de répondre 100 fois à la même question, la Team pourra se concentrer sur les vrais questions complexes et les noobs comme moi pourront potasser la doc pour répondre aux tits nouveaux pas encore démoralisé (ok ok j'en rajoute).
Ceci étant je veux bien participer à la rédaction/mise à jour d'une telle "bible".

J’arrête ici ... pour le moment ;-)

Aujourd'hui rien n’empêche de faire un theme en html5 dans piwigo saimon nous le -//:---\spam :-)

Bah utilisateur de Stripped, et ravie de l'être, je veux bien me tester sur son HTML5isation.
J'ai à priori justement besoin de prendre ça en main pour mon taf.

Rien qu'un plugin qui rajoute un icone dans la barre d'action en haut, par exemple, c'est déja manqué pour stripped qui fonctionne avec du texte...

Je comprends pas. C'est déjà ce qui arrive avec Facebookplug ou le choix de langue.
Tu veux dire que c'est môche ?
Moi je pointe le bon fonctionnement. Après l'esthétique ...
Mais tu as raison ceci dit.

Bah je vais pas me plaindre des possibilités offertes de mon coté.
D'ailleurs chapeau bas parceque partir de rien et faire un truc aussi poussé, c'est limite impressionnant.