Design & Développement web - Le topic des canards qui mangent des cookies

[tenshu]

Non mais sérieux wordpress pour quelques pages + actus ça envoi du bois.
En SEO les meilleurs résultats sont sous cette plate-forme.
Et le mec qui a pensé l'interface admin mérite un bisous copieux.

Sous le capot c'est autre chose, mais du coup je complexe pas d'ecrire un truc à l'arrache.

[Anon26492]

En SEO, pas d'accord du tout :

- WordPress, c'est lent. Et à cause de la quantité de code, et à cause de l'optimisation douteuse des thèmes.
- par défaut, tu as un contrôle très pauvre de ce qui importe : il faut un plugin genre yoost pour pouvoir mettre les mains dans les titles et autre, sinon t'as de la triplette du bourrin partout
- tu as très vite fait de générer du duplicate content sous WP

Bref, WordPress peut être relativement bien branlé niveau SEO, mais faut s'y connaître. Du coup c'est pas si rapide à déployer. Tu as bien plus de puissance avec un blog maison ou tu peux opti comme un porc (c'est à dire pas trop non plus)

[Tomaka17]

WordPress serait encore mieux s'il supportait les caractères spéciaux dans les tags.
J'en ai marre d'écrire "cplusplus" parce que "c++" ne marche pas

[tenshu]

- Avec du cache c'est (très) rapide, si le site reste simple.
- Valable pour tout les CMS
- Comment t'arrives a dupliquer du contenu?

[Anon26492]

Typiquement le duplicate se fait à cause des archives, des tags et des résultats de recherche.

Pour la vitesse, le cache te fait économiser coté serveur, mais côté client tu as toujours une optimisation douteuse (plus ou moins selon les thèmes et plugin). Quid coté config du serveur aussi (gzip, header, etags, cors et tutti quantité ?)

Combien un WordPress score sous Yslow ?

Je suis pas antiWP hein, bien maîtrisé c'est un super outil. Sauf que souvent, quand je vois un site sous WP, c'est synonyme de 15 <script> dans head et cinquante requêtes HTTP pour un pauvre blog...

[Say hello]

WordPress serait encore mieux s'il supportait les caractères spéciaux dans les tags.
J'en ai marre d'écrire "cplusplus" parce que "c++" ne marche pas

Utilise "Cpp".

[MrBeaner]

Plusieurs questions qui suivent mon cours hebdomadaire d'aujourd'hui et nos discussions de la semaine passée :

1) Mdt donnait un exemple où se trouvait "===" mais j'ai pas bien saisi le sens de l'opérateur (si c'est un opérateur). Mon googlefu me donne ça comme définition :

equality without type coersion

2) Question terminologie, j'aimerais bien connaître les définitions logiques précises de chaque commande (genre : <p> = balise ; <p align: "left"> est un attribut de balise ; <p align="left"> est une valeur d'attribut ; etc.). Vous connaîtriez une source qui présente ces concepts de cette manière plutôt que de la façon où sont présentées les propriétés dans les répertoires style sitepoint et co. ?

3) Vous pensez qu'il est préférable pour un débutant comme moi de coder d'abord de façon la plus stricte possible plutôt que de surfer sur la tolérance de certains langages, quitte à me retrouver comme dans la situation où j'avais oublié qu'il fallait des accolades après "if(a=i)" s'il y a plusieurs instructions qui suivent ?

exemple en JS:

var m=prompt("quelle distance désirez-vous convertir ?", " ");
	km=1000*m;
alert(m+" mètres = "+km+"+" kilomètres.")

pourrait s'écrire plus rigoureusement :

var m=prompt("quelle distance désirez-vous convertir ?", " ");
var km=1000*parseFloat(m);
alert(m+" mètres = "+km+"+" kilomètres.");

Mais est-ce bien utile ou bien est-ce se fatiguer pour rien ?

[Anon26492]

Mdt donnait un exemple où se trouvait "===" mais j'ai pas bien saisi le sens de l'opérateur (si c'est un opérateur). Mon googlefu me donne ça comme définition :

Le Javascript est un langage au type implicite.
Dans un langage explicitement typé, quand tu déclares une variable, tu dois préciser sa nature : un nombre entier, un nombre à virgule, une chaîne de caractères, etc.
Dans un langage à typage implicite, le langage se débrouille.

Par exemple, si tu écris :

var x = 1;
var y = '1';

Dans un cas tu as un nombre, dans l'autre une chaine.

Si tu fais

if (x == y), JavaScript va chercher à comparer deux types différents selon des règles qui lui sont propres.
if (x === y), JavaScript va d'abord vérifier que les deux types sont identiques.

C'est important parce que JavaScript a une manière bien à lui de gérer les types, et tu peux avoir de très mauvaises surprise avec une égalité type "==". Genre elle passe alors qu'en fait, c'est pas égal
Par exemple, if (0 == '') est true.
Je dirais que le typage (surtout avec l'horrible + ou le fameux NaN) et la portée des variables sont à l'origine de la majorité des galères de débutant en JS.

Un vrai programmeur t'expliquera ça mieux que moi.

Question terminologie, j'aimerais bien connaître les définitions logiques précises de chaque commande (genre : <p> = balise ; <p align: "left"> est un attribut de balise ; <p align="left"> est une valeur d'attribut ; etc.). Vous connaîtriez une source qui présente ces concepts de cette manière plutôt que de la façon où sont présentées les propriétés dans les répertoires style sitepoint et co. ?

Dans le standard, dispo sur le W3C.
align est un attribut à oublier par contre, il est déprécié.

3) Vous pensez qu'il est préférable pour un débutant comme moi de coder d'abord de façon la plus stricte possible plutôt que de surfer sur la tolérance de certains langages, quitte à me retrouver comme dans la situation où j'avais oublié qu'il fallait des accolades après "if(a=i)" s'il y a plusieurs instructions qui suivent ?

Trouve le style que tu préfères toi.
Attention, tu dans ton premier code, tu déclares km en global (car point virgule après le prompt)


edit: correction de vocabulaire, je confond toujours dynamique/implicite.

[deathdigger]

Pour les CMS, j'ai trois exemples qui me viennent en tête :

- Quand j'étais à mon compte, un mec m'a demandé de lui faire un site marchand gratuit parce que les CMS c'est gratuit
- Je dois faire des trucs tout bête sur le site de ma boite qui est en typo3 : changer un numéro de téléphone sur une page (ça m'a pris 2 heures) et je dois extraire des annonces pour en faire un flux : j'ai toujours pas réussi à trouver comment chopper l'url de l'annonce après une journée passée dessus (y'a de l'url rewritting). Avec un site "basique", ça m'aurait pris 5 minutes pour comprendre le truc, là, il va falloir que je me cogne la doc de ce truc pour pouvoir comprendre comment ça marche (en sachant qu'en plus y'a des plugins dans tous les sens)
- Pour un autre site en C#, des dev ont utilisé Mojo qui est plutôt bien branlé. Sauf qu'ils ont laissé les trois quarts du code qui servent à rien et qui alourdissent le code plus qu'autre chose.

J'ai également fait une formation d'une semaine sur Joomla, le mec qui me l'a fait vendait des sites web entre 1300 et 2000€ basés sur ce cms, il se prenait même pas la tête pour le côté graphique, il achetait des "skins" tout faits. Je trouve qu'on est à la limite de l'escroquerie avec ce genre de choses.

@MrBeaner : Pour la terminologie, c'est la même que celle du XML, donc regarde de ce côté. Et afin d'assimiler les bonnes pratiques, je te conseille d'essayer de faire du xhtml strict et de vérifier si ça passe sur le w3validator, au moins ça apprend la rigueur dans le code, et c'est plus joli

[darkgrievous]

- Avec du cache c'est (très) rapide, si le site reste simple.

Dans l'absolu tout site avec un bon système de cache est rapide.

Wordpress c'est comme tout, ça dépend de ce que tu met avec.

Combien un WordPress score sous Yslow ?

D pour wired et techcrunch, mais quand tu vois que gzip n'est parfois même pas activé ...

Le défaut de WP c'est que ça devient vite un clickodrome ou tu perds 30 minutes à cherche un truc qui se ferait un 30 second en php.

[Tomaka17]

2) Question terminologie, j'aimerais bien connaître les définitions logiques précises de chaque commande (genre : <p> = balise ; <p align: "left"> est un attribut de balise ; <p align="left"> est une valeur d'attribut ; etc.). Vous connaîtriez une source qui présente ces concepts de cette manière plutôt que de la façon où sont présentées les propriétés dans les répertoires style sitepoint et co. ?

Le HTML est très simple.
Côté vocabulaire, à part "balise" et "attribut", t'as aussi "doctype" (mais qui est un concept un peu plus avancé et qui ne sert à rien), et c'est tout.
Du coup pas besoin d'une encyclopédie à ce niveau-là.

3) Vous pensez qu'il est préférable pour un débutant comme moi de coder d'abord de façon la plus stricte possible plutôt que de surfer sur la tolérance de certains langages, quitte à me retrouver comme dans la situation où j'avais oublié qu'il fallait des accolades après "if(a=i)" s'il y a plusieurs instructions qui suivent ?

Tu peux surfer sur la "tolérance du langage" (en fait c'est pas une histoire de tolérance, ça fait partie du langage) mais seulement si tu sais que tu ne feras pas d'erreurs et que tu n'auras pas de mal à te relire et tout.

Par exemple ton exemple tu aurais aussi pu l'écrire comme ça :

f=[prompt,alert]; i=1>>1;
     x=f[i++]('quelle distance désirez-vous convertir ?');f[i](x + " mètres = "+1000*x + " kilomètres");

Mais il vaut mieux pas le faire car tu auras beaucoup de mal à te relire et à détecter tes éventuelles erreurs.
En effet il n'y a pas que les erreurs que le compilateur te signale, mais il y a aussi les erreurs de "logique" (c'est à dire que tu as mal pensé ton code) que tu dois détecter toi-même.

Là par exemple en relisant ton premier exemple, tu auras peut être l'impression que "km = 1000*m" est dans un if ou un truc comme ça, vu qu'il est décalé vers la droite (indenté). Pour le moment ton code est simple donc il n'y a pas de problème, mais si le code était un peu plus long et complexe ça pourrait t'induire en erreur.

[Skiant]

@MrBeaner : Pour la terminologie, c'est la même que celle du XML, donc regarde de ce côté. Et afin d'assimiler les bonnes pratiques, je te conseille d'essayer de faire du xhtml strict et de vérifier si ça passe sur le w3validator, au moins ça apprend la rigueur dans le code, et c'est plus joli

Pas d'accord pour le XHTML, y'a plein de règles du XHTML qui sont totalement superflues et qui n'apportent rien, alors que les règles HTML5, bien plus simples, sont tout aussi bien supportées par les navigateurs.

[tenshu]

Pas d'accord pour le XHTML, y'a plein de règles du XHTML qui sont totalement superflues et qui n'apportent rien, alors que les règles HTML5, bien plus simples, sont tout aussi bien supportées par les navigateurs.

Tu fais référence à quoi ?

---------- Post added at 10h06 ---------- Previous post was at 09h32 ----------

Typiquement le duplicate se fait à cause des archives, des tags et des résultats de recherche.

Heu j'ai eu un doute, mais dans les archives et tag ce sont toujours des liens vers une URL unique.
C'est pas vraiment un duplicate, sinon google mettrais une tarte direct.
Dans l'absolu un maillage de liens internes un peu trop fort c'est effectivement pas recommandé mais j'ai jamais vu de problème.

Enfin bref on est d'accord c'est pas l'outil le plus efficace de la terre, mais pour monter un site de 3 pages avec actu franchement je me ferais pas chier à sortir l'artillerie lourde.


Ou alors je le ferais avec le micro framework Silex avec le bundle adminGenerator pour le backend.
Mais juste par ce que j'aurais envie de remettre un peu les mains dans le cambouis.

D'ailleurs je vous conseille Silex pour faire des pages Facebook, c'est à mon avis un choix judicieux.

[Skiant]

Tu fais référence à quoi ?

Le doctype, l'encoding les attributs booléens et les trailing slashes, principalement.

XHTML :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
</head>
<body>
    <img src="dafuq.jpg" />
    <form action="">
        <input type="text" disabled="disabled">
    </form>
</body>
</html>

HTML5 :

<!DOCTYPE HTML>
<html lang="en-US">
<head>
    <meta charset="UTF-8">
</head>
<body>
    <img src="dafuq.jpg">
    <form action="">
        <input type="text" disabled>
    </form>
</body>
</html>

[deathdigger]

Le doctype, l'encoding les attributs booléens et les trailing slashes, principalement.

XHTML :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
</head>
<body>
    <img src="dafuq.jpg" />
    <form action="">
        <input type="text" disabled="disabled">
    </form>
</body>
</html>

HTML5 :

<!DOCTYPE HTML>
<html lang="en-US">
<head>
    <meta charset="UTF-8">
</head>
<body>
    <img src="dafuq.jpg">
    <form action="">
        <input type="text" disabled>
    </form>
</body>
</html>

Merci d'appuyer mon exemple en montrant un code propre en xhtml et un code dégueulasse en html

[Tomaka17]

En fait je crois que Skiant n'aime juste pas tout ce qui est XML et apparenté.

[deathdigger]

Ouais, sauf que c'est obligatoire de savoir faire du xml propre. Si tu veux utiliser un autre langage pour lire les flux de ton fichier, ça ne se fera pas en html mais en xml. Si tu veux une communication entre plusieurs sites, ça se fera en xml et pas html, etc.
On a d'un côté un truc très propre et très structuré, et de l'autre la foire au bordel qui avec ses tolérances peut causer énormément de problème de mise en forme.

[Skiant]

Ouais, sauf que c'est obligatoire de savoir faire du xml propre.

Euh... Non.
Si tu dois faire du XML, tu fais du XML. Le HTML, c'est pas du XML, point.

---------- Post added at 11h23 ---------- Previous post was at 11h18 ----------

En fait je crois que Skiant n'aime juste pas tout ce qui est XML et apparenté.

Disons que je n'aime pas qu'on vienne foutre du XML et apparenté dans le HTML alors que ça n'a rien à y foutre.
Et je déteste encore plus être forcé d'utiliser une syntaxe de chie (sérieux, required="required", you don't say ?) juste pour qu'un parser ne fasse pas une erreur fatale.

[Møgluglu]

edit: correction de vocabulaire, je confond toujours dynamique/implicite.

Tu es sûr que tu voulais pas dire dynamique ?

Le typage Javascript est implicite et dynamique : le programmeur n'indique pas les types, le programme les identifie au fur et à mesure à l'éxécution. C'est proche de ne pas avoir de type du tout.

On peut avoir du typage implicite et statique, comme en Caml pour le web ou avec le mot-clef auto en C++11 pour le web. C'est le compilateur qui se charge d'inférer le type de chaque variable du programme. Ensuite il génère du code avec les types en dur, et le programme n'aura pas à s'en occuper.

En typage explicite et dynamique, on doit avoir des langages comme Java pour le web, à qui on indique tout les types, mais qui va quand-même vérifier à l'exécution qu'on ne fait pas de connerie. Mais on peut retrouver le même genre de blague qu'en JavaScript avec des conversion implicites avantureuses.

[rOut]

En JavaScript pour le web j'espère.

[deathdigger]

Euh... Non.
Si tu dois faire du XML, tu fais du XML. Le HTML, c'est pas du XML, point.

---------- Post added at 11h23 ---------- Previous post was at 11h18 ----------



Disons que je n'aime pas qu'on vienne foutre du XML et apparenté dans le HTML alors que ça n'a rien à y foutre.
Et je déteste encore plus être forcé d'utiliser une syntaxe de chie (sérieux, required="required", you don't say ?) juste pour qu'un parser ne fasse pas une erreur fatale.

Non mais le html, c'est laisser les gens ne pas fermer leurs ballises, et t'imagines pas le genre de merde que ça peut faire notamment avec du JS

[Skiant]

Non mais le html, c'est laisser les gens ne pas fermer leurs ballises, et t'imagines pas le genre de merde que ça peut faire notamment avec du JS

Non, ça c'est du mauvais HTML (dingue comment vous assimilez les mauvaises pratiques au langage lui-même, comme si le dev était dénué de toute responsabilité sur son code).

Y'a pas de balise fermante pour les input, img, br, hr, et quelques autres dont je ne me souviens plus là maintenant tout de suite.
Les autres tags doivent être fermés.

[tenshu]

L'auto fermant c’est juste une question de logique
A quoi ça servait de conserver <img></img>
Alors que l'on foutais rien dans cette balise ?

A la rigueur peut être que mettre le src ou le alt ou le title dedans aurait été logique mais comme c'est pas le cas c'est parfaitement logique.

Après le doctype HTML5 ne force pas la main tu peux utiliser <input> comme <input/> et je suis à peu prés sur que <input></input> n'est pas (trop) sanctionné.
Mais de mon point de vu ouvrir une balise sans la refermer
Imagine comment les règles de parsing se compliquent.


Et le HTML c'est pas du dev, c'est de la description

[rOut]

Y'a peut être pas de balises fermantes mais c'est quand même beaucoup plus propre d'être explicite et d'écrire:

<img src="bla.png" />

Que:

<img src="bla.png">

La sémantique XML t'assures que seule le premier exemple est valide et que le second ne l'est pas, parce que c'est une syntaxe ambigue.

[Tomaka17]

Les autres tags doivent être fermés.

Justement non, c'est ça le problème
Ce code HTML est par exemple tout à fait correct :

<table>
<tr>
  <td><p>Colonne 1
  <td><p>Colonne 2
  <td><p>Colonne 3
</tr>
</table>

Ce n'est pas du tout une tolérance du HTML ou quoi que ce soit, ça fait partie du HTML, d'ailleurs ce genre d'exemple est même utilisé sur le site du w3. C'est pour ça que beaucoup de gens préfèrent le XHTML plus propre.

Le fait de savoir quelles balises doivent se fermer ou non, et se ferment à quel moment est justement défini dans le doctype, et c'est de la grosse chiasse à parser.
Par exemple <br>, <input> ou <img> c'est juste un élément à cet endroit précis, alors que <p> c'est une balise ouvrante qui contient tout ce qui se situe au-delà.
Mais si le <p> se ferme automatiquement quand on ouvre un autre <p>, ce n'est pas le cas pour le <div> par exemple.
Bref, c'est le bordel.

[tenshu]

C'est d'ailleurs marrant que cette balise ne soit pas :

<img alt="Un poney">img/poney.png</img>
ou
<img src="img/poney.png">Un poney</img>

[Anon26492]

Perso, j'ai toujours préféré le HTML. Jamais pigé pourquoi les gens s'acharnaient à utiliser la syntaxe xHTML (avec un doctype strict) pour finir par envoyer un Content-Type: text/html

Enfin si, si le xHTML fut si populaire, c'est qu'à l'époque les gens faisaient n'importe quoi. Des sites en table, des attributs dans tous les sens, des styles en ligne, des balises non fermées et le tout de manière totalement anarchique (mais souvent légale), avec des majuscules, en oubliant les quotes... le xHTML fut une tentative d'apporter rigueur et professionnalisme à l'inté web.

C'est désormais le cas : si je vois encore quelques sites en table, si je vois énormément d'horreurs en JavaScript et pas mal en CSS, globalement le HTML est propre.

Et img n'est pas valide sans son alt

[Tomaka17]

<img src="img/poney.png">Un poney</img>

Cette syntaxe eut été beaucoup plus logique d'ailleurs, puisque si un navigateur ne supportait pas la balise <img>, le texte à l'intérieur serait automatiquement affiché à la place.

[Anon26492]

La balise img date un peu.

I'd like to propose a new, optional HTML tag:
IMG
Required argument is SRC="url".
This names a bitmap or pixmap file for the browser to attempt to pull over the network and interpret as an image, to be embedded in the text at the point of the tag's occurrence.

Hélas, le post de Pilgrim sur cette histoire est 404 :/

[GrandFather]

Vous en êtes encore à la vieille querelle XHTML (god) vs HTML (evil) ?
HTML est à la base du SGML (également précurseur de XML) qui autorise l'absence de fermeture, et les premiers parseurs HTML étaient des déclinaisons de parseurs SGML. L'intérêt de passer au XHTML, c'est surtout pour faciliter l'écriture des algo d'analyse structurelle et sémantique des pages. Si vous n'écrivez pas de parseurs, ou si vous ne produisez pas vos pages par un middleware XML, franchement XHTML ou HTML c'est du kif.