Diese verfluchten div-Tags

[Nils]

und ich schon wieder mit einer kleinen angesammelten Fragestellung:

kennt jemand einen Link durch dessen Durcharbeiten ich zum Profi im Umgang mit div-Tags werde. Ich habe häufig wiederkehrende div-Tag-Probleme, die jedes Mal Stunden Arbeit zur Behebung erfordern...

Falls die Antwort ein html-Validator oder ein PHP-Debugger sein sollte, dann bitte direkt ein Tool empfehlen, da ich schon zig ausprobiert habe und keiner mir den erhofften Erfolg bot.

MFG
Nils

Linkback: https://www.modified-shop.org/forum/index.php?topic=32989.0

[Matt]

Die Antwort ist vielschichtig.

• Sauber arbeiten, Änderungen direkt prüfen, auch kleine Schritte. Dann fallen Fehler schneller auf.
• Editor nehmen, der Tags automatisch schließen kann. Sublime wäre da als Cross-Plattform-Editor zu nennen.
• Bei schließenden Tags notieren, was sie schließen (als Kommentar), vor allem wenn sie Tags schließen, die in einer anderen Datei geöffnet wurden.
• Nicht nur div verwenden, sondern semantisch bessere Tags. Unterschiedliche Tags legen nämlich ein unterschiedliches 'kaputt'-Verhalten an den Tag, wenn sie nicht richtig verschachtelt geschlossen wurden und Fehler lassen sich so schneller finden.
• Konsequent jeden Tag schließen, egal was die Spec sagt.

Und wenn ich noch länger drüber nachdenken würde würde mir noch mehr einfallen. Ein HTML Validator hat mir aber in den seltensten Fällen geholfen, einen nicht geschlossenen Tag zu finden.

[Nils]

Hi Matt,

Sauber arbeiten, Änderungen direkt prüfen, auch kleine Schritte. Dann fallen Fehler schneller auf.

Der Tipp kommt leider etwas zu spät 

Editor nehmen, der Tags automatisch schließen kann. Sublime wäre da als Cross-Plattform-Editor zu nennen.

Aber der macht das doch auch nur (wie so viele andere Editoren auch) für einzelne Dokumente ohne dass der gesamte Quelltext der dynamisch zusammengesetzten geprüft wird. Meine einzelnen Dokumente sind bezüglich geschlossener Tags ja weitgehend in Ordnung. Außerdem erkennen Editoren (oft oder (fast) immer) Smartys nicht, in denen bereits Tags eingeschlossen sein können... Ich glaub der erste Tipp von dir und Erfahrung sind die Lösung des Problems und vielleicht eine IDE, falls ich damit irgendwann mal umgehen kann.

vor allem wenn sie Tags schließen, die in einer anderen Datei geöffnet wurden.

Das dachte ich mir auch schon. Ich bin auch noch auf der Suche nach nem Skript oder so, welches mir (in unkomplizierter Weise) verrät, in welcher Reihenfolge die PHPs gestartet werden. Genügt dafür bereits die Zeitleiste der google Devs?

Nicht nur div verwenden, sondern semantisch bessere Tags. Unterschiedliche Tags legen nämlich ein unterschiedliches 'kaputt'-Verhalten an den Tag, wenn sie nicht richtig verschachtelt geschlossen wurden und Fehler lassen sich so schneller finden.

Ja, und wie ich lernen musste, scheinen divs von der ganz üblen Sorte zu sein. Aber dafür müsste man genauer wissen, wann man welche einsetzen darf/kann/sollte.

Konsequent jeden Tag schließen, egal was die Spec sagt.

Was ist Spec ? Meinst du in jeder Datei konsequent schließen oder unter Vernachlässigung der verschachtelten Tags?
Da kommt wieder das Problem, dass in Smartys manchmal bereits Tags enthalten sind und ich das oft dann nicht erkenne aus zu geringer Erfahrung.

MFG
Nils

[Matt]

Die Smarties, die Tags enthalten, sollten doch aber an einer Hand abzählbar sein.

Die Google Dev Tools verraten dir gar nichts darüber, wann welches php zum Einsatz kommt. Der Browser bekommt ja nur das fertige Ergebnis. Aber da das ganze ja linear abgearbeitet wird in so einem Template ist das ja doch relativ einfach nachzuvollziehen.

Spec = Spezifikation. HTML fällt ja nicht vom Himmel, schlaue Leute entwickeln sowas. Und da sind halt auch Tags vorgesehen, die nicht zwingend geschlossen sein müssen (<p> zum Beispiel). Es empfiehlt sich aber, es trotzdem zu tun.

[saithis]

Editor nehmen, der Tags automatisch schließen kann. Sublime wäre da als Cross-Plattform-Editor zu nennen.

Aber der macht das doch auch nur (wie so viele andere Editoren auch) für einzelne Dokumente ohne dass der gesamte Quelltext der dynamisch zusammengesetzten geprüft wird. Meine einzelnen Dokumente sind bezüglich geschlossener Tags ja weitgehend in Ordnung. Außerdem erkennen Editoren (oft oder (fast) immer) Smartys nicht, in denen bereits Tags eingeschlossen sein können... Ich glaub der erste Tipp von dir und Erfahrung sind die Lösung des Problems und vielleicht eine IDE, falls ich damit irgendwann mal umgehen kann.

vor allem wenn sie Tags schließen, die in einer anderen Datei geöffnet wurden.

Das dachte ich mir auch schon. Ich bin auch noch auf der Suche nach nem Skript oder so, welches mir (in unkomplizierter Weise) verrät, in welcher Reihenfolge die PHPs gestartet werden. Genügt dafür bereits die Zeitleiste der google Devs?

Mein Tipps wären hier:

• Tags immer in der gleichen Daten schließen, in der sie auch erstellt werden, das ist übersichtlicher und man verwirrt die IDE nicht.
• Wenn du Tags (z.B. <form>) von einer funktion generieren lässt, dann lass auch das close tag von einer funktion generieren. Oder noch besser: Nur die attribute des tags generieren lassen, dadurch kommt die IDE nicht so durcheinander.
• Bei komplett neuen Templates erst mal alles ohne Smarty schön hinbasteln und dann das Smarty einbauen wo nötig.
• Öfters mal den Seitenquelltext im Firefox anschauen. Alles was dort rot markiert wird, ist fehlerhaft. (z.B. fehlendes öffnendes/schließendes Tag)

Nicht nur div verwenden, sondern semantisch bessere Tags. Unterschiedliche Tags legen nämlich ein unterschiedliches 'kaputt'-Verhalten an den Tag, wenn sie nicht richtig verschachtelt geschlossen wurden und Fehler lassen sich so schneller finden.

Ja, und wie ich lernen musste, scheinen divs von der ganz üblen Sorte zu sein. Aber dafür müsste man genauer wissen, wann man welche einsetzen darf/kann/sollte.

Divs sind nicht übel, sie sind fürs Styling sogar die beste und richtigste wahl.
Divs verhalten sich semantisch neutral und werden von google und co behandelt als wären sie nicht da.
Nur wenn du zum Stylen ein inline Objekt brauchst, dann ist span besser, welches auch semantisch neutral ist.
Styling mit <table> wäre von der ganz üblen sorte. Das wäre nämlich semantisch falsch, macht die accessibility kaputt und ist schwerer in allen browsern gleich hinzubekommen.
Es ist auch immer besser ein ein semantisch neutrales tag zu nehmen, als ein sematisches falsch zu verwenden.

Konsequent jeden Tag schließen, egal was die Spec sagt.

Was ist Spec ? Meinst du in jeder Datei konsequent schließen oder unter Vernachlässigung der verschachtelten Tags?
Da kommt wieder das Problem, dass in Smartys manchmal bereits Tags enthalten sind und ich das oft dann nicht erkenne aus zu geringer Erfahrung.

MFG
Nils

Er meint du sollst alle Tags die du öffnest (z.B. <div>) auch wieder schließen (z.B. </div>).
Die Browser korrigieren das zwar oftmals richtig, wenn du es vergisst, aber manchmal passieren auch seltsame dinge, weil der browser es nicht richtig korrigiert hat.

Beispiel:
Hallo <div><span style="color:red;">schöne</div> Welt

Da würden die meisten Browser erkennen, das das </span> fehlt und es vor dem schließenden div hin machen, so das nur "schöne" rot ist. Sobald du aber das div außenrum weg machst ist "Welt" plötzlich auch rot.

Zusätzlich könntest du noch den Devs auf die Füße treten, das sie Twig support einbauen sollen. Twig ist auch eine Template Engine, die aber viel ausgereifter ist und für die es auch IDEs gibt, die dir bei den Templates helfen können.

Ich hab die Twig unterstützung sogar schon mal implementiert, aber die Devs haben sie bisher nicht übernommen.

[Nils]

Hallo,

@ Matt

Die Smarties, die Tags enthalten, sollten doch aber an einer Hand abzählbar sein.

Dann schieß mal los 

Die Google Dev Tools verraten dir gar nichts darüber, wann welches php zum Einsatz kommt.

Kann man da nicht z.B. in FirePHP irgendwelchen Code integrieren, damit Firebug/Firephp das macht?

Spec = Spezifikation. HTML fällt ja nicht vom Himmel, schlaue Leute entwickeln sowas. Und da sind halt auch Tags vorgesehen, die nicht zwingend geschlossen sein müssen (<p> zum Beispiel). Es empfiehlt sich aber, es trotzdem zu tun.

Aber oftmals funktionieren Tags wie p und span nicht in Fällen, in denen das div-Tag dann aber doch funktioniert.

@ saithis

Danke für die Tipps!!

Tags immer in der gleichen Daten schließen, in der sie auch erstellt werden

good idea!

und man verwirrt die IDE

na gut, mit IDEs stehe ich sowieso auf Kriegspfad, weil die Einrichtung einer IDE bisher nie ohne Probleme bei mir geklappt hat. Daher nutze ich keine.

Wenn du Tags (z.B. <form>) von einer funktion generieren lässt, dann lass auch das close tag von einer funktion generieren. Oder noch besser: Nur die attribute des tags generieren lassen, dadurch kommt die IDE nicht so durcheinander.

Kapier ich nicht...

Bei komplett neuen Templates erst mal alles ohne Smarty schön hinbasteln und dann das Smarty einbauen wo nötig.

Ich nutze eigentlich nur die standardmäßig vorhandenen Smarties, da ich auch hiermit auf Kriegspfad stehe (leider - ich bin derzeit mental nicht in der Lage, mich so auf Neues einzulassen...).

 

Öfters mal den Seitenquelltext im Firefox anschauen. Alles was dort rot markiert wird, ist fehlerhaft. (z.B. fehlendes öffnendes/schließendes Tag)

Wirklich alles???

Divs sind nicht übel, sie sind fürs Styling sogar die beste und richtigste wahl.

Mittlerweile versehe ich jedes Tag (in Problemdateien) mit "border:5px solid irgendeine Farbe", damit ich besser mit denen klar komme. So geht es schon ganz gut.

Divs verhalten sich semantisch neutral

Soll das u.a. heißen, dass sie auch auf unterschiedlichen Geräten gleich erscheinen?

Nur wenn du zum Stylen ein inline Objekt brauchst, dann ist span besser,

...wird aber leider nicht immer "angenommen"...

Styling mit <table> wäre von der ganz üblen sorte.

Und wieso ist dann bereits im Standard-Template so oft mit table gestylt?
Könntest du vielleicht mal einen Blick auf meine website werfen?
Es geht um die Artikelbeschreibungen. Diese habe ich in Tabellenform angelegt.
Sind diese auch ungeeignet bzw. sollte ich die irgendwie ersetzen?
Oder ist das für den Zweck in Ordnung?
Meine website URL lautet baueinheiten.de und den user-name und das passwort würde ich dir dann in einer privaten Nachricht zukommen lassen, falls du Zeit/Lust dazu hast.

Es ist auch immer besser ein ein semantisch neutrales tag zu nehmen, als ein sematisches falsch zu verwenden.

Hättest du zu dem Thema vielleicht einen link, der das knapp erklärt (nicht zu umfangreich oder kompliziert bitte wegen der oben erwähnten Mentalproblematik derzeit...)

Er meint du sollst alle Tags die du öffnest (z.B. <div>) auch wieder schließen (z.B. </div>).

Aber es wäre ok, wenn ich das für jede Datei einzeln mache und so nach und nach das Gesamtbild bzw. das dynamisch generierte HTML-Endergebnis nach und nach korrigiert wird, anstatt dass ich nun zwanghaft versuche, die einzelnen Fehler im Quelltext des HTML-Ergebisses zu korrigieren und dabei woanders scheinbare Fehler auftauchen?

Zusätzlich könntest du noch den Devs auf die Füße treten, das sie Twig support einbauen sollen.

Verstehe ich nicht.?...

Bis bald.

MFG
Nils

[Matt]

Die Smarties, die Tags enthalten, sollten doch aber an einer Hand abzählbar sein.

Dann schieß mal los 

Aus dem Kopf bekomm ich die auch nicht zusammen.

Kann man da nicht z.B. in FirePHP irgendwelchen Code integrieren, damit Firebug/Firephp das macht?

Nein, weil FirePHP dir nur hilft wenn du was per AJAX lädst.

Spec = Spezifikation. HTML fällt ja nicht vom Himmel, schlaue Leute entwickeln sowas. Und da sind halt auch Tags vorgesehen, die nicht zwingend geschlossen sein müssen (<p> zum Beispiel). Es empfiehlt sich aber, es trotzdem zu tun.

Aber oftmals funktionieren Tags wie p und span nicht in Fällen, in denen das div-Tag dann aber doch funktioniert.

Wann funktioniert denn ein Tag und wann nicht? Es gibt bestimmte Verschaltelungskombinationen, die nicht möglich sind, aber ich glaube eher, du stolperst hier über block-level Elemente und inline-Elemente. Das ist aber jeweils nur ihr Default-Verhalten, beide kann man mit CSS jeweils in die andere Kategorie verfrachten.

Wenn du Tags (z.B. <form>) von einer funktion generieren lässt, dann lass auch das close tag von einer funktion generieren. Oder noch besser: Nur die attribute des tags generieren lassen, dadurch kommt die IDE nicht so durcheinander.

Kapier ich nicht...

Nimm beispielsweise templates/xtc5/account_newsletter.html. Da wird das Form durch {$FORM_ACTION} geöffnet. Jetzt dieses mit </form> zu schließen bringt den Editor (muss ja nicht gleich ne IDE sein, ich nutze auch keine) u.U. aus dem Tritt. Deshalb wird {$FORM_END} benutzt.

Divs verhalten sich semantisch neutral

Soll das u.a. heißen, dass sie auch auf unterschiedlichen Geräten gleich erscheinen?

Nein, soll es nicht. Link zum Thema: https://developer.mozilla.org/de/docs/Web/HTML/HTML5/HTML5_element_list

Nur wenn du zum Stylen ein inline Objekt brauchst, dann ist span besser,

...wird aber leider nicht immer "angenommen"...

Siehe oben.

Styling mit <table> wäre von der ganz üblen sorte.

Und wieso ist dann bereits im Standard-Template so oft mit table gestylt?

Weil. Die Antwort auf deine Frage ist weil.

Es geht um die Artikelbeschreibungen. Diese habe ich in Tabellenform angelegt.

Das halte ich in dem Fall für ok (es kommt immer etwas auf das persönliche Verhältnis zu <dl>, <dt> und <dd> an). Beim Liveshopping ist es das meiner Meinung nach schon nicht mehr.

Zusätzlich könntest du noch den Devs auf die Füße treten, das sie Twig support einbauen sollen.

Verstehe ich nicht.?...

Andere Template-Engine. Statt {if} ist es dann {% if %}, statt {$variable} ist es {{variable}}. Löst deine Probleme auch nicht.

[saithis]

und man verwirrt die IDE

na gut, mit IDEs stehe ich sowieso auf Kriegspfad, weil die Einrichtung einer IDE bisher nie ohne Probleme bei mir geklappt hat. Daher nutze ich keine.

Sind aber extrem praktisch.
Für PHP, HTML und CSS ist PhpStorm die beste IDE.
Es gibt auch noch Webstorm, das ist PhpStorm ohne den PHP Teil.

Von den kostenlosen ist denk ich Netbeans die beste.
Kommt aber bei weitem nicht an PhpStorm ran.

Wenn du Tags (z.B. <form>) von einer funktion generieren lässt, dann lass auch das close tag von einer funktion generieren. Oder noch besser: Nur die attribute des tags generieren lassen, dadurch kommt die IDE nicht so durcheinander.

Kapier ich nicht...

Nimm beispielsweise templates/xtc5/account_newsletter.html. Da wird das Form durch {$FORM_ACTION} geöffnet. Jetzt dieses mit </form> zu schließen bringt den Editor (muss ja nicht gleich ne IDE sein, ich nutze auch keine) u.U. aus dem Tritt. Deshalb wird {$FORM_END} benutzt.

Noch etwas besser wäre da eben sowas wie: <form {$FORM_ATTRIBUTES}></form>
Dann könntest du nämlich im Template selber noch Attribute (z.B. class="") hinzufügen.
Aber dazu müsstest du den PHP Code anpassen.

Öfters mal den Seitenquelltext im Firefox anschauen. Alles was dort rot markiert wird, ist fehlerhaft. (z.B. fehlendes öffnendes/schließendes Tag)

Wirklich alles???

Ja, alles was Rot ist. (Es gibt auch noch Orange, das kannst du ignorieren)

Zusätzlich könntest du noch den Devs auf die Füße treten, das sie Twig support einbauen sollen.

Verstehe ich nicht.?...

Andere Template-Engine. Statt {if} ist es dann {% if %}, statt {$variable} ist es {{variable}}. Löst deine Probleme auch nicht.

Twig wird von mehr IDEs unterstützt, dadurch ist es leichter zu schreiben (wenn man so eine IDE nutzt).
Die restlichen Vorteile von Twig sind für dieses Thema hier in der Tat irrelevant.

Auf den Rest hat dir ja Matt schon (hoffentlich gut genug) geantwortet.

[Nils]

Hallo,

@ Matt

Abgesehen davon hat der Shop schon eine Struktur, nur dass es keine einheitliche Code-Designrichtlinie für den Shop gibt. Mit 2.0 hat sich da einiges getan, aber die Altlasten wird man so ohne weiteres nur Stück für Stück los.

Stimmt, das war ein Problem. Das hab ich mittlerweile begriffen.

Nimm beispielsweise templates/xtc5/account_newsletter.html. Da wird das Form durch {$FORM_ACTION} geöffnet. Jetzt dieses mit </form> zu schließen bringt den Editor (muss ja nicht gleich ne IDE sein, ich nutze auch keine) u.U. aus dem Tritt. Deshalb wird {$FORM_END} benutzt.

klingt interessant. Muss ich mich mal reinfuchsen.

Weil. Die Antwort auf deine Frage ist weil.

Das heisst soviel, wie "da geb ich dir recht..., oder?"

Du kennst ja meine Seite. Und bei den Bauteilen werden ja die ganzen Eigenschaften tabellarisch aufgeführt. Für sowas "darf" und für die Auflistung der verschiedenen erhältlichen Varianten darf man Tabellen doch aber verwenden, nicht wahr? (siehe Abbildungen im Anhang als Beispiel)

ups, das hast du schon teilweise beantwortet. Ist es auch für Attribute in der Optionsauswahl in Ordnung (siehe Anhang)

Das halte ich in dem Fall für ok (es kommt immer etwas auf das persönliche Verhältnis zu <dl>, <dt> und <dd> an). Beim Liveshopping ist es das meiner Meinung nach schon nicht mehr.

<dl> <dt> und <dd> mag ich nicht 

LiveShopping hab ich auch eingedivt !

Das halte ich in dem Fall für ok

Aber wieso eigentlich nur ok? Es sind doch die typischen Daten, die man tabellarisch auflistet. Dafür werden doch auch heutzutage noch normale Tabellen empfohlen, oder irre ich da?

Andere Template-Engine. Statt {if} ist es dann {% if %}, statt {$variable} ist es {{variable}}.

Und wozu das Ganze? Ist mir zu hoch. Brauchst mir nicht erklären. Ich muss erstmal mit den Smartys klarkommen, bevor ich weiteres Terrain erforsche...

@ saithis

Dir antworte ich gleich in einer separaten Nachricht.

MFG
Nils

[Nils]

@ saithis

Hallo,

Um IDEs zu verstehen, müsste ich wahrscheinlich bei nem erfahrenen Entwickler eine Weile über die Schulter schauen, da ich sonst immer an Kleinigkeiten Tage an Zeit verliere, weil ich das Problem habe, bei Problem(ch)en "aufzugeben"...

Kann man PhpStorm eine Weile testen? Oder ist das so preiswert, dass mans auch gleich kaufen kann?
Ich schaue aber gleich auch selbst mal online nach bzgl. Thema PhpStorm. Hab davon jetzt schon häufiger gehört. Vielleicht lohnt es sich ja.

Ja, alles was Rot ist

Dann haben aber auch ziemlich viele größere Webauftritte arge Probleme!

MFG
Nils

[Matt]

Weil. Die Antwort auf deine Frage ist weil.

Das heisst soviel, wie "da geb ich dir recht..., oder?"

Heißt soviel wie: Macht halt keiner. Geht ja auch so. Und außer dem Matt stört sich auch keiner dran.

Du kennst ja meine Seite. Und bei den Bauteilen werden ja die ganzen Eigenschaften tabellarisch aufgeführt. Für sowas "darf" und für die Auflistung der verschiedenen erhältlichen Varianten darf man Tabellen doch aber verwenden, nicht wahr? (siehe Abbildungen im Anhang als Beispiel)

Natürlich.

Das halte ich in dem Fall für ok

Aber wieso eigentlich nur ok?

Wenn du in Richtung responsive gehst machen dir die Tabellen an der Stelle nur Probleme. Also nimmt man sie lieber nicht.

[Nils]

Heißt soviel wie: Macht halt keiner. Geht ja auch so. Und außer dem Matt stört sich auch keiner dran.

komisch. Mir kommt es so vor, als würde es jeden stören und als wäre es nicht mehr weit, dass man dafür in die Hölle kommen wird 
und nun sagst du sowas? Aber ich glaubs dir, wenn du das sagst. Letztlich kann es aber anscheinend nie schaden, vollständig auf normale Tabellen zu verzichten - so wie ich das sehe...

MFG
Nils

[Matt]

Wenn du wirklich tabellarischen Inhalt hast nimm Tabellen. Mach ich auch so (http://www.erzgebirge-palast.de/Schwibboegen/Laubsaegearbeiten/3D-Schwibbogen-Schwibbogenwerkstatt-43x30x7cm::8077.html#tab-information im Tab Details).

[Nils]

Aber was ist mit deinem resonsive-template-Argument?

Ich habe deine Seite gerade mal aufgerufen und ein Problem entdeckt!
Wenn man ran- und wegzoomt, verschiebt sich die Tabelle an einen anderen Ort!

MFG
Nils

[Matt]

Also bei mir bleibt sie da wo sie soll. Sowohl in Firefox als auch in Chrome.

Es ist ja nicht so, dass man Tabellen nicht responsive bekommt:
http://blog.kulturbanause.de/2012/06/tabellen-im-responsive-webdesign/
Es ist halt so, dass man deutlich mehr Aufwand reinstecken muss als wenn man ein paar div-Tags neu floated.