HTML-Code einrücken?
0 0 0 0 0 0 0 
dedlfix
0 0 0 0 
Gunnar Bittersmann
0 0 dedlfix
0 dedlfix
0
HTML-Code einrücken?
Hallo,
rückt man HTML-Code ein oder nicht?
Was meint ihr?
Wie sieht eurer Meinug nach schöner HTML-Code aus?
Beispiel1:
*
<html>
<head>
<title>Titel</title>
</head>
</body>
</html>
*
Beispiel2:
*
<html>
<head>
<title>Titel</title>
</head>
</body>
</html>
*
Und macht man eurer Meinung nach zwischen öffnendem div-Tag und Inhalt einen Umbruch?
<div>
Text
</div>
oder eben
<div>Text</div>
Was würdet ihr in dem Fall machen, wenn in dem div nur ein img ist?
<div><img></div> ???
Und bricht man eurer Meinug nach lange Zeilen um?
Gruß
-
Hi,
rückt man HTML-Code ein oder nicht?
grundsätzlich: ja!
Und macht man eurer Meinung nach zwischen öffnendem div-Tag und Inhalt einen Umbruch?
<div>
Text
</div>oder eben
<div>Text</div>
bei so kleinen Dingen, wäre das untere OK.
Aber es gibt ja kein Gesetz, wie Du das machen mußt.
Das wichtige ist, daß man eine Struktur erkennt.Jeder macht das sicher etwas anders.
Z.B. bevorzugen viele solche Schreibweisen:if ($a == 1){
machwas....
}ich persönlich bevorzuge:
if ($a == 1)
{
machwas....
}d.h. es ist beides richtig, nur in meiner Version sehe ich direkt bei großen Codeblöcken, wo die Klammer anfängt.
Was würdet ihr in dem Fall machen, wenn in dem div nur ein img ist?
<div><img></div> ???genau so würde ich die Zeile lassen. Aber da hinter "img" ja sicher noch "src=..." kommt und das länger werden kann, würde ich es dann doch über drei Zeilen verteilen.
Und bricht man eurer Meinug nach lange Zeilen um?
Jein! Bei Text, der dargestellt werden soll: ja
Ansonsten überlassen ich es dem Editor.Gruß
Reiner-
Hi,
rückt man HTML-Code ein oder nicht?
grundsätzlich: ja!ACK.
<div>Text</div>
bei so kleinen Dingen, wäre das untere OK.Ebenfalls. Meine Faustregel lautet: Wenn nur ein Element bzw. einzeiliger Text drin ist, dann schreibe alles in eine Zeile. Abweichungen existieren, wie bei jeder Faustregel.
Z.B. bevorzugen viele solche Schreibweisen:
if ($a == 1){
machwas....
}Nö, aber:
if ($a == 1) {
machwas ...
}if ($a == 1)
{
d.h. es ist beides richtig, nur in meiner Version sehe ich direkt bei großen Codeblöcken, wo die Klammer anfängt.Bei obiger Version sehe ich das auch, aber vor allem sehe ich sofort, um _was_ für einen Block es sich handelt. Bei der Schreibweise, die öffnende Klammer in eine neue Zeile zu packen, gelingt mir das nicht. Der Quintessenz stimme ich zu: Fast alles ist richtig, vieles ist sinnvoll, wenig ist zwingend. Welchen Stil man verwendet hängt in erster Linie davon ab, wer alles mit dem Code klar kommen muss. So war es bisher in jedem größeren Team, in dem ich gearbeitet habe, absolute Pflicht, die öffnende Klammer in der Block-eröffnenden Zeile zu lassen ;-)
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes
-
-
rückt man HTML-Code ein oder nicht?
Kann man theoretisch machen, wie man will. Nur sollte man einheitlich bleiben.
Wie sieht eurer Meinug nach schöner HTML-Code aus?
Eingerückt ist in jedem Fall schöner und übersichtlicher.
Und macht man eurer Meinung nach zwischen öffnendem div-Tag und Inhalt einen Umbruch?
Das hängt teilweise von der Menge des Textes ab. Ich bevorzuge normalerweise:
<div>
Text
</div>Was würdet ihr in dem Fall machen, wenn in dem div nur ein img ist?
<div><img></div> ???<div>
<img/>
</div>Und bricht man eurer Meinug nach lange Zeilen um?
Nein, das macht mein Editor automatisch wenn ich es will.
Ich persönlich lasse meinen Quellcode ständig von "Tidy" aufräumen. Tidy erstellt automatisch Einrückungen und Umbrüche (wenn ich will) und überprüft den Quellcode gleich nebenbei. Echt praktisch.
MfG Jonathan
-
Hallo Jonathan!
Tidy erstellt automatisch Einrückungen und Umbrüche (wenn ich will) und überprüft den Quellcode gleich nebenbei. Echt praktisch.
Um Gottes Willen! Die automatischen Umbrüche à la Tidy hatten mich beim einen Job für den SELF-Raum fast zum Wahnsinn gebracht. Umbruch zwischen a und href, zwischen img und src oder zw. weiteren Attributen zum Beispiel, gerade wo und wie es Tidy passte. Ich musste damals den HTML-Code hunderter von Dateien auf bestimmte Inhalte durchsuchen, diese waren vorher mit Tidy bearbeitet worden....
Seit dem schreibe ich alles (1) in einer Zeile, wenn ich einen Umbruch sehen will, dafür ist mein Editor da.
(1) allerdings nicht wie hier im Quelltext: http://www.editpad.de/editpadlite.html ;)
Thema Einrückungen... naja, ich habe Quelltext gesehen, da musste man ellenlang horizontal scrollen. Auch nicht gerade übersichtlich. Wenn man im Editor den Zeilenumbruch aktiviert hatte, war es auch nicht mehr schön. Also, wenn schon Einrückungen, maximal 2 oder 3 Leerzeichen!
<div>
Text
</div>Viele Grüße aus Frankfurt/Main,
Patrick--
_ - jenseits vom delirium - _
<hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash>-
Um Gottes Willen! Die automatischen Umbrüche à la Tidy hatten mich beim einen Job für den SELF-Raum fast zum Wahnsinn gebracht. Umbruch zwischen a und href, zwischen img und src oder zw. weiteren Attributen zum Beispiel, gerade wo und wie es Tidy passte. Ich musste damals den HTML-Code hunderter von Dateien auf bestimmte Inhalte durchsuchen, diese waren vorher mit Tidy bearbeitet worden....
Tidy kann selbstverständlich auch alle Umbrüche (wieder) entfernen. Zudem ist Tidy recht kofigurierbar. Ich sehe das Problem nicht wirklich.
mfG Jonathan
-
Hallo Jonathan!
Tidy kann selbstverständlich auch alle Umbrüche (wieder) entfernen. Zudem ist Tidy recht kofigurierbar. Ich sehe das Problem nicht wirklich.
Ich will Deine Begeisterung nicht schmälern, jeder schwärmt für was er toll findet, nur hatte ich damals Tidy nicht. Ich pers. brauche und habe es bis heute nicht, ich code auf einem Editor zwar mit einigen Features, der hat aber noch nicht mal Syntaxhighlighting. Und da ich alles vom lokalen Webserver teste, ist eine Validierung kein Problem (DynDNS-Domain) ;)
Das Problem war damals einfach (2000 oder 2001 war das), dass meine Suchstrings nicht gematscht haben, weil eben überall diese unmöglichem Umbrüche waren.
Viele Grüße aus Frankfurt/Main,
Patrick--
_ - jenseits vom delirium - _
<hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash>-
Hallo,
Ich will Deine Begeisterung nicht schmälern, jeder schwärmt für was er toll findet, nur hatte ich damals Tidy nicht. Ich pers. brauche und habe es bis heute nicht, ich code auf einem Editor zwar mit einigen Features, der hat aber noch nicht mal Syntaxhighlighting. Und da ich alles vom lokalen Webserver teste, ist eine Validierung kein Problem (DynDNS-Domain) ;)
Das Problem war damals einfach (2000 oder 2001 war das), dass meine Suchstrings nicht gematscht haben, weil eben überall diese unmöglichem Umbrüche waren.
Ich sehe ja durchaus dein Problem, aber nur weil du ein durch Tidy "verwurstetes" Dokumen bearbeiten musstest, heißt das ja nicht das Tidy schlecht ist. Ich kann mit jedem Editor totalen Müll-Code erstellen, das heißt dann ja auch nicht, dass der Editor dann schlecht ist.
Und um die Zeilenumbrüche beim Suchen zu ignorieren hättest du ja auch einfache Reg. Ausdrücke nehmen können. Sowas wie /<img\s+scr="blah"\s+.*//?>/ (jetzt mal ganz primitiv)
-
-
-
-
-
Hello,
bei allen Elementen geht das nicht. Bei Blockelementen, die nicht direkt Daten enthalten drfen, sondern erst noch weitere Elemente, mache ie es immer. Das Blockelement selber darf auch eingerückt werden und es darf davor und danach eine Leerzeile stehen.
<table>
<tr>
<td>Daten</td>
</tr>
</table>Kritisch ist es bei Datenelementen
<td>
Daten
</td>kan unangenehme Folgen haben, speziell dann, wenn man nicht weiß, was in "Daten" mal drinstehen wird. Das passiert schließlich bei Generiertem HTML-Code (aus CMS oder PHP, Perl, ...) ständig.
Spannender ist für mich immer die Frage, wie weit ich einrücken muss, wenn ich den Code generieren lasse. Da habe ich noch kein Rezept gefunden, wie das Script "wissen" kann, in welcher Spalte es beginnen soll.
Man müsste praktisch den Parser oder Validator "rückwärts" nachbauen. :-)
Harzliche Grüße vom Berg
http://www.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Kritisch ist es bei Datenelementen
<td>
Daten
</td>kan unangenehme Folgen haben, speziell dann, wenn man nicht weiß, was in "Daten" mal drinstehen wird.
Nö, eigentlich nicht, sofern du kein whitespace:pre benutzt.
Spannender ist für mich immer die Frage, wie weit ich einrücken muss, wenn ich den Code generieren lasse. Da habe ich noch kein Rezept gefunden, wie das Script "wissen" kann, in welcher Spalte es beginnen soll.
Man müsste praktisch den Parser oder Validator "rückwärts" nachbauen. :-)
Du kannst den ganzen generierten Code z.B. durch Tidy jagen, wie es die Wikipedia <del>macht</del> <ins>meines Wissens mal gemacht hat</ins>. Dann hast du automatisch eingerückten Code, egal was für nen Mist du generierst.
-
Hello,
Kritisch ist es bei Datenelementen
<td>
Daten
</td>kan unangenehme Folgen haben, speziell dann, wenn man nicht weiß, was in "Daten" mal drinstehen wird.
Nö, eigentlich nicht, sofern du kein whitespace:pre benutzt.
Eigentlich doch!
Ein Besipiel steht doch oben. Hast Du es nicht gesehen? :-)
Ein weiteres hat Dedlfix eben genannt. https://forum.selfhtml.org/?t=150318&m=976810Harzliche Grüße vom Berg
http://www.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Eigentlich doch!
Ein Besipiel steht doch oben. Hast Du es nicht gesehen? :-)Nein. Welches Beispiel?
Ein weiteres hat Dedlfix eben genannt. https://forum.selfhtml.org/?t=150318&m=976810
Da gehts aber nur um ne IE-Macke (die ich im übrigen nicht nachvollziehen kann. Noch nie Probleme mit solchen verlinkten Bildern gehabt. Obwohl ich alles einrücke.)
-
echo $begrüßung;
Ein weiteres hat Dedlfix eben genannt. https://forum.selfhtml.org/?t=150318&m=976810
Da gehts aber nur um ne IE-Macke (die ich im übrigen nicht nachvollziehen kann. Noch nie Probleme mit solchen verlinkten Bildern gehabt. Obwohl ich alles einrücke.)Sind bei dir Links unterstrichen? Wenn nicht, fällt es dir vielleicht auch nicht auf. Man kann es dann am gepunkteten Link-Rahmen erkennen, der dann rechts unten einen Bogen schlägt.
echo "$verabschiedung $name";
-
Sind bei dir Links unterstrichen? Wenn nicht, fällt es dir vielleicht auch nicht auf. Man kann es dann am gepunkteten Link-Rahmen erkennen, der dann rechts unten einen Bogen schlägt.
Schlag mich bitte nicht, aber ich kann das beschriebene Verhalten nur erzeugen, wenn ich explizit ein einfüge.
Ich habe z.B. folgendes:
<a href="konqueror.htm">
<img src="images/konqueror16.png" alt="Konqueror:" title=
"Konqueror" height="16" width="16" />
</a>und nix passiert im IE (weder 7 noch 6). Links sind selbstversändlich unterstrichen.
-
Hello,
Schlag mich bitte nicht, aber ich kann das beschriebene Verhalten nur erzeugen, wenn ich explizit ein einfüge.
Das ist doch eigentlich ganz egal, was DU nachvollziehen kannst.
Es gibt genügend User, die noch Browser benutzen, die diese Probleme machen.
Da man die ohne Aufwand aber vermeiden kann, sehe ich nicht ein, warum man es unterlassen sollte.Harzliche Grüße vom Berg
http://www.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Das ist doch eigentlich ganz egal, was DU nachvollziehen kannst.
Es gibt genügend User, die noch Browser benutzen, die diese Probleme machen.
Da man die ohne Aufwand aber vermeiden kann, sehe ich nicht ein, warum man es unterlassen sollte.Sehe ich durchaus ein, aber wenn ich ein Problem nicht reproduzieren kann, wie soll ich dann dadrauf Rücksicht nehmen?
Andererseits ist es mir auch egal. Private Webseiten programmiere ich eh nur noch so, dass die in IE6 benutzbar sind und nicht ganz schrecklich aussehen, aber auf kleinere Darstellungsfehler wie Linien nach Links würde ich sowieso keine größere Rücksicht nehmen, selbst wenn die reproduzierbar wären. Von mir aus sollen die IE-Benutzer ruhig mitkriegen, was für einen misgestalteten Browser die benutzen.
-
Hallo Jonathan.
Das ist doch eigentlich ganz egal, was DU nachvollziehen kannst.
Es gibt genügend User, die noch Browser benutzen, die diese Probleme machen.
Da man die ohne Aufwand aber vermeiden kann, sehe ich nicht ein, warum man es unterlassen sollte.Sehe ich durchaus ein, aber wenn ich ein Problem nicht reproduzieren kann, wie soll ich dann dadrauf Rücksicht nehmen?
Befolge einfach die Hinweise und Tipps. Schließlich kannst du ja sicher auch kaum nachvollziehen, wie ein Blinder deine Site sieht (pun not intended) und dennoch versuchst du (hoffentlich) sie barrierearm zu halten.
Einen schönen Donnerstag noch.
Gruß, Mathias
--
ie:% fl:| br:< va:) ls:& fo:) rl:( n4:~ ss:) de:] js:| mo:| zu:)
debian/rules
-
-
-
-
-
-
-
-
Hi,
Spannender ist für mich immer die Frage, wie weit ich einrücken muss, wenn ich den Code generieren lasse.
dieses Problem betrachte ich als vollständig gelöst. In Einklang mit fast allen mir bekannten Styleguides, gängiger Praxis und persönlicher Erfahrung lautet die Regel: Exakt vier Leerzeichen pro Ebene, und *NIEMALS* Tabulatoren verwenden.
Ausnahmen für das "niemals" sind natürlich technische Bedingungen wie sie z.B. bei Makefiles gelten.
Da habe ich noch kein Rezept gefunden, wie das Script "wissen" kann, in welcher Spalte es beginnen soll.
Entweder ist die vorherige Zeile (und damit auch ihre Einrückung, also Ebenentiefe) bekannt, oder es wird bei Ebene 0 (bzw. n, welches beliebig, aber fest ist) begonnen. Generierter Code erhebt nur dann die Ansprüche auf Menschenlesbarkeit, wenn er anschließend von Menschen weiterverarbeitet werden soll. Für die Wartung ist m.E. lediglich sinnvollerweise nötig, dass jede einzelne Ebene _in sich_ konsistent ist, also dass Start- und End-Tag gleich weit eingerückt sind. Alles weitere halte ich ganz klar für übertrieben.
Man müsste praktisch den Parser oder Validator "rückwärts" nachbauen. :-)
Viel Spaß ;-)
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
dieses Problem betrachte ich als vollständig gelöst. In Einklang mit fast allen mir bekannten Styleguides, gängiger Praxis und persönlicher Erfahrung lautet die Regel: Exakt vier Leerzeichen pro Ebene, und *NIEMALS* Tabulatoren verwenden.
Warum niemals Tabulatoren?
Entweder ist die vorherige Zeile (und damit auch ihre Einrückung, also Ebenentiefe) bekannt, oder es wird bei Ebene 0 (bzw. n, welches beliebig, aber fest ist) begonnen.
Und wie macht man die Ebene der vorherigen Zeile dem Scipt bekannt?
Gruß
-
Hello,
Spannender ist für mich immer die Frage, wie weit ich einrücken muss, wenn ich den Code generieren lasse.
Das sollte ich vielleicht bei Funktionen einstellbar machen.
Ich selber rücke z.B. immer nur zwei Zeichen ein. Das stammt noch aus der Zeit, als Bildschirme nicht seitlich scrollen konnten ;-)
Aber jemand, der das richtig[tm] machen will, besteht vielleicht auf den 4 Spalten.Da habe ich noch kein Rezept gefunden, wie das Script "wissen" kann, in welcher Spalte es beginnen soll.
Entweder ist die vorherige Zeile (und damit auch ihre Einrückung, also Ebenentiefe) bekannt, oder es wird bei Ebene 0 (bzw. n, welches beliebig, aber fest ist) begonnen. Generierter Code erhebt nur dann die Ansprüche auf Menschenlesbarkeit, wenn er anschließend von Menschen weiterverarbeitet werden soll. Für die Wartung ist m.E. lediglich sinnvollerweise nötig, dass jede einzelne Ebene _in sich_ konsistent ist, also dass Start- und End-Tag gleich weit eingerückt sind. Alles weitere halte ich ganz klar für übertrieben.
Man müsste praktisch den Parser oder Validator "rückwärts" nachbauen. :-)
Viel Spaß ;-)
Andere Idee:
Man gibt den Funktionen die aktuelle Spalte als Referenz mit.
Die Funktion selber (z.B. "make_table()" ) weiß ja, wann sie um wieviele Zeichen einrücken musss, relativ zum Beginn. Da muss sie dann also immer nur "$spalte = $spalte + DIFF" und am Ende wieder "$spalte = $spalte - DIFF" rechnen. Bounds sollte man vielleicht sicherheitshalber noch kontrollieren und ggf. richtigstellen. Negative Einrückungen (also vor dem linken Rand des Scriptes) machen sich vielleicht nicht so gut.Nun die Frage für den Elefanten ...
Sollte man den Wert einfach in $GLOBALS speichern, oder sollte man tatsächlich einen Referenz-Attribut mitschleppen bei jeder Generator-Funktion? Kann es einen Grund geben, mehrere Outputs innerhalb eines Scriptes zu berechnen? Dateiausgabe, Standardausgabe, zwei Frames *g* ?
Da bleibt dann wahrscheinlich ohnehin nur die objektorientierte Aufbereitung.
Ich hätte es aber gerne auch ohne gelöst.Harzliche Grüße vom Berg
http://www.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hi,
Bound??? *schäm_für_fehlendes_buzzword-wissen*
Das mit dem Parameter ist schon nicht schlecht (mache ich wenn ich dran denke so) ist aber manchmal nervig.
Irgendwie müsste es da eine Lösung geben...?
Gruß
-
Tach.
Bound??? *schäm_für_fehlendes_buzzword-wissen*
Ich glaube, daß war eher Toms Fehler. Vermutlich wollte er eigentlich die "Bounds checken" und ggf. "fixen". ;)
--
Once is a mistake, twice is jazz.
-
-
Tach.
Sollte man den Wert einfach in $GLOBALS speichern, oder sollte man tatsächlich einen Referenz-Attribut mitschleppen bei jeder Generator-Funktion?
Weder noch. Dieser ganze Aufwand ist völlig überflüssig, weil es den Parser nicht die Bohne interessiert, ob du deine Zeilen nun schick einrückst oder nicht. Auch den Usern ist die Formatierung deines HTML-Codes [1] egal, es sei denn, ein Großteil dieser Leute besucht deine Seiten mit Telnet. Interessiert es sie doch genug, um den Code ausgiebig zu studieren, sind sie hoffentlich schlau genug, zu einem Editor zu greifen, der ihnen notfalls auch auf einer einzigen Zeile stehenden Code hübsch anordnet ... falls sich ihre Textformatierungsästhetik nicht mit deiner deckt. Genau zu einem solchen Programm würde ich dir auch raten, wenn dir so viel an der Formatierung maschinengenerierten HTML-Codes liegt.
[1] Oder der Code überhaupt.
--
Once is a mistake, twice is jazz.-
Hello,
*grins*
Woher kennst Du meine "User"?
Harzliche Grüße vom Berg
http://www.annerschbarrich.deTom
--
Nur wer das Ganze kennt, kann im Detail entscheiden
Nur selber lernen macht schlau
-
-
-
Hello out there!
[…] lautet die Regel: Exakt vier Leerzeichen pro Ebene, und *NIEMALS* Tabulatoren verwenden.
Hast du dafür auch eine plausible Begründung?
Meine Begründung FÜR Tabulatoren und GEGEN Leerzeichenansammlungen hatte ich in http://forum.de.selfhtml.org/archiv/2005/8/t114102/#m726539 und http://forum.de.selfhtml.org/archiv/2007/2/t146169/#m948631 dargelegt.
Du bist doch sonst so für semantischen Code; also bitte EINE Einrückung, nicht vier (ich will aber fünf!).
Leerzeichenansammlungen zum Einrücken sind das Äquivalent zu '<br><br><br><br>' bzw. ' ' in HTML.
See ya up the road,
Gunnar--
„Wer Gründe anhört, kommt in Gefahr nachzugeben.“ (Goethe)-
Hallo,
also bisjetzt finde ich die Erläuterungen von Gunnar für Tabulatoren statt Leerzeichen sehr überzeugend, also was spricht für Leerzeichen?
Gruß
-
also bisjetzt finde ich die Erläuterungen von Gunnar für Tabulatoren statt Leerzeichen sehr überzeugend, also was spricht für Leerzeichen?
Für Leerzeichen spricht, dass einige Autoren/Editoren lieber Leerzeichen zum einrücken benutzen. Und es ist viel einfacher, alle Tabs automatisch nach Leerzeichen zu konvertieren, statt die Leerzeichen nach Tabs.
Denn wenn man Leerzeichen und Tabs gemischt zum Einrücken im Code hat kann das je nach Editor und eingestellter Tab-Breite zu ganz blöden Ergebnissen kommen.
-
-
-
Hallo Cheatah,
dieses Problem betrachte ich als vollständig gelöst. In Einklang mit fast allen mir bekannten Styleguides, gängiger Praxis und persönlicher Erfahrung lautet die Regel: Exakt vier Leerzeichen pro Ebene, und *NIEMALS* Tabulatoren verwenden.
Ich verstehe das nicht. Ich stelle mir immer eine Tabulatoren-Schrittweite von vier Leerzeichen ein, aber eben Tabulatoren. Ich hasse Leerzeichen zur Einrückung. Sie haben nur Nachteile. Tabulatoren haben nur Vorteile. Ich rege mich jedesmal auf, dass scheinbar alle Editoren mir Leerzeichen aufzwingen wollen. Ich verstehe das nicht.
Beste Grüße
Richard--
~§%+-
echo $begrüßung;
Ich verstehe das nicht. Ich stelle mir immer eine Tabulatoren-Schrittweite von vier Leerzeichen ein, aber eben Tabulatoren. Ich hasse Leerzeichen zur Einrückung. Sie haben nur Nachteile. Tabulatoren haben nur Vorteile. Ich rege mich jedesmal auf, dass scheinbar alle Editoren mir Leerzeichen aufzwingen wollen. Ich verstehe das nicht.
Ein Leerzeichen ist immer ein Leerzeichen "breit". Ein Tabulator hab eine variable Breite. Das könnte beim Ausdruck stören. Außerdem ergibt es unschöne Einrück-Effekte, wenn mehrere Autoren mit unterschiedlichen Einstellungen arbeiten, einer mit Leerzeichen, ein anderer mit Tabulatoren der Breite x, und man sich das dann anschaut und Breite y eingestellt hat. Ansonsten ist es (außer vielleicht bei Python) nicht weiter tragisch.
echo "$verabschiedung $name";
-
Hallo Dedl,
Ansonsten ist es (außer vielleicht bei Python) nicht weiter tragisch.
Soweit ich weiss, wandelt der Python Parser vor dem weiteren Verarbeiten Tabulatoren in acht Leerzeichen um. Verwendet man konsistent entweder Leerzeichen oder aber Tabulatoren, ist es also kein Problem. Bei einer Mischung von Leerzeichen und Tabulatoren kann es aber zu Problemen kommen, weil dem Autor je nach Tabulator-Einstellung eine bestimmte Einrücktiefe vorgegaukelt wird, die dann aber nicht stimmt. Deswegen bin ich im Leerzeichen-Camp gelandet, ich weiss einfach gerne, was in die Datei kommt und damit auch was explizit verarbeitet wird.
Tim
-
-
-
-
-
echo $begrüßung;
rückt man HTML-Code ein oder nicht?
Dem HTML-Code ist das ziemlich egal. Nein, ist es nicht. Denn durch die Formatierung bringst du Leerzeichen, Zeilenumbrüche, Tabulatoren, was man zusammengefasst als Whiespace bezeichnet, hinein. HTML betrachtet mehrere Whitespace-Zeichen als ein Zeichen (abgesehen von vorformatiertem Text), aber es zählt auf alle Fälle mindestens als ein Zeichen. Auch wenn zwischen zwei Elementen nur Whitespace steht, steht etwas dazwischen. Und dieses Dazwischen hat gelegentlich eine Auswirkung auf die Darstellung.
z.B. <a href="..."><img src="..."></a>
Der IE macht hinter die Bilder einen lustigen Unterstrich, wenn man zwischen <img> und </a> Whitespace stehen hat.
Was meint ihr?
Für wen schreibst du den HTML-Code? Für dich? Für einen Code-Wettbewerb? Für Menschen, die ihn leicht lesen können sollen? Für Browser, die daraus was machen sollen?
Letzlich zählt das, was der Empfänger interpretiert. Dass es zur Fehlersuche hilfreich ist, übersichtlichen Quelltext zu schreiben, ist aber auch unbestritten.
echo "$verabschiedung $name";
-
P.S.:
Was macht ihr mit PHP-Code im HTML-Dokument?
Immer vorne anfangen in der Zeile?
Den PHP-Code dann auch nur mit Leerzeichen einrücken oder mit Tabulatoren?<div>Text1
<?php
echo $variabler_text;
?>
weiter mit dem Text...Aber dann hat man zwischen Text1 und dem vaiablen_text einen Zeilenumbruch und der variable_text steht nicht eingerückt.
Und nach dem variablen_text hat man glaube ich nochmal einen zeilenumbruch...Gruß
-
Hello,
Was macht ihr mit PHP-Code im HTML-Dokument?
Immer vorne anfangen in der Zeile?Das geht nicht!
<td>
<?php
echo "<img ...>macht Probeme
aber
<td><?php
echo "<img ...>";
?></td>
würde den Zweck erfüllen
Harzliche Grüße vom Berg
http://www.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hallo,
was geht bei meinem Beispiel nicht? Die Einrückung müsste man eben im echo einbauen...
Also ich benutze in HTML immer Leerzeichen zum Einrücken (eigentlich 2 vielleicht 4) und in PHP-Scripts Tabs, jetzt ist es sehr unwahrscheinlich, dass wenn ich hinter einem Tag mein <?php mache das genau auf einem Tab landet. Nach welchem Prinzip hast du bie deinem Beispiel eingerückt? Und hat man dabei auch diese nervenden Zeilenumbrüche zwischen Script-Ausgabe und HTML?
Gruß
-
P.S.: Und wie macht ihr das mit solchen echos
echo<<<bla;
hhhh
bla;Die müssen ja immer am Zeilen-Anfang stehen...
Und was haltet ihr von soetwas?
<div>Text<?php echo $var; ?>Text</div>
Gruß
-
P.S.: Und wie macht ihr das mit solchen echos
echo<<<bla;
hhhh
bla;Nicht verwenden.
Und was haltet ihr von soetwas?
<div>Text<?php echo $var; ?>Text</div>
Nicht viel. Ich versuche möglichst den HTML-Code, den Text-Inhalt und das PHP zu trennen.
-
P.S.: Und wie macht ihr das mit solchen echos
echo<<<bla;
hhhh
bla;Nicht verwenden.
Was dann verwenden für mehrzeilige Ausgaben mit Variablen und Text?
Gruß
-
Was dann verwenden für mehrzeilige Ausgaben mit Variablen und Text?
Wenn es denn sein muss:
echo "blah\n$diesunddas ist toll\nbla";
Aber wie gesagt, die Texte lagere ich (z.B. wegen der Übersetzbarkeit) bei größeren Projekten gerne in Datenbanken oder externen Dateien aus.
Dann würde ich wohl eher so ne Funktion verwenden:
echo insertTemplate(getTemplateString("beispieltext"),"diesunddas",$diesunddas);
wobei getTemplateString("beispieltext") dann in dem Fall etwas wie "blah\n%%diesunddas%% ist toll\nbla" zurückliefert.
(das ist jetzt mal ganz im groben gesponnen und ist kein real verwendeter Quelltext)
-
Ja aber in langen texten kommen oft tags vor da wird man ja mit einem template das nur di tags für den text enthält ganz verrückt...
-
Ja aber in langen texten kommen oft tags vor da wird man ja mit einem template das nur di tags für den text enthält ganz verrückt...
Ich weiß jetzt nicht ganz, was du meinst. Diese Template-Texte sollten eigentlich relativ kurze Texte sein. Längere Texte wie z.B: Artikel und ähnliches werden selbstverständlich extern aus einer Datenbank oder anderen externen Dateien wie XMLs geladen. Ob da jetzt Tags drin sind, ist doch eher Nebensächlich.
-
Naja ich meinte eher: Ich kann ja nicht für jeden kleinen Tag ein Template nutzen...
Gruß
-
Naja ich meinte eher: Ich kann ja nicht für jeden kleinen Tag ein Template nutzen...
Musst du ja auch nicht. Du kannst ja auch mehrere Tags zusammen in ein Template packen. Z.B. könnte der ganze Seitenkopf zusammen ein Template sein. (Mit jeweis einsetzbaren Title usw.)
Und wenn der Code ne Liste generiert, brauchst du ja auch nur ein Template wie <li>%%text%%</li> und ein anderes Template z.B: <ul class="navigation">%%listitems%%</ul> und den Rest erledigt dein Template-System.
-
Hallo,
so für grobe Templates bin ich ja auch, also Grundgerüst von Inhalt trennen usw...
Aber was habe ich davon wenn ich für listen ein Template verwende?
Die will man doch entweder verwenden oder nicht viel zu verändern gibts doch da nicht.Und wo speichert ihr soviele Template dateien?
Außerdem muss man dann um seinen Inhalt zu ändern immer den PHP-Code mit den Template-Funktionen durchforsten...
Vielleicht kann mir jemand die Vorteiel nahebringen
Gruß
-
Aber was habe ich davon wenn ich für listen ein Template verwende?
Die will man doch entweder verwenden oder nicht viel zu verändern gibts doch da nicht.Ich finde es besser so, als wenn man die Liste direkt im Code erzeugt. Aber das ist wohl eher Geschacksache. Vorteil von den Mini-Templates ist halt, dass du problemlos alees mögliche anpassen kannst. Du kannst nachträglich Klassen oder IDs ändern, aus einer <ul> eine <ol> machen usw. ohne dich durch möglicherweise kompizierten Code durchzuwühlen.
Und wo speichert ihr soviele Template dateien?
In einem separaten Verzeichnis? (Denkbar wären natürlich auch andere Orte wie mehrere Templates zumsammen in einer XML-Datei, aber das ist das übliche)
Außerdem muss man dann um seinen Inhalt zu ändern immer den PHP-Code mit den Template-Funktionen durchforsten...
Nein. Der _Inhalt_ wird in einer Datenbank o.ä. gespeichert und lässt sich hofentlich über eine Web-Oberfläche ändern. Das Template-System stellt nur das Layout und evtl. so einfache Beschriftungen wie "Admin-bereich", "Index", "Impressung", "Nächste Seite", etc.
Vielleicht kann mir jemand die Vorteiel nahebringen
-
Und wo speichert ihr soviele Template dateien?
In einem separaten Verzeichnis? (Denkbar wären natürlich auch andere Orte wie mehrere Templates zumsammen in einer XML-Datei, aber das ist das übliche)
Gute Template-Systeme brauchen im übrigen auch nicht so viele Templates. Es ist dann möglich in die Templates so eine Art Pseudo-For-Schleife einzubauen die dann z.B. soviele Listeneinträge ausgibt wie beabsichtigt. Dummes Beispiel:
[...]
<ul>
{{foreach|links}}
<li><a href="{{links.url}}">{{links.name}}</a></li>
{{/foreach}}
</ul>
[...](Syntax relativ frei erfunden)
-
-
-
-
-
-
-
-
-
-
-
-
-