[Intermédiaire] Brick à Brack - Site de Brickfilm

Bonjour

Je me nomme Maxime, j'ai actuellement 16ans et je suis en première S, je développe depuis mes 10-11ans et j'arrive désormais à avoir des résultats semi-pro voir pro sur mes projets. Nous sommes actuellement une petite équipe 4administrateurs, 4 modérateurs et des personnes pour dynamiser le forum

J'ai naviguer sur pas mal de site m'ai je n'est recueillit que très peu d'avis sur notre site, j'en reviens à vous pour avoir un avis franc de notre site : http://www.brick-a-brack.com

Il est développé en HTML5, CSS3, PHP, MySQL et fonctionne sur Firefox, Chrome et IE8-9-10 (Pas tester avant)

Toutes les critiques que vous donnerez seront bénéfiques alors merci d'avance

La meta d'encodage est mal rédigée :

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<!-- 
Et pourquoi pas ?
<meta charset="UTF-8" />
-->

Je trouve que le design ne correspond pas au sujet fun du site. Je n'aime pas le menu "Liens utiles" à base d'images, et qui n'est pas dans le ton du site.

Les ressources et leur système de tri est très bien. Par contre, il faut à tout prix optimiser les images : une page comme celle-ci, avec des images de 500 octets en 4000×3000 redimensionnées en css à 500×375, c'est pas possible

Enfin, il y a pas mal de fôtes d'orthographe. Dommage!

Super projet au demeurant! Bonne continuation.

a écrit :
Ah ouais le meta d'encodage on peut le faire comme ça ?

En fait, je ne sais pas si cette forme peut remplacer une meta http-equiv

Le mieux serait peut-être la nouvelle fome, en plus d'une déclaration d'encodage dans le htaccess.

Muchos a écrit :
En fait, je ne sais pas si cette forme peut remplacer une meta http-equiv

Le mieux serait peut-être la nouvelle fome, en plus d'une déclaration d'encodage dans le htaccess.

Elle peut la remplacer, comme indiqué ici et là. Pour ce qui est du rapide tour que j'ai fais dans le code source, quelque chose m'a interpellé. Aucune balise Hn. Sur toute les pages qu'il m'ait été donné de voir (à peu près tous les liens du menu). Chose voulue ?
Modifié par Knozelfhoegtj (31 Dec 2012 - 12:30)

Ces balises sont surtout dédié pour le référencement non ?
Si je n'en ai pas mis c’est surtout que j'ignore ce quelles apportent de plus ^^

D'accord. Une question simple qui fera suite à ta réponse :

Pourquoi utilises-tu HTML5 ? Qu'est-ce que ça t'apporte de plus ?

Ben, le HTML5 apporte une meilleure accessibilité et couplé à du CSS3 ça permet de faire de grand trucs ?

Meilleure accessibilité, oui, mais la principale plus-value est qu'il est plus clair, sémantiquement parlant. Sans titre, tu n'as pas de sémantique. Ton code doit être écrit de manière à ce que lorsqu'une personne désactive tes CSS, la hiérarchie de tes éléments soit encore compréhensible. D'autant plus que tu as besoin de ces balises pour le référencement, effectivement.

Edit : La CSS3 est utilisable avec ou sans HTML5. Couplé ou non, tu pourras faire de « grands trucs ».
Modifié par Knozelfhoegtj (31 Dec 2012 - 12:54)

Merci pour ce petit éclaircissement je vais m'y mettre au plus vite

Hello, j'aime bien le concept du site, quelques remarques maintenant que je suis là :

-pourquoi laisser des entités html comme é si tu es en utf-8 ? Autant mettre directement les caractères accentués en utf-8.

-Tu as un bout de script js pour le captcha sur toutes tes pages (qui est donc rechargé à chaque fois), à mon avis il vaudrait mieux l'intégrer à un ton fichier javascript.js pour qu'il soit en cache une fois pour toute.

-Dans le même ordre d'idée j'ai plutôt tendance à utiliser un CDN (celui de google par exemple) pour charger jquery, ça gagne un poil en temps de chargement vu que 9 fois sur 10 il est déjà en cache.

-J'utiliserais plutot <b> ou <strong> ou <em> plutôt que <span class="gras">. D'une part ça évite de créer une classe, tu peux directement appliquer tes styles aux éléments, et d'autre part ce sera reconnu comme un élément important du texte, notamment par les lecteurs d'écran.

-Même genre de remarque pour ta classe .souligne : En général on évite ce genre de noms de classe parce que le jour ou quelqu'un veut changer le CSS pour que les titres soient en italique et non plus soulignés, tu as une classe .souligne qui met le texte en italique... Quand dans un projet tu te retrouves avec .souligne en italique, .bleu en orange et .lien-rouge en souligné jaune ça devient compliqué de s'y retrouver

-Les placeholders de ton formulaire ne dispensent en principe pas de mettre des <label> (quitte à les cacher en CSS), toujours pour des raisons d'accessibilité.

Bonne continuation en tout cas !
Modifié par BlueScreenJunky (31 Dec 2012 - 15:08)

a écrit :
- J'utiliserais plutot <b> ou <strong> ou <em> plutôt que <span class="gras">. D'une part ça évite de créer une classe, tu peux directement appliquer tes styles aux éléments, et d'autre part ce sera reconnu comme un élément important du texte, notamment par les lecteurs d'écran.

Le principe de séparation contenu/mise en forme ne serait pas respecté. On ne met pas de <strong> juste parce que ceci ou cela doit être en gras. Le <strong> a une valeur en référencement. Si tu veux user d'effets graphique, il faut pour moi passer par les CSS. Même si il est vrai qu'ajouter une classe à un span pour ça, c'est inutilement surcharger le code.

.box span {
    font-weight:bold;
}

Je préconiserais ça.
Modifié par Knozelfhoegtj (31 Dec 2012 - 15:58)

Pour les entités j'avais eu un soucis avec ma BDD il passait mal j'ai donc mis de htmlentities mais c'est vrai que désormais c'est inutile

Pour les js je verrai pour simplifier tous ça

Pour les classes .souligne, .barre, .gras etc
En fait j'utilise un Editeur de Message sur 90% des textes du site, et la plupart sont sauvegarder dans la base de donnée.
Donc de mon coté moi j'ai juste <g>MON TEXTE</g> Pour le gras
C’est aussi plus simple pour les membres que devoir entrer du HTML brut.
Après c’est une fonction php qui convertit le tout et nous ressort les classes.
Si j'ai envie de modifier j'ai juste a aller sur ce que je veux, l’éditorial par exemple et remplacer ces balise par les nouvelles.

Knozelfhoegtj a écrit :

Le principe de séparation contenu/mise en forme ne serait pas respecté. On ne met pas de &lt;strong&gt; juste parce que ceci ou cela doit être en gras. Le &lt;strong&gt; a une valeur en référencement. Si tu veux user d'effets graphique, il faut pour moi passer par les CSS.

Je n'ai pas regardé TOUT son site, mais les occurrences de <span class='strong'> que j'ai trouvé étaient des éléments du texte à mettre en valeur car importants (genre le message pour dire "Je rappelle qu'il n'est possible de proposer qu'une seule vidéo Choisissez donc la meilleure de vos créations !"). D'ailleurs de manière générale j'ai très rarement vu des mots en gras au milieu d'un paragraphe JUSTE pour faire joli, en générale si on met un mot ou une phrase en gras c'est quand même bien pour attirer l'attention dessus car il s'agit d'un élément important.
Je continue donc à penser qu'il est sémantiquement plus correct d'utiliser <strong> ou <em>.
Et je reprend mon exemple du lecteur d'écran qui mettra en principe l'accent sur les termes ou phrases en <strong>, alors qu'il lira un <span> de la même manière que le reste, ce qui fait qu'une partie du sens du contenu serait perdue pour un non voyant par rapport à un voyant en utilisant <span>

Après si on veut vraiment creuser et éviter qu'une phrase comme celle citée au dessus soit considérée comme plus important par google, on peut envisager un <span role="alert"> : ça permet de contenter à la fois les lecteurs d'écran et autres agrégateurs, et de ne pas perturber google.
D'ailleurs j'en profite pour poser une question : Dans ce cas vaut-il mieux se contenter de <span role="alert"> et appliquer un style à [role="alert"] en CSS, ou bien ajouter une classe du genre <span role="alert" class="alert"> ?
Modifié par BlueScreenJunky (01 Jan 2013 - 13:03)

oops, j'ai posté par erreur
Modifié par BlueScreenJunky (01 Jan 2013 - 13:03)

Tu retourneras regarder le site, et tu verras que la plupart des mots en gras (je prends un exemple au hasard, "Cliquez ici") ne sont pas des mots d'une importance significative. Pour ce qui est de ta question, le .box span me paraît être un bon compromis..