Le 25 déc. 2009 à 19:03, Jean Lespinasse a écrit :

> Le 24 déc. 2009 à 14:39, pascal weber a écrit :
>
>> Lorsqu'un client paye un graphiste c'est pour avoir... du graphisme. Y
compris sur IE.
>> Et comme je le disais le problème c'est surtout la pauvreté du css pour faire
du graphisme.
>
> Sincèrement tu te trompes. Le graphisme est l'art de la mise en page, de
l'organisation de l'information, de « créer, choisir et utiliser des éléments
graphiques (dessins, caractères typographiques, photos, couleurs, etc.) pour
élaborer un objet de communication et/ou de culture » - comme défini dans
l'introduction de l'article Wikipedia sur le sujet. Pour ce faire les css sont
extrêmement efficaces.

Je n'ai jamais mis en cause les css : c'est même la seule solution pour faire du
design web extrêmement poussé. C'est seulement le design "pur css" (sans images
de background) que je trouve pauvre. Les fonctions un peu avancées (coins
arrondis, ombres, imports de polices etc) ne fonctionnent malheureusement pas
partout. Mais il est évident qu'un site est en (x)html/css.

Et mon propos ne concerne que la maquette. Je ne trouve pas plus évident et plus
pratique de coder directement. Je travaille essentiellement des gabarits
dynamiques pour cms et mon code est réparti sur environ une centaine de scripts
et une douzaine de css (selon les fonctionnalités utilisées pas le client). De
plus, pour pouvoir être labelisé accessiweb, les éléments doivent apparaître
visuellement dans le même ordre que dans le code (ce qui à mon avis est absurde
mais c'est ainsi...) donc avant de me lancer dans la production de tout ça, je
maquette et je fais valider la maquette, car si le client me demande de modifier
l'ordre de mes blocs, c'est beaucoup de fichiers à rouvrir ! Alors que sur une
maquette "en dur", c'est un seul fichier et quelques clics...

>
>> Si on utilise efficacement ses outils vectoriels, il suffit également de
changer un code couleur pour modifier une palette.
>
> OK. Donne moi la manip à faire dans Illustrator, ou Indesign, ou XPress. Je ne
la connais pas. Ça pourra me servir: en une seule fois remplacer une couleur par
une autre sur l'ensemble d'un design. Merci d'avance.

Simplement cocher la case "couleur globale" lorsqu'on crée une couleur dans le
nuancier. Ensuite il suffit de modifier la couleur dans le nuancier pour la
changer partout où elle est utilisée...

>
>> […] nous sommes justement bientôt en 2010 : dans une société de l'image et de
l'apparence, avec des outils très évolués, des smartphones, des écrans dont la
résolution ne cesse de s'affiner etc,
>
> Voilà bien l'argument qui plaide en faveur des css et de leur potentiel
d'adaptation à des affichages changeants. L'interface d'iTunes est toute en css,
de même que celle de l'iPhone, pas d'images pour faire les boutons, tout est en
code, comme ici:
>
> http://mwhenry.com/blog/examples/iphone_buttons/
>
http://www.launchpadhq.com/blog/2007/07/07/replicating-iphone-buttons-the-webkit\
-way/
>
> Ceci pour illustrer la “puissance” du principe “css”.

Je le répète : je ne conçois même pas qu'on puisse gérer l'apparence d'une page
web autrement qu'en css.

>
>> Bref une société où lorsqu'on vend une prestation graphique, le client ne
paye par pour avoir simplement des blocs aux coins arrondis et des ombres
portées (sauf sous IE !).
>
> Tu ne comprends pas. Les coins arrondis et les ombres portées font partie des
quelques trucs que ne sait faire IE. C'était là le sujet et c'était ma réponse à
ton affirmation que rien ne marchait dans IE. Cela dit, de fait tu conviens bien
qu'en graphisme c'est peu de choses et ce faisant tu abondes dans mon sens.
>
>> Mais je suis bien d'accord qu'il existe actuellement un vide béant : l'outil
qui permettrait de faire du (vrai) graphisme (avec les fonctionnalités d'un
illustrator ou d'un photoshop) et de coder à la fois de façon à faire
l'intégration directement en maquettant.
>
> Parle plutôt d'Indesign ou Xpress qui sont des outils de conception graphique
à l'inverse de Photoshop et d'Illustrator plutôt destinés à la création
d'images.
>
> Il est très difficile de concevoir un tel logiciel. En webdesign on peut
utiliser différentes options pour obtenir un même affichage, elles dépendent du
contexte, du contenu qui peut être changeant, rien n'est figé ni définitif comme
en imprimerie lorsque sortie de l'imprimante la mise en page ne change plus,
souvent le contenu est aléatoire, généré par un CMS, etc. Un logiciel, non doué
de raison :-) est bien incapable de faire un choix pour trouver les solutions
les meilleures relativement au contexte d'utilisation. Ceux qui s'y essaient
produisent le plus souvent un code bien pourri. Reste qu'il existe de très bons
éditeurs, avec prévisualisation instantanée des modifications qui une fois qu'on
connaît bien le html-css sont très efficaces et un vrai plaisir à utiliser.

Oui après 10 ans de print puis autant de web je commence à saisir la différence
!-)
J'imaginais un photoshop où on pourrait à la fois faire du graphisme (comme
actuellement) et styler en css ne serait-ce que les champs de texte. Ou
inversement un éditeur css qui proposerait une palette d'outils pour éditer
directement les images de background par exemple...

Mais effectivement toutes les tentatives en ce sens ne sont pas concluantes.
Mais je dis ça comme ça. Pour ma part je code tout "à la mano" depuis des années
et j'aurais du mal à utiliser un logiciel qui code à ma place. Je crois que si
je n'avais pas mes div et mes .class {...} sous les yeux je serais perdu !-)

pw

>



[Les parties de ce message comportant autre chose que du texte seul ont été
supprimées]

Le 25 déc. 2009 à 19:23, bruno.bichet a écrit :

> Oui, mais non : lors de ma dernière expérience de réunion avec un client,
> j'ai utilisé son matériel pour une démo. Il se trouve qu'il avait IE6
> installé,

Quel blaireau !

Si ça m'arrivait, je lui installerais gracieusement Firefox.

:-)

> Et je ne parle pas uniquement de client totalement néophyte, tu peux faire
> une réunion avec un pro qui t'offre son netbook (xp/ie6) pour tester un
> truc. Et là, t'as beau sortir un discours du type : "ouay, mais là, tu oua,
> j''suis overbooké, j'ai pas eu le temps de mettre mon propre site au point,
> toussa..." Ca sent un peu le #fail quand même ^^

Il y aura bientôt un an que je ne tiens plus compte d'IE6. C'est dans le cahier
des charges et le client peut toujours aller voir ailleurs. J'en ai eu marre de
m'échiner gratuitement pour cette daube car le temps passé en plus pour IE6
n'est jamais rémunéré.

À +
--
Jean

Le 25 décembre 2009 19:03, Jean Lespinasse
<jean.lespinasse@...>a écrit :

> Le 25 déc. 2009 à 15:55, Bruno a écrit :
>
> Reste que la plupart des visiteurs sont correctement équipés: avec IE6
> autour des 10 à 13% et le reste en navigateurs normaux.
>

Oui, mais non : lors de ma dernière expérience de réunion avec un client,
j'ai utilisé son matériel pour une démo. Il se trouve qu'il avait IE6
installé, et là, quand tu affiche ton site devant ton client, t'as pas
vraiment intérêt à lui proposer une version dégradé, fut-elle gracieusement
!

Et je ne parle pas uniquement de client totalement néophyte, tu peux faire
une réunion avec un pro qui t'offre son netbook (xp/ie6) pour tester un
truc. Et là, t'as beau sortir un discours du type : "ouay, mais là, tu oua,
j''suis overbooké, j'ai pas eu le temps de mettre mon propre site au point,
toussa..." Ca sent un peu le #fail quand même ^^

--
Bruno Bichet

Artisan en architecture de l'information appliquée aux sites web, Formateur
CHIC, intégrateur HTML et CSS
http://css4design.com/ »

L'actualité des blogs d'entreprise et de la blogosphère people (avec une
pointe de web 2.0 et parfois beaucoup de recul)
http://notoriousblog.fr/
Sent from Reserved, ***


[Les parties de ce message comportant autre chose que du texte seul ont été
supprimées]

Le 25 déc. 2009 à 15:55, Bruno a écrit :

> J'ai l'impression qu'il y a beaucoup d'incompréhension sur ce qu'est qu'une
prestation en webdesign parce que la plupart du temps, la "cerise sur la gâteau"
c'est justement ce le client a payé.

Et il l'a.

> […] on déplace la problématique sur le matériel utilisé par le client final :
ce n'est plus le webdesigner/intégrateur qui ne veut pas passer du temps sans
contrepartie financière, mais le visiteur qui n'est pas à jour.

C'est bien toujours comme ça. Chacun voit midi à son écran. Reste que la plupart
des visiteurs sont correctement équipés: avec IE6 autour des 10 à 13% et le
reste en navigateurs normaux. Mes clients sont soit sous Mac soit sous Windows à
jour, donc IE8. Pas de problème d'IE6, ni pour leur expliquer au besoin que même
si certains sont un peu à la traîne côté équipement d'une part j'ai choisi de
les avertir par un script leur conseillant la mise à niveau du navigateur,
d'autre part malgré cela ils auront accès à l'intégralité du site. Je dis bien
“au besoin” car je n'évoque jamais la question avec eux, pas la peine: ils
voient le site à leur écran…

À +
--
Jean

Le 24 déc. 2009 à 14:39, pascal weber a écrit :

> Lorsqu'un client paye un graphiste c'est pour avoir... du graphisme. Y compris
sur IE.
> Et comme je le disais le problème c'est surtout la pauvreté du css pour faire
du graphisme.

Sincèrement tu te trompes. Le graphisme est l'art de la mise en page, de
l'organisation de l'information, de « créer, choisir et utiliser des éléments
graphiques (dessins, caractères typographiques, photos, couleurs, etc.) pour
élaborer un objet de communication et/ou de culture » - comme défini dans
l'introduction de l'article Wikipedia sur le sujet. Pour ce faire les css sont
extrêmement efficaces.

> Si on utilise efficacement ses outils vectoriels, il suffit également de
changer un code couleur pour modifier une palette.

OK. Donne moi la manip à faire dans Illustrator, ou Indesign, ou XPress. Je ne
la connais pas. Ça pourra me servir: en une seule fois remplacer une couleur par
une autre sur l'ensemble d'un design. Merci d'avance.

> […] nous sommes justement bientôt en 2010 : dans une société de l'image et de
l'apparence, avec des outils très évolués, des smartphones, des écrans dont la
résolution ne cesse de s'affiner etc,

Voilà bien l'argument qui plaide en faveur des css et de leur potentiel
d'adaptation à des affichages changeants. L'interface d'iTunes est toute en css,
de même que celle de l'iPhone, pas d'images pour faire les boutons, tout est en
code, comme ici:

http://mwhenry.com/blog/examples/iphone_buttons/
http://www.launchpadhq.com/blog/2007/07/07/replicating-iphone-buttons-the-webkit\
-way/

Ceci pour illustrer la “puissance” du principe “css”.

> Bref une société où lorsqu'on vend une prestation graphique, le client ne paye
par pour avoir simplement des blocs aux coins arrondis et des ombres portées
(sauf sous IE !).

Tu ne comprends pas. Les coins arrondis et les ombres portées font partie des
quelques trucs que ne sait faire IE. C'était là le sujet et c'était ma réponse à
ton affirmation que rien ne marchait dans IE. Cela dit, de fait tu conviens bien
qu'en graphisme c'est peu de choses et ce faisant tu abondes dans mon sens.

> Mais je suis bien d'accord qu'il existe actuellement un vide béant : l'outil
qui permettrait de faire du (vrai) graphisme (avec les fonctionnalités d'un
illustrator ou d'un photoshop) et de coder à la fois de façon à faire
l'intégration directement en maquettant.

Parle plutôt d'Indesign ou Xpress qui sont des outils de conception graphique à
l'inverse de Photoshop et d'Illustrator plutôt destinés à la création d'images.

Il est très difficile de concevoir un tel logiciel. En webdesign on peut
utiliser différentes options pour obtenir un même affichage, elles dépendent du
contexte, du contenu qui peut être changeant, rien n'est figé ni définitif comme
en imprimerie lorsque sortie de l'imprimante la mise en page ne change plus,
souvent le contenu est aléatoire, généré par un CMS, etc. Un logiciel, non doué
de raison :-) est bien incapable de faire un choix pour trouver les solutions
les meilleures relativement au contexte d'utilisation. Ceux qui s'y essaient
produisent le plus souvent un code bien pourri. Reste qu'il existe de très bons
éditeurs, avec prévisualisation instantanée des modifications qui une fois qu'on
connaît bien le html-css sont très efficaces et un vrai plaisir à utiliser.

À +
--
Jean

Le 25 déc. 2009 à 00:57, Gildas Cotomale a écrit :

>> La plupart du temps, quand je sors d'une réunion client pour un site web,
>> j'ai déjà donné deux ou trois pistes à mon interlocuteur, de sorte que la
>> première proposition graphique est souvent attendu, il n'y a pas de surprise
>> qui nécessiterait une deuxième piste graphique.
>>
>> D'ailleurs, je suis adepte du One Shot, dans le sens où j'estime que le
>> client ne m'a pas payé pour lui faire plusieurs propositions entre lesquels
>> il devra choisir (c'est pas son boulot) mais pour lui faire une proposition
>> honnête qu'il faudra sans doute améliorer par la suite sachant qu'elle
>> correspond au cahier des charges.
>>

> outre le fait que ce n'est pas son boulot (plus il y a de propositions
> ça signifie qu'on ne l'a pas bien aidé à spécifier son besoin ou
> peut-être qu'on ne sait pas bien y répondre), faut voir le temps et
> l'énergie que ça perd... tout à fait d'accord avec le principe du one
> shot & rulez (le client apprécie cette efficacité)

Finalement bien d'accord avec vous deux.

--
Jean

Le 25 déc. 2009 à 15:55, Bruno a écrit :

> > un site dégradé n'est quand même pas un site sans style non ? il ne
> > faut pas confondre un "site qui ne fonctionne pas" avec un site qui
> > dégrade : c'est juste que tu n'as pas la cerise sur le gâteau où le
> > petit parfum de rose en plus, mais tu as le gâteau ;
>
> On avait déjà vu "il y a internet et internet" et maintenant sous prétexte de
dégradation gracieuse on va finir avec "il y a webdesign et webdesign" ;)
>
> J'ai l'impression qu'il y a beaucoup d'incompréhension sur ce qu'est qu'une
prestation en webdesign parce que la plupart du temps, la "cerise sur la gâteau"
c'est justement ce le client a payé.
>
> Le webdesign est un métier à part entière qui se trouve vraiment à la limite
du graphisme et du développement en terme d'état d'esprit. La plupart du temps,
les partisans de la dégradation gracieuse sont :
>
> - soit des graphistes qui vont au plus simple : ne pas se prendre la tête avec
ie6)
>
> - soit des profils plus "développeur" qui sont satisfaits quand les
fonctionnalités sont là : qu'importe le flacon pourvu qu'on ait l'ivresse.
>
> Bref, reste à trouver l'entre-deux.
>
> Reste aussi l'amélioration progressive. En fonction des besoins exprimés par
le client, il est possible de dire : voilà ce qu'on peut faire dans un premier
temps pour satisfaire les exigences du parc d'UA installé. Et dans un deuxième
temps, on ajoute une couche de gloss pour ceux qui sont mieux équipés.
>
> Souvent, dit comme ça, vis à vis du client, on déplace la problématique sur le
matériel utilisé par le client final : ce n'est plus le webdesigner/intégrateur
qui ne veut pas passer du temps sans contrepartie financière, mais le visiteur
qui n'est pas à jour.

Tout à fait d'accord. Tout comme je suis d'accord avec Fabien lorsqu'il évoque
le fait que les "papes" du design "pur code" ne proposent généralement pas de
sites visuellement très sexy.

Non je ne confonds pas un site qui ne fonctionne pas avec une site dégradé. Mais
SI : un site dégradé est de fait un site sans style. En tout cas pas dans le
style que le client a payé.

Et je ne vois pas au nom de quoi, alors que rien ne l'empêche techniquement à
part un "purisme" déplacé, un client paierait pour une charte graphique visible
uniquement par 20% des visiteurs. Il me semble que le boulot de webdesigner
n'est pas de livrer un site "pur code" mais un site qui affiche correctement le
design que le client a acheté sur les machines que ses visiteurs utilisent, à
savoir sous IE pour les deux tiers. On peut effectivement souvent négocier un
affichage dégradé sous IE6 en argumentant sur l'obsolescence de cette version,
mais sous IE7/8 c'est non négociable.

Mais le sujet de départ c'est la méthodologie qui consiste à maquetter tout en
code et à ne plus utiliser Photoshop ou autres outils graphiques pour produire
des maquettes. Je faisais simplement remarquer que les coins arrondis en css3
c'est "super" (youpi l'extase !) mais ça limite beaucoup les possibilités
graphiques.

@ Gildas :

> :-/ donc au final, le site il se fait pas avec du css ?
> (ceci dit, les CSS c'est l'habillage du site... je veux dire par là
> que tu peux t'amuser à avoir des blocs en désordre et réarranger le
> flux à ta convenance en utilisant les feuilles de style... ça te fera
> l'ossature de la page. pour moi, graphisme, c'est faire des images...
> mais les images ne feront jamais le site --sauf si ce ne sont que des
> images ou du flash et non une page web-- et tu auras besoin de css
> pour intégrer tes images de fond par exemple)

Qui a dit qu'il faut se passer de css ? Je ne vois d'ailleurs pas comment on
peut gérer l'aspect d'une page web autrement qu'avec une feuille de style ?

Ce qui est gênant, ce sont les évangélistes qui prêchent LA bonne méthode. C'est
d'ailleurs pour ça, au fond, que le sujet fait réagir. Car chacun a ses méthodes
de travail et je ne crois pas qu'il y en ait une meilleure qu'une autre. La
meilleure méthode, c'est celle qui convient à chacun. Je trouve insultant de
dire à quelqu'un qui maquette sous Photoshop "réveille-toi on est en 2010". Ca
équivaut à dire à un écrivain qui travaillerait avec un stylo et un cahier qu'il
est un mauvais écrivain parce qu'il n'utilise pas un ordinateur portable...

Qu'importent les outils et la méthode. Le client paye pour une charte graphique.
Son site doit afficher correctement cette charte chez 99% des visiteurs de son
site. Et tout ça en respectant les standards et en étant accessible. C'est pas
toujours évident, ça demande parfois du temps, chacun a des outils et des
méthodes avec lesquels il se sent à l'aise et lui permettent de faire le boulot
pour lequel on le paye. Et le client ainsi que les visiteurs n'ont strictement
rien à f... de savoir si le design est "pur code" ou "made in photoshop". Je
crois.

Pw

[Les parties de ce message comportant autre chose que du texte seul ont été
supprimées]

--- Dans pompeurs@..., Gildas Cotomale <gildas.cotomale@...> a
écrit :

> un site dégradé n'est quand même pas un site sans style non ? il ne
> faut pas confondre un "site qui ne fonctionne pas" avec un site qui
> dégrade : c'est juste que tu n'as pas la cerise sur le gâteau où le
> petit parfum de rose en plus, mais tu as le gâteau ;

On avait déjà vu "il y a internet et internet" et maintenant sous prétexte de
dégradation gracieuse on va finir avec "il y a webdesign et webdesign" ;)

J'ai l'impression qu'il y a beaucoup d'incompréhension sur ce qu'est qu'une
prestation en webdesign parce que la plupart du temps, la "cerise sur la gâteau"
c'est justement ce le client a payé.

Le webdesign est un métier à part entière qui se trouve vraiment à la limite du
graphisme et du développement en terme d'état d'esprit. La plupart du temps, les
partisans de la dégradation gracieuse sont :

- soit des graphistes qui vont au plus simple : ne pas se prendre la tête avec
ie6)

- soit des profils plus "développeur" qui sont satisfaits quand les
fonctionnalités sont là : qu'importe le flacon pourvu qu'on ait l'ivresse.

Bref, reste à trouver l'entre-deux.

Reste aussi l'amélioration progressive. En fonction des besoins exprimés par le
client, il est possible de dire : voilà ce qu'on peut faire dans un premier
temps pour satisfaire les exigences du parc d'UA installé. Et dans un deuxième
temps, on ajoute une couche de gloss pour ceux qui sont mieux équipés.

Souvent, dit comme ça, vis à vis du client, on déplace la problématique sur le
matériel utilisé par le client final : ce n'est plus le webdesigner/intégrateur
qui ne veut pas passer du temps sans contrepartie financière, mais le visiteur
qui n'est pas à jour.

bruno bichet

le 25/12/09 1:50, Fabien Basmaison à fabien.basmaison@... a écrit :

> Joyeux Noël à toutes et à tous !

... juste comme ça, histoire de se souvenir, il me semble qu'il y a plus de
10 années de cela, Dreamweaver de Macromédia d'alors proposait déjà les
ombres portées dans sa palette d'effets CSS ... mais cela ne fonctionnait
seulement et que sur IE5 ou 4 alors qu'on développait traditionnellement
pour IE3 !!! (si mes souvenirs troublés par les fêtes ne me traïssent pas
;-)

... Bonnes fêtes à vous

Cordialement
Michel Wagner

On 24/12/2009 19:39, Jean Lespinasse wrote:
> Relis l'article. C'est très pertinent. Et réveille-toi, nous sommes bientôt
en 2010.
>

Bonjour la liste...

De mon côté, je ne trouve pas du tout cette remarque pertinente. Quand
je lis cette article, j'ai l'impression de retomber sur une maquette
identique à ce que faisais Zeldman dans "Design Web : Utilisez les
standards". Et excusez du peu, c'est tout sauf "sexy".

J'ai de plus souvent l'impression qu'elle utilise Photoshop plus comme
une excuse pour écrire un article sur "Comment utiliser des technologies
CSS 3". Honnêtement, quand je lis "Switching to rounded corners is a
nightmare if you´re doing your mockup in Photoshop, since it means
recreating most of the shapes and UI elements in the design.", je ne
comprends pas trop la relation. Qui a dit qu'utiliser Photoshop revient
à copier / coller des images ? Avoir l'aspect graphique au préalable et
pouvoir l'affiner pour ensuite le transposer (avec les informations
correspondant aux border-radius, etc.) est quand même un plus à mon avis.

L'équipe qui va faire un bête copier/coller depuis le logiciel
permettant de créer un layout vers le code a clairement un problème,
mais ce n'est pas la faute au logiciel, c'est celle de l'équipe qui ne
sait pas travailler de concert ou utiliser les logiciels à sa
disposition de manière efficace.

Il suffit juste de pas faire les choses bêtement, quoi. Je trouve
vraiment pas que cet article mérite autant d'intérêt ou de compliments,
tellement il donne l'impression de taper sur l'un pour valoriser l'autre.

Joyeux Noël à toutes et à tous !

> Lorsqu'un client paye un graphiste c'est pour avoir... du graphisme. Y compris
sur IE.
> Et comme je le disais le problème c'est surtout la pauvreté du css pour
faire du graphisme.
>
:-/ donc au final, le site il se fait pas avec du css ?
(ceci dit, les CSS c'est l'habillage du site... je veux dire par là
que tu peux t'amuser à avoir des blocs en désordre et réarranger le
flux à ta convenance en utilisant les feuilles de style... ça te fera
l'ossature de la page. pour moi, graphisme, c'est faire des images...
mais les images ne feront jamais le site --sauf si ce ne sont que des
images ou du flash et non une page web-- et tu auras besoin de css
pour intégrer tes images de fond par exemple)

>>
>> Enfin si au final ça dérange le client rien ne t'empêche de réaliser le
design à l'ancienne: avec des images de fond. Ça ne change rien pour toi, ni
à ce que tu préfères. Sauf qu'en tapant directement dans le code tu gagnes un
temps fou en développement. Même en vectoriel, si tu dois changer la couleur
de fond de 6 blocs empilés en couches superposées ça prend du temps alors
qu'en CSS tu passes en quelques secondes de [color: rgba(44,67,99,0.4); à
color: rgba(235,98,122,0.7);] et le tour est joué.
>
je fais plutôt l'inverse : mes images sont des captures d'écran...
l'essentiel du travail est fait dans l'éditeur web =p

> Si on utilise efficacement ses outils vectoriels, il suffit également de
changer un code couleur pour modifier une palette.
>
>> Tu auras pu expérimenter et présenter rapidement des modèles différents
avant le choix définitif sans perdre du temps dans Illustrator pour devoir tout
refaire en html-css ensuite.
>
oui, pas de double travail... (bon, s'il y a double rémunération, je
dis pas non)

>>
>> Relis l'article. C'est très pertinent. Et réveille-toi, nous sommes
bientôt en 2010.
>>
>> :-)
>
> Je suis en grande partie d'accord sur le fond, mais seulement lorsqu'on
travaille sur des sites graphiquement pauvres.
> Et nous sommes justement bientôt en 2010 : dans une société de l'image et
de l'apparence, avec des outils très évolués, des smartphones, des écrans
dont la résolution ne cesse de s'affiner etc, des outils gratuits souvent
géniaux qui font de chacun un vidéaste ou un graphiste en trois clics. Bref
une société où lorsqu'on vend une prestation graphique, le client ne paye par
pour avoir simplement des blocs aux coins arrondis et des ombres portées (sauf
sous IE !).
>>
>
au fait, l'auter de l'article est dans l'univers de l'image (d'après
sa courte biographie) en plus de faire du design web

> Mais je suis bien d'accord qu'il existe actuellement un vide béant : l'outil
qui permettrait de faire du (vrai) graphisme (avec les fonctionnalités d'un
illustrator ou d'un photoshop) et de coder à la fois de façon à faire
l'intégration directement en maquettant. Avis aux éditeurs de logiciels !
>
là, le seul éditeur qui peut te donner bonheur est Microsoft... quand
les navigateurs sont norme-compliants, tu pourras faire beaucoup de
choses avec ton logiciel graphique et récupérer le SVG dans ta page...
entre temps, je demande de tester Amaya :)

> La plupart du temps, quand je sors d'une réunion client pour un site web,
> j'ai déjà donné deux ou trois pistes à mon interlocuteur, de sorte que la
> première proposition graphique est souvent attendu, il n'y a pas de surprise
> qui nécessiterait une deuxième piste graphique.
>
> D'ailleurs, je suis adepte du One Shot, dans le sens où j'estime que le
> client ne m'a pas payé pour lui faire plusieurs propositions entre lesquels
> il devra choisir (c'est pas son boulot) mais pour lui faire une proposition
> honnête qu'il faudra sans doute améliorer par la suite sachant qu'elle
> correspond au cahier des charges.
>
outre le fait que ce n'est pas son boulot (plus il y a de propositions
ça signifie qu'on ne l'a pas bien aidé à spécifier son besoin ou
peut-être qu'on ne sait pas bien y répondre), faut voir le temps et
l'énergie que ça perd... tout à fait d'accord avec le principe du one
shot & rulez (le client apprécie cette efficacité)

> Dès lors qu'on fait du design un peu graphique et non plus de la simple mise
en page basique, on touche très vite les limites du procédé. Et si en plus
ça ne fonctionne pas dans IE7/8 ! C'est déjà la croix et la bannière pour
faire accepter au client que les visiteurs qui naviguent avec IE6  ne peuvent
pas voir la même chose que les autres... Un site qui s'affiche de façon
dégradée dans IE8 c'est carrément inconcevable si on veut que le client paye
sa facture et que l'histoire ne finisse pas au tribunal...

un site dégradé n'est quand même pas un site sans style non ? il ne
faut pas confondre un "site qui ne fonctionne pas" avec un site qui
dégrade : c'est juste que tu n'as pas la cerise sur le gâteau où le
petit parfum de rose en plus, mais tu as le gâteau ; et le client ne
voit pas la différence s'il utilise ie. (en ce qui me concerne, on
valide toujours dans le navigateur du client -même si c'est ie2-- et
pourtant je ne travaille pas avec ie dont il n'y aucune trace sur mes
machines)


my 0.02EUR

Le 24 déc. 2009 à 12:39, Jean Lespinasse a écrit :

> Le 24 déc. 2009 à 12:14, pascal weber a écrit :
>
>> Ca vaut pour du design ultra basique comme celui présenté dans l'article.
>>
>> Dès lors qu'on fait du design un peu graphique et non plus de la simple mise
en page basique, on touche très vite les limites du procédé. Et si en plus ça ne
fonctionne pas dans IE7/8 !
>
> As-tu bien lu l'article ? As-tu compris ? Qu'est ce qui ne fonctionne pas dans
IE: Les blocs à coins arrondis, les ombres portées sur les caractères, sur les
blocs… Pour le reste la mise en page est la même et comme je le dis bien, ça ne
se casse pas la gueule. Ça n'est pas gênant et comme le dit l'auteur.

Lorsqu'un client paye un graphiste c'est pour avoir... du graphisme. Y compris
sur IE.
Et comme je le disais le problème c'est surtout la pauvreté du css pour faire du
graphisme.

>
> Enfin si au final ça dérange le client rien ne t'empêche de réaliser le design
à l'ancienne: avec des images de fond. Ça ne change rien pour toi, ni à ce que
tu préfères. Sauf qu'en tapant directement dans le code tu gagnes un temps fou
en développement. Même en vectoriel, si tu dois changer la couleur de fond de 6
blocs empilés en couches superposées ça prend du temps alors qu'en CSS tu passes
en quelques secondes de [color: rgba(44,67,99,0.4); à color:
rgba(235,98,122,0.7);] et le tour est joué.

Si on utilise efficacement ses outils vectoriels, il suffit également de changer
un code couleur pour modifier une palette.

> Tu auras pu expérimenter et présenter rapidement des modèles différents avant
le choix définitif sans perdre du temps dans Illustrator pour devoir tout
refaire en html-css ensuite.

>
> Relis l'article. C'est très pertinent. Et réveille-toi, nous sommes bientôt en
2010.
>
> :-)

Je suis en grande partie d'accord sur le fond, mais seulement lorsqu'on
travaille sur des sites graphiquement pauvres.
Et nous sommes justement bientôt en 2010 : dans une société de l'image et de
l'apparence, avec des outils très évolués, des smartphones, des écrans dont la
résolution ne cesse de s'affiner etc, des outils gratuits souvent géniaux qui
font de chacun un vidéaste ou un graphiste en trois clics. Bref une société où
lorsqu'on vend une prestation graphique, le client ne paye par pour avoir
simplement des blocs aux coins arrondis et des ombres portées (sauf sous IE !).
>

Mais je suis bien d'accord qu'il existe actuellement un vide béant : l'outil qui
permettrait de faire du (vrai) graphisme (avec les fonctionnalités d'un
illustrator ou d'un photoshop) et de coder à la fois de façon à faire
l'intégration directement en maquettant. Avis aux éditeurs de logiciels !



[Les parties de ce message comportant autre chose que du texte seul ont été
supprimées]

Le 24 décembre 2009 12:14, pascal weber <p.weber@...> a écrit :

> Ca vaut pour du design ultra basique comme celui présenté dans l'article.
> Dès lors qu'on fait du design un peu graphique et non plus de la simple
> mise en page basique, on touche très vite les limites du procédé.
>



> Le 24 déc. 2009 à 11:48, Jean Lespinasse a écrit :
>
> > Bonjour,
> Travaillez directement en html-css. Depuis que j'ai découvert le pompage et
> les pompeurs, j'ai toujours fait comme ça, me voici conforté dans mes
> intuitions.
>

J'ai adopté depuis longtemps une approche souple qui mixe le meilleur des
deux mondes. Je fais généralement une maquette sous photoshop ou illustrator
selon les besoins *pour moi* et je fais l'intégration dans la foulée que je
présente au client.

La plupart du temps, quand je sors d'une réunion client pour un site web,
j'ai déjà donné deux ou trois pistes à mon interlocuteur, de sorte que la
première proposition graphique est souvent attendu, il n'y a pas de surprise
qui nécessiterait une deuxième piste graphique.

D'ailleurs, je suis adepte du One Shot, dans le sens où j'estime que le
client ne m'a pas payé pour lui faire plusieurs propositions entre lesquels
il devra choisir (c'est pas son boulot) mais pour lui faire une proposition
honnête qu'il faudra sans doute améliorer par la suite sachant qu'elle
correspond au cahier des charges.

Bref, de mon point de vue, une fois que le client commence à manipuler son
site, les choses sont beaucoup plus simples et les modifications demandées
beaucoup moins nombreuses qu'après une présentation à l'ancienne de la
maquette purement graphique en couleur sur un papier souvent flatteur, sans
aucun rapport avec le rendu à l'écran.

Mais, il arrive que le projet et/ou le client ait de fortes attentes non
exprimées sur l'univers graphique dans lequel il se surinvestit, genre,
"l'apparence de mon site doit représenter toutes les valeurs contradictoire
de l'entreprise, etc". Dans ce cas, le client vient souvent avec plein
d'idées, des maquettes, des bout de tissus, des chiffons, etc. Dans ces
cas-là, on sait tout de suite, qu'on va en baver. Epicétou ;)

--
Bruno Bichet

Artisan en architecture de l'information appliquée aux sites web, Formateur
CHIC, intégrateur HTML et CSS
http://css4design.com/ »

L'actualité des blogs d'entreprise et de la blogosphère people (avec une
pointe de web 2.0 et parfois beaucoup de recul)
http://notoriousblog.fr/


[Les parties de ce message comportant autre chose que du texte seul ont été
supprimées]

Le 24 déc. 2009 à 12:14, pascal weber a écrit :

> Ca vaut pour du design ultra basique comme celui présenté dans l'article.
>
> Dès lors qu'on fait du design un peu graphique et non plus de la simple mise
en page basique, on touche très vite les limites du procédé. Et si en plus ça ne
fonctionne pas dans IE7/8 !

As-tu bien lu l'article ? As-tu compris ? Qu'est ce qui ne fonctionne pas dans
IE: Les blocs à coins arrondis, les ombres portées sur les caractères, sur les
blocs… Pour le reste la mise en page est la même et comme je le dis bien, ça ne
se casse pas la gueule. Ça n'est pas gênant et comme le dit l'auteur.

Enfin si au final ça dérange le client rien ne t'empêche de réaliser le design à
l'ancienne: avec des images de fond. Ça ne change rien pour toi, ni à ce que tu
préfères. Sauf qu'en tapant directement dans le code tu gagnes un temps fou en
développement. Même en vectoriel, si tu dois changer la couleur de fond de 6
blocs empilés en couches superposées ça prend du temps alors qu'en CSS tu passes
en quelques secondes de [color: rgba(44,67,99,0.4); à color:
rgba(235,98,122,0.7);] et le tour est joué. Tu auras pu expérimenter et
présenter rapidement des modèles différents avant le choix définitif sans perdre
du temps dans Illustrator pour devoir tout refaire en html-css ensuite.

Relis l'article. C'est très pertinent. Et réveille-toi, nous sommes bientôt en
2010.

:-)

PS: n'oublie pas qu'il faut poster la réponse après la citation en ayant pris
soin de supprimer tout texte inutile à la compréhension de l'échange.

À +
--
Jean

Ca vaut pour du design ultra basique comme celui présenté dans l'article.

Dès lors qu'on fait du design un peu graphique et non plus de la simple mise en
page basique, on touche très vite les limites du procédé. Et si en plus ça ne
fonctionne pas dans IE7/8 ! C'est déjà la croix et la bannière pour faire
accepter au client que les visiteurs qui naviguent avec IE6  ne peuvent pas voir
la même chose que les autres... Un site qui s'affiche de façon dégradée dans IE8
c'est carrément inconcevable si on veut que le client paye sa facture et que
l'histoire ne finisse pas au tribunal... Va faire comprendre, même à un
juge-geek, que ton client doit payer pour un site qui ne s'affiche normalement
que pour 20% des visiteurs (dans le meilleur des cas...).

Perso je n'utilise pas photoshop car je préfère travailler en vectoriel (surtout
si les éléments de la charte graphique du site doivent être repris pour du
print), mais je pense qu'il permet d'aller tout de même beaucoup plus loin en
matière de graphisme et qu'il a donc encore de beaux jours devant lui...

pw


Le 24 déc. 2009 à 11:48, Jean Lespinasse a écrit :

> Bonjour,
>
> Excellent article mais en anglais ; IE6 s'abstenir, bien sûr.
>
> http://24ways.org/2009/make-your-mockup-in-markup
>
> On notera l'utilisation intelligente des ombres et transparences et CSS3:
text-shadow, box-shadow, opacité, couleurs en RGBA, etc. Bien sûr ça ne marche
pas dans IE7-8 mais voici ce que l'auteur en pense : “we should create designs
that are beautiful in modern browsers, but still degrade nicely for the other
guy.” La prime aux « bons » brouteurs dans lesquels les pages seront plus jolies
sans pour autant se ramasser dans IE > 6.
>
> Au final, primordial, à retenir et à appliquer, en somme le B+A = BA: ne
faites surtout pas les maquettes de vos sites dans Photoshop ou autre pour les
décliner (traduire ?) ensuite. Travaillez directement en html-css. Depuis que
j'ai découvert le pompage et les pompeurs, j'ai toujours fait comme ça, me voici
conforté dans mes intuitions.
>
> Vade retro Toshop, plongez dans le code ! :-)
>
> À +
> --
> Jean
>
>
>

Bonjour,

Excellent article mais en anglais ; IE6 s'abstenir, bien sûr.

http://24ways.org/2009/make-your-mockup-in-markup

On notera l'utilisation intelligente des ombres et transparences et CSS3:
text-shadow, box-shadow, opacité, couleurs en RGBA, etc. Bien sûr ça ne marche
pas dans IE7-8 mais voici ce que l'auteur en pense : “we should create designs
that are beautiful in modern browsers, but still degrade nicely for the other
guy.” La prime aux « bons » brouteurs dans lesquels les pages seront plus jolies
sans pour autant se ramasser dans IE > 6.

Au final, primordial, à retenir et à appliquer, en somme le B+A = BA: ne faites
surtout pas les maquettes de vos sites dans Photoshop ou autre pour les décliner
(traduire ?) ensuite. Travaillez directement en html-css. Depuis que j'ai
découvert le pompage et les pompeurs, j'ai toujours fait comme ça, me voici
conforté dans mes intuitions.

Vade retro Toshop, plongez dans le code ! :-)

À +
--
Jean

> bonjour,
>
> Pour conserver la hauteur de tes onglets , quelque soit la taille des
> caractéres , il vaut mieux la fixée et ne pas faire usage des marges
> internes horizontal(padding-top et bottom).
>
> Tu peut par exemple modifier le comportement de tes span flottant .

En faisant les recommandations indiquées avec une hauteur de 27px (et
28px pour le span current), ça marche nickel !

Merci !!!

Il ne me reste plus que le pb de formulaire de login à résoudre...

Boby
>
> En imposant les marges internes latérales uniquement , une hauteur
> (25px a 27px a la louche) et un line-height équivalent a la hauteur
> (si on prend la louche , c'est entre 25px et 27px:) . Tant que tes
> onglets n'auront qu'une ligne de texte cela conviendra.
> Cela n'empêchera pas les onglets de s'élargir .
>
> L'onglet actif aurait besoin d'une hauteur d'1 pixel supplémentaire
> pour cacher la bordure (basse) .. a verifier  .
> le site et Le menu semble supporter un grossissement du texte
> d'environ 200% avec FF vista, (body: font-size:2em , contre 0.8em
> dans la feuille de style).
>
> Pour safari , je n'ai qu'une version windows et je ne remarque pas de
> différence sur la position de ton premer formulaire.
>
> Cordialement.
>
>
>
>
>
> To: pompeurs@...
> From: boby.k@...
> Date: Sat, 19 Dec 2009 17:09:54 +0100
> Subject: [pompeurs-css] Re: décalage entre FF sous XP, linux et Mac,
> et pb pour Safari  sous Mac
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>       ---- Original Message ----
>
>
>
>> Le 18 déc. 09 à 16:02, Boby k a écrit :
>
>>
>
>>> Bonjour
>
>>>
>
>>> Je suis en train de développer un site et j'ai eu des retours
>
>>> négatifs
>
>>> pour des utilisateurs de FF et safari sous linux et Mac.
>
>>>
>
>>> Je travaille sous XP et chez moi, sous FF et IE, tout s'affiche
>>> bien.
>
>>> Voici les pb relevés sur le site test
>
>>> http://hgse.free.fr :
>
>>> - Sous FF linux, le menu horizontal (onglets) et légèrement espacé
>>> du
>
>>> bloc principal au dessus (il ne "repose" pas dessus comme il
>>> devrait)
>
>>> - Sous FF Mac, idem mais avec encore plus de décalage
>
>>> - Sous Safari Mac, menu horizontal "fou" ! (complètement décalé sur
>
>>> trois niveaux) et formulaire de login tout à gauche de la fenêtre
>>> (et
>
>>> pas aligné sur le div page)
>
>>>
>
>>> Sauriez-vous d'où viennent ces pbs ? Comment les corriger ?
>
>>
>
>> Déjà tu peux corriger 180 warning qui portent sur :
>
>> <!--- rubriques contextuelles -(fonction du menu horizontal) --->
>
>>
>
>> <!-- mon commentaire.... --> devrait calmer tidy.
>
>>
>
>
>
> J'ai corrigé ces erreurs, merci !
>
>
>
>> Sinon sous safari mac le menu horizontal est sur deux niveau chez
>
>> moi...
>
>
>
> Oui, oui, c'est normal. Il doit y avoir 5 menus sur la même ligne (les
>
> régions) et un menu sur une seule (l'inter)
>
>
>
> Suite à vos remarques (différences de tailles de caractères entre
> linux,
>
> mac et XP), je me suis rendu compte effectivement que sous FF XP, si
> je
>
> fais un zoom (menu affichage zoom), cela me décale mon menu horizontal
>
> par rapport au div sur lequel il est censé "poser".
>
> le header-content qui contient mon menu est toujours à une position
> top
>
> de 158px et mon div content de 214px. Pourtant que je zoom en + ou en
> -,
>
> cela écarte mon menu du div content. Le pb vient donc bien de la
> taille
>
> de police dans le menu. Auriez-vous une solution ?
>
>
>
> Par ailleurs, comment expliquer que le formulaire de login soit tout à
>
> gauche dans safari ???
>
>
>
> Vous remerciant
>
>
>
> Boby
>
>
>
>>
>
>> pierre
>
>>
>
>
>
> page : margin-top 35px
>
> content :
>
> margin 177px
>
> header-content :
>
> top 123px
>
> height 70px
>
>
>
> [Les parties de ce message comportant autre chose que du texte seul
> ont été supprimées]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _________________________________________________________________
> Tchattez en direct en en vidéo avec vos amis !
> http://www.windowslive.fr/messenger/
>
> [Les parties de ce message comportant autre chose que du texte seul
> ont été supprimées]
>
>
>
> ------------------------------------
>
> Liens Yahoo! Groupes
>
>
>

bonjour,

Pour conserver la hauteur de tes onglets , quelque soit la taille des caractéres
, il vaut mieux la fixée et ne pas faire usage des marges internes
horizontal(padding-top et bottom).

Tu peut par exemple modifier le comportement de tes span flottant .

En imposant les marges internes latérales uniquement , une hauteur (25px a 27px
a la louche) et un line-height équivalent a la hauteur (si on prend la louche ,
c'est entre 25px et 27px:) . Tant que tes onglets n'auront qu'une ligne de texte
cela conviendra.
Cela n'empêchera pas les onglets de s'élargir .

L'onglet actif aurait besoin d'une hauteur d'1 pixel supplémentaire pour cacher
la bordure (basse) .. a verifier  .
le site et Le menu semble supporter un grossissement du texte d'environ 200%
avec FF vista, (body: font-size:2em , contre 0.8em  dans la feuille de style).

Pour safari , je n'ai qu'une version windows et je ne remarque pas de différence
sur la position de ton premer formulaire.

Cordialement.





To: pompeurs@...
From: boby.k@...
Date: Sat, 19 Dec 2009 17:09:54 +0100
Subject: [pompeurs-css] Re: décalage entre FF sous XP, linux et Mac, et pb pour
Safari  sous Mac




























       ---- Original Message ----



> Le 18 déc. 09 à 16:02, Boby k a écrit :

>

>> Bonjour

>>

>> Je suis en train de développer un site et j'ai eu des retours

>> négatifs

>> pour des utilisateurs de FF et safari sous linux et Mac.

>>

>> Je travaille sous XP et chez moi, sous FF et IE, tout s'affiche bien.

>> Voici les pb relevés sur le site test

>> http://hgse.free.fr :

>> - Sous FF linux, le menu horizontal (onglets) et légèrement espacé du

>> bloc principal au dessus (il ne "repose" pas dessus comme il devrait)

>> - Sous FF Mac, idem mais avec encore plus de décalage

>> - Sous Safari Mac, menu horizontal "fou" ! (complètement décalé sur

>> trois niveaux) et formulaire de login tout à gauche de la fenêtre (et

>> pas aligné sur le div page)

>>

>> Sauriez-vous d'où viennent ces pbs ? Comment les corriger ?

>

> Déjà tu peux corriger 180 warning qui portent sur :

> <!--- rubriques contextuelles -(fonction du menu horizontal) --->

>

> <!-- mon commentaire.... --> devrait calmer tidy.

>



J'ai corrigé ces erreurs, merci !



> Sinon sous safari mac le menu horizontal est sur deux niveau chez

> moi...



Oui, oui, c'est normal. Il doit y avoir 5 menus sur la même ligne (les

régions) et un menu sur une seule (l'inter)



Suite à vos remarques (différences de tailles de caractères entre linux,

mac et XP), je me suis rendu compte effectivement que sous FF XP, si je

fais un zoom (menu affichage zoom), cela me décale mon menu horizontal

par rapport au div sur lequel il est censé "poser".

le header-content qui contient mon menu est toujours à une position top

de 158px et mon div content de 214px. Pourtant que je zoom en + ou en -,

cela écarte mon menu du div content. Le pb vient donc bien de la taille

de police dans le menu. Auriez-vous une solution ?



Par ailleurs, comment expliquer que le formulaire de login soit tout à

gauche dans safari ???



Vous remerciant



Boby



>

> pierre

>



page : margin-top 35px

content :

margin 177px

header-content :

top 123px

height 70px



[Les parties de ce message comportant autre chose que du texte seul ont été
supprimées]


















_________________________________________________________________
Tchattez en direct en en vidéo avec vos amis !
http://www.windowslive.fr/messenger/

[Les parties de ce message comportant autre chose que du texte seul ont été
supprimées]

---- Original Message ----


> Le 18 déc. 09 à 16:02, Boby k a écrit :
>
>> Bonjour
>>
>> Je suis en train de développer un site et j'ai eu des retours
>> négatifs
>> pour des utilisateurs de FF et safari sous linux et Mac.
>>
>> Je travaille sous XP et chez moi, sous FF et IE, tout s'affiche bien.
>> Voici les pb relevés sur le site test
>> http://hgse.free.fr :
>> - Sous FF linux, le menu horizontal (onglets) et légèrement espacé du
>> bloc principal au dessus (il ne "repose" pas dessus comme il devrait)
>> - Sous FF Mac, idem mais avec encore plus de décalage
>> - Sous Safari Mac, menu horizontal "fou" ! (complètement décalé sur
>> trois niveaux) et formulaire de login tout à gauche de la fenêtre (et
>> pas aligné sur le div page)
>>
>> Sauriez-vous d'où viennent ces pbs ? Comment les corriger ?
>
> Déjà tu peux corriger 180 warning qui portent sur :
> <!--- rubriques contextuelles -(fonction du menu horizontal) --->
>
> <!-- mon commentaire.... --> devrait calmer tidy.
>

J'ai corrigé ces erreurs, merci !


> Sinon sous safari mac le menu horizontal est sur deux niveau chez
> moi...

Oui, oui, c'est normal. Il doit y avoir 5 menus sur la même ligne (les
régions) et un menu sur une seule (l'inter)

Suite à vos remarques (différences de tailles de caractères entre linux,
mac et XP), je me suis rendu compte effectivement que sous FF XP, si je
fais un zoom (menu affichage zoom), cela me décale mon menu horizontal
par rapport au div sur lequel il est censé "poser".
le header-content qui contient mon menu est toujours à une position top
de 158px et mon div content de 214px. Pourtant que je zoom en + ou en -,
cela écarte mon menu du div content. Le pb vient donc bien de la taille
de police dans le menu. Auriez-vous une solution ?

Par ailleurs, comment expliquer que le formulaire de login soit tout à
gauche dans safari ???

Vous remerciant

Boby

>
> pierre
>

page : margin-top 35px
content :
margin 177px
header-content :
top 123px
height 70px




[Les parties de ce message comportant autre chose que du texte seul ont été
supprimées]

Les décalages sur Linux et Mac sont souvent dus à l'affichage du texte : Je
trouve que les polices linux semblent plus épaisses, et il me semble que le
lissage des polices sur Mac fait grossir le texte de quelques pixels, ce qui
suffit à décaler en largeur ou en hauteur.

Le 18 déc. 09 à 16:02, Boby k a écrit :
>
> > Bonjour
> >
> > Je suis en train de développer un site  et j'ai eu des retours
> > négatifs
> > pour des utilisateurs de FF et safari sous linux et Mac.
>
--
Goulven Champenois


[Les parties de ce message comportant autre chose que du texte seul ont été
supprimées]

Le 18 déc. 09 à 16:02, Boby k a écrit :

> Bonjour
>
> Je suis en train de développer un site  et j'ai eu des retours
> négatifs
> pour des utilisateurs de FF et safari sous linux et Mac.
>
> Je travaille sous XP et chez moi, sous FF et IE, tout s'affiche bien.
> Voici les pb relevés sur le site test
> http://hgse.free.fr  :
> - Sous FF linux, le menu horizontal (onglets) et légèrement espacé du
> bloc principal au dessus (il ne "repose" pas dessus comme il devrait)
> - Sous FF Mac, idem mais avec encore plus de décalage
> - Sous Safari Mac, menu horizontal "fou" ! (complètement décalé sur
> trois niveaux) et formulaire de login tout à gauche de la fenêtre (et
> pas aligné sur le div page)
>
> Sauriez-vous d'où viennent ces pbs ? Comment les corriger ?


Déjà tu peux corriger  180 warning qui portent sur :
    <!--- rubriques contextuelles  -(fonction du menu horizontal) --->


<!-- mon commentaire....  --> devrait calmer tidy.

Sinon sous safari mac le menu horizontal est sur deux niveau chez moi...

pierre



[Les parties de ce message comportant autre chose que du texte seul ont été
supprimées]

Le 18. 12. 09 16:02, Boby k a écrit :
> Bonjour
>
> Je suis en train de d�velopper un site  et j'ai eu des retours n�gatifs
> pour des utilisateurs de FF et safari sous linux et Mac.
>
> Je travaille sous XP et chez moi, sous FF et IE, tout s'affiche bien.
> Voici les pb relev�s sur le site test
> http://hgse.free.fr  :
> - Sous FF linux, le menu horizontal (onglets) et l�g�rement espac� du
> bloc principal au dessus (il ne "repose" pas dessus comme il devrait)
> - Sous FF Mac, idem mais avec encore plus de d�calage
> - Sous Safari Mac, menu horizontal "fou" ! (compl�tement d�cal� sur
> trois niveaux) et formulaire de login tout � gauche de la fen�tre (et
> pas align� sur le div page)
>
> Sauriez-vous d'o� viennent ces pbs ? Comment les corriger ?
>
> Vous remerciant
>
> Boby

Aussi sous Linux :

Opera affiche comme Firefox, mais les zones de login sont plus
décrochées du cadre principal.

Un petit tour par le W3C Validator (et CSS Validator) est peut-être à
envisager.

Opera est réputé pour son respect des standards.

Cordialement,

Pierre

--
Pierre Graber
Enseignant
CH-2022 Bevaix
http://pcpg.net
http://saen.ch

Bonjour

Je suis en train de développer un site  et j'ai eu des retours négatifs
pour des utilisateurs de FF et safari sous linux et Mac.

Je travaille sous XP et chez moi, sous FF et IE, tout s'affiche bien.
Voici les pb relevés sur le site test
http://hgse.free.fr  :
- Sous FF linux, le menu horizontal (onglets) et légèrement espacé du
bloc principal au dessus (il ne "repose" pas dessus comme il devrait)
- Sous FF Mac, idem mais avec encore plus de décalage
- Sous Safari Mac, menu horizontal "fou" ! (complètement décalé sur
trois niveaux) et formulaire de login tout à gauche de la fenêtre (et
pas aligné sur le div page)

Sauriez-vous d'où viennent ces pbs ? Comment les corriger ?

Vous remerciant

Boby


[Les parties de ce message comportant autre chose que du texte seul ont été
supprimées]

Merci de toutes vos réponses, qui m'ont permis d'établir un tableau synthétique,
que je ne suis malheureusement pas certaine de pouvoir rendre public, malgré mon
intention initiale. Hélas.

Le 17 nov. 2009 à 16:23, romy a écrit :

> Je suis en train d'établir un tableau récapitulatif francophone des bugs
> connus CSS d'IE6/7/8. Savez-vous s'il existe une liste de référence des bugs
> connus d'IE 8 ?
>
> Romy Duhem-Verdière
> --------------------------------------------
> XHTML / CSS / SPIP / accessibilité et W3C
> ------------------------------------------------------
> http://romy.tetue.net - romy@... - 06 82 30 96 16

bonjour,

je ne connais ou ne voit pas de solution non plus , excepté mettre le tableau en
position:absolute; pour le media print.

Solution bancale qui demande que le fieldset ne contienne q'un seul tableau
conteneur en absolu et que celui-ci ne s'affiche pas au dessus/dessous d'autre
contenus.

Le plus simple/sur  est probablement de virer le fieldset .

GC

To: pompeurs@...
From: vincent.clavien@...
Date: Tue, 1 Dec 2009 00:07:09 +0100
Subject: [pompeurs-css] Bug Firefox lors de l'impression




























       Bonjour à tous,



Je me trouve face à un bug ennuyeux qui semble viser Firefox uniquement.



J'ai une page qui contient une très grande table qu'il s'agit

d'imprimer. Cette table est elle-même contenue dans divers blocs

(form, fieldset, div). Le problème est le suivant : lors de

l'impression (et même l'aperçu avant impression) dans Firefox, seule

la première page est imprimée. La table devrait continuer sur une ou

plusieurs pages suivantes, mais elle est coupée et rien ne vient après

la première page.



Le problème ne se pose que dans Firefox (j'ai la version 3.5.5). J'ai

testé dans Safari 4, Chrome 4, IE8, qui parviennent tous à imprimer

l'intégralité du tableau sur plusieurs pages.



En faisant des tests pour préciser la cause du problème, j'ai

découvert que le bug n'est pas lié aux feuilles de styles (il persiste

même si je supprime tous les styles de la page), mais qu'il semble lié

à l'élément <fieldset> dans lequel se trouve la table en question.

Autrement dit, si je supprime le <fieldset>, le bug disparaît et la

table s'imprime correctement.



Une recherche sur le web m'a retourné ce vieil article de ALA, traduit

sur Pompage :-) :

http://www.pompage.net/pompe/impression/

Le deuxième sous-titre, "Réparer un float flappi", décrit précisément

mon problème, mais la solution proposée ne fonctionne pas chez moi.

Mon fieldset possède bien la propriété "float: left", mais le bug

persiste si j'utilise "float: none !important" dans le feuille de

style pour impression, et il persiste même si je supprime complètement

cette propriété dans la feuille de style principale.



Poursuivant ma recherche je suis arrivé sur cette page de Bugzilla :

https://bugzilla.mozilla.org/show_bug.cgi?id=104040

Qui est un doublon de :

https://bugzilla.mozilla.org/show_bug.cgi?id=85768

Là encore, cela décrit mon problème, mais apparemment ces bugs sont

résolus depuis plusieurs années, et les diverses solutions proposées

(ajouter "position: relative !important" à l'élément incriminé)

s'avèrent tout autant infructueuses.



Je suis un peu à court d'idée pour résoudre ce problème. Donc avant de

me résoudre à virer simplement ce fieldset, je voulais voir si vous

aviez une ou deux suggestions à me faire. :-)



Merci d'avance

Vincent
















_________________________________________________________________
Vivez Noël avant l'heure avec Hotmail Magic Moment !
http://www.hotmailmagicmoment.com

[Les parties de ce message comportant autre chose que du texte seul ont été
supprimées]

Bonjour à tous,

Je me trouve face à un bug ennuyeux qui semble viser Firefox uniquement.

J'ai une page qui contient une très grande table qu'il s'agit
d'imprimer. Cette table est elle-même contenue dans divers blocs
(form, fieldset, div). Le problème est le suivant : lors de
l'impression (et même l'aperçu avant impression) dans Firefox, seule
la première page est imprimée. La table devrait continuer sur une ou
plusieurs pages suivantes, mais elle est coupée et rien ne vient après
la première page.

Le problème ne se pose que dans Firefox (j'ai la version 3.5.5). J'ai
testé dans Safari 4, Chrome 4, IE8, qui parviennent tous à imprimer
l'intégralité du tableau sur plusieurs pages.

En faisant des tests pour préciser la cause du problème, j'ai
découvert que le bug n'est pas lié aux feuilles de styles (il persiste
même si je supprime tous les styles de la page), mais qu'il semble lié
à l'élément <fieldset> dans lequel se trouve la table en question.
Autrement dit, si je supprime le <fieldset>, le bug disparaît et la
table s'imprime correctement.

Une recherche sur le web m'a retourné ce vieil article de ALA, traduit
sur Pompage :-) :
http://www.pompage.net/pompe/impression/
Le deuxième sous-titre, "Réparer un float flappi", décrit précisément
mon problème, mais la solution proposée ne fonctionne pas chez moi.
Mon fieldset possède bien la propriété "float: left", mais le bug
persiste si j'utilise "float: none !important" dans le feuille de
style pour impression, et il persiste même si je supprime complètement
cette propriété dans la feuille de style principale.

Poursuivant ma recherche je suis arrivé sur cette page de Bugzilla :
https://bugzilla.mozilla.org/show_bug.cgi?id=104040
Qui est un doublon de :
https://bugzilla.mozilla.org/show_bug.cgi?id=85768
Là encore, cela décrit mon problème, mais apparemment ces bugs sont
résolus depuis plusieurs années, et les diverses solutions proposées
(ajouter "position: relative !important" à l'élément incriminé)
s'avèrent tout autant infructueuses.

Je suis un peu à court d'idée pour résoudre ce problème. Donc avant de
me résoudre à virer simplement ce fieldset, je voulais voir si vous
aviez une ou deux suggestions à me faire. :-)

Merci d'avance
Vincent

Le 29 nov. 2009 à 12:03, Gildas Cotomale a écrit :

> D a un module pour récupérer WP
> (ça me fait penser que si le besoin existe, on peut s'inspirer de ce
> module pour écrire celui d'importation de DC... il faut dire que WP
> est plus connu et qu'on trouve de ses utilisateurs qui sont
> drupalistes et vice-versa)

Ce peut être une bonne idée de créer ce module d'import de DotClear pour Drupal.
Je pense que le fait de pouvoir échanger les contenus entre CMS les favorisent
tous. En l'occurrence ces trois là DotClear, Drupal, WordPress sont d'excellente
qualité et permettent de satisfaire des besoins spécifiques.

À noter qu'on trouve aussi plusieurs modules Drupal visant à pousser IE6 hors du
web, c.-à-d. engageant les utilisateurs à upgrader leur navigateur. Il va sans
dire que j'ai installé l'un d'eux (sevenup) et que je ne me suis guère soucié de
cette antiquité lorsque j'ai travaillé au style des deux sites que je viens de
faire sous Drupal.

À plus.
--
Jean

> Peut-on sur un même serveur faire cohabiter ces deux CMS ?
>
> J'ai passé un site web statique sous Drupal, avec refonte de l'interface,
> thème personnalisé etc. J'avais déjà installé, en plus des pages
statiques
> un blog sous Dotclear. Pour l'instant je développe le nouveau site Drupal
> dans un sous répertoire de ma racine: "www/drupal", le blog est lui dans
> un autre sous répertoire "www/blog" avec à chacun sa base de données.

bah, je ne sais pas ce que tu entends par faire "cohabiter" les deux
car c'est déjà ce que tu fais : chacun à son répertoire (il est même
possible de les même dans le même répertoire tant qu'ils n'ont pas de
fichiers de même nom --le problème de la page index.php demeurant le
plus gros alors) et ses tables (comme elles sont préfixées, ça peut
être dans la même base sans soucis)

> Une fois le site terminé, je vais transférer tous les fichiers du
répertoire
> Drupal à la racine, modifier le htaccess en conséquence et mettre le site
> en production. J'aimerais conserver Dotclear tel quel parce qu'il donne
> entière satisfaction, que le client qui l'utilise est habitué à son
> interface de rédaction et que je n'ai pas trouvé de moyen facile de
> réimporter son contenu dans un blog Drupal du nouveau site sauf à copier un
> par un les articles, ainsi que les commentaires, perdre leurs dates et
> chronologie, ou encore les perdre ou les abandonner. Comment puis-je m'y
> prendre au niveau de mon "www/" ?

là par contre, c'est plus costaud que de la cohabitation ; c'est de la
colaboration ou du mariage là. =D
rien n'étant jamais vraiment impossible, c'est casse couille à l'heure
actuelle car rien n'est prévu dans ce sens (les structures des deux
sont assez éloignées). =( cependant, Drupal est assez souple (ou
maniable, mais cela fini par être un peu complexe) car il peux
utiliser des bases et des tables différentes de celles que son
installation crée par défaut (et donc n'ayant pas le préfixe) : ça se
déclare dans le fichier de configuration et c'est documenté sur le
site (en anglais). il reste quand même un souci énorme car les deux ne
sont pas organisés pareillement (et donc il faut y passer du temps
pour pouvoir faire des ponts entre les objets de l'un et l'autre).

quand à copier coller des posts dans les noeuds, il faut voir du côté
des modules de Drupal comme wghtml (mais pour les commentaires, sais
pas)


> Je n'ai rien trouvé pour ce faire. Aussi j'ai eu recours à une autre
> solution. J'ai importé le blog dans les blogs du Drupal installé sur le
> serveur. Comme cela peut-être utile et que j'ai beaucoup cherché avant d'y
> parvenir voici la marche à suivre avec les liens ad hoc.
>
> On ne peut importer directement le DotClear dans le Drupal, comme ça tout de
> go. Il faut:
>
> - exporter DotClear en un ficher texte (flat export) ;
> - importer dans WordPress ;
en effet, WP sait récupérer DC ainsi... et ce n'est pas bête car
> - exporter ;
> - importer dans Drupal.
D a un module pour récupérer WP
(ça me fait penser que si le besoin existe, on peut s'inspirer de ce
module pour écrire celui d'importation de DC... il faut dire que WP
est plus connu et qu'on trouve de ses utilisateurs qui sont
drupalistes et vice-versa)

chapeau pour l'astuce : je note dans un coin ;)