text-align
- Créateur du sujet phelibre
- Date de début
La valeur bottom n'existe pas pour la propriété text-align. Quant à vertical-align, il n'est d'utilité que pour une cellule de tableau (ou tout élément HTML se comportant comme tel grâce à display:table-cell).
Un peu de lecture sur le sujet: Comment centrer verticalement un élément ?
Un peu de lecture sur le sujet: Comment centrer verticalement un élément ?
Décidément je parle beaucoup sans réfléchir ces derniers temps 
phelibre, pourrais-tu donner le contexte précis de ta page stp ?
phelibre, pourrais-tu donner le contexte précis de ta page stp ?
Un positionnement en absolute peut te sauver si ta div est en relative mais il faut donner de "l'air" si tu as du flux dans la div (un padding doit convenir), ça dépend beaucoup du contenu et des attributs donnés. :siffle:
Bonjour,
n'est-il pas plus simple d'ajouter le petit texte dans un paragraphe <p> et ensuite de faire joujou avec le positionnement de ce paragraphe. Sémantiquement ça me paraît plus juste.
n'est-il pas plus simple d'ajouter le petit texte dans un paragraphe <p> et ensuite de faire joujou avec le positionnement de ce paragraphe. Sémantiquement ça me paraît plus juste.
Eh bien le contexte n'existe plus car abandonné ( je voulais avoir une barre ou rectangle long ou il y aurai eu des idéogrammes avec le texte associé en dessous ) le rendu est nul :siffle:
Merci pour les réponses, le site http://www.alsacreations.com devrait me convenir
une petite question avant de partir mon site http://phelibre.free.fr est en HTML 4 , quel est l'intérêt vue le style site de passer en XHTML ?
merci,
Merci pour les réponses, le site http://www.alsacreations.com devrait me convenir
une petite question avant de partir mon site http://phelibre.free.fr est en HTML 4 , quel est l'intérêt vue le style site de passer en XHTML ?
merci,
Le xhtml c'est du html écrit de façon à être du xml valide. Ça peut permettre de récupérer facilement des données de ton site pour des robots en parsant le xml, un poil plus simple que de parser du html. Je crois que ça améliore aussi la vitesse d'affichage des navigateurs qui le lisent plus facilement, mais j'ai pas testé pour vérifier.
Et puis c'est les nouveaux standards. Vu le temps qu'ils mettent à évoluer dans le domaine, autant participer à les faire adopter. Moi le html et tout ce qui tourne autour ça me scandalise à quel point ça a peu évolué depuis sa création. Entre les éléments de formulaires qui sont hyper basique, le javascript qu'est un vrai langage de merde, le css où le blaireau qu'a inventé les div a jamais du les utiliser pour faire des mises en page complexes. Les libs ajax qui sont que des surcouches pourries pour faire des choses que les navigateurs devrait gérer nativement et beaucoup mieux que ça.
Et franchement, côté w3c, ils font du neuf avec du vieux, mais il serait temps de se décider à reprendre tout ça de 0 pour en faire quelque chose d'utilisable et performant.
C'était mon coup de gueule du jour...
Et puis c'est les nouveaux standards. Vu le temps qu'ils mettent à évoluer dans le domaine, autant participer à les faire adopter. Moi le html et tout ce qui tourne autour ça me scandalise à quel point ça a peu évolué depuis sa création. Entre les éléments de formulaires qui sont hyper basique, le javascript qu'est un vrai langage de merde, le css où le blaireau qu'a inventé les div a jamais du les utiliser pour faire des mises en page complexes. Les libs ajax qui sont que des surcouches pourries pour faire des choses que les navigateurs devrait gérer nativement et beaucoup mieux que ça.
Et franchement, côté w3c, ils font du neuf avec du vieux, mais il serait temps de se décider à reprendre tout ça de 0 pour en faire quelque chose d'utilisable et performant.
C'était mon coup de gueule du jour...
A
Anonyme
Invité
Oh le beau troll
Tu es au courant que xhtml existe depuis 1999 et css depuis 1997? C'est pas de la faute du w3c si les webdesigners ont mis le temps à comprendre qu'il fallait séparer le contenu de sa présentation. Encore maintenant, quand on lit les messages sûr ce forum on voit encore pleins de mise en page en mode tableaux. La faute sûrement aux produits Adobe qui permettent d'exporter une page découpée pour le web.
Pour ce qui est de javascript, je ne suis pas informaticien, mais il ne me semble pas que ça soit si nul que ça. De plus des librairies comme jquery permettent de faire pas mal de choses sans trop se casser la tête.
Pour ce qui est du futur, je ne sais pas si tu es au courant mais (x)HTML 5 est presque finalisé et déjà supporté par les navigateurs modernes (ie8 le devrait aussi). Css3 est aussi sur les rails et est déjà supporté en partie.
Bref, les choses bougent, parfois lentement du côté des webdesigners, mais les bonnes pratiques finissent par s'imposer. Les «fabricants» de navigateurs, eux, sont sur les startings-blocks et avides d'implémenter ces nouvelles technologies...
Le web va de mieux en mieux et c'est bien.
Tu es au courant que xhtml existe depuis 1999 et css depuis 1997? C'est pas de la faute du w3c si les webdesigners ont mis le temps à comprendre qu'il fallait séparer le contenu de sa présentation. Encore maintenant, quand on lit les messages sûr ce forum on voit encore pleins de mise en page en mode tableaux. La faute sûrement aux produits Adobe qui permettent d'exporter une page découpée pour le web.
Pour ce qui est de javascript, je ne suis pas informaticien, mais il ne me semble pas que ça soit si nul que ça. De plus des librairies comme jquery permettent de faire pas mal de choses sans trop se casser la tête.
Pour ce qui est du futur, je ne sais pas si tu es au courant mais (x)HTML 5 est presque finalisé et déjà supporté par les navigateurs modernes (ie8 le devrait aussi). Css3 est aussi sur les rails et est déjà supporté en partie.
Bref, les choses bougent, parfois lentement du côté des webdesigners, mais les bonnes pratiques finissent par s'imposer. Les «fabricants» de navigateurs, eux, sont sur les startings-blocks et avides d'implémenter ces nouvelles technologies...
Le web va de mieux en mieux et c'est bien.
salut,
Il me semble que que ie8 ne suportera pas CSS3 (mais faut-il s'en étonner ?). Quand à la question de l'intégration par les webdesigner, il faut dire que pendant longtemps on leur à demander de travailler pour IE sans autre forme de procès. Aujourd'hui les choses bouges (les PDM ne sont plus tout à fait les mêmes).
Enfin, le fait qu'ie n'implémente pas la dernière moutures de CSS (je pense ici à border-radius) est pour moi le signe du champ du cygne.
Il me semble que que ie8 ne suportera pas CSS3 (mais faut-il s'en étonner ?). Quand à la question de l'intégration par les webdesigner, il faut dire que pendant longtemps on leur à demander de travailler pour IE sans autre forme de procès. Aujourd'hui les choses bouges (les PDM ne sont plus tout à fait les mêmes).
Enfin, le fait qu'ie n'implémente pas la dernière moutures de CSS (je pense ici à border-radius) est pour moi le signe du champ du cygne.
Oui les choses bougent, sauf que concrètement, ça nous apporte rien. La séparation du contenu et de la présentation, moi j'ai pas encore vu l'intérêt. Pour les aveugle peut-être, mais vu ce que ça coûte aux dévelopeurs on pourrait tous leur payer un salarié à temps plein pour lire à leur place. Une mise en page 100% css, ça prend toujours nettement plus de temps qu'avec des tableaux. Au lieu de simplifier la création d'interfaces web qui prennent un temps fou, on les a encore complexifiées. Pour faire une page web on utilise 4 langages, dont 3 qu'on génère parfois avec le 4e. C'est une aberration. Pour faire du web2 on ajoute du xml avec un parseur à chaque bout, ce qui monte le total à 5 langages. Pour faire des composants graphiques évolués, on ajoute 15 tonnes de javascript et de css. Bien sûr pour nous faciliter la tâche on a quelques usines à gaz type dojo, ajaxtag, prototype, scriptaculous, mootools, jquery, ou d'une certain façon gwt, mais c'est des surcouches qu'on ajoute sur des langages qui sont plus du tout à adaptés à l'utilisation qu'on en a. Mais ajouter des couches, c'est très à la mode, alors continuons. Peut-être que dans 10 ans le w3c fera quelque chose de vraiment constructif, qui sera repris par les navigateurs dans 20, et qui arriveront auprès du grand public dans 30 ans. Puisqu'on en est toujours à devoir assurer une compatibilité IE6... Qui sait à peine reconnaître un div.
Malheureusement pas le temps de développer ( gloup gloup, je compte sur toi ) mais très rapidement tout de même:
) mais très rapidement tout de même:Référencement, accessibilité, temps de chargement, styles alternatifs, portabilité, maintenabilité, modularité et pérennité du code, impression des pages
Pour peu que tu connaisses bien les fondements de CSS, c'est très franchement l'inverse, et c'est d'autant plus vrai pour un layout très "riche" graphiquement.
Très rapidement à nouveau:
Ceci dit, rien n'empêche effectivement les constructeurs de navigateurs de commencer à implémenter certaines fonctionnalités déjà bien définies (opacity, border-radius, box-shadow, etc.), mais de là à dire qu'un navigateur supporte CSS3, il y a de la marge
Attention, CSS3 est encore bien loin d'être finalisé. Ça avance doucement, mais la spécification est d'une tout autre nature que CSS2. Les différents (et trop nombreux) modules en cours de développement n'avancent pas non plus à la même vitesse.
Ceci dit, rien n'empêche effectivement les constructeurs de navigateurs de commencer à implémenter certaines fonctionnalités déjà bien définies (opacity, border-radius, box-shadow, etc.), mais de là à dire qu'un navigateur supporte CSS3, il y a de la marge
A
Anonyme
Invité
( gloup gloup, je compte sur toi
Heu Non merci
Tu as bien résumé, j'ai déjà eu ce genre de discussion avec notre ami jadis
grumff, pour bien te faire comprendre le bénéfice de la séparation du contenu de la présentation va voir par exemple cet article sur alistapart et fais un aperçu avant impression. Étonnant non? Ça fonctionne aussi dans le viellissant et emmerdant IE6 (avec une ou deux petites différences), c'est un des innombrables bénéfices des css évoqués par benjamin.
Sauf que ce qui compte le plus pour le référencement c'est surtout le nombre de site qui pointent vers le tiens et leur fréquentation. Le reste est assez accessoire. Et c'est des principes imposées par les moteurs de recherche qui sont régulièrement remis en question. C'est pas bien référencé macgeneration par exemple ? Pourtant c'est plein de tableau.Malheureusement pas le temps de développer ( gloup gloup, je compte sur toi
Référencement,
oui, on en revient aux aveugles, voir post précedent, et de toutes façons ça leur suffit même pas, mais pourtant c'est l'argument le moins négligeables.
hyper négligeable avec les machines actuelles.
Ça c'est de la théorie. Dans la pratique on retouche jamais les css sans retoucher les div, on n'a jamais deux feuilles de style, sauf quelques sites, toujours les mêmes qu'on nous renvoie en exemple. Et le contenu est stocké en bdd ou dans des fichiers d'internationalisation, les sites statiques ça n'existe plus, ou alors ils sont fait avec dreamweaver (rire). La séparation n'a aucune raison d'être à l'affichage, une page html c'est justement que de la présentation.
Point de vue extrêmement subjectif. J'ai justement le sentiment de connaître relativement correctement les fondements de css, mais le simple titre de ce sujet est un exemple flagrant.
Le centrage horizontal est tout aussi drôle d'ailleurs. Et pour reproduire les interactions des cases de tableaux entre elles quand les tailles des unes et des autres peuvent varier, c'est toujours du bidouillage à deux balles. Sans parler du temps d'adaptation pour une compatibilité ie6 (utilisé par tous les clients de la boite où je bosse, et demandé dans tous les contrats quand j'étais en ssii).
Bien sûr je joue pas les les extrémistes non plus. Mettre les balises adaptées pour l'accessibilité selon si on est dans un paragraphe un titre de niveau 1 ou 2 ou un vrai tableau, je le fais quand c'est possible, j'utilise avec plaisir le css pour pas avoir à répéter les mêmes paramètres partout, définir la couleur du texte, etc... Mais vouloir à tout prix suivre à la lettre les recommandations du w3c et éliminer tous les tableaux pour faire la mise en page, je trouve ça ridicule au possible. C'est du moutonisme. Pour le xhtml je dis pas, ça coûte rien de fermer les balises et c'est ptêtre un poil mieux pour optimiser la vitesse d'affichage, mais bon, ça casse pas des briques.
A
Anonyme
Invité
Finalement je vais te répondre grumff, mais pas maintenant, peut-être ce midi ou ce soir parce que là il y a beaucoup de choses à dire...
@+
@+
A
Anonyme
Invité
Le fait d'utiliser un site sémantiquement correct (notamment la hiérarchie des titres), valide et accessible facilite grandement le travail des robots pour savoir de quoi parle un article.
AMHA, si macgeneration est bien référencé, c'est juste dû à sa popularité et l'amélioration du code html (encore beaucoup de progrès à faire pourtant) et l'adoption d'urls significatives sur le forum et dans les articles.
L'accessibilité ne se résume pas qu'aux aveugles, c'est même une norme au W3C, il y a différent niveaux proposés suivants le genre de site que l'on réalise : un administration publique se doit d'avoir le niveau le plus élevé. Si on suit quelques règles de bases (pas forcément celles du w3c), on peut déjà faire un site accessible au plus grand nombre sans perdre du temps lors de la création, c'est un automatisme à avoir.
Pas d'accord, quand je surfe avec mon iphone en edge, je suis bien content de trouver une mise en page légère avec un code html de qualité, un fichier css et des images qui se mettent dans le cache du navigateur. De plus, outre les performances et l'amélioration de la bande passante, il y a encore plein de personnes dans le monde qui surfent sans adsl.
N'importe quoi. :rolleyes: Tu as été voir le site que je t'ai donné tout à l'heure? Tu n'as pas vu que le document était différent à l'écran et sur l'imprimante? Comment est-ce possible? Parce que on a séparé le contenu de la présentation et que l'on a donné une feuille de style css différente pour le media screen et le media print. Il existe bien d'autres media, et aujourd'hui on peut même utiliser des medias queries pour adapter la présentation à la taille de l'écran.
Pour ce qui est des bases de données, le fait d'avoir un code html pur, sans code de présentation permet justement de changer facilement de thèmes. Exemple sur le site de dotaddict qui référence (entre autres) les thèmes pour dotclear 2, quand on sélectionne un thème, le code html du billet ne change pas. Parfois, le code html «autour» change un peu avec un fichier css propre, parfois le thème est juste constitué du fichier css, on passe ainsi d'un thème classique, à un thème plus stylé ou carrément de type magazine. Et c'est comme ça pour beaucoup de cms modernes...
J'ai commencé à apprendre le web en mode tableaux et je peux te dire que la mise en page par css est beaucoup plus rapide. Et je ne parle pas de la flexibilité quand on ajoute du contenu. Il ne sert à rien d'essayer de reproduire en css le fonctionnement d'un site en mode tableaux, il faut d'abord analyser le boulot et produire le code html+css adapté. Il y a des cas très rare ou on devra encore utiliser un tableau pour faire du multicolonnage mais c'est de moins en moins nécessaire, de plus il existe des règles css pour donner à des éléments html le comportement de cellules, de tableaux. Malheureusement elles ne sont pas implémentées dans IE6 (7?).
En conclusion, j'ai plus l'impression que ton coup de gueule est une méconnaissance sur telles ou telles choses concernant les css et un coup de gueule contre IE6 qui a ses bugs bien à lui. Il existe pourtant de nombreuses ressources francophones sur le web, mes préférées :
Bon on s'éloigne du post original mais bon j'en profite
J'ai besoin de changer la couleur de fond que j'ai déclaré dans mon css pour la page galerie
J'ai donc redéclaré dans la page galerie dans la rubrique <body> ma couleur de fond.
Mais impossible , le navigateur ne le prends pas en compte !
Pour y arriver je suis obliger de recharger un autre css (avec la bonne couleur of course)
Vous feriez comment vous avec un seul css ?
merci, cela concerne la reprise de mon site http://phelibre.free.fr
J'ai besoin de changer la couleur de fond que j'ai déclaré dans mon css pour la page galerie
J'ai donc redéclaré dans la page galerie dans la rubrique <body> ma couleur de fond.
Mais impossible , le navigateur ne le prends pas en compte !
Pour y arriver je suis obliger de recharger un autre css (avec la bonne couleur of course)
Vous feriez comment vous avec un seul css ?
merci, cela concerne la reprise de mon site http://phelibre.free.fr
Donne le code phelibre.
gloupgloup, j'aurai pas le temps de répondre point par point. Me fais pas dire ce que j'ai pas dis, j'ai rien contre le css. Je maintiens toujours que faire plusieurs feuilles de style pour une même page n'arrive jamais. Le cas de l'impression est un exemple à la con. Sortir du texte pour l'imprimer c'est que dalle. On obtient la même chose avec un copier/coller dans pages, d'autant que la page en question est hyper simple. Il faut deux minutes pour réécrire une page qui fasse une mise en page pour l'impression, pas plus de temps que pour écrire la css. Sans parler de l'utilisation de rapports birt ou autre chose du genre, quoi que le cas d'utilisation soit un peu différent. Tu me refiles que des exemples de sites où le temps de développement n'a pas compté, et qui ont des mises en pages qui ont été pensées pour le css, et non pas faites par un graphiste qui n'a aucune notion de comment c'est implémenté. Envoi plutôt des liens de sites sous-traités, réalisé dans des délais serrés par des webagency ou des ssii.
Mais bref, à la limite c'est même pas le problème. Le css encore une fois j'ai rien contre. Ni contre le fait de respecter la sémantique des balises, mais dans une certaine mesure. Un moteur de recherche va pas partir en live parce qu'on a mis 3 tableaux pour la mise en page. C'est la principale chose que je reproche au css, d'avoir voulu supprimer les tableaux pour la mise en page, c'est ridicule, ça n'a aucune justification, c'est de la stupidité. Soit, un tableau a une signification sémantique, mais dans ce cas il fallait en inventer un deuxième qui ne serve qu'à la mise en page. Vouloir tout faire avec une seule balise c'est du masochisme. Je suis désolé mais les comportement des tableaux sont quasi impossibles à reproduire en css, comme je l'ai dis précédemment, la façon dont les colonnes et lignes entières s'adaptent en fonction de la largeur/hauteur de texte saisi dans une colonne, ça peut pas être fait autrement. Je te remercie au passage pour l'argument à deux balles du type tu trouves ça plus compliqué donc tu sais pas faire, nan, je crois que je me suis assez bouffé de toutes les technos depuis que j'ai 12 ans pour savoir les comparer.
Et pour info, le gros de mon boulot c'est des logiciels type client léger/client riche. Pas des sites web, et c'est là que je fais un très gros reproche au w3c qui n'a fait aucun effort dans cette direction. Les langages sont pas du tout adaptés au web2, ou au développement d'applis client/serveur, le coût de l'interface est gigantesque. On devrait pas avoir besoin de gwt pour faire des applis web qui n'utilisent qu'un seul langage. On devrait avoir des mécanismes qui permettent de transmettre automatiquement les événements au code serveur qui en retour pourrait renvoyer un ordre de mise à jour des composants de la page, sans qu'on ait à passer par du JS. C'est une suggestion à la con, mais qui n'a rien d'impossible techniquement. C'est juste une approche complètement différente de ce qu'on fait aujourd'hui. Et c'est là que les standards n'évoluent pas du tout. La réalisation d'interfaces web riches en web2 est hyper coûteuse en temps, alors que chaque heure nous ait comptée et coûte cher (Une journée soit 8H de dev pour un ingé, c'est 400 à 600 euros hors région parisienne). Il y a un énorme travail à faire pour essayer des approches radicalement différentes, et les efforts déployés dans cette direction sont ridicules. Il n'y a que GWT d'un peu révolutionnaire, mais ça me convient pas parfaitement non plus, on se retrouve avec deux couches métiers, une côté client et une côté serveur, c'est l'autre théorie très à la mode de l'empilement de couches. Moi je pense qu'on pourrait tout mettre côté serveur, ils sont tellement puissants qu'on se donne même pas la peine de compiler les applis...
gloupgloup, j'aurai pas le temps de répondre point par point. Me fais pas dire ce que j'ai pas dis, j'ai rien contre le css. Je maintiens toujours que faire plusieurs feuilles de style pour une même page n'arrive jamais. Le cas de l'impression est un exemple à la con. Sortir du texte pour l'imprimer c'est que dalle. On obtient la même chose avec un copier/coller dans pages, d'autant que la page en question est hyper simple. Il faut deux minutes pour réécrire une page qui fasse une mise en page pour l'impression, pas plus de temps que pour écrire la css. Sans parler de l'utilisation de rapports birt ou autre chose du genre, quoi que le cas d'utilisation soit un peu différent. Tu me refiles que des exemples de sites où le temps de développement n'a pas compté, et qui ont des mises en pages qui ont été pensées pour le css, et non pas faites par un graphiste qui n'a aucune notion de comment c'est implémenté. Envoi plutôt des liens de sites sous-traités, réalisé dans des délais serrés par des webagency ou des ssii.
Mais bref, à la limite c'est même pas le problème. Le css encore une fois j'ai rien contre. Ni contre le fait de respecter la sémantique des balises, mais dans une certaine mesure. Un moteur de recherche va pas partir en live parce qu'on a mis 3 tableaux pour la mise en page. C'est la principale chose que je reproche au css, d'avoir voulu supprimer les tableaux pour la mise en page, c'est ridicule, ça n'a aucune justification, c'est de la stupidité. Soit, un tableau a une signification sémantique, mais dans ce cas il fallait en inventer un deuxième qui ne serve qu'à la mise en page. Vouloir tout faire avec une seule balise c'est du masochisme. Je suis désolé mais les comportement des tableaux sont quasi impossibles à reproduire en css, comme je l'ai dis précédemment, la façon dont les colonnes et lignes entières s'adaptent en fonction de la largeur/hauteur de texte saisi dans une colonne, ça peut pas être fait autrement. Je te remercie au passage pour l'argument à deux balles du type tu trouves ça plus compliqué donc tu sais pas faire, nan, je crois que je me suis assez bouffé de toutes les technos depuis que j'ai 12 ans pour savoir les comparer.
Et pour info, le gros de mon boulot c'est des logiciels type client léger/client riche. Pas des sites web, et c'est là que je fais un très gros reproche au w3c qui n'a fait aucun effort dans cette direction. Les langages sont pas du tout adaptés au web2, ou au développement d'applis client/serveur, le coût de l'interface est gigantesque. On devrait pas avoir besoin de gwt pour faire des applis web qui n'utilisent qu'un seul langage. On devrait avoir des mécanismes qui permettent de transmettre automatiquement les événements au code serveur qui en retour pourrait renvoyer un ordre de mise à jour des composants de la page, sans qu'on ait à passer par du JS. C'est une suggestion à la con, mais qui n'a rien d'impossible techniquement. C'est juste une approche complètement différente de ce qu'on fait aujourd'hui. Et c'est là que les standards n'évoluent pas du tout. La réalisation d'interfaces web riches en web2 est hyper coûteuse en temps, alors que chaque heure nous ait comptée et coûte cher (Une journée soit 8H de dev pour un ingé, c'est 400 à 600 euros hors région parisienne). Il y a un énorme travail à faire pour essayer des approches radicalement différentes, et les efforts déployés dans cette direction sont ridicules. Il n'y a que GWT d'un peu révolutionnaire, mais ça me convient pas parfaitement non plus, on se retrouve avec deux couches métiers, une côté client et une côté serveur, c'est l'autre théorie très à la mode de l'empilement de couches. Moi je pense qu'on pourrait tout mettre côté serveur, ils sont tellement puissants qu'on se donne même pas la peine de compiler les applis...
Sujets similaires
