En fait, CSS2 définit que l'attribut overflow s'appliquent aux éléments de type block, et les tables n'en font clairement pas partie.
En forçant "display: block" dans "tbody", j'arrive également à mes fins avec Konqueror, et le résultat est à peu près le même du coté de Mozilla. Evidement, le rendu ne ressemble à rien puisque l'on brise le modèle de table.
IE6 ne veut rien savoir. Pas de IE7 sous la main pour tester.
Vire le "display: block" de <tbody>, ce n'est pas un mode approprié pour une table (en plus de inline, block et none, il existe des modes standard spéciaux pour les tables).
S'il n'y a pas trop de contraintes sur la table et ses autres composantes (comme des hauteurs contradictoires), ça passe sans problème (chez moi, sur Firefox et Firebird).
Par contre, c'est catastrophique sous IE.
Si tu as une imprimante laser au bureau et de quoi relier des documents, je te conseille fortement d'imprimer les spécifications du HTML 4.01 (Le document sur XHtml ne fait qu'étendre celui-ci) et celles de CSS2. Elles pèsent 340 pages chacune, mais chaque volume contient non seulement la liste des balises, mais aussi celle des attributs classés par ordre alphabétique avec, pour chacun d'un, les balises auxquelles ils s'appliquent. En outre, le contenu est généralement très détaillé et chaque référence à une notion quelquonque exposée dans un paragraphe est accompagné du numéro de page précis où elle est définie.
Notament pour le coup du tableau. D'une, ça ne fait rien du tout (ou alors, je n'ai rien compris), ensuite, ça ne permet pas d'avoir des en-têtes fixes, un peu comme quand on fige les volets dans un tableur.
C'est-à-dire que overflow n'est pas propre à un tableau en général. Ensuite, pour que cela ait du sens, il faut également que l'élément concerné ait une taille définie. Sinon, il croît avec son contenu et la directive overflow reste sans objet.
Pour les entêtes de tableaux, il existe les balises <thead>, <tbody> et <tfoot> (au moins en XHTML), à définir à l'intérieur de <table></table>. Attention, <thead> et <tfoot> doivent être définis avant <tbody>. Ceci permet d'indiquer au navigateur quelles sont les données qui forment les entêtes et pieds de table, mais le rendu reste à sa charge. Leur réplication fonctionne bien à l'impression si la CSS a été définie pour le médium printer en particulier. Je n'ai pas essayé à l'écran. Tu dois probablement pouvoir figer une entête mais pas un panneau latéral. Le HTML n'a pas non plus vocation à devenir un tableur (qui eux-mêmes ne proposent pas tous cette fonctionnalité, de toutes façons).
Tu peux également essayer de mettre un <span> avec un overflow bien défini autour des cellules que tu veux scroller. Cela reste correct d'un point de vue syntaxique, mais sémantiquement, je ne pense pas que la DTD du XHTML te laisse le faire, et cela ne passera donc sûrement pas le validateur. Très gruik, donc. A essayer pour la bidouille, mais à ne pas livrer en production.
Le coup de l'image de fond, j'ai compris le principe, mais honnêtement, je trouve ça porc.... Ceci dit, si le html était un langage propre, ça se saurait !
Moi aussi, mais à y réflechir, cela a plus de sens qu'on ne le croit. Non seulement, c'est beaucoup plus léger, mais cela passe également avec tous les navigateurs, mêmes anciens, et cela revient en somme à remplir une sorte de "formulaire préimprimé", un peu comme une copie fournissant dès le départ le lignage et la marge.
En outre, une <div class="menu"> a encore du sens, mais si l'on se retrouve à utiliser des balises particulières et à classifier des informations de manière à contourner les limitations d'affichage du navigateur, alors on se remet à lier contenu et mise en page et on brise le concept même des CSS. A ce moment, il vaut mieux quand même revenir au fond d'écran, même si c'est décevant.
Pour sa défense, je suis quand même obligé de dire que quiquonque n'a pas été concrètement confronté à ce problème en CSS ne peut savoir réellement de quoi il s'agit.
C'est loin d'être un problème con. L'ajustement précis de la hauteur d'un élément est en problème qui émaille régulièrement les forums consacrés aux CSS. D'ailleurs, une petite recherche permet déjà d'obtenir de bons éléments de réponse.
Le problème de la manchette latérale est le suivant : ton <div> est un élément à priori relatif à son container parent, ici le <body>. Or, la taille de celui-ci n'est pas connue à l'avance car il dépend de son contenu. La plupart des gens assimile le corps du document au médium qui en fait le rendu, en l'occurence le moniteur. Dans le cas d'une imprimante à flot continu (type listing), par exemple, la hauteur maximum n'est pas fixée ...
Le problème du height: 100px est qu'il va effectivement utiliser la hauteur de l'écran. Mais si le contenu du corps est plus haut que l'écran, la manchette n'ira pas plus bas pour autant. Même chose pour le contenu de la manchette qui débordera hors des frontières si il est un minimum fourni.
Moi, j'ai fini par abandonner et j'ai " résolu " le problème en trichant : J'ai affecté une image de fond répétée à <body> qui dessine une manchette trompe-l'oeil et j'ai déclaré une division transparente dont la hauteur n'est pas définie. Cette manière de faire est également la plus légère pour le navigateur.
Pour le tableau à taille fixe mais avec des barre de défilement : overflow: auto.
Le bon sens nous pousse à utiliser un Makefile par répertoire, sauf cas particuliers où il n'y a rien à compiler ou à traiter d'une manière générale dans ces dépôts.
Ensuite, on compile en général toutes les sources et ressources d'un même module en un seul *.o local, puis le Makefile du premier niveau les assemble tous avec le main pour former l'exécutable final.
Après, cela dépend un peu de ton niveau en matière de Makefile. Tu n'es pas obligé d'utiliser de règles implicites ou autres optimisations dans le genre, mais il faut au minimum écrire correctement ses dépendances (tout l'intérêt d'un Makefile).
Oui, enfin, on se tord surtout les doigts sur des claviers AZERTY.
D'un autre coté, si la plupart des symboles ont quand même du sens (telles les accolades pour définir un bloc d'instructions), il faut bien reconnaître que la plupart des lexiques des langages informatiques (américains pour la plupart) ont été conçus en fonction de ce que le clavier proposait.
Oui, et c'est même très important de le faire, parce que cela permet d'être sûr, après coup, que l'on a résolu le problème, et que l'on ne s'est pas cantonné à tatonner jusqu'à ce que l'application ait l'air de fonctionner comme attendu.
Oui, c'est bien cela qui empêche le partage. « -s » signifie « source » dans ce contexte, « -o » veut dire « out » et « -j » signifie « jump ».
Le « /24 » est équivalent à un « netmask 255.255.255.0 » et sert à dire que seuls les 24 premiers bits, donc les trois premiers octets, de l'adresse désignent le réseau. Les huits derniers donnent le numéro de machine.
Cela veut donc dire que seuls seront « traduits » les paquets IP qui non seulement sont sur le point de sortir par eth1 (donc, à priori, se dirigent vers Internet), mais qui proviennent également et exclusivement d'une adresse en 192.168.0.xxx .
Et comme toi, tu as mis en place des adresses en 192.168.1.xxx, évidemment, cela ne passe pas. Le pire, ces que ces paquets sont probablement envoyés tels quels vers l'extérieur, mais ils sont arrêtés aussi secs par ta Freebox.
Solution :
Soit, tu remplaces « -s 192.168.0.0/24 » par « -s 192.168.1.0/24 », soit tu retires carrément cette directive pour que tout ce qui est censé sortir soit traduit sans distinction. Attention : le « -j » fait partie de la directive suivante. Il sert à dire ce qu'il faut faire d'un paquet une fois que l'on a constaté qu'il correspond bien à la règle que l'on a définie (en l'occurence, le traduire).
# Onze pour une coupe
Posté par Obsidian . En réponse au journal Les 10 commandements du linuxien. Évalué à 9.
# En voila un :
Posté par Obsidian . En réponse au message Cherche patch ACL pour noyaux 2.4 récents. Évalué à 2.
http://acl.bestbits.at/download.html
C'est pas suffisant ?
[^] # Re: C'est pas très clair
Posté par Obsidian . En réponse au message Fixer arbitrairement une taille fixe à un élement.. Évalué à 3.
http://www.w3.org/TR/html401
http://www.w3.org/TR/xhtml1/ (étend la précédente)
http://www.w3.org/TR/CSS2/
Mais je te conseille les versions imprimables :
http://www.w3.org/TR/html401/html40.ps.gz (Postscript)
http://www.w3.org/TR/html401/html40.pdf.gz (PDF)
http://www.w3.org/TR/CSS2/css2.ps.gz (Postscript)
http://www.w3.org/TR/CSS2/css2.pdf (PDF)
Elles sont plus faciles à lire et à consulter.
Bon courage pour la suite.
[^] # Re: oui et en francais ca donne quoi ?
Posté par Obsidian . En réponse au message problème de démarrage. Évalué à 3.
Pour une fois que quelqu'un est contraint d'utiliser la console, on ne va pas l'en dissuader.
[^] # Re: C'est pas très clair
Posté par Obsidian . En réponse au message Fixer arbitrairement une taille fixe à un élement.. Évalué à 2.
En forçant "display: block" dans "tbody", j'arrive également à mes fins avec Konqueror, et le résultat est à peu près le même du coté de Mozilla. Evidement, le rendu ne ressemble à rien puisque l'on brise le modèle de table.
IE6 ne veut rien savoir. Pas de IE7 sous la main pour tester.
[^] # Re: C'est pas très clair
Posté par Obsidian . En réponse au message Fixer arbitrairement une taille fixe à un élement.. Évalué à 2.
S'il n'y a pas trop de contraintes sur la table et ses autres composantes (comme des hauteurs contradictoires), ça passe sans problème (chez moi, sur Firefox et Firebird).
Par contre, c'est catastrophique sous IE.
Si tu as une imprimante laser au bureau et de quoi relier des documents, je te conseille fortement d'imprimer les spécifications du HTML 4.01 (Le document sur XHtml ne fait qu'étendre celui-ci) et celles de CSS2. Elles pèsent 340 pages chacune, mais chaque volume contient non seulement la liste des balises, mais aussi celle des attributs classés par ordre alphabétique avec, pour chacun d'un, les balises auxquelles ils s'appliquent. En outre, le contenu est généralement très détaillé et chaque référence à une notion quelquonque exposée dans un paragraphe est accompagné du numéro de page précis où elle est définie.
[^] # Re: C'est pas très clair
Posté par Obsidian . En réponse au message Fixer arbitrairement une taille fixe à un élement.. Évalué à 2.
C'est-à-dire que overflow n'est pas propre à un tableau en général. Ensuite, pour que cela ait du sens, il faut également que l'élément concerné ait une taille définie. Sinon, il croît avec son contenu et la directive overflow reste sans objet.
Pour les entêtes de tableaux, il existe les balises <thead>, <tbody> et <tfoot> (au moins en XHTML), à définir à l'intérieur de <table></table>. Attention, <thead> et <tfoot> doivent être définis avant <tbody>. Ceci permet d'indiquer au navigateur quelles sont les données qui forment les entêtes et pieds de table, mais le rendu reste à sa charge. Leur réplication fonctionne bien à l'impression si la CSS a été définie pour le médium printer en particulier. Je n'ai pas essayé à l'écran. Tu dois probablement pouvoir figer une entête mais pas un panneau latéral. Le HTML n'a pas non plus vocation à devenir un tableur (qui eux-mêmes ne proposent pas tous cette fonctionnalité, de toutes façons).
Tu peux également essayer de mettre un <span> avec un overflow bien défini autour des cellules que tu veux scroller. Cela reste correct d'un point de vue syntaxique, mais sémantiquement, je ne pense pas que la DTD du XHTML te laisse le faire, et cela ne passera donc sûrement pas le validateur. Très gruik, donc. A essayer pour la bidouille, mais à ne pas livrer en production.
Moi aussi, mais à y réflechir, cela a plus de sens qu'on ne le croit. Non seulement, c'est beaucoup plus léger, mais cela passe également avec tous les navigateurs, mêmes anciens, et cela revient en somme à remplir une sorte de "formulaire préimprimé", un peu comme une copie fournissant dès le départ le lignage et la marge.
En outre, une <div class="menu"> a encore du sens, mais si l'on se retrouve à utiliser des balises particulières et à classifier des informations de manière à contourner les limitations d'affichage du navigateur, alors on se remet à lier contenu et mise en page et on brise le concept même des CSS. A ce moment, il vaut mieux quand même revenir au fond d'écran, même si c'est décevant.
[^] # Re: C'est pas très clair
Posté par Obsidian . En réponse au message Fixer arbitrairement une taille fixe à un élement.. Évalué à 3.
C'est loin d'être un problème con. L'ajustement précis de la hauteur d'un élément est en problème qui émaille régulièrement les forums consacrés aux CSS. D'ailleurs, une petite recherche permet déjà d'obtenir de bons éléments de réponse.
Le problème de la manchette latérale est le suivant : ton <div> est un élément à priori relatif à son container parent, ici le <body>. Or, la taille de celui-ci n'est pas connue à l'avance car il dépend de son contenu. La plupart des gens assimile le corps du document au médium qui en fait le rendu, en l'occurence le moniteur. Dans le cas d'une imprimante à flot continu (type listing), par exemple, la hauteur maximum n'est pas fixée ...
Le problème du height: 100px est qu'il va effectivement utiliser la hauteur de l'écran. Mais si le contenu du corps est plus haut que l'écran, la manchette n'ira pas plus bas pour autant. Même chose pour le contenu de la manchette qui débordera hors des frontières si il est un minimum fourni.
Moi, j'ai fini par abandonner et j'ai " résolu " le problème en trichant : J'ai affecté une image de fond répétée à <body> qui dessine une manchette trompe-l'oeil et j'ai déclaré une division transparente dont la hauteur n'est pas définie. Cette manière de faire est également la plus légère pour le navigateur.
Pour le tableau à taille fixe mais avec des barre de défilement : overflow: auto.
Bon courage.
# Un makefile par répertoire.
Posté par Obsidian . En réponse au message makefile pour code divisé en modules. Évalué à 2.
Le bon sens nous pousse à utiliser un Makefile par répertoire, sauf cas particuliers où il n'y a rien à compiler ou à traiter d'une manière générale dans ces dépôts.
Ensuite, on compile en général toutes les sources et ressources d'un même module en un seul *.o local, puis le Makefile du premier niveau les assemble tous avec le main pour former l'exécutable final.
Après, cela dépend un peu de ton niveau en matière de Makefile. Tu n'es pas obligé d'utiliser de règles implicites ou autres optimisations dans le genre, mais il faut au minimum écrire correctement ses dépendances (tout l'intérêt d'un Makefile).
http://www.google.fr/search?hl=fr&q=Makefile&btnG=Re(...)
[^] # Re: pourquoi le lisp
Posté par Obsidian . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 1.
D'un autre coté, si la plupart des symboles ont quand même du sens (telles les accolades pour définir un bloc d'instructions), il faut bien reconnaître que la plupart des lexiques des langages informatiques (américains pour la plupart) ont été conçus en fonction de ce que le clavier proposait.
[^] # Re: ...
Posté par Obsidian . En réponse au journal "Si j'écrit un bon programme, pourquoi devrais-je le donner ?". Évalué à 4.
[^] # Re: BFM
Posté par Obsidian . En réponse au journal Tout le monde gagne à l'arrivée de Windows Vista !!. Évalué à 9.
[^] # Re: Sans déconner...
Posté par Obsidian . En réponse au message Labyrinthe. Évalué à 3.
Bon, Fatou : qu'est-ce qui t'ennuie ? Ou en es-tu dans ton projet ? Qu'attends-tu que l'on fasse pour toi exactement ?
(Un peu de naïveté de fait pas de mal. Parfois, on a quelques bonnes surprises ...)
[^] # Re: Ç cédille majuscule
Posté par Obsidian . En réponse au journal Que répond un codeur dont le programme ne fonctionne pas ?. Évalué à 2.
[^] # Re: IPoP
Posté par Obsidian . En réponse au journal 1er avril ? 450Go sur une feuille de papier.... Évalué à 2.
Oui, il faudra ajuster le MTU en fonction du délai du ping, mais à 450 Go par feuille, cela reste intéressant ! :-)
# IPoP
Posté par Obsidian . En réponse au journal 1er avril ? 450Go sur une feuille de papier.... Évalué à 5.
[^] # Re: Mes réponses
Posté par Obsidian . En réponse au journal Que répond un codeur dont le programme ne fonctionne pas ?. Évalué à 2.
[^] # Re: Mes réponses
Posté par Obsidian . En réponse au journal Que répond un codeur dont le programme ne fonctionne pas ?. Évalué à 2.
[^] # Re: Mes réponses
Posté par Obsidian . En réponse au journal Que répond un codeur dont le programme ne fonctionne pas ?. Évalué à 7.
[^] # Re: licence globale
Posté par Obsidian . En réponse au journal après la taxe Windows, la taxe Vivendi.. Évalué à 2.
[^] # Re: Abonnement au mois = attrape nigot !
Posté par Obsidian . En réponse au journal après la taxe Windows, la taxe Vivendi.. Évalué à 2.
[^] # Re: Les montres saimal
Posté par Obsidian . En réponse au journal Les montres. Évalué à 10.
[^] # Re: salut :)
Posté par Obsidian . En réponse au message Lancer automatiquement une commande. Évalué à 2.
https://linuxfr.org/forums/9/19603.html
Et que ton partage de connexion avait déjà été discuté là :
https://linuxfr.org/forums/9/18771.html
Oui, c'est bien cela qui empêche le partage. « -s » signifie « source » dans ce contexte, « -o » veut dire « out » et « -j » signifie « jump ».
Le « /24 » est équivalent à un « netmask 255.255.255.0 » et sert à dire que seuls les 24 premiers bits, donc les trois premiers octets, de l'adresse désignent le réseau. Les huits derniers donnent le numéro de machine.
Cela veut donc dire que seuls seront « traduits » les paquets IP qui non seulement sont sur le point de sortir par eth1 (donc, à priori, se dirigent vers Internet), mais qui proviennent également et exclusivement d'une adresse en 192.168.0.xxx .
Et comme toi, tu as mis en place des adresses en 192.168.1.xxx, évidemment, cela ne passe pas. Le pire, ces que ces paquets sont probablement envoyés tels quels vers l'extérieur, mais ils sont arrêtés aussi secs par ta Freebox.
Solution :
Soit, tu remplaces « -s 192.168.0.0/24 » par « -s 192.168.1.0/24 », soit tu retires carrément cette directive pour que tout ce qui est censé sortir soit traduit sans distinction. Attention : le « -j » fait partie de la directive suivante. Il sert à dire ce qu'il faut faire d'un paquet une fois que l'on a constaté qu'il correspond bien à la règle que l'on a définie (en l'occurence, le traduire).
Pour le reste :
$ man iptables
Bon courage.
[^] # Re: Re : Voyez-vous ce qui j'ai pu oublier dans la remise en route ?
Posté par Obsidian . En réponse au message Connexion entre PC. Évalué à 2.
[^] # Re: Nicolas la la ...
Posté par Obsidian . En réponse au journal Qui a dit ?. Évalué à 3.
ou celle-là :
http://matomik.free.fr/_temp/mozinor/la_fievre.avi