Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problème : Un div qui reste plus petit que son contenu !!

0 views
Skip to first unread message

Zouplaz

unread,
Feb 17, 2009, 10:59:10 AM2/17/09
to
Bonjour, j'ai div qui refuse de prendre la hauteur de son contenu avec
FF3 (IE = OK)

Voici les règles css

div.app_list { border:1px solid black; background-color:white;
margin:10px 0 0 10px; width:700px; padding:5px; }
div.app_list div.entry { height:auto; clear: both; }
div.app_list div.entry div.datas{ float:left; width:75% }
div.app_list div.entry div.commands { float:left; width:auto; }

Voici le code html

<div class="app_list">

<div class="entry">
<div class="datas">
<b>H098ATRS (ADMIN)</b> : admin nom admin prénom - <a
href="mailto:chris...@bobo.com">chris...@bobo.com</a>
</div>
<div class="commands"></div>
</div>

<div class="entry">
<div class="datas">
<b>H098ATRS (ADMIN)</b> : admin nom admin prénom - <a
href="mailto:chris...@bobo.com">chris...@bobo.com</a>
</div>
<div class="commands"></div>
</div>

<div class="entry">
<div class="datas">
<b>H098ATRS (ADMIN)</b> : admin nom admin prénom - <a
href="mailto:chris...@bobo.com">chris...@bobo.com</a>
</div>
<div class="commands"></div>
</div>

</div>

La hauteur de l'élément app_list est donc incorrect. Je signale que la
page passe la validation w3c.

Header :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">


Voila, une idée quelqu'un ??

Merci d'avance

docanski

unread,
Feb 17, 2009, 12:23:51 PM2/17/09
to
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Zouplaz ecrit ce qui suit en ce 17.02.2009 16:59 :

> Bonjour, j'ai div qui refuse de prendre la hauteur de son contenu avec
> FF3 (IE = OK)

FF3 et Galeon auront le comportement voulu avec :

div.app_list div.entry { height:auto;clear:both; margin-bottom:35px }

> Voila, une idée quelqu'un ??

C'est la seule qui me vient à l'esprit. Elle paraît empirique ... mais
elle est efficace.

Cordialement,
--
docanski

Portail et annuaire du nord-Bretagne : http://armorance.free.fr/
Guide des champignons d'Europe : http://mycorance.free.fr/
La vallée de la Rance maritime : http://valderance.free.fr/
Les côtes du nord de la Bretagne : http://docarmor.free.fr/

Pierre Goiffon

unread,
Feb 17, 2009, 12:24:56 PM2/17/09
to
Zouplaz wrote:
> Bonjour, j'ai div qui refuse de prendre la hauteur de son contenu avec
> FF3 (IE = OK)

Pourriez-vous plutôt poster une URL ? C'est beaucoup plus facile à
diagnostiquer...


> Header :
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
> "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

Rassurez-moi, vous ne servez pas ce XHTML 1.1 en text/html ?

Zouplaz

unread,
Feb 26, 2009, 6:32:17 AM2/26/09
to
le 17/02/2009 18:24, Pierre Goiffon nous a dit:

Merci pour votre réponse, ainsi que celle de docanski... Je ne pouvais
pas poster d'url, c'est sur un réseau interne. Par contre, c'est vrai
que ce doctype était une connerie - J'ai basculé sur dur 1.0
transitionnal et tout est ok maintenant. Merci de m'avoir mis sur la piste.

docanski

unread,
Feb 26, 2009, 7:13:13 AM2/26/09
to
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Zouplaz ecrit ce qui suit en ce 26.02.2009 12:32 :

> Merci pour votre réponse, ainsi que celle de docanski... Je ne pouvais
> pas poster d'url, c'est sur un réseau interne. Par contre, c'est vrai
> que ce doctype était une connerie - J'ai basculé sur dur 1.0
> transitionnal et tout est ok maintenant. Merci de m'avoir mis sur la piste.

C'est dommage de placer un doctype XHTML si c'est pour faire du
transitionnal. Ce n'est plus "dur" du tout, dans ces conditions ;-)

Zouplaz

unread,
Mar 4, 2009, 4:10:51 AM3/4/09
to
le 26/02/2009 13:13, docanski nous a dit:

>
> C'est dommage de placer un doctype XHTML si c'est pour faire du
> transitionnal. Ce n'est plus "dur" du tout, dans ces conditions ;-)
>

Je viens de lire cet article édifiant :
http://www.thewebsqueeze.com/web-design-articles/choosing-the-best-doctype-for-your-website.html

C'est sans doute de ça dont tu parles ? Je crois que je vais me mettre
au HTML strict...

Patrick Mevzek

unread,
Mar 4, 2009, 8:55:50 AM3/4/09
to
Le Wed, 04 Mar 2009 10:10:51 +0100, Zouplaz a écrit:
>> C'est dommage de placer un doctype XHTML si c'est pour faire du
>> transitionnal. Ce n'est plus "dur" du tout, dans ces conditions ;-)
>>
> Je viens de lire cet article édifiant :
> http://www.thewebsqueeze.com/web-design-articles/choosing-the-best-doctype-for-your-website.html

Edifiant car il dit de ne pas faire du XHTML alors que ...
la page en question est elle-même en doctype xhtml :-) ?
(et elle ne valide pas, 35 erreurs !)

Sinon j'aime bien le début :
Deciding between HTML and XHTML is not as straightforward.
This is much more of a personal preference, with no clearly wrong answer.

Ca se gate après, par exemple :
"XHTML produces cleaner code"

No it doesn't.

et 2 lignes après :
There are only two respects in which XHTML code is "cleaner":


M'enfin bon le sujet a déjà été débattu et le document de Pierre Goiffon en français
dit les mêmes choses (avec les mêmes parti-pris :-)) mais a l'avantage d'être en français.


--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>

Pierre Goiffon

unread,
Mar 4, 2009, 1:09:36 PM3/4/09
to
Zouplaz wrote:
>> C'est dommage de placer un doctype XHTML si c'est pour faire du
>> transitionnal. Ce n'est plus "dur" du tout, dans ces conditions ;-)
>
> Je viens de lire cet article édifiant :
> http://www.thewebsqueeze.com/web-design-articles/choosing-the-best-doctype-for-your-website.html

Intéressant article, cela me donne des idées pour reformuler le mien !
En particulier, lister ce que peut apporter XHTML dans un environnement
Web (quelque soit le terme choisit, comme nous l'avions discuté avec
Patrick - cf <499ed455$0$4846$426a...@news.free.fr> - je considère
qu'il s'agit de contraintes uniquement et pas d'apport, et oui ces
contraintes peuvent être recherchées par le concepteur).
C'est le paragraphe "XHTML produce cleaner code" qui m'y fait penser, et
je regrette qu'il soit un peu mal formulé à mon sens (l'obligation d'un
document bien formé sinon plantage du navigateur n'est pas valable en
environnement Web).

Merci d'avoir communiqué l'URL !

Patrick Mevzek

unread,
Mar 4, 2009, 1:22:00 PM3/4/09
to
Le Wed, 04 Mar 2009 19:09:36 +0100, Pierre Goiffon a écrit:
> (l'obligation d'un
> document bien formé sinon plantage du navigateur n'est pas valable en
> environnement Web).

Clairement, il va falloir que vous expliquiez ce que «environnement Web»
veut dire pour vous parce que si un navigateur n'est pas un environnement
web selon vous, j'avoue perdre mon latin et ne plus rien comprendre...

Zouplaz

unread,
Mar 4, 2009, 2:13:34 PM3/4/09
to
le 04/03/2009 19:22, Patrick Mevzek nous a dit:

> Le Wed, 04 Mar 2009 19:09:36 +0100, Pierre Goiffon a écrit:
>> (l'obligation d'un
>> document bien formé sinon plantage du navigateur n'est pas valable en
>> environnement Web).
>
> Clairement, il va falloir que vous expliquiez ce que «environnement Web»
> veut dire pour vous parce que si un navigateur n'est pas un environnement
> web selon vous, j'avoue perdre mon latin et ne plus rien comprendre...
>

Environnement hétérogène et bordélique - Contrairement à l'environnement
intranet, maîtrisé, homogène avec la version voulue du soft voulu qui
permettra au guichetier de guicheter ?

Patrick Mevzek

unread,
Mar 4, 2009, 2:46:13 PM3/4/09
to
Le Wed, 04 Mar 2009 20:13:34 +0100, Zouplaz a écrit:
>> Clairement, il va falloir que vous expliquiez ce que «environnement
>> Web» veut dire pour vous parce que si un navigateur n'est pas un
>> environnement web selon vous, j'avoue perdre mon latin et ne plus rien
>> comprendre...
>>
> Environnement hétérogène et bordélique - Contrairement à l'environnement
> intranet, maîtrisé, homogène avec la version voulue du soft voulu qui
> permettra au guichetier de guicheter ?

Et quand on développe un site on peut pas d'abord le tester en interne et
en local (y compris dans le cadre de plusieurs environnements, OS,
navigateurs) pour profiter des erreurs de parsing très voyantes (entre
autres), et après seulement après le rendre public ?

Pierre Goiffon

unread,
Mar 5, 2009, 6:09:28 AM3/5/09
to
Patrick Mevzek wrote:
>> (l'obligation d'un
>> document bien formé sinon plantage du navigateur n'est pas valable en
>> environnement Web).
>
> Clairement, il va falloir que vous expliquiez ce que «environnement Web»
> veut dire pour vous parce que si un navigateur n'est pas un environnement
> web selon vous, j'avoue perdre mon latin et ne plus rien comprendre...

Je suis très surpris de votre demande de précisions !
Un site qui n'est pas utilisable sous MSIE (pages servies en
application/xml+xhtml par exemple) ne peut être utilisé que dans un
intranet ou cas très particuliers. Si l'on veut "faire du web" on
n'impose pas de telles pré-requis, on essaie d'ouvrir son site au plus
large éventail de navigateurs.

Patrick Mevzek

unread,
Mar 5, 2009, 7:53:23 AM3/5/09
to
Le Thu, 05 Mar 2009 12:09:28 +0100, Pierre Goiffon a écrit:
>> Clairement, il va falloir que vous expliquiez ce que «environnement
>> Web» veut dire pour vous parce que si un navigateur n'est pas un
>> environnement web selon vous, j'avoue perdre mon latin et ne plus rien
>> comprendre...
>
> Je suis très surpris de votre demande de précisions ! Un site qui n'est
> pas utilisable sous MSIE (pages servies en application/xml+xhtml par
> exemple) ne peut être utilisé que dans un intranet ou cas très
> particuliers. Si l'on veut "faire du web" on n'impose pas de telles
> pré-requis, on essaie d'ouvrir son site au plus large éventail de
> navigateurs.

Rien n'empêche d'être flexible, de détecter MSIE, et de lui renvoyer text/
html puisqu'il est incapable de faire autre chose. Et de renvoyer le bon
type MIME à tous les autres navigateurs, davantage standard.

Pierre Goiffon

unread,
Mar 5, 2009, 8:12:52 AM3/5/09
to
Patrick Mevzek wrote:
>> Un site qui n'est
>> pas utilisable sous MSIE (pages servies en application/xml+xhtml par
>> exemple) ne peut être utilisé que dans un intranet ou cas très
>> particuliers. Si l'on veut "faire du web" on n'impose pas de telles
>> pré-requis, on essaie d'ouvrir son site au plus large éventail de
>> navigateurs.
>
> Rien n'empêche d'être flexible, de détecter MSIE, et de lui renvoyer text/
> html puisqu'il est incapable de faire autre chose. Et de renvoyer le bon
> type MIME à tous les autres navigateurs, davantage standard.

Intérêt ?

Patrick Mevzek

unread,
Mar 5, 2009, 8:23:09 AM3/5/09
to

Vous dites que le XHTML est inutilisable en « environnement Web » à cause
de MSIE qui ne sait pas se dépêtrer d'un type MIME tout à fait standard,
je vous dit comment remédier à cela (c'est à dire en s'écartant
légèrement du standard « pur », tout en restant 100% conforme au XHTML
1.0 - pas besoin de nous reparler de l'annexe C :-)), et vous me demandez
l'intérêt ?

Zouplaz

unread,
Mar 5, 2009, 10:13:22 AM3/5/09
to
le 04/03/2009 20:46, Patrick Mevzek nous a dit:

> Le Wed, 04 Mar 2009 20:13:34 +0100, Zouplaz a écrit:
>>> Clairement, il va falloir que vous expliquiez ce que «environnement
>>> Web» veut dire pour vous parce que si un navigateur n'est pas un
>>> environnement web selon vous, j'avoue perdre mon latin et ne plus rien
>>> comprendre...
>>>
>> Environnement hétérogène et bordélique - Contrairement à l'environnement
>> intranet, maîtrisé, homogène avec la version voulue du soft voulu qui
>> permettra au guichetier de guicheter ?
>
> Et quand on développe un site on peut pas d'abord le tester en interne et
> en local (y compris dans le cadre de plusieurs environnements, OS,
> navigateurs) pour profiter des erreurs de parsing très voyantes (entre
> autres), et après seulement après le rendre public ?
>

En théorie oui, dans la pratique non - Trop d'environnements différents.
Je me contente de tester sur les navigateurs les plus répandus, dans
leurs versions les plus récentes. Et même comme ça j'ai parfois des
surprises...

Patrick Mevzek

unread,
Mar 5, 2009, 10:40:18 AM3/5/09
to
Le Thu, 05 Mar 2009 16:13:22 +0100, Zouplaz a écrit:
>> Et quand on développe un site on peut pas d'abord le tester en interne
>> et en local (y compris dans le cadre de plusieurs environnements, OS,
>> navigateurs) pour profiter des erreurs de parsing très voyantes (entre
>> autres), et après seulement après le rendre public ?
>>
>>
> En théorie oui, dans la pratique non - Trop d'environnements différents.

Comme lesquels ?

Il ne faut pas non plus mettre tous les sites dans le même panier.
Un petit site personnel, bah si ce n'est pas parfait partout ce n'est pas
bien grave.
Un site qui est sensé générer du revenu, directement ou indirectement,
doit être testé de manière adéquate et avec un budget pour cela. Oui vous
allez me dire en théorie oui en pratique non. Certes, je suis d'accord.
Mais alors ce n'est pas au responsable du site de se plaindre de
problèmes, il ne peut s'en prendre qu'à lui-même.

> Je me contente de tester sur les navigateurs les plus répandus, dans
> leurs versions les plus récentes. Et même comme ça j'ai parfois des
> surprises...

Des exemples précis ?
(je ne nie pas l'existence de telles surprises évidemment, mais plus on
en voit passer mieux c'est au moins pour la culture général, donc je suis
avide d'exemples concrets).

Pierre Goiffon

unread,
Mar 5, 2009, 11:19:37 AM3/5/09
to
Patrick Mevzek wrote:
>>>> Un site qui n'est
>>>> pas utilisable sous MSIE (pages servies en application/xml+xhtml par
>>>> exemple) ne peut être utilisé que dans un intranet ou cas très
>>>> particuliers. Si l'on veut "faire du web" on n'impose pas de telles
>>>> pré-requis, on essaie d'ouvrir son site au plus large éventail de
>>>> navigateurs.
>>> Rien n'empêche d'être flexible, de détecter MSIE, et de lui renvoyer
>>> text/ html puisqu'il est incapable de faire autre chose. Et de renvoyer
>>> le bon type MIME à tous les autres navigateurs, davantage standard.
>> Intérêt ?
>
> Vous dites que le XHTML est inutilisable en « environnement Web » à cause
> de MSIE qui ne sait pas se dépêtrer d'un type MIME tout à fait standard,
> je vous dit comment remédier à cela (c'est à dire en s'écartant
> légèrement du standard « pur », tout en restant 100% conforme au XHTML
> 1.0 - pas besoin de nous reparler de l'annexe C :-)), et vous me demandez
> l'intérêt ?

Vous avez sauté le début qui vous avais fait réagir, cad (dans
<49AEC3E0...@free.fr.invalid>) :

> l'obligation d'un document bien formé sinon plantage du navigateur n'est pas valable en environnement Web

Je peux comprendre que l'on souhaite qu'un document mal formé soit
rejeté par le navigateur.
Je ne comprend pas que l'on choisisse XHTML en ajoutant une louche de
négociation de contenu pour cette raison, sachant que seuls quelques
rares utilisateurs auront ce comportement.

Patrick Mevzek

unread,
Mar 5, 2009, 11:47:57 AM3/5/09
to
Le Thu, 05 Mar 2009 17:19:37 +0100, Pierre Goiffon a écrit:
> Je peux comprendre que l'on souhaite qu'un document mal formé soit
> rejeté par le navigateur.
> Je ne comprend pas que l'on choisisse XHTML en ajoutant une louche de
> négociation de contenu pour cette raison, sachant que seuls quelques
> rares utilisateurs auront ce comportement.

Mais _évidemment_ le but n'est PAS que les *utilisateurs* aient les
erreurs de parsing. Le but est qu'elles soient immédiatement détectées
lors du développement du site et des tests avant mise en production et
disponibilité au public.
Oui, on peut faire autrement et faire du xmllint par exemple, mais un bon
gros message d'erreur en gras rouge dans le navigateur ca permet de se
forcer à corriger et de ne pas faire de gros hacks pour juste passer
outre l'erreur...
Bref, ca tient compte de l'humain.

Mais à part cela j'ai l'impression de moins en moins comprendre la
discussion alors je vais aller me c(a|ou)cher et continuer mon travail de
mise à jour sur mes sites :-)

Pierre Goiffon

unread,
Mar 5, 2009, 1:32:30 PM3/5/09
to
Patrick Mevzek wrote:
> Le Thu, 05 Mar 2009 17:19:37 +0100, Pierre Goiffon a écrit:
>> Je peux comprendre que l'on souhaite qu'un document mal formé soit
>> rejeté par le navigateur.
>> Je ne comprend pas que l'on choisisse XHTML en ajoutant une louche de
>> négociation de contenu pour cette raison, sachant que seuls quelques
>> rares utilisateurs auront ce comportement.
>
> Mais _évidemment_ le but n'est PAS que les *utilisateurs* aient les
> erreurs de parsing. Le but est qu'elles soient immédiatement détectées
> lors du développement du site et des tests avant mise en production et
> disponibilité au public.

Argument recevable :)
Mais le validateur automatique nécessite sans aucun doute moins de
lourdeurs de mise en place pour un résultat identique !

(et moi je m'en vais rentrer chez moi d'ici quelques minutes :) )

Zouplaz

unread,
Mar 5, 2009, 1:41:35 PM3/5/09
to
le 05/03/2009 16:40, Patrick Mevzek nous a dit:

> Le Thu, 05 Mar 2009 16:13:22 +0100, Zouplaz a écrit:
>>> Et quand on développe un site on peut pas d'abord le tester en interne
>>> et en local (y compris dans le cadre de plusieurs environnements, OS,
>>> navigateurs) pour profiter des erreurs de parsing très voyantes (entre
>>> autres), et après seulement après le rendre public ?
>>>
>>>
>> En théorie oui, dans la pratique non - Trop d'environnements différents.
>
> Comme lesquels ?

Par exemple, les anciennes version d'Internet Explorer (5.5, 6) qui ne
collaborent plus du tout avec IE7 sur un même système (et même comme ça
c'était galère). D'où nécessité d'utiliser des images disques virtuelles
pour VirtualPC gratuites mais limitées dans le temps et distribuées par
MSDN. Et quand on aura IE8, même topo pour IE7.
Autre exemple, jusqu'à l'année dernière et l'apparition de Safari sur PC
j'avais des clients qui me comptaient leurs malheurs et qui devaient
m'envoyer des captures d'écran pour me montrer les problèmes qu'ils
rencontraient (super pour débugger). Ou bien de vieilles versions de
Firefox 1.x... Et encore, le jour où il va falloir prendre en compte de
manière sérieuse la problématique des navigateurs sur mobiles avec des
mise à jour logicielles beaucoup moins fréquente et faciles que sur un
PC ou un Mac...

>
> Il ne faut pas non plus mettre tous les sites dans le même panier.
> Un petit site personnel, bah si ce n'est pas parfait partout ce n'est pas
> bien grave.
> Un site qui est sensé générer du revenu, directement ou indirectement,
> doit être testé de manière adéquate et avec un budget pour cela. Oui vous
> allez me dire en théorie oui en pratique non. Certes, je suis d'accord.
> Mais alors ce n'est pas au responsable du site de se plaindre de
> problèmes, il ne peut s'en prendre qu'à lui-même.

Non, il ne le comprendra pas. Une page qui foire c'est ma faute, les
problèmes techniques n'intéressent pas les clients. Et c'est d'autant
plus problématique sur des prestations à budget restreint.

>
>> Je me contente de tester sur les navigateurs les plus répandus, dans
>> leurs versions les plus récentes. Et même comme ça j'ai parfois des
>> surprises...
>
> Des exemples précis ?
> (je ne nie pas l'existence de telles surprises évidemment, mais plus on
> en voit passer mieux c'est au moins pour la culture général, donc je suis
> avide d'exemples concrets).
>

Pleins, surtout liés à Javascript pourtant appuyé par des usines à gaz
genre Prototype et c'est pas complètement hors sujet dans la mesure où
l'utilisation de ce langage permet d'aller là où css et consorts ne vont
pas (encore). Obstrusif ou pas, difficile de s'en passer et ça va pas
aller en s'améliorant. Maintenant des exemples précis je peux pas t'en
donner j'ai déjà assez de mal à mémoriser les informations utiles ;-)

Patrick Mevzek

unread,
Mar 5, 2009, 2:10:45 PM3/5/09
to
Le Thu, 05 Mar 2009 19:41:35 +0100, Zouplaz a écrit:
> Par exemple, les anciennes version d'Internet Explorer (5.5, 6) qui ne
> collaborent plus du tout avec IE7 sur un même système (et même comme ça
> c'était galère). D'où nécessité d'utiliser des images disques virtuelles
> pour VirtualPC gratuites mais limitées dans le temps et distribuées par
> MSDN.

Il y a d'autres moyens de faire cela. Vous connaissez wine ? ie4linux ?

> Autre exemple, jusqu'à
> l'année dernière et l'apparition de Safari sur PC j'avais des clients
> qui me comptaient leurs malheurs et qui devaient m'envoyer des captures
> d'écran pour me montrer les problèmes qu'ils rencontraient (super pour
> débugger).

Et le client ne pouvait même pas prêter ponctuellement une machine qui va
bien pour faire les tests ?

Vous savez qu'il existe des services en ligne de captures d'écran sur
différents navigateurs ?

Indépendamment de cela, avoir plusieurs *OS* ca peut être pratique, et le
multiboot (au pire) est a priori accessible comme technologie de nos
jours.

>> Il ne faut pas non plus mettre tous les sites dans le même panier. Un
>> petit site personnel, bah si ce n'est pas parfait partout ce n'est pas
>> bien grave.
>> Un site qui est sensé générer du revenu, directement ou indirectement,
>> doit être testé de manière adéquate et avec un budget pour cela. Oui
>> vous allez me dire en théorie oui en pratique non. Certes, je suis
>> d'accord. Mais alors ce n'est pas au responsable du site de se plaindre
>> de problèmes, il ne peut s'en prendre qu'à lui-même.
>
> Non, il ne le comprendra pas.

Cela s'appelle apprendre alors. Et faire comprendre.

> Une page qui foire c'est ma faute, les
> problèmes techniques n'intéressent pas les clients. Et c'est d'autant
> plus problématique sur des prestations à budget restreint.

Je ne crois pas à l'adage "le client est roi". À force de tirer vers le
bas (en général), forcément il y a des conséquences...



>>> Je me contente de tester sur les navigateurs les plus répandus, dans
>>> leurs versions les plus récentes. Et même comme ça j'ai parfois des
>>> surprises...
>>
>> Des exemples précis ?
>> (je ne nie pas l'existence de telles surprises évidemment, mais plus on
>> en voit passer mieux c'est au moins pour la culture général, donc je
>> suis avide d'exemples concrets).
>>
>>
> Pleins, surtout liés à Javascript pourtant appuyé par des usines à gaz
> genre Prototype et c'est pas complètement hors sujet

On est donc bien loin d'un pur problème de différence HTML/XHTML...

Zouplaz

unread,
Mar 5, 2009, 2:48:30 PM3/5/09
to
le 05/03/2009 20:10, Patrick Mevzek nous a dit:

> Le Thu, 05 Mar 2009 19:41:35 +0100, Zouplaz a écrit:
>> Par exemple, les anciennes version d'Internet Explorer (5.5, 6) qui ne
>> collaborent plus du tout avec IE7 sur un même système (et même comme ça
>> c'était galère). D'où nécessité d'utiliser des images disques virtuelles
>> pour VirtualPC gratuites mais limitées dans le temps et distribuées par
>> MSDN.
>
> Il y a d'autres moyens de faire cela. Vous connaissez wine ? ie4linux ?

Oui mais ça n'est qu'une solution logicielle différente. Et pas plus
simple. D'autant que wine ne reste qu'une émulation approximative.

>
>> Autre exemple, jusqu'à
>> l'année dernière et l'apparition de Safari sur PC j'avais des clients
>> qui me comptaient leurs malheurs et qui devaient m'envoyer des captures
>> d'écran pour me montrer les problèmes qu'ils rencontraient (super pour
>> débugger).
>
> Et le client ne pouvait même pas prêter ponctuellement une machine qui va
> bien pour faire les tests ?

Non

>
> Vous savez qu'il existe des services en ligne de captures d'écran sur
> différents navigateurs ?
>
> Indépendamment de cela, avoir plusieurs *OS* ca peut être pratique, et le
> multiboot (au pire) est a priori accessible comme technologie de nos
> jours.
>

J'ai les OS, ce qui est moins disponible c'est le temps. Je ne sais pas
quel est votre métier mais je fais malheureusement parti des
informaticiens qui doivent ménager la chèvre et le chou s'il veulent
s'assurer un salaire chaque mois.

>>> Il ne faut pas non plus mettre tous les sites dans le même panier. Un
>>> petit site personnel, bah si ce n'est pas parfait partout ce n'est pas
>>> bien grave.
>>> Un site qui est sensé générer du revenu, directement ou indirectement,
>>> doit être testé de manière adéquate et avec un budget pour cela. Oui
>>> vous allez me dire en théorie oui en pratique non. Certes, je suis
>>> d'accord. Mais alors ce n'est pas au responsable du site de se plaindre
>>> de problèmes, il ne peut s'en prendre qu'à lui-même.
>> Non, il ne le comprendra pas.
>
> Cela s'appelle apprendre alors. Et faire comprendre.
>
>> Une page qui foire c'est ma faute, les
>> problèmes techniques n'intéressent pas les clients. Et c'est d'autant
>> plus problématique sur des prestations à budget restreint.
>
> Je ne crois pas à l'adage "le client est roi". À force de tirer vers le
> bas (en général), forcément il y a des conséquences...
>

Non, le client n'est pas roi mais n'est pas un idiot non plus... Quant à
tirer vers le bas, je ne sais pas sur quoi vous vous appuyez pour dire
ça - vous ne me connaissez pas.

Enfin, ça reste vraiment de la tchatche tout ça.

Patrick Mevzek

unread,
Mar 5, 2009, 3:18:10 PM3/5/09
to
Le Thu, 05 Mar 2009 20:48:30 +0100, Zouplaz a écrit:
>> Il y a d'autres moyens de faire cela. Vous connaissez wine ? ie4linux ?
>
> Oui mais ça n'est qu'une solution logicielle différente. Et pas plus
> simple.

Installer un unique logiciel n'est pas plus simple que
« utiliser des images disques virtuelles

pour VirtualPC gratuites mais limitées dans le temps et distribuées par

MSDN » selon vous ?
Je n'ai pas le même point de vue...

> D'autant que wine ne reste qu'une émulation approximative.

Et concrétement ?
(je parle bien dans l'optique tests de sites web avec IE & compagnie, pas
de wine en général).

>> Indépendamment de cela, avoir plusieurs *OS* ca peut être pratique, et
>> le multiboot (au pire) est a priori accessible comme technologie de nos
>> jours.
>>
>>
> J'ai les OS, ce qui est moins disponible c'est le temps.

On tourne en boucle. J'ai déjà dit que les tests ca doit avoir un budget
et prévu spécifiquement. Si ce n'est pas le cas, alors on a d'autres
problèmes que XHTML vs HTML.

> Non, le client n'est pas roi mais n'est pas un idiot non plus... Quant à
> tirer vers le bas, je ne sais pas sur quoi vous vous appuyez pour dire
> ça - vous ne me connaissez pas.

Cela tombe bien je ne parlais pas de vous en particulier.

> Enfin, ça reste vraiment de la tchatche tout ça.

C'est vrai je vous demande des exemples concrets (sur la problématique
XHTML vs HTML) et vous me parlez de la difficulté de tester sur IE5 quand
il y a IE7 et compagnie, ou d'utiliser Safari sur un PC, ou des
bibliothèques Javascript et de leurs propres spécificités. Bref de
beaucoup de choses, mais sans plus aucun rapport avec XHTML vs HTML
et la visibilité des erreurs de parsing dans le premier cas.

Après que les clients ne comprennent pas ou ne veulent pas comprendre,
qu'on ait jamais le temps de faire les choses comme on veut ou comme on
pourrait bien les faire, oui, ca je suis au courant déjà, mais on n'est
pas dans le bon fil, ni groupe même pour en parler.

0 new messages