Est-il possible d'utiliser inconnu des balises HTML?
Corrigez-moi si je me trompe, mais autant que je sache, inconnu des balises HTML dans une balise (c'est à dire les balises ne sont pas définis dans la spécification HTML, comme par exemple, <foobar>) finira par être traité comme un régulier <div> dans un navigateur HTML 5 de l'environnement.
Je suis en train de penser: comment supportable est-ce pratique? Je veux dire, si j'utilise inconnu des balises HTML dans mon balisage, quels sont les pièges puis-je m'attendre? Va un velociraptor se jettent sur moi, dans quelques secondes?
La raison pour laquelle je demande, c'est que si ces balises reporter à <div>, je peux éventuellement utiliser ces balises dans un plus sémantiques de manière que, par exemple, l'attribution des noms de classe qui permettent d'identifier les modules. Jetez un oeil à cet article, par exemple, d'un .media de la classe. Maintenant, si au lieu d'écrire que CSS pour cibler .media, je le fais cible <media> à la place? À mon avis, que fait le balisage beaucoup plus lisible et maintenable, mais je dois reconnaître que c'est pas "correct" HTML.
MODIFIER
Juste pour être transparent, je ne trouver ce DONC, la question à partir de quelques années en arrière. Il a été fermé comme hors-sujet, mais j'ai l'impression que j'ai un point dans ma propre formulation. C'est un proche en double, je l'avoue, mais c'est depuis quelques années en arrière, alors il pourrait y avoir eu des changements dans le général environ des opinions à travers les développeurs web sur le sujet.
Vous devez vous connecter pour publier un commentaire.
Vous devriez toujours l'approche HTML tel qu'il est défini dans son cahier des charges. La "définition" de nouvelles balises est un peu une approche extrême. Il pourrait passer un contrôle de navigateur parce qu'il met en œuvre diverses failsafes, mais il n'y a pas de garantie. Vous êtes entrer dans la terre de Comportement Indéfini, au mieux. Pour ne pas mentionner, vous allez échouer les tests de validation, mais vous semblez être au courant de cela.
Si vous souhaitez être plus sémantiquement expressive dans votre balisage, vous pouvez utiliser HTML5 qui définit tout à fait un peu plus de balises permettant de décrire la structure de votre page au lieu de générique
divs qui doivent être annexésids ouclasses.En fin de compte, une réponse courte: Non, c'est une mauvaise pratique, vous ne devriez pas le faire et il pourrait y avoir des imprévus des problèmes plus tard dans votre développement.
user1309389 eu une très bonne réponse, et je suis d'accord avec l'appel à la spécification. Mais je suis en désaccord avec leurs conclusions, et je pense qu'ils ont tort sur les éléments qui ont conduit à "un comportement indéterminé". Je veux proposer une autre façon de penser à ce sujet, enracinée dans la façon dont les spécifications et les navigateurs fait poignée en-éléments.
C'est 2015, nous sommes à la veille de la CustomElement spec être largement adoptée, et polyfills sont facilement disponibles. Maintenant il est grand temps de se demander à propos de "faire vos propres éléments". Dans un proche avenir, vous serez en mesure de créer de nouveaux éléments avec votre propre choix de la balise et le comportement d'un standard et de prise en charge que tout le monde peut aimer. Mais jusqu'à présent les terres dans tous les navigateurs, et jusqu'à ce que la majorité des gens sont à l'aide de l'appui des navigateurs, vous pouvez profiter de l'ardeur au travail de Polymère ou X-Tags projets pour vérifier l'avenir des éléments personnalisés dans un quasi-standard et la plupart du temps-de prise en charge que très peu de gens peuvent aimer. C'est probablement la "bonne chose" pour le faire. Mais cela ne répond pas à votre question, et franchement je le trouve "il suffit d'utiliser X" ou "ne pas faire X" pour être moins utile que "voici comment la spécification couvre ce, et voici ce que les navigateurs n'". Donc, voici ce que j'aime.
À l'encontre de la recommandation sincère (et parfois en criant) d'une grande partie de la web communauté de dev, j'ai travaillé avec le "made-up" éléments pour la dernière année, dans tous mes projets de production, sans un polyfill, et je n'ai pas eu d'insolubles problèmes (encore), et pas de plaintes. Comment? En s'appuyant sur le comportement standard de HTMLUnknownElement, la partie de la spec W3C qui couvre l'affaire du "made-up" éléments. Si un navigateur rencontre une inconnue élément HTML, il y a un bien définis et sans ambiguïté manière qu'il devrait être manipulés, et HTMLUnknownElement définit le comportement, et vous pouvez construire sur le dessus de cela. HTMLUnknownElement a également pour être puissant et corriger assez à "ne pas casser le web" lors de la rencontre de toutes les balises qui sont maintenant obsolètes, comme la
<blink>tag. Il n'est pas recommandé que vous utilisez HTMLUnknownElement, mais dans la théorie et dans la pratique, il n'y a absolument pas de mal à le faire, si vous savez ce que vous faites.Alors, comment ne HTMLUnknownElement travail? C'est simplement une extension de la HTMLElement de l'interface, qui est le standard de l'interface sous-jacente de tous les éléments HTML. Contrairement à la plupart des autres éléments cependant, HTMLUnknownElement ne pas ajouter des comportements particuliers — vous obtenir les raw d'un élément, sans fioritures avec des tout spécial de comportements, ni contraignant des règles quant à l'utilisation. Le HTMLDivElement interface fonctionne presque exactement de la même manière, l'extension de La et en ajoutant presque pas de comportements supplémentaires. Mettez tout simplement, faire vos propres élément est presque identique à l'aide d'un div ou span.
Ce que j'aime à propos de "prendre" des éléments est le changement de mentalité. Vous devez utiliser ou d'inventer éléments HTML en fonction de plusieurs facteurs, allant de façon claire, il rend le balisage de lire, à la façon dont le navigateur et les lecteurs d'écran et les moteurs de recherche analyse de votre code, quelle est la probabilité que votre code est "correcte" par certaines mesures objectives. Je utiliser avec parcimonie, composée des éléments, mais j'utilise exactement de la manière Richard décrit, pour rendre les choses encore plus d'importance pour l'auteur de l'HTML, et pas seulement utiles pour un service informatique qui extrait les métadonnées. Lorsque utilisés de manière cohérente à travers une équipe, il y a peut être un gros avantage car composé d'éléments peuvent exprimer de façon concise ce qu'ils sont pour.
J'aime particulièrement en utilisant des éléments à indiquer le moment où je vais les utiliser JS pour définir supplémentaire comportement d'un élément. Par exemple, si j'ai un élément qui auront des enfants ajoutées/supprimées par le JS, je vais utiliser un élément comme un indice que cet élément est soumis à des comportements particuliers. Par la même occasion, je n'utilise pas un élément un élément standard suffira. Vous verrez
<dynamic-list>vivre heureux à côté de<div>dans mon code.Maintenant, à propos de ces satanés validateurs. Oui, en utilisant des éléments n'est pas "valide" dans le sens où il ne passe pas un "validateur". Mais beaucoup de fonctions couramment utilisées, des modèles et des systèmes modernes de l'HTML et JS de développement de l'échec de tous les validateurs du W3C. Les validateurs ne sont pas la loi — le spec. Et la loi n'est pas de liaison de la mise en œuvre dans tous les navigateurs. L'utilitaire de validateurs a été dimishing pendant des années comme la flexibilité en matière de HTML a été en augmentation, et que les navigateurs ont changé dans leur relation à la spéc. Les validateurs sont parfaits pour les gens qui ne sont pas à l'aise avec le HTML et ont besoin de conseils. Mais si vous êtes à l'aise de prendre votre orientation à partir de la spécification et de navigateur implémentations, il n'y a pas de raison de s'inquiéter d'être plantée par le validateur. Certainement, si vous suivez plusieurs des lignes directrices proposées par Google, Apple, Microsoft, etc, pour la mise en œuvre de toutes les fonctionnalités expérimentales, vous travaillerez à l'extérieur des limites du valideur. C'est absolument un bon chose à faire, aussi longtemps que vous le faites délibérément et vous en savez assez sur ce que vous faites.
Donc, si vous allez créer vos propres éléments et de s'appuyer sur HTMLUnknownElement, ne suffit pas de le traiter comme un sauvage à l'ouest. Vous devez suivre quelques règles simples.
Vous devez utiliser un trait d'union dans le nom de votre tag. Si vous le faites, vous avez la garantie de ne jamais entrer en collision avec une future édition de la spécification HTML. Donc, ne jamais dire
<wrong>, toujours dire<quite-right>.Faites-les éléments ne peuvent pas être auto-fermeture — vous avoir à les fermer avec une balise de fermeture. Vous ne pouvez pas dire
<wrong>ou<still-wrong />, vous avez à dire<totally-good></totally-good>.Vous devez définir un
displaypropriété pour votre élément en CSS, sinon le rendu le comportement est indéfini.C'est à ce sujet. Si vous faites ces choses, vous devriez être bon d'utiliser, composée d'éléments dans IE9 et, en s'appuyant sur le filet de sécurité de la HTMLUnknownElement. Pour moi, les avantages de loin, l'emportent de loin sur les coûts, de sorte que j'ai été en utilisant ce modèle très. Je lance un site d'hébergement SaaS pour de grands groupes industriels, et je n'ai eu aucun problèmes ou des plaintes à ce jour. Si vous avez à prendre en charge les anciennes versions d'IE, il est sage de rester loin de tout "2015" de la technologie ou de leurs brut des approximations, et de rester en toute sécurité dans le sentier parties de la spécification.
Donc, en résumé, la réponse à votre question est "oui, si vous savez ce que vous faites".
quite-rightqui ont des traits d'union dans les. Pour un peu plus de détails, voir stackoverflow.com/questions/28508533/...Pas. Vous ne recevrez pas de validation, vous recevrez aléatoire des questions de la croix-navigateur et vous VA être mangé par les dinosaures. CSS est la réponse si vous voulez que votre page se comporter de manière prévisible.
Oui, Nous Pouvons.
Il y a une nouvelle spécification d'éléments personnalisés/tag - http://w3c.github.io/webcomponents/spec/custom/.
Seul problème avec cela est que vous devez utiliser js pour enregistrer votre nouvel élément
Vous pouvez en lire plus à ce sujet à
https://developers.google.com/web/fundamentals/getting-started/primers/customelements
Règle n ° 1 du navigateur de l'interopérabilité est la suivante: ne pas avoir d'erreurs. N'importe comment beaucoup de navigateurs vous test, il y a toujours des navigateurs, vous pouvez pas test, par exemple parce qu'elles n'existent pas encore.
Aussi, inconnu éléments seront traités comme des
<span>, pas<div>par la plupart des navigateurs actuellement.Si c'est vraiment la source de la lisibilité(*) vous êtes après, vous devriez regarder dans le XML+XSLT.
De cette façon, vous pouvez utiliser tous les noms de balise que vous voulez, et de les faire se comporter d'une manière que vous aimez et vous n'avez pas à vous inquiéter que
<media>sera un véritable élément dans une version future de HTML.Un bon exemple dans la réalité, c'est l'élément
<picture>. Si un site web a jamais utilisé<picture>et s'appuyait sur l'idée que cet élément aurait aucun style ou le contenu spécial par lui-même, ils sont dans la merde maintenant!(*) Avec XML+XSLT, la lisibilité sera dans la partie XML, pas le XSLT partie, évidemment.
Dans mon cas, j'ai utiliser beaucoup d'entre eux dans mon Webkit-alimenté jeu GUI système, et tout fonctionne.
Dans votre exemple, vous parlez
<media>, il pourrait être grande, mais si html6 ajoute cette balise pour un autre élément, votre code ne sera pas retrocompatible.Généralement pas recommandé, par exemple, IE l'habitude d'appliquer le style css-les styles d'étiquettes inconnues.
Tous les autres navigateurs rendre les étiquettes inconnues comme
inline-Éléments (ce qui provoque des problèmes avec l'imbrication).Je vous recommande l'article suivant: http://diveintohtml5.info/ Il y a une section sur les étiquettes inconnues.
my-custom-tagcomme une étiquette valide (vos balises personnalisées devrait toujours contenir un tableau de bord).Le seul inconvénient qui m'inquiète, c'est que si une balise personnalisée que j'utilise actuellement, devient un officiel de la balise HTML de l'année prochaine ou plus tard encore?
Donc comment à ce sujet: au Lieu de balises personnalisées utiliser 'div' + une CSS personnalisée de classe.
CSS-classes sont destinés à être personnalisé, il est certainement ok pour avoir votre propre CSS personnalisé-classes. Votre div peut par la suite avoir un nombre quelconque de CSS-classes associées avec elle faire de la sémantique des machines encore plus flexible, vous pouvez l'appeler l'héritage multiple.
Au lieu de div que vous pourriez utiliser span pour le même but. Je voudrais utiliser quelque chose de plus court en fait, disons p, mais malheureusement p a son propre comportement particulier de ce qui se passe si vous n'avez pas le fermer.
Mais certainement si vous allez l'itinéraire d'exprimer la sémantique avec CSS-classes alors il aide à l'utilisation d'une étiquette de nom aussi court que possible. Je souhaite qu'il y avait quelque chose de plus court que la div, dire, par exemple, t pour le "tag".
W3C dit:
Voici la source: https://www.w3schools.com/html/html5_browsers.asp
C'est une mauvaise pratique et vous ne devriez pas le faire. Le navigateur affiche la div comme solution de repli dans la plupart des cas, mais il n'est pas valide html et donc ne le sera jamais passer un test de validité.
Quel est le problème avec l'utilisation judicieuse de < !-- vos trucs ici -- >. Il a travaillé pour les scripts de retour autour de la temps de la période Crétacée, Paleogene limite. Les dinosaures cessé d'être un problème autour de ce temps, qui est en dehors de la voler, à plumes variété.