[spip-dev] [spip-commit] r18547 - in spip: prive prive/formulaires squelettes-dist squelettes-dist/formulaires

Dev
1

(je réponds sur spip-dev et sur la zone vu que ça concerne un commit
sur le core et un sur l'extension forum).

17/09/2011, romy@rezo.net:

Author: romy@rezo.net
Date: 2011-09-17 23:58:45 +0200 (sam, 17 sep 2011)
New Revision: 18547

Log:
D?\195?\169sactiver la mise en capitales et
l?\226?\128?\153auto-correction sur les navigateurs mobiles sur les
champs de recherche, de login et d'email.

Ces attributs ne sont pas standards et sont ajoutés par Apple (Safari,
iPhone).

C'est louable de vouloir faciliter la vie des utilisateurs de ces
navigateurs, mais on devrait pas commencer à mettre des attributs
exotiques. C'est comme ça que le développement web est devenu un
cauchemar dans les années 90 (chaque site de "conseils en développement
web" y allant de son petit attribut maison pour tel ou tel navigateur).

Pareil pour le meta "viewport", même si y'a en théorie plus de
souplesse sur l'utilisation de valeurs de meta que sur les noms
d'attributs eux-mêmes. Mais en vrai c'est la même.

Plus généralement, sincèrement, j'aime vraiment pas la tendance d'Apple
à ajouter tout plein de trucs aux specs HTML dans leur coin, en
court-circuitant complètement les processus classiques de
standardisation/consensus existants, et je suis pas pour que SPIP
encourage cette pratique.

À la limite, une solution pourrait être de faire un plugin "navigation
Safari/iPhone" qui intègre les favicons spécial mac, le meta viewport,
les autotructruc off, et tutti quanti. Et encore, même avoir un tel
plugin sur la zone me paraîtrait contraire à l'idée de SPIP d'un web
ouvert et non commercial, mais on a déjà des plugins Facebook et
Google+ alors on n'est pas à ça près. Mais mettre ça dans le core
direct, bof.

2

Je suis d'accord, mais concrétement, comment faire ? Faut-il dupliquer tous les formulaires SPIP dans un plugin dédié, afin de leur ajouter ces 2 petits attributs ? Pour avoir le double à maintenir ??

-- Romy

3

18/09/2011, romy@rezo.net:

Je suis d'accord, mais concrétement, comment faire ? Faut-il
dupliquer tous les formulaires SPIP dans un plugin dédié, afin de
leur ajouter ces 2 petits attributs ? Pour avoir le double à
maintenir ??

Si tu tiens vraiment à avoir ces 2 petits attributs oui.

C'est une très bonne question, du coup : est-ce que ça vaut la peine de
dupliquer tous les formulaires pour ajouter ces 2 petits attributs mais
avoir le double à maintenir ?

Sinon, pour donner une réponse plus technique: tu pourrais faire un
javascript qui ajoute dynamiquement aux formulaires concernés les 2
attributs. C'est juste une idée, il y en a peut-être des meilleures,
mais celle-ci devrait fonctionner.

4

Dans ce cas, à la réflexion, il faudrait aussi retirer de SPIP tous les scripts et hacks de compatibilité Microsoft, dont les 5 premières lignes de chaque squelette de la dist, quelques déclarations CSS éparpillées et l'extension « Support vieux navigateurs »...

Mais je pense que SPIP a davantage vocation à aider les vrais gens à publier sur le Web qu'à préserver une pureté de code, en accord avec sa nature profondément libriste.

Dilemme ?

-- Romy

5

17/09/2011, romy@rezo.net:

Author: romy@rezo.net
Date: 2011-09-17 23:58:45 +0200 (sam, 17 sep 2011)
New Revision: 18547

Log:
D?\195?\169sactiver la mise en capitales et
l?\226?\128?\153auto-correction sur les navigateurs mobiles sur les
champs de recherche, de login et d'email.

Ces attributs ne sont pas standards et sont ajoutés par Apple (Safari,
iPhone).

C'est louable de vouloir faciliter la vie des utilisateurs de ces
navigateurs, mais on devrait pas commencer à mettre des attributs
exotiques. C'est comme ça que le développement web est devenu un
cauchemar dans les années 90 (chaque site de "conseils en développement
web" y allant de son petit attribut maison pour tel ou tel navigateur).

Pareil pour le meta "viewport", même si y'a en théorie plus de
souplesse sur l'utilisation de valeurs de meta que sur les noms
d'attributs eux-mêmes. Mais en vrai c'est la même.

Plus généralement, sincèrement, j'aime vraiment pas la tendance d'Apple
à ajouter tout plein de trucs aux specs HTML dans leur coin, en
court-circuitant complètement les processus classiques de
standardisation/consensus existants, et je suis pas pour que SPIP
encourage cette pratique.

Dans ce cas, à la réflexion, il faudrait aussi retirer de SPIP tous les scripts et hacks de compatibilité Microsoft, dont les 5 premières lignes de chaque squelette de la dist, quelques déclarations CSS éparpillées et l'extension « Support vieux navigateurs »...

100% d'accord.

Mais je pense que SPIP a davantage vocation à aider les vrais gens à publier sur le Web qu'à préserver une pureté de code, en accord avec sa nature profondément libriste.

Dilemme ?

C'est devenu tellement naturel de faire des hacks pour IE que l'on a oublié que c'était des hacks et non un standard.
L'ajout de code pour smartphone et entre autre pour iOS, fait "bondir"/réagir certaines personnes (rien contre la communauté Spip ni même quiconque). Pourtant, cela devient aussi une habitude de webdesigner avec l'envolée des smartphones en tout genre. Presque un standard.

6

18/09/2011, romy@rezo.net:

Dans ce cas, à la réflexion, il faudrait aussi retirer de SPIP tous
les scripts et hacks de compatibilité Microsoft, dont les 5 premières
lignes de chaque squelette de la dist, quelques déclarations CSS
éparpillées et l'extension « Support vieux navigateurs »...

D'une part, je ne suis effectivement pas vraiment favorable au pâté
"spécial IE" sur tous les squelettes de la dist. Merci d'avoir soulevé
la question ! Quant au support des vieux navigateurs, c'est un plugin,
facilement désactivable.

Mais surtout, ce sont en fait 2 problématiques très différentes.

On ne peut pas remonter dans le temps. Les vieux navigateurs sont là,
on les gruge en attendant que les gens actualisent à un navigateur
plus récent, gérant enfin les standards vu qu'on est enfin sortis de la
guerre des navigateurs des années 90. Comme le dit Teddy, on met ces
hacks en ayant pleinement conscience que ce sont des hacks, Microsoft
s'est gagné une réputation de merde avec ça, à tel point que les
versions récentes d'IE sont maintenant conformes.

Ici c'est différent: c'est des attributs tout frais, ajoutés sans
vergogne par Apple en 2011, mais comme c'est Apple et pas MS on trouve
ça super, on les gère et on donne donc notre aval, alors qu'il est
encore temps de dire non, contrairement à IE6. On ne peut pas remonter
dans le temps, mais on peut agir sur le présent en ne cautionnant pas
une guerre des navigateurs 2.0.

Du coup pour moi ce n'est pas la même chose. Mais si ça l'est, il faut
mettre ces hacks dans l'extension "vieux navigateurs". Je trouverais ça
très drôle mais parlant.

Mais je pense que SPIP a davantage vocation à aider les vrais gens à
publier sur le Web qu'à préserver une pureté de code, en accord avec
sa nature profondément libriste.

En le disant comme ça, tu fais comme si la responsabilité était
uniquement entre nos mains, les navigateurs étant en "lecture seule".
C'est un peu culpabilisateur, mais tu te trompes de responsables :
certains fabricants d'appareils mobiles ont décidé en 2011 qu'ils
allaient coller par défaut une majuscule à toutes les saisies de texte,
et que c'est aux webmestres de changer ça explicitement en ajoutant un
attribut exotique, et que si on le fait pas on prend les utilisateurs
en otage. En vrai c'est *leur* responsabilité, et si ça entraîne une
gêne pour les utilisateurs ce n'est pas à nous de corriger ça. Les
acheteurs se plaindront et ça disparaîtra aussi vite que c'est apparu.

7

18/09/2011, romy@rezo.net:

Dans ce cas, à la réflexion, il faudrait aussi retirer de SPIP tous
les scripts et hacks de compatibilité Microsoft, dont les 5 premières
lignes de chaque squelette de la dist, quelques déclarations CSS
éparpillées et l'extension « Support vieux navigateurs »...

Du coup pour moi ce n'est pas la même chose. Mais si ça l'est, il faut
mettre ces hacks dans l'extension "vieux navigateurs". Je trouverais ça
très drôle mais parlant.

Oui, pour moi c'est vraiment du même ordre :slight_smile:

Mais je pense que SPIP a davantage vocation à aider les vrais gens à
publier sur le Web qu'à préserver une pureté de code, en accord avec
sa nature profondément libriste.

En le disant comme ça, tu fais comme si la responsabilité était
uniquement entre nos mains, les navigateurs étant en "lecture seule".
C'est un peu culpabilisateur, mais tu te trompes de responsables :
certains fabricants d'appareils mobiles ont décidé en 2011 qu'ils
allaient coller par défaut une majuscule à toutes les saisies de texte,
et que c'est aux webmestres de changer ça explicitement en ajoutant un
attribut exotique, et que si on le fait pas on prend les utilisateurs
en otage. En vrai c'est *leur* responsabilité, et si ça entraîne une
gêne pour les utilisateurs ce n'est pas à nous de corriger ça. Les
acheteurs se plaindront et ça disparaîtra aussi vite que c'est apparu.

En fait, je me fiche pas mal des responsabilités. Du point de vue utilisateur : peu importe.

La question est donc : est-ce qu'on aide le gus à publier sur le Web ou est-ce qu'on décide qu'il doit lui aussi pâtir de cette guerre idiote ? qu'il doit prendre sur lui-même de se salir les mains à coder ça parce que SPIP veut rester propre ?

-- Romy

8

18/09/2011, romy@rezo.net:

Oui, pour moi c'est vraiment du même ordre :slight_smile:

Oki, du coup ça doit aller dans le plugin "support vieux navigateurs"
avec tous les autres hacks.

En fait, je me fiche pas mal des responsabilités. Du point de vue
utilisateur : peu importe.

La question est donc : est-ce qu'on aide le gus à publier sur le Web
ou est-ce qu'on décide qu'il doit lui aussi pâtir de cette guerre
idiote ? qu'il doit prendre sur lui-même de se salir les mains à
coder ça parce que SPIP veut rester propre ?

Je répète: l'iPhone du gus est très évolutif: si on joue pas le jeu des
attributs exotiques, il ira se plaindre auprès d'Apple qui corrigera le
comportement au lieu de nous refiler le bébé.

Encore une fois: le comportement de Safari, iPhone etc. est pas gravé
dans la roche, contrairement à celui d'IE6.

En tant qu'auteurs de *plugins* (je parle à la zone ici) on peut avoir
cette attitude de "boh trop tard, maintenant que c'est là il faut aider
les utilisateurs", et d'ailleurs c'est souvent la seule attitude
possible.
Mais en tant qu'auteurs de *CMS* (je parle au core ici), mine de rien
on est des acteurs du web importants, et si on (les gros CMS) ne
cautionne pas quelque chose ou si on le cautionne, ça a des
conséquences sur le comportement des navigateurs.
C'est deux responsabilités différentes.

9

Salut,

si je peux me permettre, je trouve que la prise en compte du web mobile à la sauce apple n’a rien a faire dans le plugin “support vieux navigateurs”. Nous ne sommes pas ici dans la même problématique. De plus, il faut prendre en compte qu’un navigateur mobile a forcement ses propres contraintes. Le but d’Apple à l’époque de la création de ces attributs exotiques n’était pas forcément le web mobile mais de donner la possibilité au dev de créer des webapps au look et au comportement très proche des applis natives de l’époque. Je parle ici d’avant l’iPhone et donc de la première génération d’iPod Touch. Entre temps est arrivé ou arrive (rayer la mention inutile) HTML5 et son cortège de possibilités, de souplesse et de tolérance. Logiquement les navigateurs mobiles plus récents on embrassés HTML5 (pas tous) et Apple à mis à jour sur beaucoup de point son safari mobile, mais à conservé son exotisme… dont je trouve certains point très bien vu (icon de bureau, splash screen, etc…).
Bref, personnellement je suis vraiment pour la segmentation et pour laisser le choix au dev du site de gérer ou non la prise en compte des “vieux navigateurs” et/ou de gérer le support mobile.

Je vote pour un plugin “web mobile”.

Fabrice Coutant

StrangeBlackHole SAS
6 rue d’Australie - 344
91300 Massy

10

Moi je vote pour un squelette “responsive webdesign”. Tout en html et CSS.
Mais là, pas dans la dist. Un plugin dédié.
On reprend le design de la dist, puis on adapte les CSS selon la taille Max de l’écran. Avec les fameux hacks made in Apple entre autre.
Y a un article sur Alistapart.

11

Et concrètement, pour les formulaires : on les duplique tous ? avec la double maintenance que ça implique ?

12

Et concrètement, pour les formulaires : on les duplique tous ? avec la double maintenance que ça implique ?

Je dirais oui, même s’il je comprends la problématique de la double maintenance. Cela dit comme le suggère davux (il me semble) cela peut très bien être géré par un bout de Javascript (dans le plugin en question). C’est d’ailleurs ce que fait très bien jQtouch. Un HTML propre et une couche de JS pour « iPhoniser » le tout.

13

Extrêmement rares sont les webmestres à volontairement préférer (ou : à avoir préféré)
que leur site s'affiche mal sous IE.

Je vois mal que ce soit différent avec les iphones et consorts, surtout vu leur attrait actuel
(au contraire de microsoft qui était ringardisé).

Je dirais oui, même s'il je comprends la problématique de la double maintenance. Cela dit comme le suggère davux (il me
semble) cela peut très bien être géré par un bout de Javascript (dans le plugin en question). C'est d'ailleurs ce que
fait très bien jQtouch. Un HTML propre et une couche de JS pour "iPhoniser" le tout.

"Cachez ces tâches de sauce Apple que je ne saurais voir !"

Mais si ce n'est pas juste pour se faire plaisir,
toutes ces complications n'auront de sens que si elles sont expliquées et revendiquées,
genre par un lien dans l'interface privée à côté de l'activation de ce JS
car le militantisme pro-normes en serait la seule raison d'être.

JLuc,
(qui n'a ni mobile ni Apple)

14

19/09/2011, JLuc:

Extrêmement rares sont les webmestres à volontairement préférer (ou :
à avoir préféré) que leur site s'affiche mal sous IE.

IE/MS est maintenant plutôt respectueux des standards, contrairement à
son comportement critiqué d'il y a 15 ans.

Les webmestres implémentant les hacks l'ont toujours fait en grognant,
sans avoir le choix, et en faisant tout ce qu'ils pouvaient pour
convaincre MS d'arrêter les conneries, ce qui a fini par porter ses
fruits d'ailleurs.

Là on a le choix car les attributs exotiques en question sont encore
tout frais.

Je vois mal que ce soit différent avec les iphones et consorts,
surtout vu leur attrait actuel (au contraire de microsoft qui était
ringardisé).

C'est pas parce que c'est une boîte fashion qui chie sur les standards
que d'un coup ça devient une bonne idée.
Et : la fin ne justifie pas toujours les moyens.

> Je dirais oui, même s'il je comprends la problématique de la double
> maintenance. Cela dit comme le suggère davux (il me semble) cela
> peut très bien être géré par un bout de Javascript (dans le plugin
> en question). C'est d'ailleurs ce que fait très bien jQtouch. Un
> HTML propre et une couche de JS pour "iPhoniser" le tout.

"Cachez ces tâches de sauce Apple que je ne saurais voir !"

C'est pas de l'anti Apple (en ce qui me concerne), c'est de l'anti
je-fais-ma-variante-de-HTML.

Mais si ce n'est pas juste pour se faire plaisir,
toutes ces complications n'auront de sens que si elles sont
expliquées et revendiquées, genre par un lien dans l'interface privée
à côté de l'activation de ce JS car le militantisme pro-normes en
serait la seule raison d'être.

JS, surcharge de formulaire, ou autre solution, peu importe. Ce qui est
clair, et même Romy est d'accord même si elle ne l'a pas dit ici, c'est
que ça n'a rien à faire dans le core.

Sur la forme de la discussion : on ne va pas commencer à traiter les
arguments ou les gens de militants (pourquoi pas intégristes ou encore
nazis ?) juste parce qu'on n'est pas d'accord.
Par ailleurs tu déformes mon argument, ou alors je l'ai mal expliqué:
il ne s'agit pas d'être des ayatollahs des normes mais de ne pas
retomber dans les blagues des années 90 où chaque navigateur ajoutait
ses propres bouts de specs, avec le tableau (sic.) que ça a fini par
donner et l'énergie dépensée pendant les 10 années suivantes pour
redresser la barre.

Mais comme dirait Ponce Pilate, tant que c'est en plugin, je m'en lave
les mains (quoiqu'on puisse argumenter que la zone devrait être un lieu
de promotion du web ouvert, mais c'est un autre débat).

15

tout à faitd'accord avec ce message :expressionless: