![Sommaire ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Jump Camp - HTML5
Ähnlich wie Jump Camp - HTML5 (20)
Jump Camp - HTML5
- 1. HTML 5 Presented by David CHAU
Hinweis der Redaktion
- HTML a toujours été le langage utilisé pour le web. Il a tout d’abord été conçu comme un langage sémantique afin de décrire des documents scientifiques. Au cours des années, le langage a beaucoup évolué, tout d’abord grâce aux différents navigateurs qui implémentaient de nouvelles fonctionnalités, puis au W3C rédigeant des spécifications permettant de standardiser le langage. Cependant, on s’est aperçu que HTML répondait mal aux exigences des applications web. La spécification de HTML 5 permet de rectifier ce manque ainsi que de mettre à jour les spécifications afin d’apporter des corrections aux différents problèmes mis en avant durant ces dernières années.
- Tim Berners-Lee annonce publiquement le web sur Usenet, il ne cite que le langage SGML, mais donne l’URL d’un document de suffixe .html. Techniquement, il trouvait SGML trop complexe, mais il voulait attirer la communauté hypertexte qui considérait que SGML était le langage le plus prometteur pour standardiser le format des documents hypertexte. De plus, SGML était déjà utilisé par son employeur, le CERN. A l’époque, les premiers éléments du langage HTML comprennent le titre du document, les hyperliens, la structuration du texte en titres, sous-titres, listes ou texte brut, et un mécanisme rudimentaire de recherche par index. La description de HTML est alors assez informelle et principalement définie par le support des web divers navigateurs. Avec le navigateur NCSA Mosaic, HTML connaît deux inventions majeures. D’abord l’invention de l’élément IMG permet d’intégrer des images (dans un premier temps, uniquement des GIF et des XBM) aux pages web (Mosaic 0.10). Ensuite l’invention des formulaires (Mosaic 2.0pre5) rend le web interactif en permettant aux visiteurs de saisir des données dans les pages et de les envoyer au serveur web. Cette invention permet notamment de passer des commandes, donc d’utiliser le web pour faire du commerce électronique. Netscape ajoute le support sur la présentation (clignotement, centrage…) En mars 1995, le World Wide Web Consortium (W3C) nouvellement fondé propose le résultat de ses recherches sur HTML+ : le brouillon HTML 3.0. Il comprend notamment le support des tables, des figures et des expressions mathématiques. Ce brouillon expire le 28 septembre 1995 sans donner de suites directes. Fin 1995, le RFC 1866 décrivant HTML 2.0 est finalisé. Le principal éditeur est Dan Connolly. Ce document décrit HTML tel qu’il existait avant juin 1994, donc sans les nombreuses additions de Netscape Navigator. Le 14 janvier 1997, le W3C publie la spécification HTML 3.2. Elle décrit la pratique courante observée début 1996 , donc avec une partie des additions de Netscape Navigator et d’Internet Explorer. Ses plus importantes nouveautés sont la standardisation des tables et de nombreux éléments de présentation. HTML 3.2 précède de peu HTML 4.0 et contient des éléments en prévision du support des styles et des scripts. Le 18 décembre, le W3C publie la spécification HTML 4.0 qui standardise de nombreuses extensions supportant les styles et les scripts, les cadres (frames) et les objets (inclusion généralisée de contenu). HTML 4.0 apporte également différentes améliorations pour l’accessibilité des contenus dont principalement la possibilité d’une séparation plus explicite entre structure et présentation du document, ou le support d’informations supplémentaires sur certains contenus complexes tels que les formulaires, les tableaux ou les sigles. HTML 4.0 introduit trois variantes du format, destinées à favoriser l’évolution vers un balisage plus signifiant, tout en tenant compte des limites temporaires des outils de production : la variante stricte (strict) exclut des éléments et attributs dits « de présentation », destinés à être remplacés par les styles CSS, ainsi que les éléments pour inclure applet et frame qui sont remplacés par l’élément object réputé plus apte à l’interopérabilité et à l’accessibilité. la variante transitoire (transitional) étend la variante stricte en reprenant les éléments et attributs dépréciés de HTML 3.2, dont les éléments de présentation sont couramment utilisés par les éditeurs HTML de l’époque. la variante frameset normalise la technique des jeux de cadres composant une ressource unique à partir de plusieurs pages web assemblées par le navigateur. Ces variantes perdurent par la suite sans modifications notables en HTML 4.01 et dans le format de transition XHTML 1.0 issu de HTML. La dernière spécification de HTML est la 4.01 datant du 24 décembre 1999. Elle n’apporte que des corrections mineures à la version 4.0. Le développement de HTML en tant qu’application du Standard Generalized Markup Language (SGML) est officiellement abandonné au profit de XHTML, application de Extensible Markup Language (XML). Cependant, en 2004, des fabricants de navigateurs web créent le web Hypertext Application Technology Working Group (WHATWG) dans le but, notamment, de relancer le développement du format HTML et de répondre aux nouveaux besoins sur une base technologique jugée plus aisément implémentable que celle du XHTML 2.0 en cours de conception. Ceci s’inscrit dans le contexte d’une contestation plus générale du mode de fonctionnement du W3C, réputé trop fermé par une partie des développeurs et designers web En mars 2007, tirant la conséquence des réticences d’une partie de l’industrie et des concepteurs de contenus web face à XHTML 2.0, le W3C relance le développement de HTML et crée un nouveau groupe de travail encadré par Chris Wilson (Microsoft) et initialement Dan Connolly (W3C), maintenant Michael Smith (W3C). Il s’agit notamment :de faire évoluer HTML pour décrire la sémantique des documents mais aussi les applications en ligne ;de parvenir à un langage extensible via XML tout en maintenant une version non XML compatible avec les parseurs HTML des navigateurs actuels ;et d’enrichir les interfaces utilisateurs avec des contrôles spécifiques : barres de progrès, menus, champs associés à des types de données spécifiques.Les travaux du WHATWG ont été formellement adoptés en mai 2007 comme point de départ d’une nouvelle spécification HTML 5. Ce document a été publié sous forme de Working Draft le 22 janvier 2008. Parmi les principes de conception évoqués par le groupe de travail figurent en particulier :la compatibilité des futures implémentations HTML avec le contenu web existant, et la possibilité pour d’anciens agents utilisateurs d’exploiter les futurs contenus HTML 5 ;une approche pragmatique, préférant les évolutions aux modifications radicales, et adoptant les technologies ou pratiques déjà largement partagées par les auteurs de contenus actuels ;la priorité donnée, en cas de conflit d’intérêt, aux besoins des utilisateurs sur ceux des auteurs, et par suite, à ceux des auteurs sur les contraintes d’implémentation par les navigateurs ;le compromis entre la richesse sémantique du langage et l’utilité pratique des solutions disponibles pour remplir l’objectif majeur d’indépendance envers le media de restitution. Le développement de XHTML 2.0 est initialement poursuivi en parallèle, en réponse aux besoins d’autres secteurs du web, tels que les périphériques mobiles, les applications d’entreprise et les applications serveurs. Puis, en juillet 2009, le W3C décide la non-reconduction du XHTML 2 Working Group à la fin 2009.
- HTML5 est tout d’abord le successeur de html4 Cette spécification de la W3C permet de définir la nouvelle version du langage HTML ainsi que le xHTML. Elle a pour objectif de passer des documents web vers le web des applications. L’ambition de cette nouvelle itération est donc de supprimer les balises obsolètes, d’en remplacer certaines et d’en introduire de nouvelles afin de donner une structure sémantique plus cohérente aux applications web. HTML s’accompagne des Web Forms 2.0 qui ajoutent de nouvelles fonctionnalités: Le contrôle rudimentaire de type et de la validité des champs une extension considérable des type pour les éléments input Des extensions aux boutons submit Des procédures pour traiter des éléments et des valeurs inattendus un modèle d’évènements générés à partir des composants d’un formulaire Une mise a jour des spécifications de la soumission d’un formulaire De nouvelles API vont ainsi standardiser un certain nombre d’interactions : - L’accès hors ligne et le stockage sur le disque dur (pour une exploitation en mode déconnecté) ; - L’édition en ligne, le drag&drop ; - L’accès à l’historique de navigation… Le travail de séparation entre les données et la présentation continue. Ainsi nous pouvons voir disparaitres certains éléments comme font, center, strike ou u ainsi que les attributs align, background, bgcolor etc.
- HTML 5 nous offre 2 syntaxes possibles: le standard html ou le xhtml. Selon la syntaxe, il faudra indiquer respectivement le type MIME text/html ou application/xml L’encodage des caractères est simplifié coté html. Il peut cependant être indiquer via le header html ou grâce au BOM (Byte Order Mark) en début de fichier. Le doctype défini est case-insensitive. Il permet de s’assurer que le navigateur effectue un rendu en mode standard. Notez que la définition est maintenant très succinte. En effet, les versions précédentes du langage HTML étant basés sur le SGML, une DTD était requise.
- Par exemple un article peut contenir plusieurs sections.
- HTML5 introduit de nouveaux éléments visant à structurer le contenu. Ainsi nous pouvons voir apparaître les éléments section, header, footer, nav, article Prenons l’exemple suivant: Avec HTML 4, l’élément DIV était fortement utilisé afin de structurer une page HTML comme le touilleur-express. Nous aurions donc concu la page de la facon suivante. En HTML 5, la structure de la page change. Ainsi cette page deviendrait ceci.
- Connexion établie au premier contact avec le serveur compatible websocket. Après un accord réciproque des deux parties et certaines vérifications de sécurité la connexion est promu en TCP standard. Concernant le protocole de transport, L’entete ne fait plus que 1 octet. On passe d’un overhead de quelques octets contre les 900 octets associés aux requetes traditionnelles. Les trames son identifiées grâce au seul octet en entete. Dans le cas d’une trame binaire, la longueur de la trame est indiquées dans l’entete. Coté implémentation, pour l’instant je ne connais que Jetty et Chromium. Il me semble que webkit devrait bientôt suivre.
- La spécification html 5 introduit l’interface websoket
- HTML 5 s’accompagne des Web Forms 2.0 qui ajoutent de nouvelles fonctionnalités: Tout d’abord une extension considérable des types de l’élément input. Le type color nous permet d’obtenir une palette de couleurs et un date picker pour le type date. De plus, il offre un contrôle rudimentaire de types et de la validité des champs grâce aux types, mais aussi aux attributs tels que l’attribut pattern, le required ou bien le min et max notamment pour le type number
- Pour tester si le navigateur supporte les canvas, vous pouvez ajouter ce test. Si le navigateur ne supporte pas les canvas, getContext sera indefini.
- Dans ce TP, il faudra juste faire attention à ne pas trop rafraichir les tweets. En effet, Twitter restreints les requetes avec des quotas.
- Tout d’abord, créons notre structure HTML. Inserons le doctype, et l’encodage. Notre page comporte un titre, un menu constitué d’un bouton, d’un élément article vide et de deux balises script. Qui peux me dire pourquoi il existe une balise article vide? Une idée? Cette balise me sert de place-holder afin d’y injecter les tweets. Notez bien que les balises scripts se trouvent dans le body de la page et non dans le head. Je vous expliquerai pourquoi dans les slides suivants.
- Nous en avons fini au niveau HTML pour le moment. Passons maintenant au JavaScript. Le JavaScript va nous permettre de récupérer les données de Twitter, puis de les afficher grâce à une fonction callback qui sera bien évidemment exécuter au retour de l’appel.
- Cette fonction permet de récupérer les feeds publiques de twitter. Tout d’abord, un peu de nettoyage. On récupère l’élément head de la page afin d’y supprimer tous les éléments script qui pourrait s’y trouver grâce à la boucle for. On change le texte du bouton. O n constitue enfin un élément script ayant comme URL l’appel à Twitter à l’aide de l’API JSONP. Dans l’URL, on passe comme paramètre un callback=Twitter.twitterCallback. Au chargement du script, on rajoute une fonction permettant de changer le texte du bouton. Enfin, on accroche notre nouvel élément script à l’élément head.
- Il faut maintenant créer la fonction de callback. Cette fonction est vraiment très simple. Elle itère sur les résultats donnés par la variable obj, et pour chaque élément nous allons faire un affichage grâce à la fonction display.
- Ici, rien de très difficile, Tout d’abord, on récupère notre élément ayant l’id timeline. Dans notre page HTML, cet élément nous sert de place-holder ce qui nous permet d’inserer de nouveaux éléments. Nous créons ensuite un élément section auquel nous y placon une image correspondant à l’avatar de l’auteur du tweet, son message, ainsi que la date. Et voici donc la première version de notre page. Mais où intervient la base de données? Nullepart . Nous ne l’avons pas encore créer.
- Afin d’utiliser la base de données nous allons apporter une petite modification sur la page HTML. Nous allons remplacer le Twitter.load par Twitter.init.
- Nous allons créer une variable globale db contenant notre accès à la base de données. Le test sur window.openDatabase permet de déterminer si le navigateur supporte la base de données. Si oui, nous ouvrons une instance à l’aide de cette fonction.
- Si la variable db n’est pas nulle, nous allons exécuter un script permettant de créer la table dans laquelle seront stockés les messages. La fonction executeSql prends ici 4 paramètres, la requetes SQL, un tableau d’objets correspondant aux variables de la requete. Ici, nous n’avons pas de variable. U ne fonction à exécuter lorsque l’exécution du SQL s’est bien passée et une autre lorqu’il y a eu une erreur. Donc l’instruction dit: dans les 2 cas, exécute la méthod. S i la variable db est nulle, le support a la base de données n’a pas été implémenté. On appelle alors la méthode de récupération des tweets.
- Cette méthode est seulement appelé si le navigateur supporte les base de données. Elle permet de récupérer les entrées de la table. Si la requete s’est bien passée, on vide les entrées dans notre place-holder afin des les recréer. Sinon, on ne fait rien. Mais comment les résultats sont-ils insérés en base? Il faut d’abord modifier la fonction callback.
- Il faut maintenant créer la fonction de callback. Cette fonction est vraiment très simple. Elle itère sur les résultats donnés par la variable obj, et pour chaque élément nous allons faire un affichage grâce à la fonction display.
- Nous avons déjà vu la fonction executeSQL. La fonction insert est récursive. arStatus est une LIFO. Nous dépilons l’élément puis exécutons l’insersion. Quelque soit le résultat, nous rappellons la fonction tant que la pile n’est pas vide. Enfin si elle se retrouve vide, nous appelons la fonction de callback qui est Twitter.readStatus. Maintenant, vous pouvez a nouveau tester. Vous remarquerez que la liste des entrées augmentent å chaque rafraichissement.