kurtbosh wrote: >>> Il y a de l'idée dans tes remarques mais il ne faut pas toucher à mes >>> tables, il n'y a que ça de vrai ! Les boites CSS pfftt. >> Heu ... pour un bandeau et 3 colonnes dessous ... >> les rendus doivent tout de même être assez proches, >> vu comme ça de ma chaise. > Les tables sont reconnues par : > - HTML 4.01 STRICT > - XHTML > - HTML 5 (d'après ce que j'ai lu car seules les Frames disparaissent)
> Et puis c'est 100% fiable les tables !
> J'ai essayé à plusieurs reprises d'utiliser les boîtes CSS : quan d > c'est parfait avec FF, ça m... avec IE et inversement, surtout au > moment des resizing.
Si vous avez l'habitude de faire de la mise en page en utilisant des tableaux alors oui, vous aurez quelques difficultés à changer vers du contenu simplement structuré, avec le minimum de balises html servant uniquement à la mise en forme.
Il y a aujourd'hui de très nombreux sites utilisant CSS avec le minimum de tableaux et qui tournent depuis longtemps pour rejeter l'argument "les tables fonctionnent partout, pas le CSS" !
D'un point de vue purement concepteur, vous avez de très nombreuses bidouilles à connaître pour faire de la mise en page en tableaux, et c'est la même chose si vous voulez faire du CSS. Cependant si l'on est en strict avec un minima sur IE6, à mon sens ça réduit considérab lement le volume de bidouilles à connaître, largement au profit de CSS !
Par contre, la mise en page par tableaux est une horreur absolue à intégrer (je pense aux sites dynamiques en particulier) et à mainteni r ! Séparer fond et forme permet de gagner considérablement sur ces aspec ts.
En résumé, passer à CSS c'est un investissement, mais ça en vaut très largement le coup. Et il y a de très nombreux concepteurs aujourd'hui qui peuvent en témoigner ! (moi par exemple :) )
Oui, sans doute mais je les aime bien mes tables, elles m'obéissent au doigt et à l'il et elles ne m'ont jamais posé le moindre problème. Les boîtes, c'est vrai je ne les maitrise pas, elles n'en font qu'à leur tête ! Je reconnais aussi que s'y retrouver dans une page où il y a beaucoup de tables imbriquées ce n'est pas toujours simple !!!! J'y viendrai, c'est certain mais je n'ai pas encore le courage. Pour l'instant j'essaie de passer du transitionnel au strict sans erreur détectée par le w3c. Ce sera déjà un gros progrès. Je viens déj à d'utiliser les Hn pour les titres avec un seul H1 par page (et plus de Hn pour autre chose que des titres...), maintenant c'est le passage au Strict et c'est du boulot - même si je n'avais pas d'erreur en transitional. Il me restera quand toutes les pages seront en strict à condenser la page CSS pour avoir moins de déclarations... Il faut du temps.
Merci pour les conseils judicieux.
On 23 fév, 12:39, Pierre Goiffon <pgoif...@free.fr.invalid> wrote:
kurtbosh wrote:
>>> Il y a de l'idée dans tes remarques mais il ne faut pas toucher à mes
>>> tables, il n'y a que ça de vrai ! Les boites CSS pfftt.
>> Heu ... pour un bandeau et 3 colonnes dessous ...
>> les rendus doivent tout de même être assez proches,
>> vu comme ça de ma chaise.
> Les tables sont reconnues par :
> - HTML 4.01 STRICT
> - XHTML
> - HTML 5 (d'après ce que j'ai lu car seules les Frames disparaissent)
> Et puis c'est 100% fiable les tables !
> J'ai essayé à plusieurs reprises d'utiliser les boîtes CSS : quan d
> c'est parfait avec FF, ça m... avec IE et inversement, surtout au
> moment des resizing.
Si vous avez l'habitude de faire de la mise en page en utilisant des
tableaux alors oui, vous aurez quelques difficultés à changer vers du
contenu simplement structuré, avec le minimum de balises html servant
uniquement à la mise en forme.
Il y a aujourd'hui de très nombreux sites utilisant CSS avec le minimum
de tableaux et qui tournent depuis longtemps pour rejeter l'argument
"les tables fonctionnent partout, pas le CSS" !
D'un point de vue purement concepteur, vous avez de très nombreuses
bidouilles à connaître pour faire de la mise en page en tableaux, et
c'est la même chose si vous voulez faire du CSS. Cependant si l'on est
en strict avec un minima sur IE6, à mon sens ça réduit considérab lement
le volume de bidouilles à connaître, largement au profit de CSS !
Par contre, la mise en page par tableaux est une horreur absolue à
intégrer (je pense aux sites dynamiques en particulier) et à mainteni r !
Séparer fond et forme permet de gagner considérablement sur ces aspec ts.
En résumé, passer à CSS c'est un investissement, mais ça en vaut très
largement le coup.
Et il y a de très nombreux concepteurs aujourd'hui qui peuvent en
témoigner ! (moi par exemple :) )
Oui, sans doute mais je les aime bien mes tables, elles m'obéissent au
doigt et à l'il et elles ne m'ont jamais posé le moindre problème.
Les boîtes, c'est vrai je ne les maitrise pas, elles n'en font qu'à
leur tête ! Je reconnais aussi que s'y retrouver dans une page où il y
a beaucoup de tables imbriquées ce n'est pas toujours simple !!!! J'y
viendrai, c'est certain mais je n'ai pas encore le courage. Pour
l'instant j'essaie de passer du transitionnel au strict sans erreur
détectée par le w3c. Ce sera déjà un gros progrès. Je viens déj à
d'utiliser les Hn pour les titres avec un seul H1 par page (et plus de
Hn pour autre chose que des titres...), maintenant c'est le passage au
Strict et c'est du boulot - même si je n'avais pas d'erreur en
transitional. Il me restera quand toutes les pages seront en strict à
condenser la page CSS pour avoir moins de déclarations... Il faut du
temps.
kurtbosh wrote: >>> Il y a de l'idée dans tes remarques mais il ne faut pas toucher à mes >>> tables, il n'y a que ça de vrai ! Les boites CSS pfftt. >> Heu ... pour un bandeau et 3 colonnes dessous ... >> les rendus doivent tout de même être assez proches, >> vu comme ça de ma chaise. > Les tables sont reconnues par : > - HTML 4.01 STRICT > - XHTML > - HTML 5 (d'après ce que j'ai lu car seules les Frames disparaissent)
> Et puis c'est 100% fiable les tables !
> J'ai essayé à plusieurs reprises d'utiliser les boîtes CSS : quan d > c'est parfait avec FF, ça m... avec IE et inversement, surtout au > moment des resizing.
Si vous avez l'habitude de faire de la mise en page en utilisant des tableaux alors oui, vous aurez quelques difficultés à changer vers du contenu simplement structuré, avec le minimum de balises html servant uniquement à la mise en forme.
Il y a aujourd'hui de très nombreux sites utilisant CSS avec le minimum de tableaux et qui tournent depuis longtemps pour rejeter l'argument "les tables fonctionnent partout, pas le CSS" !
D'un point de vue purement concepteur, vous avez de très nombreuses bidouilles à connaître pour faire de la mise en page en tableaux, et c'est la même chose si vous voulez faire du CSS. Cependant si l'on est en strict avec un minima sur IE6, à mon sens ça réduit considérab lement le volume de bidouilles à connaître, largement au profit de CSS !
Par contre, la mise en page par tableaux est une horreur absolue à intégrer (je pense aux sites dynamiques en particulier) et à mainteni r ! Séparer fond et forme permet de gagner considérablement sur ces aspec ts.
En résumé, passer à CSS c'est un investissement, mais ça en vaut très largement le coup. Et il y a de très nombreux concepteurs aujourd'hui qui peuvent en témoigner ! (moi par exemple :) )
Oui, sans doute mais je les aime bien mes tables, elles m'obéissent au doigt et à l'il et elles ne m'ont jamais posé le moindre problème. Les boîtes, c'est vrai je ne les maitrise pas, elles n'en font qu'à leur tête ! Je reconnais aussi que s'y retrouver dans une page où il y a beaucoup de tables imbriquées ce n'est pas toujours simple !!!! J'y viendrai, c'est certain mais je n'ai pas encore le courage. Pour l'instant j'essaie de passer du transitionnel au strict sans erreur détectée par le w3c. Ce sera déjà un gros progrès. Je viens déj à d'utiliser les Hn pour les titres avec un seul H1 par page (et plus de Hn pour autre chose que des titres...), maintenant c'est le passage au Strict et c'est du boulot - même si je n'avais pas d'erreur en transitional. Il me restera quand toutes les pages seront en strict à condenser la page CSS pour avoir moins de déclarations... Il faut du temps.
Merci pour les conseils judicieux.
Michael DENIS
Olivier Miakinen a écrit :
des balises invalides en SGML (<br/> par exemple).
<br /> ;-) C'est vrai, même si les navigateurs ne sont nullement gênés par cette spécificité.
Il ne sera plus recevable lorsque la majorité des navigateurs pourront utiliser un vrai parser XML pour lire du XHTML, et que l'on abandonnera la soupe de balises text/html déclarée comme du XHTML. Ce n'est clairement pas le cas aujourd'hui, et tu le reconnais toi-même (cf. ta remarque sur les « navigateurs "anciens" »)
Si cela devient le cas, les utilisateurs de xhtml seront ravis d'avoir fait le pari, à défaut... :-)
-- Michaël DENIS
Olivier Miakinen a écrit :
des balises invalides en SGML (<br/> par exemple).
<br /> ;-)
C'est vrai, même si les navigateurs ne sont nullement gênés par cette
spécificité.
Il ne sera plus recevable lorsque la majorité des navigateurs pourront
utiliser un vrai parser XML pour lire du XHTML, et que l'on abandonnera
la soupe de balises text/html déclarée comme du XHTML. Ce n'est
clairement pas le cas aujourd'hui, et tu le reconnais toi-même (cf.
ta remarque sur les « navigateurs "anciens" »)
Si cela devient le cas, les utilisateurs de xhtml seront ravis d'avoir
fait le pari, à défaut... :-)
des balises invalides en SGML (<br/> par exemple).
<br /> ;-) C'est vrai, même si les navigateurs ne sont nullement gênés par cette spécificité.
Il ne sera plus recevable lorsque la majorité des navigateurs pourront utiliser un vrai parser XML pour lire du XHTML, et que l'on abandonnera la soupe de balises text/html déclarée comme du XHTML. Ce n'est clairement pas le cas aujourd'hui, et tu le reconnais toi-même (cf. ta remarque sur les « navigateurs "anciens" »)
Si cela devient le cas, les utilisateurs de xhtml seront ravis d'avoir fait le pari, à défaut... :-)
-- Michaël DENIS
Pierre Goiffon
Michael DENIS wrote:
Il ne sera plus recevable lorsque la majorité des navigateurs pourront utiliser un vrai parser XML pour lire du XHTML, et que l'on abandonnera la soupe de balises text/html déclarée comme du XHTML.
Si cela devient le cas, les utilisateurs de xhtml seront ravis d'avoir fait le pari, à défaut... :-)
Pas seulement ! La très large majorité des pages XHTML disponibles sur le Web aujourd'hui ne passeraient pas du tout si elles étaient servies en application/xml+xhtml !
Michael DENIS wrote:
Il ne sera plus recevable lorsque la majorité des navigateurs pourront
utiliser un vrai parser XML pour lire du XHTML, et que l'on abandonnera
la soupe de balises text/html déclarée comme du XHTML.
Si cela devient le cas, les utilisateurs de xhtml seront ravis d'avoir
fait le pari, à défaut... :-)
Pas seulement !
La très large majorité des pages XHTML disponibles sur le Web
aujourd'hui ne passeraient pas du tout si elles étaient servies en
application/xml+xhtml !
Il ne sera plus recevable lorsque la majorité des navigateurs pourront utiliser un vrai parser XML pour lire du XHTML, et que l'on abandonnera la soupe de balises text/html déclarée comme du XHTML.
Si cela devient le cas, les utilisateurs de xhtml seront ravis d'avoir fait le pari, à défaut... :-)
Pas seulement ! La très large majorité des pages XHTML disponibles sur le Web aujourd'hui ne passeraient pas du tout si elles étaient servies en application/xml+xhtml !
SAM
Le 2/23/09 11:27 AM, Olivier Miakinen a écrit :
Bonjour,
Le 20/02/2009 18:19, SAM a écrit :
Euh ? Je dirai que la majorité des navigateurs modernes proposent un moyen de ne pas tenir compte des target non ?
Ah ? Dans firefox par exemple, comment fait-on ? Ça m'intéresserait...
Ha? J'aurais juré craché que c'était prévu. Ben ... non :-(
Ah ? La méthode qui fonctionnait depuis des annnées dans Mozilla ne fonctionnerait donc plus dans Firefox ?
Pour _choisir_ soi-même *même* fenêtre (ou onglet) ? Au coup par coup (menu contextuel) ... non, pas trouvé.
<cit. http://www.miakinen.net/vrac/fenetre#t4> Il vous suffit de mettre dans votre fichier user.js la ligne suivante. user_pref("browser.block.target_new_window", true); </cit.>
et ça fonctionne aussi avec : target="trucmuche" ? (censé ouvrir dans une fenêtre-onglet nommée, probablement déjà ouverte)
(remplacer user.js et user_pref() par about:config pour un accès un peu plus simple)
Oui mais ça ça bloque systématiquement le html-popup, non ? Ha? il parait que ça ne fonctionne pas dans Fx ?
Bon, j'espère qu'en ce cas le menu contextuel continue à proposer : - nouvelle fenêtre - nouvel onglet
(je n'aime pas être coincé par des pré-choix, surtout s'ils ne sont pas faciles d'accès)
-- sm
Le 2/23/09 11:27 AM, Olivier Miakinen a écrit :
Bonjour,
Le 20/02/2009 18:19, SAM a écrit :
Euh ? Je dirai que la majorité des navigateurs modernes proposent un
moyen de ne pas tenir compte des target non ?
Ah ? Dans firefox par exemple, comment fait-on ? Ça m'intéresserait...
Ha? J'aurais juré craché que c'était prévu.
Ben ... non :-(
Ah ? La méthode qui fonctionnait depuis des annnées dans Mozilla ne
fonctionnerait donc plus dans Firefox ?
Pour _choisir_ soi-même *même* fenêtre (ou onglet) ?
Au coup par coup (menu contextuel) ... non, pas trouvé.
<cit. http://www.miakinen.net/vrac/fenetre#t4>
Il vous suffit de mettre dans votre fichier user.js la ligne suivante.
user_pref("browser.block.target_new_window", true);
</cit.>
et ça fonctionne aussi avec : target="trucmuche" ?
(censé ouvrir dans une fenêtre-onglet nommée, probablement déjà ouverte)
(remplacer user.js et user_pref() par about:config pour un accès un peu
plus simple)
Oui mais ça ça bloque systématiquement le html-popup, non ?
Ha? il parait que ça ne fonctionne pas dans Fx ?
Bon, j'espère qu'en ce cas le menu contextuel continue à proposer :
- nouvelle fenêtre
- nouvel onglet
(je n'aime pas être coincé par des pré-choix, surtout s'ils ne sont pas
faciles d'accès)
Euh ? Je dirai que la majorité des navigateurs modernes proposent un moyen de ne pas tenir compte des target non ?
Ah ? Dans firefox par exemple, comment fait-on ? Ça m'intéresserait...
Ha? J'aurais juré craché que c'était prévu. Ben ... non :-(
Ah ? La méthode qui fonctionnait depuis des annnées dans Mozilla ne fonctionnerait donc plus dans Firefox ?
Pour _choisir_ soi-même *même* fenêtre (ou onglet) ? Au coup par coup (menu contextuel) ... non, pas trouvé.
<cit. http://www.miakinen.net/vrac/fenetre#t4> Il vous suffit de mettre dans votre fichier user.js la ligne suivante. user_pref("browser.block.target_new_window", true); </cit.>
et ça fonctionne aussi avec : target="trucmuche" ? (censé ouvrir dans une fenêtre-onglet nommée, probablement déjà ouverte)
(remplacer user.js et user_pref() par about:config pour un accès un peu plus simple)
Oui mais ça ça bloque systématiquement le html-popup, non ? Ha? il parait que ça ne fonctionne pas dans Fx ?
Bon, j'espère qu'en ce cas le menu contextuel continue à proposer : - nouvelle fenêtre - nouvel onglet
(je n'aime pas être coincé par des pré-choix, surtout s'ils ne sont pas faciles d'accès)
-- sm
Pascale
Pierre Goiffon écrivait news:49a28b0f$0$5841$:
Par contre, la mise en page par tableaux est une horreur absolue à intégrer (je pense aux sites dynamiques en particulier) et à maintenir !
V'là autre chose... (-:
-- Pascale
Pierre Goiffon <pgoiffon@free.fr.invalid> écrivait
news:49a28b0f$0$5841$426a74cc@news.free.fr:
Par contre, la mise en page par tableaux est une horreur absolue à
intégrer (je pense aux sites dynamiques en particulier) et à maintenir !
Par contre, la mise en page par tableaux est une horreur absolue à intégrer (je pense aux sites dynamiques en particulier) et à maintenir !
V'là autre chose... (-:
-- Pascale
SAM
Le 2/23/09 1:46 PM, kurtbosh a écrit :
On 23 fév, 12:39, Pierre Goiffon wrote:
Par contre, la mise en page par tableaux est une horreur absolue à intégrer (je pense aux sites dynamiques en particulier) et à maintenir ! Séparer fond et forme permet de gagner considérablement sur ces aspects.
En résumé, passer à CSS c'est un investissement, mais ça en vaut très largement le coup. Et il y a de très nombreux concepteurs aujourd'hui qui peuvent en témoigner ! (moi par exemple :) )
Oui, sans doute mais je les aime bien mes tables, elles m'obéissent au doigt et à l'œil
Ben tes tables n'ont pas l'air de m'obéir au doigt et à l'oeil (comme déjà dit) en particulier au retrécissizing
Je reconnais aussi que s'y retrouver dans une page où il y a beaucoup de tables imbriquées ce n'est pas toujours simple !!!! J'y viendrai, c'est certain mais je n'ai pas encore le courage.
Bon, on va patienter alors ;-)
Mais le passage de table à non-table c'est du boulot ! (extraire tous les contenus des td sans en oublier pour les remettre dans du html plus normal, c'est assez fastidieux.)
Alors tente déjà de prévoir tes nouvelles pages sans tables, et migre les autres progressivement.
-- sm
Le 2/23/09 1:46 PM, kurtbosh a écrit :
On 23 fév, 12:39, Pierre Goiffon <pgoif...@free.fr.invalid> wrote:
Par contre, la mise en page par tableaux est une horreur absolue à
intégrer (je pense aux sites dynamiques en particulier) et à maintenir !
Séparer fond et forme permet de gagner considérablement sur ces aspects.
En résumé, passer à CSS c'est un investissement, mais ça en vaut très
largement le coup.
Et il y a de très nombreux concepteurs aujourd'hui qui peuvent en
témoigner ! (moi par exemple :) )
Oui, sans doute mais je les aime bien mes tables, elles m'obéissent au
doigt et à l'œil
Ben tes tables n'ont pas l'air de m'obéir au doigt et à l'oeil
(comme déjà dit) en particulier au retrécissizing
Je reconnais aussi que s'y retrouver dans une page où il y
a beaucoup de tables imbriquées ce n'est pas toujours simple !!!! J'y
viendrai, c'est certain mais je n'ai pas encore le courage.
Bon, on va patienter alors ;-)
Mais le passage de table à non-table c'est du boulot !
(extraire tous les contenus des td sans en oublier pour les remettre
dans du html plus normal, c'est assez fastidieux.)
Alors tente déjà de prévoir tes nouvelles pages sans tables, et migre
les autres progressivement.
Par contre, la mise en page par tableaux est une horreur absolue à intégrer (je pense aux sites dynamiques en particulier) et à maintenir ! Séparer fond et forme permet de gagner considérablement sur ces aspects.
En résumé, passer à CSS c'est un investissement, mais ça en vaut très largement le coup. Et il y a de très nombreux concepteurs aujourd'hui qui peuvent en témoigner ! (moi par exemple :) )
Oui, sans doute mais je les aime bien mes tables, elles m'obéissent au doigt et à l'œil
Ben tes tables n'ont pas l'air de m'obéir au doigt et à l'oeil (comme déjà dit) en particulier au retrécissizing
Je reconnais aussi que s'y retrouver dans une page où il y a beaucoup de tables imbriquées ce n'est pas toujours simple !!!! J'y viendrai, c'est certain mais je n'ai pas encore le courage.
Bon, on va patienter alors ;-)
Mais le passage de table à non-table c'est du boulot ! (extraire tous les contenus des td sans en oublier pour les remettre dans du html plus normal, c'est assez fastidieux.)
Alors tente déjà de prévoir tes nouvelles pages sans tables, et migre les autres progressivement.
-- sm
SAM
Le 2/23/09 2:15 PM, Michael DENIS a écrit :
Olivier Miakinen a écrit :
des balises invalides en SGML (<br/> par exemple).
<br /> ;-) C'est vrai, même si les navigateurs ne sont nullement gênés par cette spécificité.
Heu ... est-ce que ça ne fait passer Fx en quirksmode ?
-- sm
Le 2/23/09 2:15 PM, Michael DENIS a écrit :
Olivier Miakinen a écrit :
des balises invalides en SGML (<br/> par exemple).
<br /> ;-)
C'est vrai, même si les navigateurs ne sont nullement gênés par cette
spécificité.
Heu ... est-ce que ça ne fait passer Fx en quirksmode ?
des balises invalides en SGML (<br/> par exemple).
<br /> ;-) C'est vrai, même si les navigateurs ne sont nullement gênés par cette spécificité.
Heu ... est-ce que ça ne fait passer Fx en quirksmode ?
-- sm
Pierre Goiffon
SAM wrote:
des balises invalides en SGML (<br/> par exemple).
<br /> ;-) C'est vrai, même si les navigateurs ne sont nullement gênés par cette spécificité.
Heu ... est-ce que ça ne fait passer Fx en quirksmode ?
Ha ? Jamais entendu parler.
En tout cas écrire <br/> dans une page XHTML servie en text/html c'est passer outre l'annexe C. Ce dernier n'est pas normatif, juste informel...
Je ne connais pas le comportement des navigateurs si l'on omet les recommandations de l'annexe C, mais je ne suis pas sûr que ça soit très raisonnable de s'aventurer à aller les connaître, tout comme cela me parait dangereux de renvoyer du (x)HTML invalide...
SAM wrote:
des balises invalides en SGML (<br/> par exemple).
<br /> ;-)
C'est vrai, même si les navigateurs ne sont nullement gênés par cette
spécificité.
Heu ... est-ce que ça ne fait passer Fx en quirksmode ?
Ha ? Jamais entendu parler.
En tout cas écrire <br/> dans une page XHTML servie en text/html c'est
passer outre l'annexe C. Ce dernier n'est pas normatif, juste informel...
Je ne connais pas le comportement des navigateurs si l'on omet les
recommandations de l'annexe C, mais je ne suis pas sûr que ça soit très
raisonnable de s'aventurer à aller les connaître, tout comme cela me
parait dangereux de renvoyer du (x)HTML invalide...
des balises invalides en SGML (<br/> par exemple).
<br /> ;-) C'est vrai, même si les navigateurs ne sont nullement gênés par cette spécificité.
Heu ... est-ce que ça ne fait passer Fx en quirksmode ?
Ha ? Jamais entendu parler.
En tout cas écrire <br/> dans une page XHTML servie en text/html c'est passer outre l'annexe C. Ce dernier n'est pas normatif, juste informel...
Je ne connais pas le comportement des navigateurs si l'on omet les recommandations de l'annexe C, mais je ne suis pas sûr que ça soit très raisonnable de s'aventurer à aller les connaître, tout comme cela me parait dangereux de renvoyer du (x)HTML invalide...
Olivier Masson
SAM a écrit :
Ha! oui! OK et quand on se trompe dans l'autre sens (HTML4.01 + attribut complété) ça n'y fonctionne plus. Si on me permet de m'exprimer : ce truc est simplement débile! D'autant qu'en JS on continue de tester true/false et non pas (checked == 'checked')
Ouais, je sais que tu es un rebelle. Va raler auprès du W3C.
SAM a écrit :
Ha! oui! OK
et quand on se trompe dans l'autre sens (HTML4.01 + attribut complété)
ça n'y fonctionne plus.
Si on me permet de m'exprimer : ce truc est simplement débile!
D'autant qu'en JS on continue de tester true/false
et non pas (checked == 'checked')
Ouais, je sais que tu es un rebelle. Va raler auprès du W3C.
Ha! oui! OK et quand on se trompe dans l'autre sens (HTML4.01 + attribut complété) ça n'y fonctionne plus. Si on me permet de m'exprimer : ce truc est simplement débile! D'autant qu'en JS on continue de tester true/false et non pas (checked == 'checked')
Ouais, je sais que tu es un rebelle. Va raler auprès du W3C.