Je veux me construire un site web mais je sais pas par quoi commencer.

Aucun. Le PHP se suffit à lui même côté serveur.
Et côté client tu n'auras guère le choix. C'est de l'HTML pour la mise en page, du CSS pour de l'habillage et du Javascript pour de l'intéraction et animation.

Merci

Si tu ne sais rien, commence par des choses simples, même si elles ne sont pas directement en rapport avec ton projet final:
HTML et CSS permettent déja de fort belles choses, sachant que la définition de HTML 5 permet nombre de contrôles qui, auparavant, demandaient des scripts en Javascript ou en PHP (contrôle de validité)...
Habitue-toi à encadrer avec des simples quotes, à donner à tes champs à la fois un name qui peut servir plusieurs fois sur la page, et un id qui doit être unique (prévision de javascript) .

<form name = 'renseignements' id ='renseignements' action = 'test.html' mthod = 'post'>
<input type =  'text' name = 'nom' id ='nom'  required = 'required' value ='' />
<label for 'statut'>Abonné</label>
<input type = 'radio' name = 'statut' id = 'abonne' value ='1'  />
<label for 'statut'>Non abonné</label>
<input type = 'radio' name = 'statut' id = 'non-abonne' value ='0'  />
<button id ='envoyer'> OK </button>
</form>

N'apprends pas Javascipt et PHP ensemble.

Le standard c'est double quote, pas les simples.

Et faut pas d'espace entre un attribut, le égal et sa valeur entre guillemets

Et pis faut un "e" à method

Et faut pas d'espace entre un attribut, le égal et sa valeur entre guillemets

y'a des cas où ça pose problème ? parce que je n'y fait jamais attention mais ne me souviens pas non plus avoir eu de pb à ce sujet

par contre je mets toujours un "=" derrière les for dans les label

Signaler des erreurs inexistantes a l'unique vertu de semer la confusion:
effectivement method est mieux que mthod.
Pour le reste, le validator accepte, bien sûr:
les simples quotes que j'utilise en prévision de l'inclusion dans des variables PHP, pour éviter d'avoir trop à échapper.
les espaces autour des =, qui me semblent produire un code plus lisible que:
<input type="text"checked="checked"value="12" />
Un véritable problème est l'attribut required, présent dans la norme 5: http://www.w3.org/TR/html5/common-input ... t-required, mais non reconnu par le validator, et décrit comme un booléen à utiliser seul, contrairement, par exemple, à checked qui, lui, est reconnu par le validator sous la forme checked ='checked'...

Le plus important est de comprendre que PHP génère un "fichier". C'est ce fichier qui est interprété par le navigateur.

En cas de page bugué, cela provient soit du html qui ne fait pas ce que l'on veut, soit du PHP qui ne génère pas le html que l'on veut. Il faut donc toujours passer par une vérification du html généré pour voir si c'est bien ce que l'on veut générer.

Extrémiste ! J'ai dit qu'il fallait pas d'espace entre l'attribut et sa valeur, j'ai pas dit qu'il fallait supprimer tous les espaces !

<input type="text" checked="checked" value="12" />

n'est pas moins lisible que

<input type = "text" checked = "checked" value = "12" />

bien au contraire...

Peut être que ça passe la validation w3c.. ça dépend souvent de la dtd, mais c'est pas pour autant que c'est bien Et en l'occurrence, ça passera probablement aucun parseur xml/xsl, alors autant prendre de bonnes habitudes

Quant à l'échappement, il suffit de définir sa chaine entre apostrophes pour ne rien avoir de plus à échapper :p

Plus sérieusement, y a pas de meilleure façon de faire. La bonne façon c'est celle avec laquelle on est à l'aise pour son projet et avec les personnes qui y participent (sans oublier que celui qui reprendra votre code un jour est probablement un dangereux psychopathe qui connait votre adresse, alors essayez de pas le fâcher )

Si le testeur officiel du W3C ne vaut pas les avis d'es gurus de PHPFrance, alors il n'ey a plus rien à dire.

Si le testeur officiel du W3C ne vaut pas les avis d'es gurus de PHPFrance, alors il n'ey a plus rien à dire.

ça c'est certain, et pour cause le testeur officiel du W3C n'a pas d'avis puisque c'est un robot
Cela dit ça reste un outil intéressant, mais c'est juste un outil, qu'il faut savoir reconnaître comme tel à sa juste valeur d'outil de mesure, et dont ont pourra interpréter les résultats
Ne pas savoir faire cette différence impliquerait que l'on ne maîtrise pas son sujet puisque c'est l'outil qui te domine

Il n'y a pas d'avis à avoir quand il s'agit d'appliquer des règles.
Te demande-t-on ton avis quand on vérifie si tu accordes correctement le participe passé des verbes conjugués avec avoir.
Que ton avis diffère de la règle est un problème distinct.
De plus, si le testeur du W3c n'est qu'un robot qu'il faut interpréter, qu'en est-il des parsers dont on me vante la supériorité.
Enfin, on oublie un point important de la pensée de Tim Berner Lee:
HTML doit être strict au niveau de la conception (le validateur) et tolérant au niveau de l'exécution (les parsers...) et j'ai l'impression qu'on inverse les choses. Il n'y a pas lieu de se conformer aux Oukases d'un parser qui outrepasse la norme

C'est quoi ces diatribes éculées tout d'un coup ? On quitte dangereusement le sujet de départ.

Il n'y a pas d'avis à avoir quand il s'agit d'appliquer des règles.

Encore faut-il savoir pourquoi on les applique et ce que l'on attend du résultat.

Te demande-t-on ton avis quand on vérifie si tu accordes correctement le participe passé des verbes conjugués avec avoir.

Et n'importe qui te dira que les correcteurs grammaticaux ne font pas de merveilles...

De plus, si le testeur du W3c n'est qu'un robot qu'il faut interpréter, qu'en est-il des parsers dont on me vante la supériorité.

On ne vante aucune supériorité, on parle de problèmes pratiques. Par ailleurs que fais tu quand le validateur css te donne l'erreur "filter" ? Tu supprime ton filter et dès lors ton code n'est plus fonctionnel avec les anciens navigateurs IE ? Tu vois bien qu'il faut savoir interpréter un minimum...