Baukastenprinzip - Objekte

[Linuchs]

Moin,

mehr und mehr gehe ich dazu über, PHP-Programme und HTML-Seiten aus Bausteinen zusammenzusetzen. Im HTML sind das noch divs, ich muss mich mal mit section beschäftigen.

Wenn ich etwa in mehreren Webseiten ein input-Feld habe, das bei der Eingabe per Ajax Vorschläge für Ortsnamen holt, gehört die entspr. .js Datei dazu ebenso wie CSS Angaben.

Nun meckert der HTML-Validator, wenn ich CSS-Angaben in dem div formuliere, wo sie logisch hingehören. Der Firefox macht's trotzdem, aber unbekannte Browser?

In meinem anderen Faden von heute meinte dedlfix:

... als dass irgendwer etwas irgendwo in der Botanik ablegt und andere zu diesem Irgendwo hingehen und sich das holen.

Genau. CSS weitab im head zu verstecken, ist wie in die Botanik legen.

Gerne möchte ich lesen, wie konsequent ihr das Baukastenprinzip anwendet. Ist es nicht die objektorientierte Idee, dass Variablen und Verfahren gemeinsam in einer "Kiste" liegen?

Und was sollen die ständigen Ermahnungen, CSS nicht als inline in einen Tag zu packen? Ich will nicht für jeden Super-Sonderfall die weit weg liegende "Zentrale" verändern.

Linuchs

[dedlfix]

Tach!

Nun meckert der HTML-Validator, wenn ich CSS-Angaben in dem div formuliere, wo sie logisch hingehören. Der Firefox macht's trotzdem, aber unbekannte Browser?

Inline-Angaben sind Standard. Sie nicht inline zu notieren ist eine Frage des Stils. Warum und was auch immer bei dir gemeckert wird ...

CSS weitab im head zu verstecken, ist wie in die Botanik legen.

Systeme wie Angular 2 verwenden Komponenten, die aus HTML, JS und CSS zusammengebaute Bausteine sind. JS ist quasi der Haupt-Code. Das HTML und eventuelles CSS wird über Annotationen hinzugefügt. Das ist dann entweder der komplette Code oder ein Verweis auf eine Datei. Damit liegt das Zeug nahe beieinander. Ein Beispiel, wie das ungefähr aussieht, sieht man dort im ersten Beispiel.

PHP kennt so ein Konzept nicht. Es gibt keine Elemente, in denen man Meta-Code zu Klassen oder anderen Dingen hinzufügen kann. Du kannst aber die Daten oder Verweise in den Klassen unterbringen, vielleicht als statische Eigenschaften. Und dann schreibst du dir je ein Script, das über <script> und <style> angesprochen wird, deine Klassen abklappert und die dortigen Informationen in seine Ausgabe hinzufügt.

Wenn du das Zeugs je Komponentenverwendung einbindest, hast du bei Mehrfachverwendungen unnötig viel Code, der sich vielleicht sogar mit Namenskollisionen behindert.

dedlfix.

[Camping_RIDER]

Aloha ;)

Nun meckert der HTML-Validator, wenn ich CSS-Angaben in dem div formuliere,

zurecht.

Contexts in which this element can be used:
Where metadata content is expected.

wo sie logisch hingehören.

Sie gehören da nicht logisch hin. Sie gehören logisch da hin, wo man Metaangaben sucht - in den head, und in ein externes Stylesheet.

In meinem anderen Faden von heute meinte dedlfix:

... als dass irgendwer etwas irgendwo in der Botanik ablegt und andere zu diesem Irgendwo hingehen und sich das holen.

Genau.

Eben nicht genau. Da gings um Variablen in einer Programmiersprache. HTML ist keine Programmiersprache und CSS-Regeln keine Variablen. Du hast offenbar nicht gemerkt, dass du hier den Kontext wechselst.

CSS weitab im head zu verstecken, ist wie in die Botanik legen.

Nein. Eben nicht. CSS im Dokument verstreuen auf das man sich zusammensuchen muss, wo welche eventuell miteinander interferierenden Angaben liegen könnten, das ist in diesem Bezug wie in die Botanik legen.

Gerne möchte ich lesen, wie konsequent ihr das Baukastenprinzip anwendet.

Gar nicht. Aus gutem Grund.

Ist es nicht die objektorientierte Idee, dass Variablen und Verfahren gemeinsam in einer "Kiste" liegen?

Objektorientierung ist ein Programmierparadigma und hat nichts, aber auch gar nichts mit der Auszeichnungssprache HTML zu tun.

Und was sollen die ständigen Ermahnungen, CSS nicht als inline in einen Tag zu packen? Ich will nicht für jeden Super-Sonderfall die weit weg liegende "Zentrale" verändern.

Was HTML angeht gelten ganz andere Paradigmen.

Ganz weit oben sind da

• Separation of concerns

inklusive

• unobtrusive JavaScript
• Guter CSS-Stil

Das von dir zugrundegelegte „Baukastenprinzip“ gehört nicht dazu und ist durch sachliche Argumente auch nicht haltbar, sondern im Gegenteil ein Zeichen eines starren, unflexiblen und dadurch suboptimalen Softwaredesign.

Grüße,

RIDER

[dedlfix]

Tach!

Sie gehören da nicht logisch hin. Sie gehören logisch da hin, wo man Metaangaben sucht - in den head, und in ein externes Stylesheet.

Da kann man anderer Meinung sein. Sie gehören in die Metaangaben, weil die Syntax es so vorsieht. Logisch finde ich das nur mit einer bestimmten Betrachtungsweise.

Man kann auf zwei Weisen (vielleicht auch noch mehr) Struktur in eine Sache bringen. Die erste ist, man sortiert alles nach Typen: Alles HTML dorthin, alles Javascript dahin, alle Controller hierhin, alle Models zueinander, alle Socken in die eine Schublade und die T-Shirts in das eine Fach. Oder man sortiert und separiert es nach fachlichen Aspekten. Ich mag letzteres, weil ich üblicherwiese ein bestimmtes Thema bearbeite und nur ganz selten nur bestimmte Typen. Typenbasierte Strukturierung macht aber meine Arbeit umständlicher, weil ich zwischen mehreren verschiedenen Orten hin- und herpendeln muss.

CSS im Dokument verstreuen auf das man sich zusammensuchen muss, wo welche eventuell miteinander interferierenden Angaben liegen könnten, das ist in diesem Bezug wie in die Botanik legen.

Nicht unbedingt. Ich habe meist generelles CSS für das allgemeine Aussehen und individuelles, das nur von bestimmten Komponenten oder nur für ein einzelnes Element verwendet wird. Das generelle kann dabei genauso zentral liegen wie das Grundgerüst der Seite. Individuellen Kram habe ich gern in der Nähe dieser Sachen liegen. Wie am Ende was zusammenspielt, seht ich viel besser über die Entwicklertools als in den Code-Dateien.

Gerne möchte ich lesen, wie konsequent ihr das Baukastenprinzip anwendet.

Gar nicht. Aus gutem Grund.

Ich hingegen schon, und Angular 2 als ein nicht unbedeutendes komponentenbasiertes Framework macht es vor.

Objektorientierung ist ein Programmierparadigma und hat nichts, aber auch gar nichts mit der Auszeichnungssprache HTML zu tun.

Die Ideen hinter Objektorientierung und Komponenten scheinen mir nicht so weit auseinander zu liegen.

Und was sollen die ständigen Ermahnungen, CSS nicht als inline in einen Tag zu packen? Ich will nicht für jeden Super-Sonderfall die weit weg liegende "Zentrale" verändern.

Das hat eher weniger Gründe der Struktur. Im HTML versteckt muss es mit jedem Dokument erneut ausgeliefert werden. Zentralisiert kann es nach dem ersten Request aus dem Cache genommen werden.

Das von dir zugrundegelegte „Baukastenprinzip“ gehört nicht dazu und ist durch sachliche Argumente auch nicht haltbar, sondern im Gegenteil ein Zeichen eines starren, unflexiblen und dadurch suboptimalen Softwaredesign.

Diesen Vorwurf könnte man auch aus der anderen Perspektive machen.

dedlfix.

[Camping_RIDER]

Aloha ;)

Gerne möchte ich lesen, wie konsequent ihr das Baukastenprinzip anwendet.

Gar nicht. Aus gutem Grund.

Ich hingegen schon, und Angular 2 als ein nicht unbedeutendes komponentenbasiertes Framework macht es vor.

Objektorientierung ist ein Programmierparadigma und hat nichts, aber auch gar nichts mit der Auszeichnungssprache HTML zu tun.

Die Ideen hinter Objektorientierung und Komponenten scheinen mir nicht so weit auseinander zu liegen.

Nun, Angular ist ein JavaScript-Framework, und als solches baust du damit Webseiten eingebettet in eine Programmiersprache. Selbstverständlich ist Objektorientierung und die Verwendung von Komponenten dort vorgesehen. Weil beides Paradigmen sind, die zu einer Programmiersprache passen.

Ich bin mir im Übrigen auch sicher, dass Angular dann in der entstehenden Seite diese Komponenten wieder aufdröselt und in die Struktur bringt, die für HTML-Dokumente vorgesehen ist - mit zentralisierten Angaben zu Styles und Scripten. Ich kenne Angular nicht persönlich, aber wenn das nicht so wäre würde mich das sehr wundern. Klär mich auf, falls ich da falsch liege.

Es hat niemand bestritten, dass es Werkzeuge geben mag, bei denen am Ende Webseiten rauskommen, für die eine solche Arbeitsweise förderlich, empfehlenswert oder gar notwendig ist.

HTML funktioniert trotzdem anders. Der Weg dahin, den HTML-Code zu bekommen (vor allem bei automatisierter Zusammenstellung, wie durch PHP o.ä. - oder eben wie bei Angular mit Javascript) mag objektorientiert und komponentenbasiert sein - HTML kennt diese Strukturen aber nicht und erwartet das, was objektorientiert zusammengebaut wird, an seine eigene Anforderungen angepasst.

Für HTML als Auszeichnungssprache sind HTML-Elemente die Komponenten, aus denen sich eine Seite zusammensetzt. Jede dieser Komponenten hat ihren Platz in einem gut strukturierten HTML-Dokument. Eine weitere funktionale Gruppierung, über HTML-Elemente hinaus, ist in HTML nicht vorgesehen und läuft den HTML inhärenten Konzepten (separation of concerns, semantische Auszeichnung, ...) entgegen.

Sie gehören da nicht logisch hin. Sie gehören logisch da hin, wo man Metaangaben sucht - in den head, und in ein externes Stylesheet. Da kann man anderer Meinung sein. Sie gehören in die Metaangaben, weil die Syntax es so vorsieht. Logisch finde ich das nur mit einer bestimmten Betrachtungsweise.

Das logisch sollte hier vielleicht gestrichen werden. Aber es ist so, dass die Angaben zu script und styling eben durch die Spec als Metaangaben klassifiziert werden und damit da ins Dokument gehören, wo sie eben hingehören. Ich habe mich da nicht explizit festgelegt, aber „Where metadata content is expected.“ ist eher nicht deckungsgleich mit „bei einem Input-Feld“. Schon gar nicht dann, wenn sogar der Validator meckert.

Grüße,

RIDER

[dedlfix]

Tach!

Nun, Angular ist ein JavaScript-Framework, und als solches baust du damit Webseiten eingebettet in eine Programmiersprache. Selbstverständlich ist Objektorientierung und die Verwendung von Komponenten dort vorgesehen. Weil beides Paradigmen sind, die zu einer Programmiersprache passen.

Genau das hat Linuchs ja in seinem System vor.

Ich bin mir im Übrigen auch sicher, dass Angular dann in der entstehenden Seite diese Komponenten wieder aufdröselt und in die Struktur bringt, die für HTML-Dokumente vorgesehen ist - mit zentralisierten Angaben zu Styles und Scripten. Ich kenne Angular nicht persönlich, aber wenn das nicht so wäre würde mich das sehr wundern. Klär mich auf, falls ich da falsch liege.

Ja, sowas in der Art passiert. Aber vorgesehen ist in HTML-Dokumenten auch Inline-Zeugs und Script-Bereiche an so ziemlich jeder Stelle des Codes, nicht nur zentralisiert im Head.

Es hat niemand bestritten, dass es Werkzeuge geben mag, bei denen am Ende Webseiten rauskommen, für die eine solche Arbeitsweise förderlich, empfehlenswert oder gar notwendig ist.

So eins sucht Linuchs, weiß es nur noch nicht, scheint mir. Ich kenne da aber für PHP nichts, weswegen ich ihm da erzählte, wie man es prinzipiell selbst beuen könnte.

dedlfix.

[Camping_RIDER]

Aloha ;)

Nun, Angular ist ein JavaScript-Framework, und als solches baust du damit Webseiten eingebettet in eine Programmiersprache. Selbstverständlich ist Objektorientierung und die Verwendung von Komponenten dort vorgesehen. Weil beides Paradigmen sind, die zu einer Programmiersprache passen.

Genau das hat Linuchs ja in seinem System vor.

Hat er?

„…mehr und mehr gehe ich dazu über, […] HTML-Seiten aus Bausteinen zusammenzusetzen…“

„Wenn ich etwa in mehreren Webseiten ein input-Feld habe, […] gehört die entspr. .js Datei dazu ebenso wie CSS Angaben.“

Nun, es könnte sein, dass er das vorhat und noch nichts davon weiß. Wenn das so ist sollte irgendjemand sicherstellen, dass er das deutlich erfährt, bevor er noch davon ausgeht, dass dein Plädoyer ihn darin bestärken soll, weiterhin unvalides HTML zu produzieren, das über Skripte und Stylesheets mitten in Formularen verfügt, nur weil die für ein bestimmtes input-Element benötigt werden, das im HTML direkt daneben stehen soll, weil das so praktische „HTML-Bausteine“ sind.

Sollte Linuchs so etwas bisher nicht getan haben tut mir das Missverständnis und die harte Kritik leid. Ich befürchte aber, dass ich mit meinen Befürchtungen - zumindest bezüglich seines bisherigen Vorgehens - gar nicht so weit von der Wahrheit entfernt bin 😉

Aber vorgesehen ist in HTML-Dokumenten auch Inline-Zeugs und Script-Bereiche an so ziemlich jeder Stelle des Codes, nicht nur zentralisiert im Head.

Ja. Es gibt wie in Allem zwei Extreme und dazwischen Grauzonen, von denen mindestens Bereiche noch akzeptierbar und begründbar sind.

Die festen „Bausteine“ in HTML hören sich für mich aber sehr nach einem Extrem an, das nach HTML-Standards nicht akzeptierbar ist.

Es hat niemand bestritten, dass es Werkzeuge geben mag, bei denen am Ende Webseiten rauskommen, für die eine solche Arbeitsweise förderlich, empfehlenswert oder gar notwendig ist.

So eins sucht Linuchs, weiß es nur noch nicht, scheint mir.

Das ist sehr gut möglich.

Ich kenne da aber für PHP nichts, weswegen ich ihm da erzählte, wie man es prinzipiell selbst beuen könnte.

Richtig. Für mich kam da aber noch nicht deutlich genug raus, dass das nicht nur Werkzeuge sind, die man ähnlich füttern kann, wie er es im Moment mit seinem HTML tut, sondern, dass das die (lies: die einzigen) Werkzeuge sind, die man sinnvollerweise auf diese Art und Weise füttert.

Ich hab nichts gegen ein objektorientiertes Baukastensystem zum Erstellen von Webseiten. Aber ich hab sehr viel dagegen, wenn man denkt, HTML selbst sei ein solches oder wie ein solches zu benutzen.

Grüße,

RIDER

[dedlfix]

Tach!

Nun, es könnte sein, dass er das vorhat und noch nichts davon weiß. Wenn das so ist sollte irgendjemand sicherstellen, dass er das deutlich erfährt, bevor er noch davon ausgeht, dass dein Plädoyer ihn darin bestärken soll, weiterhin unvalides HTML zu produzieren, das über Skripte und Stylesheets mitten in Formularen verfügt, nur weil die für ein bestimmtes input-Element benötigt werden, das im HTML direkt daneben stehen soll, weil das so praktische „HTML-Bausteine“ sind.

<style>-Bereiche sind tatsächlich invalide außerhalb von <head>, <script>-Bereiche hingegen nicht. Nichtsdestotrotz haben <style>-Bereiche immer funktioniert, wenn ich sie aus einer Notlage heraus außerhalb platziert hatte. Jedenfalls spricht nichts grundlegend technisches gegen die Platzierung von Javascript in der Nähe der Komponenten. Mein Vorschlag zielte aber darauf, dass er sich ein System erschafft, das mit einer Einbindung im Head-Bereich auskommt. Wobei das Javascript auch ...

Aber vorgesehen ist in HTML-Dokumenten auch Inline-Zeugs und Script-Bereiche an so ziemlich jeder Stelle des Codes, nicht nur zentralisiert im Head. Ja. Es gibt wie in Allem zwei Extreme und dazwischen Grauzonen, von denen mindestens Bereiche noch akzeptierbar und begründbar sind.

Bei <script> wird es sogar zunehmend empfohlen, es erst kurz vor </body> zu platzieren, damit es das Seiten-Rendering nicht blockiert.

Die festen „Bausteine“ in HTML hören sich für mich aber sehr nach einem Extrem an, das nach HTML-Standards nicht akzeptierbar ist.

<hust soundslike="templates">

dedlfix.

[Camping_RIDER]

Aloha ;)

Bei <script> wird es sogar zunehmend empfohlen, es erst kurz vor </body> zu platzieren, damit es das Seiten-Rendering nicht blockiert.

Richtig - da aber aus technisch-/UX-basierten Gründen innerhalb der von HTML vorgesehenen Struktur, nicht aus Gründen des Zusammenstell-Komforts entgegen jeder best-practice-Richtlinie.

Die festen „Bausteine“ in HTML hören sich für mich aber sehr nach einem Extrem an, das nach HTML-Standards nicht akzeptierbar ist.

<hust soundslike="templates">

Dabei hab ich mich doch so schön um den Begriff gewunden, um hier nicht noch mehr Verwirrung anzulocken 😉

Es ist eben nicht ohne Grund so, dass man Templates in HTML nicht nur einfach so zusammenschustern kann, sondern dafür eine Template-Engine brauc.... *duck und weg*

Grüße,

RIDER

[Matthias Apsel]

Hallo dedlfix,

Man kann auf zwei Weisen (vielleicht auch noch mehr) Struktur in eine Sache bringen. Die erste ist, man sortiert alles nach Typen: Alles HTML dorthin, alles Javascript dahin, alle Controller hierhin, alle Models zueinander, alle Socken in die eine Schublade und die T-Shirts in das eine Fach.

Oder zu DOS-Zeiten: alle Dateien mit „A“ beginnenden Dateien in einen Ordner "A", alle mit „B“ beginnenden in "B". Jeder kennt irgendjemanden, der irgendjemanden kennt, dessen Cousin dritten Grades, dem sein Großvater hat das gemacht und sich gewundert, dass der Rechner nicht mehr startet.

Bis demnächst
Matthias

[dedlfix]

Tach!

Oder zu DOS-Zeiten: alle Dateien mit „A“ beginnenden Dateien in einen Ordner "A", alle mit „B“ beginnenden in "B".

Das Prinzip gibt es heute auch noch, hat dann aber eher technische Gründe. Zu viele Dateien in einem Verzeichnis machen das System langsam, weil zum Beispiel das Suchen darin dauert. Session-Dateien müssen nur vom System wiedergefunden werden und haben sowieso kryptische Namen. Wenn davon viele zu verwalten sind, werden die auch gern nach einem oder mehreren Anfangsbuchstaben sortiert.

Und das Prinzip gab es auch schon vor DOS, als man noch mit Karteikarten seine Daten verwaltet hat.

dedlfix.

[Matthias Apsel]

Hallo dedlfix,

Und das Prinzip gab es auch schon vor DOS, als man noch mit Karteikarten seine Daten verwaltet hat.

Genau deshalb hat der Opa das ja so gemacht.

Bis demnächst
Matthias

[TS]

Hello,

Und das Prinzip gab es auch schon vor DOS, als man noch mit Karteikarten seine Daten verwaltet hat.

Genau deshalb hat der Opa das ja so gemacht.

Und meinst Du nun, dass moderne Systeme innen drin / unten drunter anders arbeiten würden?

• direktgestreut
• indiziert
• indiziert und hashed
• in Seiten organisiert
• bTree, B+Tree, usw.
• gezielte Redundanz
• usw.

Spanned ist es eben immer, wenn man sowohl links herum als auch rechts herum strukturieren könnte oder aber sogar mitten durch...

Wer steuert also was? Bestimmt PHP, welche HTML-Teile eingebaut werden? Bestimmen die HTML-Teile, welches JavaScript und welches CSS dazugehört? Oder bestimmt der Inhalt, welche HTML-Stuktur notwendig ist und die bestimmt dann (indirekt), welche PHP-Module sie benötigt und an welcher Stelle AJAX-Unterstützung notwendig wird?

Oder ist es ganz anders? HTML ist nur eine Möglichkeit der metasemntischen Strukturierung von Informationen. Morgen könnte jemand eine vieeel bessere Sprache erfinden und dann möchten wir den HTML-Teil einfach gegen SIMPLEFORMAT austauschen, oder wie das dann eben heißt. Dann wäre es doch dumm, wenn alle Steuerung vom HTML ausging.

Also wie jetzt?

Liebe Grüße
Tom S.

[Matthias Apsel]

Hallo TS,

Ich habe vergessen, die Tags zu ändern. humor hinzuzufügen und programmiertechnik zu entfernen. Es tut mir leid.

Bis demnächst
Matthias

[TS]

Hello,

Ich habe vergessen, die Tags zu ändern. humor hinzuzufügen und programmiertechnik zu entfernen. Es tut mir leid.

Na und? Blödeln ist die Grundlage des Brainstormings!

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Wer steuert also was? Bestimmt PHP, welche HTML-Teile eingebaut werden? Bestimmen die HTML-Teile, welches JavaScript und welches CSS dazugehört? Oder bestimmt der Inhalt, welche HTML-Stuktur notwendig ist und die bestimmt dann (indirekt), welche PHP-Module sie benötigt und an welcher Stelle AJAX-Unterstützung notwendig wird?

Die Ausgabesprache bestimmt, welche Struktur der letztendlich ausgegebene Inhalt besitzt. Ein HTML-Dokument, das durch eine Sprache wie PHP oder JavaScript aus Komponenten zusammengestellt wurde unterscheidet sich strukturell nicht von einem HTML-Dokument, das von Hand als Unikat geschrieben wurde - oder sollte es zumindest nicht.

So ähnlich wie man in einer Fabrik versucht, das Fabrikat so hinzubekommen, dass man es nicht auf den ersten Blick als Massenware erkennt, sondern am Besten mit einem handgefertigten Stück verwechseln kann.

Oder ist es ganz anders? HTML ist nur eine Möglichkeit der metasemntischen Strukturierung von Informationen. Morgen könnte jemand eine vieeel bessere Sprache erfinden und dann möchten wir den HTML-Teil einfach gegen SIMPLEFORMAT austauschen, oder wie das dann eben heißt. Dann wäre es doch dumm, wenn alle Steuerung vom HTML ausging.

Genau deshalb passiert das Zusammensetzen aus Komponenten optimalerweise so, dass das, was rauskommt, sich der Struktur anpasst, die es haben soll - unabhängig von dem was reingeht. Wenn SIMPLEFORMAT rauskommen soll erwarte ich ja auch ein Dokument, das der SIMPLEFORMAT inhärenten Strukturierung entspricht und keinen HTML-Abklatsch, und auch keine zusammenhängenden Komponenten, außer, falls SIMPLEFORMAT das genau so vorsieht. Wenn HTML rauskommen soll, erwarte ich, dass die Komponenten, die der Wiederverwendbarkeit zuliebe am Stück reingingen, im HTML-Dokument nicht auch wieder am Stück rauskommen, sondern eben so, wie das für HTML am günstigsten ist.

Grüße,

RIDER

[TS]

Hello,

[...]

und der eigentliche Content bleibt auf der Strecke?

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

[...]

und der eigentliche Content bleibt auf der Strecke?

Das musst du mir jetzt erläutern.

Grüße,

RIDER

[TS]

Hello,

[...]

und der eigentliche Content bleibt auf der Strecke?

Das musst du mir jetzt erläutern.

keuch, hust
Meine "Muss-Allergie" schlägt gerade wieder zu.

Liebe Grüße
Tom S.

[Julius]

Hallo TS,

und der eigentliche Content bleibt auf der Strecke?

Wie kommst du darauf?

Gruß
Julius

[TS]

Hello,

und der eigentliche Content bleibt auf der Strecke?

Wie kommst du darauf?

Ich hatte danach gefragt, wer eigentlich was bedingen (steuern) sollte. MMn muss der Content (die Information) die Methoden steuern, mit denen sie übertragen werden will. Leider gibt es nicht zu jeder Zeit ideale Methoden. Also muss die Information (oder ihr Verwalter) die besten verfügbaren Methoden auswählen.

Zurück in die Zeit der Fernschreiber. Wie hätte man da ein Bild übertragen?
Man konnte auch schon lange vor HTML Bilder in Bildschirmseiten von Computern darstellen. Es gab Grafikkarten, die konnten innerhalb des Textmodus ein Fenster öffnen, in dem Pixeldarstellungen möglich waren. Die kennt heute keiner mehr!

Kurz und gut: Wenn jemand eine intelligentere Sprache erfindet, die der Information gerecht wird, dann sind die heutigen Browser in Nullkommanix obsolete. Oder hast Du heute noch in jedem Büro einen Fernschreiber oder einen Bildschreiber stehen? Die Information (die übertragen werden will) ist aber geblieben!

Nun wäre es doch dumm, wenn man mit den ganzen obsoleten Browsern auch gleich alle informationsverwaltenden Systeme wegschmeißen müsste, oder? Da wäre es doch gut, wenn man nicht vergessen hätte, dass die Information alle Übertragung steuern sollte, und nicht die Übertragungsmöglichkeiten die Informationen!

Liebe Grüße
Tom S.

[Julius]

Hallo TS,

und der eigentliche Content bleibt auf der Strecke?

Wie kommst du darauf?

Ich hatte danach gefragt, wer eigentlich was bedingen (steuern) sollte. MMn muss der Content (die Information) die Methoden steuern, mit denen sie übertragen werden will. Leider gibt es nicht zu jeder Zeit ideale Methoden. Also muss die Information (oder ihr Verwalter) die besten verfügbaren Methoden auswählen.

Wie sollen die Informationen das denn entscheiden?
Konkret: Wenn auf der Platte des Servers Markdown-Dokumente mit ein paar Meta-Angaben (Titel, Autor, Kategorie) liegen und jemand dieses Dokument betrachten will, wird ein separates Script aufgerufen, dass die Daten aufbereitet (Markdown parsen, Informationen ins HTML-Template einpflegen)^[1] und dann über den Webserver ausgeliefert. Hier könnte man sagen, dass anhand des Inhalts die Darstellungsform ausgewählt wird.

Wenn es sich um dynamische Inhalte (Server-seitige Programme, JavaScript) handelt, kann man die Ausgabe so implementieren, wie man lustig ist, aber meist läuft es sowieso auf HTML hinaus.

Zurück in die Zeit der Fernschreiber. Wie hätte man da ein Bild übertragen?
Man konnte auch schon lange vor HTML Bilder in Bildschirmseiten von Computern darstellen. Es gab Grafikkarten, die konnten innerhalb des Textmodus ein Fenster öffnen, in dem Pixeldarstellungen möglich waren. Die kennt heute keiner mehr!

Die waren aber weder Plattform-unabhängig, standardisiert noch weit verbreitet und mit dynamischen Inhalten brauchst du einem Fernschreiber nicht kommen.

Kurz und gut: Wenn jemand eine intelligentere Sprache erfindet, die der Information gerecht wird, dann sind die heutigen Browser in Nullkommanix obsolete.

Die Trennung von Inhalt (HTML), Darstellung (CSS) und Programm (JavaScript) ist durchdacht und muss nur sauber durchgezogen werden.

Und selbst wenn man die heutigen Web-Technologien ersetzen wollen würde: Erinnerst du dich, wie lange es brauchte, um den IE6 los zu werden? Weit verbreitete Systeme lassen sich schwer ersetzen (siehe auch 7-Bit-Kodierungen bei E-Mails). Technologischer Fortschritt ist meist Evolution, nicht Revolution, weil man in kleinen Schritten leichter mehr erreichen kann, als mit großen, schlecht umgesetzten Sprüngen.

Oder hast Du heute noch in jedem Büro einen Fernschreiber oder einen Bildschreiber stehen?

Beide standen fast nie in Privathaushalten. Webseiten-darstellende Geräte dagegen zu Hauf.

Die Information (die übertragen werden will) ist aber geblieben!

Wird sie auch immer: Von der Tontafel über den Buchdruck zur Website.

Nun wäre es doch dumm, wenn man mit den ganzen obsoleten Browsern auch gleich alle informationsverwaltenden Systeme wegschmeißen müsste, oder?

Wenn man ein sauber definiertes, flexibles Speicherformat (eigenes XML-basiertes oder HTML) hast, dann kannst du doch daraus alles machen. Was willst du mehr?

Da wäre es doch gut, wenn man nicht vergessen hätte, dass die Information alle Übertragung steuern sollte, und nicht die Übertragungsmöglichkeiten die Informationen!

Du willst Code (zur Darstellung) und die Information mischen? Das hatten wir schon mal: Flash.

Gruß
Julius

---

---

1. Hier könnte man auch ein PDF erzeugen, will man meist aber nicht. ↩︎

[TS]

Hello,

[...]

Da wäre es doch gut, wenn man nicht vergessen hätte, dass die Information alle Übertragung steuern sollte, und nicht die Übertragungsmöglichkeiten die Informationen!

Du willst Code (zur Darstellung) und die Information mischen? Das hatten wir schon mal: Flash.

Das von-Neumann-Prinzip ist älter als Flash ;-)

Aber darauf wollte ich nicht hinaus. Ich würde die (philosophische) Diskussion gerne frei von aktuellen Möglichkeiten und Verfahren durchführen. Um auf wirklich revolutionär neue Ideen zu kommen, müssten wir uns vom momentanen Digitalisierungswahn frei machen. Können wir aber nicht, da die Scheuklappen bereits angewachsen sind.

Ich weiß nicht, wohin eine Diskussion fürhren würde, in der ich keine Gegenrede erhalten würde, sondern alle in die gleiche Richtung spinnen würden? Könnte die vielleicht zu neuen Ideen führen, auch wenn sie dann erst in 100 Jahren machbar sind?

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Da wäre es doch gut, wenn man nicht vergessen hätte, dass die Information alle Übertragung steuern sollte, und nicht die Übertragungsmöglichkeiten die Informationen!

Du willst Code (zur Darstellung) und die Information mischen? Das hatten wir schon mal: Flash.

Das von-Neumann-Prinzip ist älter als Flash ;-)

Von-Neumann-Prinzip? Offenbar folgen Sinn und Aussage in diesem Beitrag dem Harvard-Prinzip. Kann ich den dann, wenn ich mir ein PDF hiervon ziehe, überhaupt auf meiner Festplatte speichern, die ja der Von-Neumann-Speicherarchitektur folgt? Oder brauch ich für so viel Harvard-Prinzip dann meine reine Datenplatte⁉️

n' guten 😉

🐟 <°)XXX>< 🐠

Grüße,

RIDER

[TS]

Hello,

Da wäre es doch gut, wenn man nicht vergessen hätte, dass die Information alle Übertragung steuern sollte, und nicht die Übertragungsmöglichkeiten die Informationen!

Du willst Code (zur Darstellung) und die Information mischen? Das hatten wir schon mal: Flash.

Das von-Neumann-Prinzip ist älter als Flash ;-)

Von-Neumann-Prinzip? Offenbar folgen Sinn und Aussage in diesem Beitrag dem Harvard-Prinzip. Kann ich den dann, wenn ich mir ein PDF hiervon ziehe, überhaupt auf meiner Festplatte speichern, die ja der Von-Neumann-Speicherarchitektur folgt? Oder brauch ich für so viel Harvard-Prinzip dann meine reine Datenplatte⁉️

Du meinst sicher das Harvard-Konzept als Grundlage der Diskussionskultur? Da bist Du absolut auf dem richtigen Weg!

Liebe Grüße
Tom S.

[Rolf b]

Auf die Gefahr hin, Ironie deinerseits zu übersehen (weil ich beim Googlen nach Harvard zuerst auch auf die Diskussionskultur gestoßen bin): Der richtige Begriff in der Informatik ist Harvard-Architektur. Aber da die meisten Computer, mit denen wir zu tun haben, die von Neumann Architektur haben, ist diese Idee ziemlich untergegangen. Man nutzt sie heute vermutlich nur noch in Maschinen, wo auch die größten Caches den von Neumann Flaschenhals nicht mehr auflösen können.

Rolf

[Julius]

Hallo TS,

Aber darauf wollte ich nicht hinaus. Ich würde die (philosophische) Diskussion gerne frei von aktuellen Möglichkeiten und Verfahren durchführen.

Ich habe ein Beispiel gebracht, weil ich nicht verstand, worauf du hinaus willst.

Ich weiß nicht, wohin eine Diskussion fürhren würde, in der ich keine Gegenrede erhalten würde, sondern alle in die gleiche Richtung spinnen würden?

Sie endet sehr schnell, würde ich sagen. Und langweilig ist sie auch noch.

Könnte die vielleicht zu neuen Ideen führen, auch wenn sie dann erst in 100 Jahren machbar sind?

Gerade in einer sachlichen und konstruktiven Diskussion entstehen neue Ideen.

Gruß
Julius

[Rolf b]

HTML Bausteine bringen die .css und .js Dateien mit, die sie brauchen, und sorgen für ein passendes Namespacing. D.h. wenn Du dein spezielles Inputfeld haben willst, musst Du ihm eine passende Klasse wie linuchs-proposable-city-input zuweisen und dein Addon-CSS muss seine Styles so definieren, dass sie nur an input-Elementen mit der Klasse linuchs-proposable-city-input gelten. Dein linuchs-proposable-city-input.js kann sich dann auf den Moment registrieren, wo das DOM geladen ist, dort per querySelectorAll() alle linuchs-proposable-city-input Elemente heraussuchen und ihnen die nötigen Events zuschustern.

Und bevor Du so eine Seite aus dem Baukasten in Produktion gibst, rennst Du mit einem Minifizierer drüber, der aus deinen 17424 kleinen CSS und JS Dateien zwei große macht.

Wenn Dir linuchs-proposable-city-input zu lang ist, könntest Du natürlich auch den Namen 🐧⌂-input nehmen.

Rolf

[Julius]

Hallo Rolf,

Wenn Dir linuchs-proposable-city-input zu lang ist, könntest Du natürlich auch den Namen 🐧⌂-input nehmen.

Ich denke, dass diese Zeichen nicht umsonst kaum bis gar nicht für so etwas benutzt werden, weil sie nicht in jeder Schriftart zu finden sind. Was mache ich dann? Dann doch lieber auf ASCII-Zeichen beschränken.

Gruß
Julius

[dedlfix]

Tach!

Wenn Dir linuchs-proposable-city-input zu lang ist, könntest Du natürlich auch den Namen 🐧⌂-input nehmen.

Ich denke, dass diese Zeichen nicht umsonst kaum bis gar nicht für so etwas benutzt werden, weil sie nicht in jeder Schriftart zu finden sind. Was mache ich dann? Dann doch lieber auf ASCII-Zeichen beschränken.

Das ist nicht weiter relevant. Code wird nicht erst als menschenlesbarer Text ausgegeben, bevor er ausgeführt werden kann. 42 bleibt 42, egal ob man dazu ein Zeichen rendern könnte oder nicht, und wird mit der Bedeutung, die für 42 festgelegt wurde, ausgeführt.

dedlfix.

[Julius]

Hallo dedlfix,

Wenn Dir linuchs-proposable-city-input zu lang ist, könntest Du natürlich auch den Namen 🐧⌂-input nehmen.

Ich denke, dass diese Zeichen nicht umsonst kaum bis gar nicht für so etwas benutzt werden, weil sie nicht in jeder Schriftart zu finden sind. Was mache ich dann? Dann doch lieber auf ASCII-Zeichen beschränken.

Das ist nicht weiter relevant. Code wird nicht erst als menschenlesbarer Text ausgegeben, bevor er ausgeführt werden kann. 42 bleibt 42, egal ob man dazu ein Zeichen rendern könnte oder nicht, und wird mit der Bedeutung, die für 42 festgelegt wurde, ausgeführt.

Natürlich, dem Computer ist das egal.
Mir geht es aber eher um das Entwickeln bzw. die Arbeit mit dem Code. Wenn man mit mehreren Leuten an so etwas arbeitet, ist es doch eher kontraproduktiv, wenn man diese speziellen Zeichen hat:

• wenn ich kein passende Glyphe in meinen Fonts habe, weiß ich als Mensch nicht sofort, was das bedeuten soll
• diese modernen Hieroglyphen sind nicht wirklich eindeutig („⌂“ würde ich eher mit „Haus“ verbinden)
• danach zu suchen, ist schwierig, dazu müsste ich das exakte Zeichen kennen – so kann ich einfach „city“ eingeben

Gruß
Julius

[dedlfix]

Tach!

Natürlich. Mir geht es aber eher um das Entwickeln bzw. die Arbeit mit dem Code. Wenn man mit mehreren Leuten an so etwas arbeitet, ist es doch eher kontraproduktiv, wenn man diese speziellen Zeichen hat:

Ja, sowas würde auch in internationalen Teams passieren, wenn man Sprachen und Schriftsysteme verwendet, die ein Teil der Mitarbeiter nicht (mit der dort üblicherweise installieren Soft- und Hardware) einzugeben in der Lage ist. Aber wenn es diese Anforderungen nicht gibt, spricht auch nichts ernsthaftes dagegen.

dedlfix.

[Rolf b]

He, das war ein Scherz... :) bzw. ein Zitat von Gunnars .💩 { color:brown }.

Falls man es ernst meint: das Problem könnte eher sein, dass 🐧 nicht in der BMP ist - ich weiß nicht ob das sauber unterstützt wird.

Rolf

[TS]

Hello,

He, das war ein Scherz... :) bzw. ein Zitat von Gunnars .💩 { color:brown }.

Ja ulkig!
Auf irgendeinem Arbeitsplatz/Gerät habe ich den Scheißhaufen auch angezeigt bekommen. tztz

Auf diesem geht es scheinbar nicht.

Liebe Grüße
Tom S.

[Julius]

Hallo Rolf,

He, das war ein Scherz... :) bzw. ein Zitat von Gunnars .💩 { color:brown }.

Falls man es ernst meint: das Problem könnte eher sein, dass 🐧 nicht in der BMP ist - ich weiß nicht ob das sauber unterstützt wird.

Wieso sollte das ein Problem sein? Wikipedia sagt, dass mittlerweile sogar Schriftsysteme außerhalb des BMP abgelegt werden. So lange alles sauber kodiert ist, sollte es doch kein Problem bei der Verwendung von 💩 als Bezeichner geben?

Mit fehlender Unicode-Unterstützung ist oft nur gemeint, dass String-Funktionen wie strlen und Konsorten Probleme machen:

$💩 = 'Ist doch eh alles 💩!';
echo $💩;
// ergibt: Ist doch eh alles 💩!
echo strlen('💩');
// ergibt: 4
echo mb_strlen('💩');
// ergibt: 1

Gruß
Julius

[Rolf b]

PHP classic !== PHP Multibytecharactersetfunktionen !== BROWSER

Ich habe jetzt nochmal was rumgestöbert, das WIKI sagt, dass eine Voraussetzung von HTML 4.0 die vollständige Unterstützung von Unicode ist. Nun ist HTML 4.01 von 1999, Unicode 3.1 aber von 2001, insofern könnte es Browser geben die sich "HTML 4.01 konform" nennen und bei Unicode im letzten Jahrtausend stehen geblieben sind. Die Anzahl der Nutzer dieser Browser dürfte aber geringer sein als die Anzahl frei lebender Demokraten in Nordkorea.

Rolf

[Julius]

Hallo Rolf,

Ich habe jetzt nochmal was rumgestöbert, das WIKI sagt, dass eine Voraussetzung von HTML 4.0 die vollständige Unterstützung von Unicode ist. Nun ist HTML 4.01 von 1999, Unicode 3.1 aber von 2001, insofern könnte es Browser geben die sich "HTML 4.01 konform" nennen und bei Unicode im letzten Jahrtausend stehen geblieben sind.

Zumindest den IE 6 (Windows XP SP2) juckt das nicht. Dort funktioniert .💩 {color:brown;} problemlos.

Gruß
Julius

[TS]

Hello,

mehr und mehr gehe ich dazu über, PHP-Programme und HTML-Seiten aus Bausteinen zusammenzusetzen. Im HTML sind das noch divs, ich muss mich mal mit section beschäftigen.

Wenn ich etwa in mehreren Webseiten ein input-Feld habe, das bei der Eingabe per Ajax Vorschläge für Ortsnamen holt, gehört die entspr. .js Datei dazu ebenso wie CSS Angaben.

Nun meckert der HTML-Validator, wenn ich CSS-Angaben in dem div formuliere, wo sie logisch hingehören. Der Firefox macht's trotzdem, aber unbekannte Browser?

An einem ähnlichen Baukasten bastele ich auch noch. Ich hatte da 1999 schon mal einen, der noch mit inline-Styles geabeitet hat, was ja uch funktioniert. Der Vorteil war, das für jedes Objekt alle Parameter nebst den zulässigen Styles automatisch abgefragt werden konnten. Selbst die zugehörigen PHP-Codes standen damals noch in der DB...

Zurück zum Thema:
Da Du ja PHP einsetzt, kannst Du die Module auch mit PHP zusammensetzen. Und dann gibt es eben für jedes Dokument mehrere Container (PHP-Arrays), in denen die dazugehörigen Funktionen, Module und CSS-Angaben gesammelt werden. Zum Schluss werden sie konsolidiert und im Dokument dort gesammelt ausgegeben, wo man sie sinnvollerweise auch manuell einsetzen würde.

Aber ich bin selber auch noch weit vom Ziel entfernt. Es kommen ja täglich Begehrlichkeiten hinzu, die jesdes Mal wieder das Datenmodell oder die "Geschäftsregeln" beschädigen...

Liebe Grüße
Tom S.

[Julius]

Hallo Linuchs,

Wenn ich etwa in mehreren Webseiten ein input-Feld habe, das bei der Eingabe per Ajax Vorschläge für Ortsnamen holt, gehört die entspr. .js Datei dazu ebenso wie CSS Angaben.

Nun meckert der HTML-Validator, wenn ich CSS-Angaben in dem div formuliere, wo sie logisch hingehören. Der Firefox macht's trotzdem, aber unbekannte Browser?

Dann solltest du das vielleicht in der Art lösen, wie dedlfix es vorschlug:
Dein Projekt intern (bzw. in deinem Falle auf dem Server) Komponenten-basiert zu organisieren und dann HTML, CSS und JS separat ausliefern.

Du könntest beispielsweise die Ausgabekontrolle von PHP benutzen und das HTML ausgeben, und Funktionen definieren, die JS und CSS bzw. die darauf verweisenden Links sammeln und dann am Ende des Prozesses der Seitengenerierung ein HTML-Grundgerüst ausgeben, in das in den Head des HTML dein CSS und JS oder bessser die Referenzen darauf eingefügt werden und dann via ob_end_flush() dein HTML ausgegeben wird.

Ist es nicht die objektorientierte Idee, dass Variablen und Verfahren gemeinsam in einer "Kiste" liegen?

Ja, in Programmiersprachen. Zusätzlich auch noch Vererbung: Du hast beispielsweise Code, der einen bestimmten Typ von Formular abwickelt und packst ihn in eine Klasse. Dann kannst du diese Klasse um die gewünschten Funktionen erweitern, aber trotzdem noch die ursprüngliche Klasse nutzen. Ich fange gerade erst an, echte Programme objektorientiert zu schreiben...

Und was sollen die ständigen Ermahnungen, CSS nicht als inline in einen Tag zu packen? Ich will nicht für jeden Super-Sonderfall die weit weg liegende "Zentrale" verändern.

Wenn dieser „Super-Sonderfall“ (wenn du eine Funktion mehr als einmal einbindest, ist das m. M. n. keiner mehr) häufiger verwendet wirst, hast du überall inline-Code drin stehen. Der Performance ist das nicht zuträglich.

Außerdem ist ein div mit einer bestimmten Gestaltung für dich als Entwickler ein Sonderfall, wenn der Nutzer diese Seite bzw. eine Seite, die diese Vorlage benutzt, mehrmals aufruft, wird dieses CSS jedes Mal mit übertragen – es ist also für den Nutzer kein Sonderfall mehr. Hier lohnt es sich, das (mit anderen Deklarationen, es sollen ja nicht zu viele einzelne Dateien übertragen werden) in eine CSS-Datei zu packen und diese dann einzubinden.

Ein oder mehrere, zentrale und ggf. minifizierte Stylesheets und Scripte können clientseitig gecacht werden und ersparen damit letztlich auch dir Traffic. Es kann allerdings durchaus sinnvoll sein, das CSS und JS zusätzlich zu modularisieren und damit nicht auf jeder Seite alles einzubinden:
Wenn du beispielsweise CSS und JS für den öffentlichen Teil deiner Site hast und welches für den Bereich für Eingeloggte und das in separaten Dateien vorliegen hast, dann kannst du dafür sorgen, dass nur im Bereich für Eingeloggte alle Dateien geladen werden.

Außerdem verbaust du dir die Möglichkeit, via Content-Security-Policy strikte Regeln für inline-Dinge (Bilder, JS und Styles) zu definieren und verschenkst damit die Möglichkeit, zu verhindern, dass eventuell auftretende XSS-Lücken ausgenutzt werden können.

Gruß
Julius

[JürgenB]

Hallo Linuchs,

ich kann dein Problem gut verstehen. Ich biete zwei Scripte an, bei denen es mir auf möglichst einfache Einbindung ankommt: entsprechendes HTML und dahinter das Script-Element mit src. Weiteres CSS jetzt im Head einzubinden, war hier keine Option, da viele Anwender meiner Scripte „HTML-Baukästen“ verwenden, und teilweise gar keinen Zugriff auf den Head-Bereich haben, oder nicht wissen, wie sie dahin kommen. Daher erstelle ich in dem einen Script das einfache CSS per Javascript, im anderen Script binde ich die CSS-Datei per Javascript ein. So müssen die Anwender nur einen kompakten Block ins HTML einfügen.

Gruß
Jürgen