jQuery, Bedeutung eines Selectors

[mathefritz]

Was hat hier , in txt2 , das </p> zu bedeuten? Soweit ich sehe ist das Ergebnis ohne </p> dasselbe .

[dedlfix]

Tach!

Was hat hier , in txt2 , das </p> zu bedeuten?

Nichts weiter. Das ist optional.

Soweit ich sehe ist das Ergebnis ohne </p> dasselbe .

Ja.

dedlfix.

[mathefritz]

Danke! Schönen Sonntag noch.

[at]

Hallo mathefritz,

es empfiehlt sich schon deshalb grundsätzlich, geöffnete Elemente auch wieder zu schließen, weil die Regeln für die Ausnahmen vielfältig und wenig intuitiv sind. Im konkreten Fall dürfte beispielsweise das </p> vor dem <button> nicht weggelassen werden. Und im Zusammenhang mit generierten Inhalten, ist es bestenfalls schwierig, solche Konstellation zu vermeiden.

MfG, at

[mathefritz]

Danke nochmal. Was eigentlich irritiert ist, daß im bisherigem Verlauf des Tutorials ein derartiger
$("<p></p>") Ausdruck noch nicht vorkam, und hier eigentlich unerklärt bleibt. Ist ja eigentlich kein Selector, der ja auf etwas schon Existierendes Bezug nehmen sollte.

[dedlfix]

Tach!

Was eigentlich irritiert ist, daß im bisherigem Verlauf des Tutorials ein derartiger $("<p></p>") Ausdruck noch nicht vorkam, und hier eigentlich unerklärt bleibt. Ist ja eigentlich kein Selector, der ja auf etwas schon Existierendes Bezug nehmen sollte.

Die jQuery()-Funktion, oft auch als $() abgekürzt, hat drei grundlegende Aufrufformen, die jeweils unterschiedliche Aufgaben erfüllen sollen. Elemente zu selektieren ist die wohl am häufigsten verwendete Form. Eine zweite hast du in dem Beispiel kennengelernt: neue Element zu erstellen, die man anschließend ins DOM einfügen kann. Die dritte ist, bei Übergabe einer Funktion diese als Eventhandler an das DOM-Ready-Event anzuhängen.

dedlfix.

[dedlfix]

Tach!

es empfiehlt sich schon deshalb grundsätzlich, geöffnete Elemente auch wieder zu schließen, weil die Regeln für die Ausnahmen vielfältig und wenig intuitiv sind.

Es handelt sich bei dem Argument für die jQuery()-Funktion nicht um ein HTML-Dokument. Insofern liegt die Relevanz der Regeln für (vollständige) HTML-Dokumente an der Stelle zwischen nur teilweise anwendbar und irrelevant. Vielmehr kommt es auf die dokumentierte Arbeitsweise der Funktion an.

When the parameter has a single tag (with optional closing tag or quick-closing) — $( "<img />" ) or $( "<img>" ), $( "<a></a>" ) or $( "<a>" ) — jQuery creates the element using the native JavaScript .createElement() function.

createElement() wiederum möchte einen nackigen Elementnamen haben. Am Ende bleibt also ein p übrig, egal ob du ein schließendes Tag hinschreibst oder nicht. Deswegen ist es in dem Fall nutzlos, das Element im Sinne der HTML-Syntaxregeln zu schließen.

Die Arbeitsweise ist anders, wenn es nicht nur ein einzelnes und attributloses Element ist:

If the HTML is more complex than a single tag without attributes [...] the actual creation of the elements is handled by the browser's .innerHTML mechanism.

Dann lohnt es sich schon eher den HTML-Regeln Aufmerksamkeit zu schenken. Jedoch haben die Browser eingebaute Korrekturmechanismen, so das bei einfachen Konstrukten (ein einzelnes Element mit Attributen) sich ebenfalls nicht lohnt, ein schließendes Tag anzufügen. Lediglich bei noch komplexeren HTML-Fragmenten mit mehreren Elementen, besonders wenn sie nicht verschachtelt sein sollen, würde ich die Empfehlung aussprechen, die Endtags zu notieren. Für die optionalen und besonders die nutzlosen Fälle würde ich hingegen keine Regel aussprechen, sondern nur auf die Dokumentation verweisen. Empfehlungen, das Endtag unter keine Umständen wegzulassen, würde ich aber mit dem Hinweis auf dessen Nutzlosigkeit bei einzelnen attributlosen Elementen kontern.

Im konkreten Fall dürfte beispielsweise das </p> vor dem <button> nicht weggelassen werden.

Irrelevant. Da wird kein HTML-Dokument erstellt, das syntaktisch korrekt sein sollte, sondern es werden Elemente ins DOM gehängt. Diese Elemente sind bereits durch die vorhergehenden Funktionsaufrufe in einer für den Browser intern relevanten Art und Weise erstellt worden. Deren Repräsentation als HTML-Code spielt an der Stelle keine Rolle mehr.

dedlfix.

[mathefritz]

danke für die ausführliche Antwort.
Das </p> vor dem <button> weglassen gibt allerdings dem <button> dann keine eigen Zeile .

[dedlfix]

Tach!

Das </p> vor dem <button> weglassen gibt allerdings dem <button> dann keine eigen Zeile .

Das </p> in $("<p></p>") kann weggelassen werden, zur Not auch noch in der Zeile darüber beim "<p>Text.</p>". Die Syntax außerhalb des <script>...</script>-Bereiches muss aber einem ordentlichen HTML-Dokument entsprechen. Das wird ja nicht von der Arbeitsweise der jQuery-Funktion beeinflusst.

dedlfix.

[at]

Hallo dedlfix.

Für die optionalen und besonders die nutzlosen Fälle würde ich hingegen keine Regel aussprechen, sondern nur auf die Dokumentation verweisen.

Umso wichtiger also, dass ich diese Regel ausgesprochen habe.

Empfehlungen, das Endtag unter keine Umständen wegzulassen, würde ich aber mit dem Hinweis auf dessen Nutzlosigkeit bei einzelnen attributlosen Elementen kontern.

Ich werte Konsistenz, Robustheit und Nachvollziehbarkeit nicht nur höher, sondern sehe darin den Nutzen. Das gilt auch Für Attributwerte, Anführungszeichen sowie abschließende Schrägstriche in leeren Elementen.

MfG, at

[dedlfix]

Tach!

Ich werte Konsistenz, Robustheit und Nachvollziehbarkeit nicht nur höher, sondern sehe darin den Nutzen. Das gilt auch Für Attributwerte, Anführungszeichen sowie abschließende Schrägstriche in leeren Elementen.

Konsistenz der Konsistenz willen, ohne unterschiedliche Kontexte zu beachten, ist unbrauchbar. In erster Linie sind die Regeln zu beachten, die ein System verlangt. Danach kann man sich um nebensächliche Dinge wie Optik und Konsistenz kümmern. Konsistenzregeln dürfen nicht das Wissen um die eigentliche Arbeitsweise überlagern oder (auch unbewusst) verdrängen.

In deiner Antwort hast du lediglich eine in dem Fall nicht notwendige Konsistenz propagiert, ohne auf die eigentliche Arbeitsweise und Notwendigkeit der jQuery-Funktion einzugehen. Das hat in dem Fall keine Auswirkungen, weil das System das korrekt wegkürzt. So eine Prinzip-statt-Wissen-Vorgehensweise kann aber auch Lücken ins System reißen, die man eigentlich zu schließen gedachte, beispielsweise beim Anwenden von Maskierungsfunktionen, ohne dass der Kontext gegeben ist, für den diese Funktion vorgesehen ist. Deswegen muss die korrekte Anwendung im Vordergrund stehen und nicht irgendeine Konsistenz. Oder anders: Man darf sich nicht darauf verlassen, dass die Konsistenz schon alles richtig macht.

dedlfix.

[at]

Hallo dedlfix.

Konsistenz der Konsistenz willen, ohne unterschiedliche Kontexte zu beachten, ist unbrauchbar.

Im Wiki spielt die Konsistenz an unterschiedlichen Stellen immer wieder zu recht eine Rolle, etwa bei den Kindelementen von Tabellen. Im Fall von <tfoot> hat der Verweis auf die Relevanz in Javascript bis gerade eben sogar die die Erläuterung der Semantik ersetzt.

In erster Linie sind die Regeln zu beachten, die ein System verlangt.

Darüber waren wir bereits hinaus.

Danach kann man sich um nebensächliche Dinge wie Optik und Konsistenz kümmern.

Da die Funktion gewährleistet ist, ist jetzt danach.

MfG, at

[Nils-Hero]

Ich stimme at hier zu. Diese Ausnahmen des W3C mögen ja philosophische Implikationen haben, die ich nachvollziehen kann (Ein Buddhist lässt gerne das Head-Element weg), aber die praktischen Auswirkungen solcher Ausnahmen sind schwer zu durchschauen. Am meisten stört, daß <element> jetzt je nach Kontext ein void-element oder ein öffnendes tag sein kann (das hat schon HTML 4 falsch gemacht und XHTML machte es besser). Hier wird Syntax mit Semantik vermischt. Diese Ausnahmen muss man jetzt alle im Kopf behalten. Ich muss das immer und immer wieder nachschlagen. Nervt!

Hätte man gesagt, wenn es keinen Inhalt hat, kannst Du immer <element></element> oder <element/> schreiben ('/' Pflicht) und wenn es Inhalt hat musst Du <element>...</element> schreiben, das wäre eine saubere Lösung gewesen. Schade drum.

Gruß, Nils

[dedlfix]

Tach!

Ich stimme at hier zu. Diese Ausnahmen des W3C mögen ja philosophische Implikationen haben,

Die Regeln und Ausnahmen des W3C haben auf den konkreten Fall keine großartige Bedeutung. Anscheinend habt ihr kein Problem, einen Großteil der HTML-Regeln weglassen zu können, wenn ihr ein einzelnes <p></p> notiert, aber ein großes Problem, sie im kleinen nicht weglassen zu können, wo es nicht nur nicht auf sie ankommt, sondern wo sie sogar erst noch weggekürzt werden müssen, bevor die eigentliche Funktion ausgeführt werden kann. Nochmal zur Erinnerung, es geht um den Fall jQuery('<p></p>'), mit dem Ziel, ein einzelnes leeres Element ins DOM zu hängen. Ohne jQuery würde man die DOM-Funktion document.createElement('p') aufrufen. Aber oh Schreck, da sind gar keine spitzen Klammern drumherum und auch kein schließendes Tag. Diese zusätzlich zu notieren wäre sogar ein Fehler. Was macht ihr denn an der Stelle mit der ach so wichtigen Konsistenz? Jetzt kommt nicht mit der Ausrede "anderer Kontext", denn diesen anderen Kontext haben wir genauso bei jQuery('<p></p>').

Was ist mit einem Konstrukt wie jQuery('<script></script>');, wenn das innerhalb eines script-Bereiches in einem HTML-Dokument notiert ist? Das würde das ganze Vorhaben torpedieren, weil </script> vom Browser als vorzeitiges Ende des Scriptbereich interpretiert wird. Den Funktionsaufruf als jQuery('<script><\/script>'); zu schreiben, wie es syntaktisch notwendig ist, würde auch wieder die Konsistenz kaputtmachen.

Diese Ausnahmen muss man jetzt alle im Kopf behalten. Ich muss das immer und immer wieder nachschlagen. Nervt!

Ja, Ausnahmen gibt es überall. Wenn man die Konsistenz vorzieht, um sich keine Ausnahmen merken zu müssen, dann ist da für mich der Punkt erreicht, wo es gefährlich wird, weil man dann anfängt, die Stellen nicht mehr zu beachten, die notwendigerweise eine eigene Sonderbehandlung erfordern. Nicht immer melden sich solche Stellen einigermaßen auffällig mit Fehlermeldung wie das </script>-Beispiel. Unbemerkt schlummernde Lücken sind die eigentlichen Probleme falsch angewendeter Konsistenz.

Um es nochmal deutlich zu sagen, es geht mir nicht darum, die Konsistenz an sich zu verteufeln, sondern dann, wenn man sie als ein wohliges Ruhekissen ansieht, um sich Wissen und das Erinnern daran zu ersparen.

dedlfix.

[Nils-Hero]

Hallo dedlfix,

es geht mir nicht darum, die Konsistenz an sich zu verteufeln, sondern dann, wenn man sie als ein wohliges Ruhekissen ansieht, um sich Wissen und das Erinnern daran zu ersparen.

Genau das sollte Konsistenz bewirken, und das ist gut so! Gute Syntax kann man aus dem Bauch heraus nutzen. Schlechte muss man nachschlagen.

Es hat auch praktische Effekte, wenn Void element und öffnendes Tag anhand der Syntax unterschieden werden können.

Ich geb mal ein konkretes Beispiel, < sei das öffnende tag, > das schließende, . sei ein Void Element.

>>> import regex
>>> p = regex.compile(r'<(?R)*>|[.]')
>>> [m[0] for m in p.finditer('<.<<><.>>>',overlapped=True)]

['<.<<><.>>>', '.', '<<><.>>', '<>', '<.>', '.']

ich kann also aus einem wohlgeformten Dokument Elemente mittels regulären Ausdrücken nur anhand der Syntax herausfiltern, ohne prüfen zu müssen, welches konkrete Element ich gerade parse. Es ist Kontext-frei.

Wenn allerdings . und < je nach Kontext etwas anderes bedeuten, wie es in HTML 4 und HTML 5 der Fall ist und wenn > manchmal optional ist, und manchmal nicht, wie es bei HTML 5 der Fall ist, dann wird das ganze komplex.

Glücklicherweise erlaubt HTML 5 auch die saubere Schreibweise, <e>...</e> bzw. <e/> statt der kruden Schreibweise <e>... und <e>, und da man Input von außen sowieso säubert, hat es für fremden Quelltext keine praktische Relevanz, außer Performance-Verlusten.

Bleibt nur die Empfehlung, bei eigenem HTML nicht in solche Spielereien zu verfallen.

Gruß, Nils

[dedlfix]

Tach!

es geht mir nicht darum, die Konsistenz an sich zu verteufeln, sondern dann, wenn man sie als ein wohliges Ruhekissen ansieht, um sich Wissen und das Erinnern daran zu ersparen.

Genau das sollte Konsistenz bewirken, und das ist gut so! Gute Syntax kann man aus dem Bauch heraus nutzen. Schlechte muss man nachschlagen.

Das Problem ist nur, dass du die Unzulänglichkeiten und zu beachtenden Sonderfälle der Systeme, die du zu verwenden nicht umhinkommst, nicht vollständig mit eigener Konsistenz ausbügeln kannst. Deshalb sehe ich Konsistenz als nettes Beiwerk an, aber nicht als die Lösung der in der Realität vorhandenen Probleme.

dedlfix.

[Nils-Hero]

Hallo dedlfix,

Du sagst also, daß eine Sprache, die statt

foo(
    bar( /* Kommentar */
         baz('lorem')
    )
)

auch

foo(
    bar( /* Kommentar
        baz('lorem

erlaubt, elegant ist. Nun, ich bin da anderer Meinung. Ich liebe auch komprimierte Syntax, aber schließende Elemente sollten niemals optional sein. 'Hier endet etwas' ist eine wichtige Information. Da ist jede weitere Diskussion überflüssig. Da unterscheidet sich unser Weltbild zu sehr.

Gruß, Nils

[dedlfix]

Tach!

Du sagst also, daß eine Sprache, die statt [...] auch [...] erlaubt, elegant ist.

Nein, ich habe überhaupt keine Dinge bewertet. Meine Aussage sollte gewesen sein, dass eine persönlich zurechtgelegte Vereinfachung (unter dem Decknamen Konsistenz) nur teilweise die Notwendigkeiten der Realität erfüllen kann - egal wie man diese Realität empfindet.

dedlfix.

[Nils-Hero]

Hallo dedlfix,

Erstens, Du hast sie sehr wohl implizit bewertet, indem Du die Syntax unterstützt. Zweitens, diese Syntax ist keine Notwendigkeit der Realität. Sie ist ein Feature das nach hinten losgehen kann.

Gruß, Nils

[dedlfix]

Tach!

Erstens, Du hast sie sehr wohl implizit bewertet, indem Du die Syntax unterstützt.

Es ist mir egal, ob die Syntax anderswo so geschrieben werden muss. In dem konkreten Fall muss sie das nicht. Und dabei kommt es nicht darauf an, ob ich das gut finde oder nicht, sondern dass es keine Notwendigkeit gab, eine anderswo aufgestellte Regel an dieser Stelle ebenfalls konsequent einzuhalten, denn der Kontext ist nicht derselbe.

Zweitens, diese Syntax ist keine Notwendigkeit der Realität. Sie ist ein Feature das nach hinten losgehen kann.

Ich wüsste nicht wie das passieren sollte, außer man missachtet die tatsächliche Arbeitsweise von Systemen zugunsten einer selbst auferlegten Konsistenz.

dedlfix.

[Nils-Hero]

Hallo dedlfix,

Es ist mir egal, ob die Syntax anderswo so geschrieben werden muss. In dem konkreten Fall muss sie das nicht. Und dabei kommt es nicht darauf an, ob ich das gut finde oder nicht, sondern dass es keine Notwendigkeit gab, eine anderswo aufgestellte Regel an dieser Stelle ebenfalls konsequent einzuhalten, denn der Kontext ist nicht derselbe.

Es gab aber auch genau so keine Notwendigkeit, dieses Feature zu implementieren. Die Mehrzahl der Sprachen implementiert es aus unten genannten Gründen nicht. Und der relevante Kontext ist nicht anders.

Zweitens, diese Syntax ist keine Notwendigkeit der Realität. Sie ist ein Feature das nach hinten losgehen kann.

Ich wüsste nicht wie das passieren sollte, außer man missachtet die tatsächliche Arbeitsweise von Systemen zugunsten einer selbst auferlegten Konsistenz.

Ein Beispiel wo es Probleme macht habe ich bereits gegeben. Und Elemente, die sich scheinbar seltsam verhalten, weil ein schließendes Tag fälschlich weglassen wurde, hatten Wir auch schon in diesem Thread.

Ferner tust Du so als hätten Wir keine Wahl, welche Systeme Wir verwenden. Dem ist vielleicht so, wenn der Standard verabschiedet ist. Aber für das Design des nächsten Standards, HTML 6, können sich diese und ähnlich Diskussionen als relevant erweisen.

Gruß, Nils

[dedlfix]

Tach!

Ich wüsste nicht wie das passieren sollte, außer man missachtet die tatsächliche Arbeitsweise von Systemen zugunsten einer selbst auferlegten Konsistenz.

Ein Beispiel wo es Probleme macht habe ich bereits gegeben.

Es ist ja schön, wenn du ein System erstellen kannst, dass korrekt und in sich konsistent funktioniert, aber welche Relevanz hat das für Systeme, die andere geschrieben haben, die nach anderen Regeln funktionieren?

Und Elemente, die sich scheinbar seltsam verhalten, weil ein schließendes Tag fälschlich weglassen wurde, hatten Wir auch schon in diesem Thread.

Das ist eine Sache des Falschverstandenhabens aufgrund einer falschen Schlussfolgerung. Ich habe mich da auf die Arbeitsweise der jQuery-Funktion bezogen und der mathefritz hat das verallgemeinert. Sowas passiert halt, da helfen vereinfachende Konsistenzbemühungen auch nicht vollständig.

Und ich kann dir auch Beispiele geben, wo konsequent verwendete Dinge zu Lücken geführt haben, weil der Kontext unzureichend beachtet wurde, für den die Dinge wirksam sind. Namentlich: mysql_real_escape_string() für einen numerischen Wert, der nicht in Anführungszeichen notiert war. Konsistent, aber falsch. Regeln falsch angewendet statt zu wissen, was man damit erreicht.

Ferner tust Du so als hätten Wir keine Wahl, welche Systeme Wir verwenden.

Wir haben manchmal die Wahl, ob wie dieses oder jenes System verwenden. Und wir können auch versuchen, eins selbst zu erfinden. Aber das befreit uns noch lange nicht von der Tatsache, dass dieses System irgendwann irgendwo in Wechselbeziehungen zu anderen Systemen treten muss, deren Regeln zu beachten sind, unabhängig davon, wie wir die finden. Es sei denn, das System ist ein reines Gedankenspiel.

dedlfix.

[Nils-Hero]

Hallo dedlfix,

Nun ja, da der Gegenstand der Diskussion ein optionaler ist, verbleibe ich mit der Empfehlung <element>...</element> sowie <element/> zu schreiben und Du empfiehlst stattdessen eine genaue Lektüre des Manuals. Die zu wählende Methode liegt im Ermessen des Betrachters.

Gruß, Nils

[dedlfix]

Tach!

Nun ja, da der Gegenstand der Diskussion ein optionaler ist, verbleibe ich mit der Empfehlung <element>...</element> sowie <element/> zu schreiben und Du empfiehlst stattdessen eine genaue Lektüre des Manuals.

Um zu wissen, muss man erst das Handbuch glesen haben. Sonst ist es nur eine Vermutung.

Was ist so schlecht an Handbuch-Lektüre? Ich weiß, Ausprobieren ist einfacher.

dedlfix.

[Nils-Hero]

Hallo dedlfix,

Ich habe das Handbuch gelesen, dennoch mache ich mir das Leben nicht unnötig schwer, indem ich potentielle Fehlerquellen von vorneherein ausschalte.

Streng genommen schreibe ich überhaupt kein HTML, ich verwende natürlich einen Präprozessor. HTML von Hand zu schreiben ist schon etwas anachronistisch :-)

Gruß, Nils