Warum arbeitet CSS mit gefälschten Elementen?


438

In meiner Klasse habe ich herumgespielt und herausgefunden, dass CSS mit erfundenen Elementen funktioniert.

Beispiel:

imsocool {
    color:blue;
}
<imsocool>HELLO</imsocool>

Als mein Professor mich zum ersten Mal sah, war er etwas überrascht, dass erfundene Elemente funktionierten, und empfahl mir, einfach alle meine erfundenen Elemente in Absätze mit IDs zu ändern.

Warum möchte mein Professor nicht, dass ich erfundene Elemente verwende? Sie arbeiten effektiv.

Warum wusste er auch nicht, dass erfundene Elemente existieren und mit CSS funktionieren? Sind sie ungewöhnlich?


62
HTML ist eine Möglichkeit, Daten eine Bedeutung zu verleihen, die von einer Vielzahl von Medien (einschließlich Personen und Browsern) verstanden werden kann. Ihre erfundenen Tags fügen keine Bedeutung hinzu. Das ist einer von vielen Gründen, warum er nicht möchte, dass Sie sie verwenden.
Punkrockbuddyholly

59
@ MrMisterMan eigentlich denke ich, dass sie es tun. Was ist sinnvoller - <p>555-212-2344</p>oder <supportPhone> 555-212-2344 </ supportPhone>
Yuriy Galanter

169
@YuriyGalanter <p class = "supportPhone">; P
punkrockbuddyholly

30
@MrMisterMan Denken Sie daran, all diese Regeln und Programmierkonstrukte wurden von Leuten erfunden, die nicht schlauer sind als Sie, und Sie können sie ändern, Sie können sie beeinflussen, Sie können Ihre eigenen Dinge bauen, die andere Leute verwenden können.
L_7337

90
Ich könnte darauf hinweisen, dass Sie im Grunde genommen XML und nicht HTML tun. XML ist eine abstraktere Auszeichnungssprache, mit der Sie Daten auf die von Ihnen beschriebene "nützliche" Weise darstellen können - d. H. mit semantischer Bedeutung verbunden. Sie können dann eine XSLT-Umwandlung verwenden, um Ihre Daten in HTML zu rendern
ose

Antworten:


470

Warum arbeitet CSS mit gefälschten Elementen?

(Die meisten) Browser sind so konzipiert, dass sie (bis zu einem gewissen Grad) vorwärtskompatibel mit zukünftigen HTML-Ergänzungen sind. Nicht erkannte Elemente werden in das DOM analysiert, ihnen ist jedoch keine Semantik oder spezielle Standardwiedergabe zugeordnet.

Wenn der Spezifikation ein neues Element hinzugefügt wird, können manchmal CSS, JavaScript und ARIA verwendet werden, um in älteren Browsern dieselbe Funktionalität bereitzustellen (und die Elemente müssen im DOM angezeigt werden, damit diese Sprachen sie bearbeiten können, um diese Funktionalität hinzuzufügen ).

(Es sollte zwar angemerkt werden, dass derzeit daran gearbeitet wird, ein Mittel zum Erweitern von HTML mit benutzerdefinierten Elementen zu definieren , aber diese Arbeit befindet sich derzeit in einem frühen Entwicklungsstadium, sodass sie wahrscheinlich vermieden werden sollte, bis sie ausgereift ist.)

Warum möchte mein Professor nicht, dass ich erfundene Elemente verwende?

  • Sie sind in der HTML-Spezifikation nicht zulässig
  • Sie können mit zukünftigen Standardelementen mit demselben Namen in Konflikt stehen
  • Es gibt wahrscheinlich ein vorhandenes HTML-Element, das für die Aufgabe besser geeignet ist

Ebenfalls; Warum wusste er nicht, dass erfundene Elemente existierten und mit CSS arbeiteten? Sind sie ungewöhnlich?

Ja. Die Leute benutzen sie nicht, weil sie die oben genannten Probleme haben.


30
"Sie sind nach der HTML-Spezifikation nicht zulässig" Nicht unbedingt wahr. Sie entsprechen nicht der HTML-Namespace-Spezifikation, aber die HTML5-Spezifikation ist eine viel umfassendere Sache, die benutzerdefinierte Spezifikationen zulässt, und gibt explizit an, wie solche Dinge in Bezug auf CSS- und API-Behandlung (DOM) behandelt werden sollen.
Ben Lesh

4
Es gibt bereits Bibliotheken, insbesondere Angular.js, mit denen Sie HTML mit benutzerdefinierten Elementen erweitern können. Vielleicht nicht in dem Sinne, wie Sie meinen, da die Elemente nur von Javascript analysiert und normalerweise in echte übersetzt werden, aber wenn Sie HTML mit benutzerdefinierten Tags erweitern möchten, können Sie dies mit Angular tun
Charlie Martin

11
+1 Für "Sie könnten mit zukünftigen Standards in Konflikt stehen". Denken Sie daran, dass es jetzt vielleicht funktioniert, aber es muss 3-4 Jahre lang funktionieren, nachdem Sie begonnen haben.
tim.baker

70
Ich möchte ein <ninja> -Tag haben, um dom-Elemente auszublenden, anstatt die
Stilanzeige

18
Ein weiterer wirklich wichtiger Punkt: Spezielle Browser für Blinde oder Personen mit ansonsten eingeschränkten Fähigkeiten verwenden die richtigen HTML-Elemente für verschiedene Zwecke (vereinfachen Sie die Navigation auf der Seite, indem Sie beispielsweise den Überschriften folgen). Die fehlende Semantik + Standard-Rendering wirkt sich möglicherweise nicht zu stark auf normale Browser aus, aber diese speziellen Browser werden wahrscheinlich verwirrt sein und die Benutzerfreundlichkeit Ihrer Website drastisch beeinträchtigen.
Arve Systad

98

TL; DR

  • Benutzerdefinierte Tags sind in HTML ungültig. Dies kann zu Renderproblemen führen.
  • Erschwert die zukünftige Entwicklung, da Code nicht portierbar ist.
  • Gültiges HTML bietet viele Vorteile wie SEO, Geschwindigkeit und Professionalität.

Lange Antwort

Es gibt einige Argumente, dass Code mit benutzerdefinierten Tags besser verwendet werden kann.

Dies führt jedoch zu ungültigem HTML. Welches ist nicht gut für Ihre Website.

Der Punkt des gültigen CSS / HTML | Paketüberfluss

  • Google bevorzugt es, damit es gut für SEO ist.
  • Dadurch funktioniert Ihre Webseite mit größerer Wahrscheinlichkeit in Browsern, die Sie nicht getestet haben.
  • Dadurch sehen Sie professioneller aus (zumindest für einige Entwickler).
  • Kompatible Browser können [gültiges HTML schneller rendern]
  • Es weist auf eine Reihe von obskuren Fehlern hin, die Sie wahrscheinlich übersehen haben und die sich auf Dinge auswirken, die Sie wahrscheinlich nicht getestet haben, z. B. die Codepage oder den Sprachensatz der Seite.

Warum validieren? W3C

  • Validierung als Debugging-Tool
  • Validierung als zukunftssichere Qualitätsprüfung
  • Die Validierung erleichtert die Wartung
  • Die Validierung hilft dabei, bewährte Verfahren zu vermitteln
  • Validierung ist ein Zeichen von Professionalität

8
Ein weiteres Argument für gültigen Code ist, dass die anderen Mitglieder oder neuen Entwickler sofort verstehen sollten, was Sie erreichen möchten, wenn Sie an einen anderen Entwickler übergeben müssen oder in einem Team arbeiten. . . Mit ungültigen, erfundenen Tags kann dies sehr schwierig werden ...
Pat Dobson

9
AKA. Zukünftige Entwicklung und Erleichterung der Wartung.
Dan Grahn

68

YADA (noch eine (andere) Antwort)

Bearbeiten: Bitte beachten Sie den Kommentar von BoltClock unten bezüglich Typ vs Tag vs Element. Ich mache mir normalerweise keine Sorgen um die Semantik, aber sein Kommentar ist sehr angemessen und informativ.

Obwohl es bereits eine Reihe guter Antworten gibt, haben Sie angegeben, dass Ihr Professor Sie aufgefordert hat, diese Frage zu stellen, damit Sie (formal) in der Schule sind . Ich dachte, ich würde nicht nur CSS, sondern auch die Mechanik von Webbrowsern etwas ausführlicher erläutern. Laut Wikipedia ist "CSS eine Stylesheet-Sprache, mit der ... ein Dokument beschrieben wird, das in einer Auszeichnungssprache geschrieben ist." (Ich habe die Betonung auf "a" hinzugefügt.) Beachten Sie, dass dort nicht "in HTML geschrieben" steht, geschweige denn eine bestimmte HTML-Version. CSS kann für HTML, XHTML, XML, SGML, XAML usw. verwendet werden. Natürlich benötigen Sie etwas, das gerendert werden kannJeder dieser Dokumenttypen wendet auch das Styling an. Per Definition kennt / versteht / kümmert sich CSS nicht um bestimmte Markup-Sprach-Tags. Daher können die Tags in Bezug auf HTML "ungültig" sein, es gibt jedoch kein Konzept für ein "gültiges" Tag / Element / Typ in CSS.

Moderne visuelle Browser sind keine monolithischen Programme. Sie sind eine Mischung aus verschiedenen "Motoren", die bestimmte Aufgaben zu erledigen haben. Bei einem Minimum kann ich mich vorstellen 3 - Motoren, das Rendering - Engine, die CSS - Engine und die Javascript - Engine / VM. Sie sind sich nicht sicher, ob der Parser Teil der Rendering-Engine ist (oder umgekehrt) oder ob es sich um eine separate Engine handelt, aber Sie haben die Idee.

Unabhängig davon , ob ein visuelles Browser ( andere haben bereits angesprochen , dass Bildschirm Leser andere Herausforderungen haben könnten mit ungültigen Tags handeln ) gilt die Formatierung , ob die Parser Blätter des „ungültig“ Tag im Dokument ab und dann , ob der Rendering - Engine gilt Stile zu diesem Tag. Da dies die Entwicklung / Wartung erschweren würde, werden CSS-Engines nicht so geschrieben, dass sie verstehen, dass "dies ein HTML-Dokument ist. Hier ist die Liste der gültigen Tags / Elemente / Typen." CSS-Engines finden einfach Tags / Elemente / Typen und teilen der Rendering-Engine mit: "Hier sind die Stile, die Sie anwenden sollten." Ob die Rendering-Engine entscheidet, die Stile tatsächlich anzuwenden, ist entscheidend.

Hier ist eine einfache Möglichkeit, sich den grundlegenden Ablauf von Engine zu Engine vorzustellen: Parser -> CSS -> Rendering. In Wirklichkeit ist es viel komplizierter, aber das ist gut genug für den Anfang.

Diese Antwort ist schon zu lang, also werde ich dort enden.


10
Obwohl Sie erwähnt haben, dass "Tags" ein allgemeiner Begriff für Elemente geworden ist, mit dem ich nicht einverstanden bin und nicht widersprechen kann, ändert dies nichts an der Tatsache, dass der richtige Begriff für sie immer noch "Elemente" ist. Ein Tag ist speziell eine Syntaxfunktion von HTML und XML und möglicherweise nicht in anderen Dokumentensprachen vorhanden, die mit CSS kompatibel sind. Zu sagen, dass CSS-Stile "Tags" sind, wie die Leute sie oft nennen, wird dem Agnostizismus der Dokumentensprache von CSS nicht sehr gerecht.
BoltClock

53

Unbekannte Elemente werden divvon modernen Browsern als s behandelt . Deshalb arbeiten sie. Dies ist Teil des kommenden HTML5-Standards, der eine modulare Struktur einführt, zu der neue Elemente hinzugefügt werden können.

In älteren Browsern (ich denke IE7-) können Sie einen Javascript-Trick anwenden, nach dem sie auch funktionieren.

Hier ist eine verwandte Frage, die ich bei der Suche nach einem Beispiel gefunden habe.

Hier ist eine Frage zum Javascript-Fix . Es stellt sich heraus, dass IE7 diese Elemente nicht sofort unterstützt.

Ebenfalls; Warum wusste er nicht, dass erfundene Tags existieren und mit CSS funktionieren? Sind sie ungewöhnlich?

Ja ganz. Vor allem aber: Sie dienen keinem zusätzlichen Zweck. Und sie sind neu in HTML5. In früheren HTML-Versionen war ein unbekanntes Tag ungültig.

Außerdem scheinen Lehrer manchmal Wissenslücken zu haben. Dies könnte auf die Tatsache zurückzuführen sein, dass sie den Schülern die Grundlagen eines bestimmten Fachs beibringen müssen, und es lohnt sich nicht wirklich, alle Vor- und Nachteile zu kennen und wirklich auf dem neuesten Stand zu sein. Ich wurde einmal inhaftiert, weil ein Lehrer dachte, ich hätte einen Virus programmiert, nur weil ich mit dem playBefehl in GWBasic einen Computer dazu bringen konnte, Musik abzuspielen . (Wahre Geschichte, und ja, vor langer Zeit). Aber was auch immer der Grund sein mag, ich denke, der Rat, keine benutzerdefinierten Elemente zu verwenden, ist vernünftig.


3
@OnoSendai Du hast mich zweifeln lassen, aber ich denke wirklich, dass sie als 'Blockelemente ohne zusätzliches Markup' gerendert werden, also im Grunde wie Divs.
GolezTrol

6
@OnoSendai Ein Blockelement hat möglicherweise die Anzeigeeigenschaft block , ist jedoch nicht erforderlich. Beispielsweise wurden Ankertags in den Blockstatus versetzt (dh, Sie dürfen Blockelemente wie divs in sie einfügen), haben jedoch weiterhin die Inline-Anzeigeeigenschaft.
Cimmanon

8
Der Anfangswert von displayist inline, daher ist der Kommentar von @ OnoSendai korrekt.
BoltClock

2
@cimmanon: aElemente haben jetzt ein transparentes Inhaltsmodell. Ob sie blockiert oder inline sind, hängt davon ab, ob ihr Vorfahr blockiert oder inline ist. Diese Antwort handelt von unbekannten Elementen, für die HTML kein Inhaltsmodell definiert. Wenn für CSS kein Browser-Standardwert vorhanden displayist, wird der Anfangswert verwendet.
BoltClock

1
@ BoltClock'saUnicorn Bedeutet das also, dass <div> <a> foo </a> <a> bar </a> </ div> die beiden <a> -Tags als Blöcke rendert? Das scheint ein bisschen verdächtig ...
flauschig

27

Eigentlich können Sie benutzerdefinierte Elemente verwenden. Hier ist die W3C-Spezifikation zu diesem Thema:

http://w3c.github.io/webcomponents/spec/custom/

Und hier ist ein Tutorial, das erklärt, wie man sie benutzt:

http://www.html5rocks.com/de/tutorials/webcomponents/customelements/

Wie von @Quentin hervorgehoben: Dies ist ein Entwurf einer Spezifikation in den frühen Tagen der Entwicklung, der Einschränkungen hinsichtlich der Elementnamen auferlegt.


7
Es sollte beachtet werden, dass dies ein Entwurf einer Spezifikation in den frühen Tagen der Entwicklung ist und dass es Einschränkungen für die Elementnamen auferlegt.
Quentin

2
+1 Wusste nicht, dass W3C verwendet, githubaber tatsächlich verwenden sie.
Vitor Canova

22

Es gibt ein paar Dinge an den anderen Antworten, die entweder nur schlecht formuliert oder vielleicht ein wenig falsch sind.

FALSE (ish): Nicht standardmäßige HTML-Elemente sind "nicht erlaubt", "illegal" oder "ungültig".

Nicht unbedingt. Sie sind "nicht konform" . Was ist der Unterschied? Etwas kann sich "nicht anpassen" und trotzdem "erlaubt" werden. Das W3C wird die HTML-Polizei nicht zu Ihnen nach Hause schicken und Sie wegbringen.

Das W3C hat die Dinge aus einem bestimmten Grund so gelassen. Konformität und Spezifikationen werden von einer Community definiert. Wenn Sie zufällig eine kleinere Community haben, die HTML für spezifischere Zwecke verwendet, und alle sich auf einige neue Elemente einigen, die sie zur Vereinfachung benötigen, können sie das haben, was das W3C als "andere anwendbare Spezifikationen" bezeichnet . (Dies ist natürlich eine grobe Vereinfachung, aber Sie haben die Idee)

Strenge Validatoren erklären Ihre nicht standardmäßigen Elemente jedoch für "ungültig". Dies liegt jedoch daran, dass es die Aufgabe des Validators ist, die Konformität mit den Spezifikationen sicherzustellen, für die er validiert, und nicht die "Legalität" für den Browser oder die Verwendung sicherzustellen .

FALSCH (ish): Nicht-Standard - HTML - Elemente werden in Rendering - Probleme führen

Möglicherweise, aber unwahrscheinlich. (Ersetzen Sie "wird" durch "könnte".) Dies kann nur dann zu einem Rendering-Problem führen, wenn Ihr benutzerdefiniertes Element mit einer anderen Spezifikation in Konflikt steht, z. B. einer Änderung der HTML-Spezifikation oder einer anderen Spezifikation, die innerhalb desselben Systems berücksichtigt wird (z SVG, Mathe oder etwas Benutzerdefiniertes).

Der Grund , warum CSS nicht standardmäßige Tags formatieren kann, liegt darin, dass in der HTML-Spezifikation eindeutig Folgendes angegeben ist :

Benutzeragenten müssen Elemente und Attribute behandeln, die sie nicht als semantisch neutral verstehen. Belassen Sie sie im DOM (für DOM-Prozessoren) und gestalten Sie sie gemäß CSS (für CSS-Prozessoren), ohne daraus eine Bedeutung abzuleiten

Hinweis: Wenn Sie ein benutzerdefiniertes Tag verwenden möchten, denken Sie daran, dass eine spätere Änderung der HTML-Spezifikation Ihr Styling in die Luft jagen könnte. Seien Sie also vorbereitet. Es ist jedoch sehr unwahrscheinlich, dass das W3C das <imsocool>Tag implementiert .

Nicht standardmäßige Tags und JavaScript (über das DOM)

Der Grund, warum Sie mit JavaScript auf benutzerdefinierte Elemente zugreifen und diese ändern können, liegt darin, dass in der Spezifikation sogar angegeben ist, wie sie im DOM behandelt werden sollen. Dies ist die (wirklich schreckliche) API, mit der Sie die Elemente auf Ihrer Seite bearbeiten können.

Die HTMLUnknownElement-Schnittstelle muss für HTML-Elemente verwendet werden, die nicht durch diese Spezifikation (oder andere anwendbare Spezifikationen) definiert sind.

TL; DR: Die Einhaltung der Spezifikation erfolgt aus Gründen der Kommunikation und Sicherheit. Nichtkonformität ist weiterhin von allen außer einem Validator zulässig , dessen einziger Zweck darin besteht, die Konformität durchzusetzen, dessen Verwendung jedoch optional ist.

Zum Beispiel:

var wee = document.createElement('wee');
console.log(wee.toString()); //[object HTMLUnknownElement]

(Ich bin sicher, das wird Flammen ziehen, aber da sind meine 2 Cent)


3
HTML legt nicht nur fest, wie Elemente in Bezug auf CSS behandelt werden sollen, die CSS-Spezifikation ist größtenteils auch vom Design her dokumentensprachunabhängig (dies ist bereits in einigen anderen Antworten impliziert, aber ich stelle es hier für fest Bequemlichkeit). Wenn es ein Verhalten gibt, das für HTML und / oder XHTML spezifisch ist, wird es immer angezeigt , auch in informativem Text (z. B. "Die ID eines HTML-Elements wird durch das idAttribut angegeben"), nicht nur in normativem Text (siehe Hintergründe und Rahmen 3 für eine Beispiel).
BoltClock

18

Nach den Angaben:

CSS

Eine Typauswahl ist der Name eines Dokumentensprachelementtyps, der unter Verwendung der Syntax von CSS-qualifizierten Namen geschrieben wurde

Ich dachte , das das hieß Element Wähler, aber anscheinend ist es eigentlich der Typ - Selektor. In der Spezifikation wird weiter darüber gesprochen, CSS qualified nameswas die tatsächlichen Namen nicht einschränkt. Das heißt, solange die Typauswahl mit der CSS-qualifizierten Namenssyntax übereinstimmt, ist sie technisch korrekt und entspricht dem Element im Dokument. Es gibt keine CSS-spezifische Einschränkung für Elemente, die in einer bestimmten Spezifikation nicht vorhanden sind - HTML oder auf andere Weise.

HTML

Es gibt keine offizielle Einschränkung für das Einfügen von Tags in das gewünschte Dokument. In der Dokumentation heißt es jedoch

Autoren dürfen Elemente, Attribute oder Attributwerte nicht für andere Zwecke als den entsprechenden semantischen Zweck verwenden, da dies verhindert, dass Software die Seite korrekt verarbeitet.

Und es heißt später

Autoren dürfen keine Elemente, Attribute oder Attributwerte verwenden, die nach dieser Spezifikation oder anderen anwendbaren Spezifikationen nicht zulässig sind, da dies die zukünftige Erweiterung der Sprache erheblich erschwert.

Ich bin mir nicht sicher, wo oder ob die Spezifikation besagt, dass unbekannte Elemente zulässig sind , aber es geht um die HTMLUnknownElement- Schnittstelle für nicht erkannte Elemente. Einige Browser erkennen möglicherweise nicht einmal Elemente, die in der aktuellen Spezifikation enthalten sind (IE8 fällt mir ein).

Es gibt zwar einen Entwurf für benutzerdefinierte Elemente , aber ich bezweifle, dass er noch irgendwo implementiert ist.


Ich denke, die meisten von uns betrachten sie als Element- Selektoren, aber es ist sinnvoll, dass sie "offiziell" Typ- Selektoren sind.
Andrew Steitz

@ Andrew Steitz: Stellen Sie sich das so vor: Element: Typ :: Person: Name. Sie können viele Elemente unterschiedlichen Typs haben, wobei jedes Element von einem einzigen Typ ist, und auf die gleiche Weise können Sie viele Personen haben, die jeweils einen Namen haben. Selektoren arbeiten an einem Dokumentbaum, und jeder Selektor kann mit einer bestimmten Anzahl von Dokumentbaumelementen übereinstimmen, die Sie mit einem Klassenselektor, einem ID-Selektor, einem Attributselektor ... oder einem Typselektor eingrenzen können. Was auch immer Sie verwenden, Sie passen immer noch zu Elementen. "Elementauswahl" wäre in diesem Fall also nicht sinnvoll - all diese Dinge wären Elementauswahl.
BoltClock

@ BoltClock'saUnicorn: Richtig, aber Klasse, ID und Attribut sind alle Attribute (LOL) eines "Elements", dh das "Ding" in den spitzen Klammern. Sie beschreiben das "Element", in dessen Eröffnungs-Tag sie sich befinden. Ja, <a> und <div> sind bestimmte "Elementtypen", aber ich bezweifle, dass jemand Klasse, ID und Attribute "Elemente" nennen würde. Ich stimme voll und ganz zu, dass alle Selektoren wirklich "Element" -Selektoren sind, aber in der GEMEINSAMEN VERWENDUNG bezeichnen die Leute "Typ" -Selektoren normalerweise als "Element" -Selektoren. Das war der Punkt meines vorherigen Kommentars. Entschuldigung, es war unklar. :-)
Andrew Steitz

@ExplosionPills - Die HTML-Spezifikationen besagen nicht, dass unbekannte Elemente nicht zulässig sind. Da jedoch jedes Element eine Auflistung von Elementnamen enthält, die als untergeordnete Elemente zulässig sind (dh das Inhaltsmodell), muss dies nicht der Fall sein. Es gibt einfach keinen Ort, an dem ein unbekanntes Element als untergeordnetes Element eines zulässigen Elements zulässig ist. Das Anwenden von HTMLUnknownElement auf solche Elemente ist Teil der vorbereitenden Spezifikation - dh was HTML-Konsumenten mit gültigen oder nicht gültigen Dokumenten tun müssen - und nicht Teil dessen, was Autoren tun müssen, um ihre Dokumente gültig zu machen.
Alohci

@Alohci Ich meine nicht erlaubt in dem Sinne, dass sie aus dem DOM verworfen würden, anstatt semantisch ungültig zu sein
Explosion Pills

13

Dies ist mit HTML5 möglich, Sie müssen jedoch ältere Browser berücksichtigen.

Wenn Sie sich dann für die Verwendung entscheiden, KOMMENTIEREN Sie unbedingt Ihr HTML !! Einige Leute haben möglicherweise Probleme, herauszufinden, was es ist, sodass ein Kommentar ihnen eine Menge Zeit sparen kann.

Etwas wie das,

<!-- Custom tags in use, refer to their CSS for aid -->

Wenn Sie Ihre eigenen benutzerdefinierten Tags / Elemente erstellen, haben die älteren Browser keine Ahnung, wie dies bei HTML5-Elementen wie nav/ aussieht section.

Wenn Sie an diesem Konzept interessiert sind, empfehle ich, es richtig zu machen.

Loslegen

Mit benutzerdefinierten Elementen können Webentwickler neue Arten von HTML-Elementen definieren. Die Spezifikation ist eines von mehreren neuen API-Grundelementen, die unter dem Dach von Web Components landen, aber möglicherweise das wichtigste. Webkomponenten existieren nicht ohne die Funktionen, die durch benutzerdefinierte Elemente freigeschaltet wurden:

Definieren neuer HTML / DOM-Elemente Erstellen Sie Elemente, die sich von anderen Elementen erstrecken. Bündeln Sie benutzerdefinierte Funktionen logisch zu einem einzigen Tag. Erweitern Sie die API vorhandener DOM-Elemente

Es gibt eine Menge, die Sie damit machen können, und es macht Ihr Skript schön, wie dieser Artikel es gerne ausdrückt. Benutzerdefinierte Elemente, die neue Elemente in HTML definieren .

Also lasst uns zusammenfassen,

Vorteile

  • Sehr elegant und leicht zu lesen.

  • Es ist schön, nicht so viele zu sehen divs. : p

  • Ermöglicht dem Code ein einzigartiges Gefühl

Nachteile

  • Die Unterstützung älterer Browser ist eine wichtige Sache.

  • Andere Entwickler haben möglicherweise keine Ahnung, was zu tun ist, wenn sie nichts über benutzerdefinierte Tags wissen. (Erklären Sie ihnen oder fügen Sie Kommentare hinzu, um sie zu informieren)

  • Schließlich ist eine Sache zu berücksichtigen, aber ich bin mir nicht sicher, Block- und Inline-Elemente. Wenn Sie benutzerdefinierte Tags verwenden, werden Sie am Ende mehr CSS schreiben, da das benutzerdefinierte Tag keine Standardseite hat.

Die Wahl liegt ganz bei Ihnen und Sie sollten sich darauf stützen, was das Projekt verlangt.

Update 1/2/2014

Hier ist ein sehr hilfreicher Artikel, den ich gefunden habe und den ich teilen möchte: Benutzerdefinierte Elemente .

Lernen Sie die Technologie Warum benutzerdefinierte Elemente? Mit benutzerdefinierten Elementen können Autoren ihre eigenen Elemente definieren. Autoren verknüpfen JavaScript-Code mit benutzerdefinierten Tag-Namen und verwenden diese benutzerdefinierten Tag-Namen wie jedes Standard-Tag.

Verwenden Sie zum Beispiel nach dem Registrieren einer speziellen Art von Schaltfläche, die als Super-Schaltfläche bezeichnet wird, die Super-Schaltfläche wie folgt:

Benutzerdefinierte Elemente sind weiterhin Elemente. Wir können sie genauso einfach erstellen, verwenden, bearbeiten und komponieren wie jeder Standard oder heute.

Dies scheint eine sehr gute Bibliothek zu sein, aber ich habe bemerkt, dass sie den Build-Status von Window nicht bestanden hat. Dies ist auch in einem Pre-Alpha, glaube ich, also würde ich dies im Auge behalten, während es sich entwickelt.


3
" Other developers may have no clue what to do if they don't know about custom tags.Ich hasse dieses Argument." Andere Entwickler sollten auch neue Dinge lernen, und wenn sie die in Ihrem Code verwendeten Techniken nicht verstehen, sollten sie Ihnen dankbar sein, dass Sie auf Mängel in ihrem Wissen hingewiesen haben. Vielleicht ist das in diesem Fall etwas unfair, weil benutzerdefinierte Tags nur als Entwurf existieren, aber ich habe das gleiche Argument gehört, wenn ich geeignete standardisierte Techniken verwendet habe.
GolezTrol

1
Ich sage nicht, dass ich das unterstütze, aber viele Entwickler lernen nicht weiter. Es gibt fast keinen Grund, etwas nicht zu kommentieren, wenn es etwas komplex oder neu ist. Wir alle kommentieren unsere Skripte richtig? Um zu zeigen, was wir ausführen und wie, genau wie bei benutzerdefinierten Tags.
Josh Powell

1
Natürlich, wenn es nur darum geht, Kommentare hinzuzufügen. Ich dachte, Sie meinten, Sie sollten überhaupt keine benutzerdefinierten Elemente verwenden, weil andere Leute das nicht verstehen würden. Das Hinzufügen eines kleinen Kommentars, wenn Sie eine weniger verwendete Technik hinzufügen, ist eine gute Sache. Seien Sie jedoch vorsichtig mit Kommentaren in HTML. Sie können auf dem Client landen, Bandbreite verbrauchen und möglicherweise Implementierungsdetails enthüllen, über die Ihre Besucher nichts erfahren sollen. Alternativ können Sie Kommentare auch als PHP / ASP-Kommentare hinzufügen, damit sie sich noch in der Vorlage befinden, aber auf dem Server verbleiben.
GolezTrol

1
@GolezTroi, es ist nicht so, dass Sie niemals Dinge tun sollten, die andere Entwickler herausfordern, es ist eine Frage des Kosten-Nutzen-Verhältnisses. Wenn Sie etwas tun, das für den nächsten Entwickler schwieriger ist, um Ihren Code zu verbessern und sauberer zu machen, tun Sie es. Aber mach keine knorrigen Dinge nur zum Spaß.
BostonJohn

1
@JoshPowell Kommentare sollten sich nicht mit dem Was und Wie befassen (der Code sagt dies bereits aus, und wenn es nicht klar genug ist, schreiben Sie den Code neu, bis er ist), sondern sollten mir sagen, warum . Es gibt nur wenige Dinge, die schlimmer sind als viele Kommentare, die nur besagen, dass die sendmailFunktion E-Mails oder ähnliches sendet. Mich würde mehr interessieren, warum Sie E-Mails senden - und wenn der Funktionsname dies offensichtlich macht, großartig! Dann brauche ich keinen Kommentar, was der Idealfall ist. Ich werde den Code trotzdem lesen.
Christopher Creutzig

4

Warum will er nicht, dass du sie benutzt? Sie sind weder üblich noch Teil des HTML5-Standards. Technisch sind sie nicht erlaubt. Sie sind ein Hack.

Ich mag sie aber selbst. Sie könnten an XHTML5 interessiert sein. Sie können Ihre eigenen Tags definieren und diese als Teil des Standards verwenden.

Wie andere bereits betont haben, sind sie ungültig und daher nicht tragbar.

Warum wusste er nicht, dass sie existieren? Ich weiß es nicht, außer dass sie nicht üblich sind. Möglicherweise war er sich einfach nicht bewusst, dass Sie es konnten.


2
Es gibt kein XHTML5 - es gab eine Arbeitsgruppe, die versuchte, XHTML 2 zu entwickeln, aber es ist vor Jahren gescheitert.
Max

1
@papirtiger: XHTML5 ist HTML5, das wie XML bereitgestellt wird, aber Sie haben Recht, dass es keinen unabhängigen XHTML-Standard gibt, der über XHTML 1.1 hinausgeht.
BoltClock

1
Es gibt also XHTML5, aber es scheint sich in Bezug auf dieses Thema der benutzerdefinierten Tags kaum von HTML5 zu unterscheiden. Daher denke ich, dass die Aussage über XHTML5, mit der Sie im Gegensatz zu HTML5 zusätzliche Tags definieren können, falsch ist, was die Abwertung erklären könnte, obwohl ich mir über XHTML5 nicht sicher genug bin, um diese Antwort entweder auf- oder abzustimmen.
GolezTrol

1
Nach dem HTML5-Entwurf des W3C sind HTML und XHTML (jetzt) ​​"konkrete Syntaxen", die dieselbe "abstrakte Sprache" darstellen. Sie haben dieselben grundlegenden Funktionen, mit Ausnahme derjenigen, die nur in einer Syntax sinnvoll sind (XML-Namespaces, HTML-Noscript-Parser-Schalter): w3.org/TR/html5/introduction.html#html-vs-xhtml
IMSoP

2

Gemachte Tags werden kaum verwendet, da es unwahrscheinlich ist, dass sie in jedem aktuellen Browser und in jedem zukünftigen Browser zuverlässig funktionieren.

Ein Browser muss den HTML-Code in ihm bekannte Elemente analysieren, damit erfundene Tags in etwas anderes konvertiert werden, das in das Dokumentobjektmodell (DOM) passt. Da die Webstandards nicht behandeln, wie mit allem umgegangen wird, was außerhalb der Standards liegt, behandeln Webbrowser nicht standardmäßigen Code auf unterschiedliche Weise.

Die Webentwicklung ist mit einer Reihe verschiedener Browser, die ihre eigenen Macken haben, schwierig genug, ohne ein weiteres Element der Unsicherheit hinzuzufügen. Am besten halten Sie sich an Dinge, die tatsächlich in den Standards enthalten sind. Dies versuchen die Browser-Anbieter zu befolgen, damit die beste Chance besteht, tatsächlich zu funktionieren.


2

Ich denke, erfundene Tags sind möglicherweise verwirrender oder unklarer als Ps mit IDs (einige Textblöcke im Allgemeinen). Wir alle wissen, dass ap mit einer ID ein Absatz ist, aber wer weiß, wofür erfundene Tags bestimmt sind? Zumindest ist das mein Gedanke. :) Daher ist dies eher ein Stil- / Klarheitsproblem als ein Problem der Funktionalität.


3
Vielen Dank, dass Sie Grammatik Fee :)
Runelynx

2

Andere haben hervorragende Punkte gemacht, aber es ist erwähnenswert, dass es einen sehr gültigen Fall für benutzerdefinierte Elemente und Attribute gibt , wenn Sie sich ein Framework wie AngularJS ansehen . Diese vermitteln nicht nur eine bessere semantische Bedeutung für die XML, sondern können auch Verhalten, Aussehen und Verhalten für die Webseite bereitstellen.


2

CSS ist eine Stylesheet-Sprache, mit der XML-Dokumente und nicht nur (X) HTML-Dokumente dargestellt werden können. Ihr Snippet mit den erfundenen Tags kann Teil eines legalen XML-Dokuments sein. Es wäre eine, wenn Sie es in ein einzelnes Root-Element einschließen. Wahrscheinlich haben Sie schon eine <html> ...</html>um sich? Jeder aktuelle Browser kann XML-Dokumente anzeigen.

Natürlich ist es kein sehr gutes XML-Dokument, es fehlen eine Grammatik und eine XML-Deklaration. Wenn Sie stattdessen einen HTML-Deklarationsheader verwenden (und wahrscheinlich eine Serverkonfiguration, die den richtigen MIME-Typ sendet), handelt es sich stattdessen um illegales HTML.

(X) HTML hat Vorteile gegenüber einfachem XML, da Elemente eine semantische Bedeutung haben, die im Kontext einer Webseitenpräsentation nützlich ist. Tools können mit dieser Semantik arbeiten, andere Entwickler kennen die Bedeutung, sie ist weniger fehleranfällig und besser zu lesen.

In anderen Kontexten ist es jedoch besser, CSS mit XML und / oder XSLT für die Präsentation zu verwenden. Das hast du getan. Da dies nicht Ihre Aufgabe war, wussten Sie nicht, was Sie taten, und HTML / CSS ist der bessere Weg, um die meiste Zeit in Ihrem Szenario daran festzuhalten.

Sie sollten Ihrem Dokument einen (X) HTML-Header hinzufügen, damit Tools Ihnen aussagekräftige Fehlermeldungen geben können.


2
Nein, es ist überhaupt kein legales (wohlgeformtes) XML. Es gibt ein <style>Element und dann ... ein <body>Element. Ein XML-Dokument darf nur ein Stammelement haben. In diesem Fall ist entweder das <style>Element das Stammelement, aber das <body>stört, oder es muss ein Stammelement hinzugefügt werden, das beide Elemente zu seinen untergeordneten Elementen macht. Es sei denn, Sie ersetzen das <style>Element durch eine Stylesheet-Referenz (selbst ein Daten-URI <?xml-stylesheet href="data:text/css,imsocool { color: blue; }"?>würde gut funktionieren), sodass das Stammelement wird <body>.
BoltClock

2

... Ich ändere einfach alle meine erfundenen Tags in Absätze mit IDs.

Ich habe tatsächlich Probleme mit seinem Vorschlag, wie man es richtig macht.

  1. Ein <p>Tag steht für Absätze. Ich sehe Leute, die es die ganze Zeit anstelle eines Div verwenden - einfach aus Platzgründen oder weil es sanfter erscheint. Wenn es kein Absatz ist, verwenden Sie ihn nicht.

  2. Sie müssen oder möchten keine IDs auf alles kleben, es sei denn, Sie müssen gezielt darauf abzielen (z. B. mit Javascript). Verwenden Sie Klassen oder nur ein direktes Div.


2

CSS wurde von Anfang an als markupunabhängig konzipiert, sodass es mit jeder Markup-Sprache verwendet werden kann, die baumähnliche DOM-Strukturen erzeugt (z. B. SVG). Jedes Tag, das der name tokenProduktion entspricht, ist in CSS vollkommen gültig. Ihre Frage bezieht sich also eher auf HTML als auf CSS.

Elemente mit benutzerdefinierten Tags werden von der HTML5-Spezifikation unterstützt. HTML5 standardisiert die Art und Weise, wie unbekannte Elemente im DOM analysiert werden müssen. HTML5 ist also die erste HTML-Spezifikation, die streng genommen benutzerdefinierte Elemente ermöglicht. Sie müssen nur den HTML5-Doctype <!DOCTYPE html>in Ihrem Dokument verwenden.

Ab benutzerdefinierten Tag-Namen selbst ...

In diesem Dokument http://www.w3.org/TR/custom-elements/ werden benutzerdefinierte Tags empfohlen, die mindestens ein '-' (Bindestrich) enthalten. Auf diese Weise werden sie nicht mit zukünftigen HTML-Elementen in Konflikt geraten. Daher sollten Sie Ihr Dokument folgendermaßen ändern:

<style>
so-cool {
    color:blue;
}
</style>

<body>
    <so-cool>HELLO</so-cool>
</body> 

2

Anscheinend hat es niemand erwähnt, also werde ich es tun.

Dies ist ein Nebenprodukt von Browserkriegen .

In den 90er Jahren, als das Internet zum ersten Mal zum Mainstream wurde, nahm der Wettbewerb auf dem Browsermarkt zu. Um wettbewerbsfähig zu bleiben und Benutzer anzulocken, versuchten einige Browser (insbesondere Internet Explorer), hilfreich und „benutzerfreundlich“ zu sein, indem sie versuchten, herauszufinden, was Seitengestalter meinten, und erlaubten daher Markups, die falsch sind (z. B. <b><i>foobar</b></i>korrekt als fett dargestellt werden). Kursivschrift).

Dies war bis zu einem gewissen Grad sinnvoll, denn wenn sich ein Browser weiterhin über Syntaxfehler beschwerte, während ein anderer etwas aß, was Sie darauf geworfen hatten, und ein (mehr oder weniger) korrektes Ergebnis ausspuckte, strömten die Leute natürlich zu letzterem.

Während viele dachten, die Browserkriege seien vorbei, hat sich in den letzten Jahren seit der Veröffentlichung von Chrome ein neuer Krieg zwischen Browser-Anbietern wieder entzündet. Apple begann erneut zu wachsen und Safari voranzutreiben, und der IE verlor seine Dominanz. (Man könnte es aufgrund der wahrgenommenen Zusammenarbeit und Unterstützung von Standards durch Browser-Anbieter als "Kalten Krieg" bezeichnen.) Daher ist es nicht verwunderlich, dass selbst moderne Browser, die angeblich streng den Webstandards entsprechen, tatsächlich versuchen, "clever" und "klug" zu sein Erlauben Sie ein solches Standard-Breaking-Verhalten, um nach wie vor einen Vorteil zu erzielen.

Leider führte dieses freizügige Verhalten zu einem massiven ( manche sagen sogar krebsartigen) Wachstum von schlecht markierten Webseiten. Da der IE der mildeste und beliebteste Browser war und Microsoft weiterhin gegen Standards verstößt, wurde der IE berüchtigt dafür, schlechtes Design zu fördern und zu fördern sowie fehlerhafte Seiten zu verbreiten und aufrechtzuerhalten.

Möglicherweise können Sie in einigen Browsern vorerst mit solchen Macken und Exploits davonkommen, aber abgesehen von gelegentlichen Rätseln oder Spielen oder Ähnlichem sollten Sie sich beim Erstellen von Webseiten und Websites immer an Webstandards halten, um sicherzustellen, dass diese korrekt und korrekt angezeigt werden Vermeiden Sie, dass sie durch ein Browser-Update beschädigt (möglicherweise vollständig ignoriert) werden.


Ich würde argumentieren, dass es etwas unangebracht ist, dem IE die Schuld an dieser besonderen Eigenart zu geben, denn als eine Reihe neuer Tags offiziell hinzugefügt wurden (für HTML5), war der IE der einzige große Browser, für den ein bestimmtes "Shim" erforderlich war, um sie stilisierbar zu machen . Dies war teilweise auf die aggressiveren Update-Regime anderer Browser zurückzuführen (dh alte IE-Versionen bleiben länger als alte Versionen von Chrome of Firefox), ist jedoch das Gegenteil davon, dass IE "am mildesten" ist.
IMSoP

HTML5? Huh? <imsocool>ist kein neues Tag in HTML5. Dies hat nichts mit HTML5 oder IE 8, 9 usw. zu tun. Diese Art von Verhalten ist keine neue Eigenart. Es ist ein Nebenprodukt jahrelanger Browserkriege. Auch wenn IE nicht für aktuelle Standarddelikte verantwortlich ist (obwohl sie sich nach dem Zorn der Webentwickler immer noch weigern, sich ordnungsgemäß anzupassen), waren sie sicherlich dafür berüchtigt, jahrelang schlechte Codierungspraktiken zu fördern. Insbesondere milde Browser (IE ist der schlimmste Täter) kamen zum schlimmsten Zeitpunkt, als das Internet anfing zu starten und Webentwickler anfingen, HTML zu lernen… falsch.
Synetech

Ich habe nicht gesagt, dass dies irgendetwas mit HTML5 zu tun hat, aber es hat mit nicht standardmäßigen Tags zu tun (wie z. B. <header>bis HTML5 zum Standard wurde), für die alte Versionen des IE mit Sicherheit nicht "tolerant" sind. Nachsicht ist auch nicht dasselbe wie Nichteinhaltung - HTML5 ist ein äußerst pragmatischer Standard, der akzeptiert, dass schlecht geformtes HTML im Gegensatz zum Idealismus früherer W3C-Spezifikationen existieren wird, und diese "Nachsicht" kommt wohl dem demokratischen Wachstum des Webs zugute.
IMSoP

Auch hier spreche ich nicht über einen bestimmten Browser oder eine bestimmte Version. Ich erkläre, dass Nachsicht im Allgemeinen ein Nebeneffekt von Browserkriegen ist. IE tolerierte viel nicht standardmäßiges und sogar fehlerhaftes Verhalten wie fehlende Tags, ungültige Tags und Attribute sowie falsch übereinstimmende Tags ( <b><i>foobar</b></i>). Dies ist kein Geheimnis und sogar ein gut kritisiertes und vielfach bösartiges Thema. Wie ich bereits sagte, war der IE nicht der einzige Browser, der ein schlechtes Markup zuließ, aber da er einen so großen Marktanteil hatte und genau zum richtigen (oder falschen) Zeitpunkt kam, trug er im Allgemeinen erheblich zu einem schlechten Markup bei .
Synetech

1

Während Browser CSS im Allgemeinen mit HTML-Tags verknüpfen, unabhängig davon, ob sie gültig sind oder nicht, sollten Sie dies ABSOLUT NICHT tun.

Aus CSS-Sicht ist daran technisch nichts auszusetzen. Die Verwendung von erfundenen Tags sollten Sie jedoch NIEMALS in HTML tun.

HTML ist eine Auszeichnungssprache, dh jedes Tag entspricht einem bestimmten Informationstyp.

Ihre erfundenen Tags entsprechen keiner Art von Informationen. Dies führt zu Problemen bei Webcrawlern wie Google.

Lesen Sie weitere Informationen zur Wichtigkeit eines korrekten Markups .

Bearbeiten

Divs beziehen sich auf Gruppen mehrerer verwandter Elemente, die in Blockform angezeigt werden sollen und als solche bearbeitet werden können.

Bereiche beziehen sich auf Elemente, die anders als der aktuelle Kontext gestaltet werden sollen und inline und nicht als Block angezeigt werden sollen. Ein Beispiel ist, wenn einige Wörter in einem Satz Großbuchstaben sein müssen.

Benutzerdefinierte Tags korrelieren nicht mit Standards und daher sollte span / div stattdessen mit Klassen- / ID-Eigenschaften verwendet werden.

Hierfür gibt es sehr spezielle Ausnahmen, wie z. B. Angular JS


3
"Nie" ist nie die richtige Antwort - Sie scheinen XHTML vergessen zu haben;)
Izkata

divs und spans entsprechen auch keiner Art von Information. Google und Screenreader scheinen damit gut umzugehen. Es ist wichtig, semantisches Markup zu verwenden, aber es ist kein Argument gegen die Verwendung von benutzerdefinierten Tags.
GolezTrol

2
Divs beziehen sich auf Gruppen mehrerer verwandter Elemente, die in Blockform angezeigt und als solche manipuliert werden sollen. Bereiche beziehen sich auf Elemente, die ähnlich gestaltet werden sollen und inline angezeigt werden sollen, nicht als Block. Benutzerdefinierte Tags korrelieren nicht mit Standards und daher sollte span / div stattdessen mit Klassen- / ID-Eigenschaften verwendet werden.
Dan Green-Leipciger

Ich habe Ihr bisschen über Screenreader entfernt, weil es falsch ist. Die unterstützende Technologie wird gut gelesen, <imsocool>some awesome text</imsocool>da sie als interpretiert wird <>...</>. Was nicht passieren wird, ist, dass sie nicht in der Lage sind, unabhängig zu diesem Textblock zu springen, als wäre es ein <p>. Natuerlich , wenn Sie Ihre eigene DOCTYPE und kartiert schreiben imsocoolan p, dass es funktionieren würde.
Ryan B

0

Obwohl CSS einen so genannten "Tag-Selektor" hat, weiß es nicht, was ein Tag ist. Damit muss die Sprache des Dokuments definiert werden. CSS wurde entwickelt, um nicht nur mit HTML, sondern auch mit XML verwendet zu werden, wobei (vorausgesetzt, Sie verwenden keine DTD oder ein anderes Validierungsschema) die Tags so gut wie alles sein können. Sie könnten es auch mit anderen Sprachen verwenden, obwohl Sie Ihre eigene Semantik für genau das entwickeln müssten, was Dinge wie "Tags" und "Attribute" entsprechen.

Browser wenden CSS im Allgemeinen auf unbekannte Tags in HTML an, da dies als besser angesehen wird, als vollständig zu brechen: Zumindest können sie etwas anzeigen. Es ist jedoch sehr schlecht, "gefälschte" Tags absichtlich zu verwenden. Ein Grund dafür ist, dass von Zeit zu Zeit neue Tags definiert werden. Wenn eines definiert wird, das Ihrem gefälschten Tag ähnelt, aber nicht ganz auf die gleiche Weise funktioniert, kann dies in neuen Browsern zu Problemen mit Ihrer Website führen.


0

Warum arbeitet CSS mit gefälschten Elementen? Weil es niemanden verletzt, weil du sie sowieso nicht benutzen sollst.

Warum möchte mein Professor nicht, dass ich erfundene Elemente verwende? Denn wenn dieses Element in Zukunft durch eine Spezifikation definiert wird, hat Ihr Element ein unvorhersehbares Verhalten.

Warum wusste er auch nicht, dass erfundene Elemente existieren und mit CSS funktionieren? Sind sie ungewöhnlich? Weil er, wie die meisten anderen Webentwickler, versteht, dass wir keine Dinge verwenden sollten, die in Zukunft zufällig kaputt gehen könnten.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.