Polices web et compléments sur les sélecteurs CSS

Licence Informatique, semestre 6

Alexandre NiveauJean-Marc Lecarpentier — Judith Jeyafreeda Andrew

Enseignement des technologies du Web

 

Polices web et compléments sur les sélecteurs CSS

Notes de cours

  • Polices en CSS
    • Polices du système et font stack
    • Utiliser n’importe quelle police avec @font-face
    • Plusieurs « styles » pour la même police
    • Inconvénients des polices sur le web
  • Compléments sur les sélecteurs avancés
    • Sélecteurs d’attributs
    • Utiliser identifiants et classes
    • Sélection plus fine des enfants
    • Pseudo-classe :target et lightbox en CSS
    • Détails sur la génération de contenu

Travail personnel

Objectifs

Les deux exercices de ce TP n'ont rien à voir : le premier, optionnel, porte sur l'utilisation de polices web, tandis que le second applique les mécanismes d'authentification et de gestion des droits à l'architecture MVCR.

Exercice 1 (optionnel) — Utilisation de polices #

Une proposition de corrigé est disponible (lien vers le CSS commenté ; archive du code).

L'objectif de l'exercice est d'utiliser des polices en CSS sur une page HTML. On va reproduire le modèle suivant :

Capture d'écran de la page
Capture d'écran de la page

Cette archive contient le HTML, ainsi que les fichiers WOFF des polices « Know Your Product » (utilisée pour le titre) et Archistico (utilisée pour le texte).

  1. Écrivez un fichier screen.css pour reproduire le modèle. Remarque : la version « grasse » d'Archistico est assez particulière. Utilisez une grande taille de police (par ex. 3em) pour mieux voir ce qui se passe, et n'hésitez pas à zoomer (selon les OS et les navigateurs, la différence peut être plus ou moins visible).
  2. Assurez-vous que vous n'avez pas utilisé de sélecteur d'élément strong dans votre CSS. Si vous en avez utilisé un, c'est très certainement que vous n'avez pas tout compris au cours ! Si les polices ne sont pas téléchargées, l'internaute doit voir la page avec les styles par défaut habituels.

Exercice 2 — Authentification dans MVCR #

Mise en place des comptes dans l'architecture

  1. Créer une classe Account qui représente un compte utilisateur (nom, login, mot de passe et statut). Créer une interface AccountStorage pour manipuler des comptes en BD. On ne s'occupe pas encore de création, modification et suppression ; en revanche on va avoir besoin d'une méthode checkAuth($login, $password), qui est censée renvoyer l'instance de Account correspondant au couple login-mot de passe s'il est correct, et null sinon.
  2. Créer une classe AccountStorageStub qui implémente AccountStorage avec un tableau écrit en dur.

Authentification

  1. Ajouter une méthode makeLoginFormPage à la vue. Faire le nécessaire dans le routeur pour que le site comporte une page dédiée à la connexion des internautes. Ajouter un lien vers cette page de connexion dans le menu.
  2. Implémenter la vérification de la connexion dans le contrôleur. Si les informations sont valides, le compte correspondant est récupéré en BD, et placé dans une variable $_SESSION['user']. Le contrôleur appelle ensuite une méthode de la vue qui effectue une redirection vers la page d'accueil avec un feedback.
  3. Restreindre l'accès des internautes non connecté·e·s à seulement la page d'accueil, la page de connexion et la liste des animaux, en vérifiant la valeur de $_SESSION['user'].
  4. Implémenter la déconnexion. Ajouter un lien sur la page d'accueil pour tester. (Dans la section suivante, on gérera ça plus proprement.)

Affichage public/privé

Pour l'instant, le site s'affiche de la même façon pour tout le monde (que la personne soit connectée ou non). C'est un peu absurde, en particulier pour le menu : le lien « nouvel animal » ne concerne que les connecté·e·s, le lien « Se connecter » ne concerne que les autres, etc. On va changer ça en séparant la vue en deux versions.

  1. Créer une classe PrivateView qui hérite de View. Son constructeur prendra une instance de Account en plus des autres paramètres. Le routeur construira une instance de PrivateView plutôt que View si l'internaute est connecté·e.
  2. S'arranger pour que le menu soit différent dans PrivateView. Typiquement, l'attribut $menu dans la vue de base devrait être rempli avec une méthode getMenu, cette méthode étant redéfinie dans PrivateView. En particulier, on va afficher le lien de déconnexion à la place du lien de connexion pour les internautes connecté·e·s.
  3. Redéfinir la page d'accueil dans la vue privée pour saluer l'internaute connecté·e.

Compléments (optionnel)

Gérer les accès plus précisément :

  • un animal ne doit pouvoir être édité ou supprimé que par la personne qui l'a créé (cela nécessite d'ajouter des informations dans la base)
  • les admins doivent pouvoir éditer et supprimer tous les animaux.

Pour faire ce genre de chose de manière sécurisée, une solution est de déclarer dans le routeur un tableau contenant la liste des actions autorisées pour l'internaute connecté·e, et de tester si l'action demandée est dans la liste avant la gestion des actions. Autrement dit, toutes les pages sont interdites par défaut : il faudra explicitement autoriser l'accès dans chaque cas.