Pour te donner mon avis sur la partie nomage des classes, c’est simple : les propriétés et leurs valeurs sont en anglais, les mots sont séparés par des « - » et non des « _ ». J’applique la même chose pour mes nom d’ID et de classes. Le fait de travailler sur des sites anglophones et multilingues n’a fait que renforcer ce choix.

Et effectivement, au-delà de l’interprétation des identifiants par une équipe de développements (en anglais pour toute cette « cible »), tu penses également à l’internaute lambda qui n’a pas à se soucier de l’identification d’une partie de document. C’est la clé : comment identifier un bloc de contenu au sein d’une page ? En mettant en place une vraie URI donc oui en déployant un moyen d’accès compréhensible par son utilisateur donc dans sa langue ! Le fragment devrait donc je pense être localisé comme le reste de l’URL même si techniquement cela est plus lourd à gérer.

(1) Réécriture d’URL : expression signe d’une mauvaise gestion du nommage des documents par un CMS. A partir du moment où les URL sont gérées nativement pourquoi déployer ce patch ? :p

Alors, a priori, tout en français. Si le projet est multilingue : dans la langue principale (si, y’en a toujours une), souvent le français, mais ça peut être italien ou japonais. Bin ouais. Enfin, si le client ou sa cible l’exige, ce sera en anglais, et sans broncher. Mais je fucke les english-lovers. Sincèrement.

En français on a des accents et autre caractère spéciaux que l’on zappe dans le nom de la class et on se retrouve souvent avec des mot incompréhensible ou qui vont demander un temps pour etre déchiffré !

Les ancres restent au niveau du navigateur et ne sont jamais transmises au serveur, donc tu ne pourra rien réécrire à ce niveau.

Je m’en vais changer mes petites habitudes alors.

J’y pense, la gestion des ancres pourrait-elle se faire grâce à la réécriture d’url ?

Ha ha, je suis diabolique. Il me vient soudain l’envie d’apprendre le sanskrit rien que pour t’embêter. Ha ha ha.

Mais dans l’absolu, je suis bien d’accord avec toi. © Vincent Valentin, 2008

Et puis je boycote « .clear » par la même occasion.

Maintenant sur un projet 100% francophone, je ne vois rien de mal à nommer une classe .non-imprimable plutôt que .no-print à condition d’être sûr que le code sera toujours maintenu par une personne francophone. 😮

@Eric : les noms de classes de Yahoo! Grids sont pas véritablement sémantiques non plus :p

Pour ma défense, je parle là de classes génériques que j’utilise sur tous mes projets, j’en ai très peu, et elles sont bien pratiques quand même.

Mais dans l’absolu, je suis bien d’accord avec toi.