Werte zwischen Fenster und PopUp tauschen

[EKKi]

Mahlzeit molily,

Sorry, aber du weißt offenbar gar nicht, was du da redest, wenn du solche Sätze aufstellst. Damit ignorierst du nämlich jegliche Realität seit ungefähr 15 Jahren.

Ich weiß sehr wohl, wovon ich rede. Und ich schreibe solche Sätze bewusst.

Eine Linkliste soll doch darstellen, wohin man von einem bestimmten Punkt aus gelangen soll.

Da ist massig Interpretationsspielraum: Ich will von einer Stelle im Formular zu einem Date-Picker für dieses Formularfeld gelangen. Ist das nun ein Link? Oder keiner, nur weil die Funktionalität mit JavaScript gelöst wird?

Das hat doch damit primär gar nichts zu tun. Es geht darum, was dieser "Date-Picker" ist. Ist es eine externe Ressource? Dann ist es ein Link, der auch zu diese externen Ressource führen sollte. Dass man diesen Link dann mit Javascript manipulieren kann, so dass er sich nicht wie ein normaler Link verhält, sondern z.B. ein Popup öffnet, wenn der Browser Javascript unterstützt, ist klar. Das hat aber mit der logischen Struktur des Dokuments wenig zu tun.

Das Web war noch nie so eindimensional. Oder nur ganz kurze Zeit, als es noch auf Tim Berners-Lees localhost passierte. Dann erfand jemand Browser mit fensterbasiertem GUI,

Naja, die haben aber an der "Eindimensionalität" (wie Du es nennst) nichts geändert.

JavaScript, Frames und so weiter.

Javascript schon, das gebe ich zu (Frames hingegen wiederum nicht - das ist einfach nur die Aufteilung des Anzeigebereichs, so dass man mehrere Dokumente auf einmal betrachten kann). Allerdings ändert Javascript zwar etwas am Wesen des WWW, das nicht mehr nur aus miteinander vernetzten Dokumenten besteht, sondern Interaktivität bietet - jedoch nichts an der grundsätzlichen Konstruktion von HTML. Vielleicht ist einfach mittlerweile HTML nicht mehr das geeignete Mittel für das WWW?

Webseiten, die clientseitig dynamisch sind.

Sicher. Aber deswegen dürfen wir die Struktur der Seite/des Dokuments nicht verhunzen.

Noch so ein moralisches Dogma.

Mag sein. Aber es ist richtig.

Ich sehe das ganz anders, weil ich in der gegenwärtigen HTML-Anwendung keinen reinen Hypertext sehe.

HTML ist Hypertext. Punkt. Nicht nur, dass es im Namen steht (ich weiß, Namen sind Schall und Rauch), aber HTML war ursprünglich als Dokumentbeschreibungs- bzw. Seitenauszeichnungssprache gedacht und ist es vom Grundkonzept her immer noch. Es gibt keine "HTML-Anwendungen". Es gibt lediglich schick formatierte und layoutete Dokumente, denen eine gewisse Interaktivität verpasst wurde.

Mit HTML lassen sich freilich Hypertexte auszeichnen und ganz klassische Hypertext-Anwendungen mit serverseitiger Dynamik umsetzen. Bei jeder Benutzer-Aktion wird eine Ressource (das »Dokument«) vom Server bezogen, die eine eindeutige URI hat.

Richtig. Genau dafür war und ist HTML gedacht. Zumindest in den Versionen, die mir bekannt sind. Es mag sein, dass sich das mit HTML 5.0 oder mit einem - vielleicht für die heutigen Anforderungen des WWW besser geeigneten - Nachfolger von HTML ändert ... das ändert aber nichts am Status quo.

Natürlich hat dieses klassische Modell seine Vorzüge. Aber es stirbt aus, die meisten Webseiten werden mit immer mehr clientseitiger Logik aufgebrezelt.

Nein. Es stirbt nicht aus. Es ist und bleibt korrekt. Nur weil immer mehr Leute gewisse Grundlagen nicht (mehr) beachten oder Strukturen und Elemente verhunzen, ist das kein Grund,

Ajax ebnet den Weg für Single-Page-Applications, die das klassisches Web im Sinne von Hypertext-Dokumenten, HTTP-Ressourcen und -URIs verdrängen.

Kann es gerne machen - ich würde es ja sehr begrüßen. Ich selbst liebe ja auch die Interaktivität von genial gestrickten "Webanwendungen". Aber HTML ist u.U. nicht (mehr) die geeignete Grundlage dafür. Wenn man etwas, was für einen ganz anderen Zweck gedacht und konstruiert war, als das, für das man es jetzt benutzen will, dermaßen stark verbiegen muss, um sein Ziel zu erreichen, dass die grundlegende Struktur und die innere Logik verloren geht, sollte man sich fragen, ob man sich des geeigneten Mittels bedient - oder vielleicht lieber etwas anderes zu Hilfe nehmen sollte.

Wenn du die Funktion von HTML auf eine bloße Beschreibungssprache für Hypertexte begrenzt, blendest du diese Realität aus.

Nein. Ich verweise lediglich darauf, was HTML IST ... im Gegensatz zu dem, wozu es BENUTZT bzw. MISSBRAUCHT wird.

Und anstatt sich mit ihr auseinanderzusetzen, belegst du sie mit moralischen Verboten.

Nein. Ich weise lediglich darauf hin, dass gewisse Vorgehensweisen von der Grundüberlegung her falsch sind - und zwar schlicht und ergreifend, weil das Mittel, dass man sich zur Umsetzung seiner Ideen und Ziele auserkoren hat, nicht das geeignete ist. HTML ist für gewisse Sachen da und kann einiges. Anderes KANN es per definitionem nicht - aber dafür ist es auch nicht gedacht. Dann sollte man es auch nicht dafür benutzen.

Glaubst du, das das von Erfolg gekrönt ist?

Das steht nicht zur Debatte.

Auf der Ebene von bloßer Dokument-Beschreibung kann man sich sinnvoll über »richtige Semantik« Gedanken machen, darüber hinaus stößt man auf Widersprüche.

Sicher. Aber für mehr war HTML nie gedacht (und ist es heutzutage selbst mit HTML 4.01 auch nicht wirklich). Abstrakte Beschreibungen, wie verschiedene Elemente, die alle mehr oder weniger mit Textausgaben zu tun haben, garniert mit ein paar Bildchen hier, ein paar tabellarischen Daten dort, als Abrundung ein paar Listen und das eine oder andere Formular - das ist HTML. Man kann dem Ganzen dann natürlich eine Interaktivität überstülpen, um es einfacher bedienbar zu machen ... aber man darf dabei nicht die Struktur der grundlegenden Ebene zerstören oder missbrauchen: ansonsten entwickelt man kein(e) HTML(-Anwendungen), sondern Zeichensalat, der zufälligerweise von gewissen Programmen so dargestellt wird, wie man es wünscht.

Eigentlich wirst du keine nennenswerte Webanwendung mit »Dokumenten« mehr finden, die auf andere »Dokumente« verlinken.

Wie definierst Du "nennenswert"?

Schau dir mal die hunderten Ajax-Anwendungen an, die viele tagtäglich nutzen. Da werden ständig a-Elemente »missbraucht«, weil die Autoren auf das dem Benutzer hinlänglich bekannte UI-Pattern von Hyperlinks zurückgreifen: Blauen Text mit Unterstrich, spezieller Zeiger, spezielle Anspringbarkeit usw.

Ja und? Millionen Fliegen fressen Scheiße - was soll mir das sagen? Es ändert nichts daran, dass es falsch ist.

Sicherlich wäre es für alle hilfreicher, wenn es eine geeignetere Grundlage für Webanwendungen gäbe als HTML ... zur Zeit gibt es aber AFAIK keine.

Ich weiß ehrlich gesagt nicht, wer dadurch einen Nachteil hatte.

Keine Ahnung, ich auch nicht. Aber nochmal: wenn jemand fragt, wie er was machen kann oder soll, oder ob das, was er vorhat OK ist, wird man ihn ja wohl noch darauf hinweisen dürfen, dass sein Vorgehen nicht HTML-konform ist. Ob er es dann trotzdem tut oder nicht, bleibt doch trotzdem ihm überlassen.

Schön, aber warum so einen Kopfstand? Der »Semantik« wegen? Ich schreibe keine reinen Hypertexte, sondern Webanwendungen. Da HTML nicht XUL oder XAML ist,

... hat es nicht deren Möglichkeiten. Wenn man diese Möglichkeiten benötigt, sollte man auch XUL oder XAML benutzen und nicht eine Hilfskrücke, die man dann anschließend versaut.

habe ich keinen Anspruch, etwas, was nicht vom HTML-Vokabular abgedeckt wird, in HTML korrekt auszuzeichnen

... und missbrauchst also HTML für etwas, für das es nicht gedacht ist - ergo solltest Du also eigentlich kein HTML schreiben.

Wenn ich eine UI-Control haben will, die wie ein Hyperlink aussieht, sich wie ein Hyperlink anfühlt, setze ich einen Hyperlink.

Das ist eben das falsche Vorgehen. Du setzt einen Hyperlink, wenn Du tatsächlich einen Hyperlink hast. Ansonsten ist es kein Link, also ist das <a>-Element schlichtweg falsch. Auch wenn Du das nicht hören magst und auch wenn das natürlich aus Gründen der Bequemlichkeit bei der Erstellung und der Interaktivität einfacher wäre, ein Element für etwas zu missbrauchen, für das es nicht gedacht ist. Das ist dann aber eine Unzulänglichkeit der Browser oder Inflexibilität der gewählten Grundlage (HTML). Beides könnte man ändern. Oder Du verzichtest eben auf sauberes Markup und machst es trotzdem falsch - das bleibt Dir ja unbenommen. Nur darfst Du Dich dann nicht darüber beschweren, wenn Dir Leute sagen, dass Du das falsche Element benutzt ... sie haben nun einmal Recht.

Auch wenn ich kein reines Hypertext-Dokument habe, sondern eine JavaScript-Anwendung auf HTML-Basis.

Was an sich schon eine kranke Konstruktion ist. Aber heutzutage eben kaum anders machbar - aufgrund der Beschränkungen sowohl der Browser als auch von HTML

Auch wenn ich gar nicht notwendig auf ein Hypertext-Dokument oder eine andere HTTP-Ressource verlinke, sondern gegebenfalls nur ein Script anstoßen will, dass die Sache mit den Ressourcen im Hintergrund oder eben im Popup-Fenster erledigt.

Und schon wären wir wieder beim Thema: wenn Du nichts verlinkst, ist <a> falsch. Ist genau dasselbe wie beim Tabellenlayout ...

Schau dir mal HTML 5 und Web Forms 2.0 an, da trägt man der Praxis Rechnung, dass HTML viel mehr ist als bloß »Dokumentbeschreibung« und Hypertextualität.

Die Frage wäre da nur, inwiefern der Begriff "HTML" dann noch angemessen ist. Ich gebe Dir Recht, neue Spezifikationen, neue Idee und neue Verfahren sind oft "besser" als Althergebrachtes - wie ich oben schon schrieb, nutze und entwickle ich ja selbst gern "Webanwendungen". Auch ich habe schon das eine oder andere Mal Elemente für etwas missbraucht, für das sie nicht gedacht sind (Elfenbeinturm mag ich nämlich auch nicht) ... aber nur, wenn es wirklich gar nicht anders ging, mit erheblichen Bauchschmerzen und dem Wissen, etwas falsch zu machen.

Wenn du command, datagrid, progress, output usw. in HTML 5 seht, muss dir ja die Semantik-Hutschnur platzen. ;)

Wieso sollte sie? Wenn es dann endlich Elemente für etwas gibt, für das vorher unschuldige andere Elemente (die damit eigentlich gar nichts zu tun hatten) missbraucht wurden, wird der Code doch wieder sauberer - und damit semantischer.

Da wird genau das angegangen, was ich sagen will.

Ich doch auch.

Dann viel Glück dabei, mit abgehobenen Argumenten bei Leuten zu landen, die bloß funktionierende Websites bauen wollen.

Das sind keine abgehobenen Argumente, das sind Grundlagen. Wenn man diese kennt und beherrscht und trotzdem keine andere Möglichkeit findet, gewisse Dinge so zu bauen, dann kann und darf man das natürlich gerne tun (wer wäre ich, dass ich so etwas verbieten wollte?) - man sollte sich dessen aber bewusst sein.

JavaScript-Logik einbauen geht nicht immer »semantisch«. Zumindest nicht mit dem derzeitigen HTML.

Mein Reden.

Das ist nicht schlimm, sondern muss man akzeptieren, um sich der wichtigen semantischen Textauszeichnung zuwenden zu können.

Schon - bewusst sein sollte man sich dessen trotzdem ... und vielleicht vorher versuchen, sein Problem so zu lösen, dass man trotzdem halbwegs semantisch bleibt (wenn es denn nicht anders geht).

MfG,
EKKi