Werte zwischen Fenster und PopUp tauschen

[derMartin]

Hi,

ich habe folgendes Problem. Ich habe ein Fenster mit einem Formular. Dieses öffnet mit Java Script ein PopUp. Auf dem PopUp wird per Link ein Wert ausgewählt (ist ein Kalender), trägt diesen Wert in das ElternFormularfeld ein und schliesst das PopUp.

Elternfenster:

  
<form name="task" action="task.php" method="POST">  
<input name="form[datum]" type="text" readonly>  
<a href="" onClick="javascript:window.open('calendar.php?','_blank', 'width=350, height=300, top=200, left=400')">Kalender</a>  
  
PopUp:  
[code lang=html]  
<a href="javascript:window.opener.document.task.elements['form[datum]'].value='11.11.2008';window.close();"></a>  

Es funktioniert auch soweit alles. Aber, wenn ein zweites Mal das PopUp öffne, ohne vorher das Form zu submitten, dann trägt er den Wert wieder in das Feld ein, der vor dem ersten Öffnen des PopUp's im Feld auf dem Elternfenster war.

Kennt jmd das Problem bzw. weiss eine Antwort?

Danke

[molily]

Hallo,

Aber, wenn ein zweites Mal das PopUp öffne, ohne vorher das Form zu submitten, dann trägt er den Wert wieder in das Feld ein, der vor dem ersten Öffnen des PopUp's im Feld auf dem Elternfenster war.

Ich verstehe den Satz und damit das Problem leider nicht. (Der Satz ist sprachlich etwas konfus.) Könntest du das vielleicht nochmal erklären und ggf. ein Beispiel hochladen? Welcher Wert wird nun eingetragen? Der ursprüngliche?
Der gezeigte Beispielcode jedenfalls kann nur einen Wert eintragen, da hast du wahrscheinlich das Kalender-Script ausgeblendet. Dann wird eher dort der Fehler liegen, vermute ich.

Mathias

[EKKi]

Mahlzeit derMartin,

Elternfenster:

<input name="form[datum]" type="text" readonly>
<a href="" onClick="javascript:window.open('calendar.php?','_blank', 'width=350, height=300, top=200, left=400')">Kalender</a>

  
Erstens ist die Verwendung von "javascript:" sinnlos und überflüssig, zweitens brauchst Du keinen Link, wenn Du nichts verlinken willst. Drittens: wieso übergibst Du nicht den aktuellen Wert des Eingabefelds (dann hättest Du nämlich das weiter unten beschriebene Problem nicht)?  
  
`<span onclick="window.open('calendar.php?datum=' + document.getElementsByName('form[datum]').value, '_blank', 'width=350,height=300,top=200,left=400');">Kalender</span>`{:.language-html}  
  
Dann muss Dein calendar.php nur noch etwas mit dem übergebenen Datum anfangen können ...  
  
  

> PopUp:  
> ~~~html
  

> <a href="javascript:window.opener.document.task.elements['form[datum]'].value='11.11.2008';window.close();"></a>  
> 

Wieder: wenn Du nichts verlinkst, brauchst Du keinen Link und die Verwendung des Pseudo-Protokolls "javascript:" ist nicht sinnvoll - besser wäre:

<span onclick="window.opener.document.task.elements['form[datum]'].value='11.11.2008'; window.close();">Datum übernehmen</span>

(Wobei ich mich ja wundere, wieso Du da ein festes Datum drin stehen hast - oder dient das nur zur "Verdeutlichung"?)

Es funktioniert auch soweit alles. Aber, wenn ein zweites Mal das PopUp öffne, ohne vorher das Form zu submitten, dann trägt er den Wert wieder in das Feld ein, der vor dem ersten Öffnen des PopUp's im Feld auf dem Elternfenster war.

Woher bekommt der Kalender denn seinen Initialwert?

MfG,
EKKi

[molily]

Hallo,

besser wäre:

[code lang=html]<span ...

Bestimmt nicht. Ein bloßes span mit onclick ist in jeder Hinsicht ein Rückschritt.
a oder button ist schon recht klug, weil auch mit der Tastatur anspringbar und als Schaltfläche maschinell und visuell unabhängig von Autoren-Styles erkennbar. Man sollte diese Elemente sinnigerweise mit JavaScript einfügen, dann kann man ruhig <a href="javascript:..."> schreiben.

Mathias

[EKKi]

Mahlzeit molily,

a oder button ist schon recht klug, weil auch mit der Tastatur anspringbar und als Schaltfläche maschinell und visuell unabhängig von Autoren-Styles erkennbar. Man sollte diese Elemente sinnigerweise mit JavaScript einfügen, dann kann man ruhig <a href="javascript:..."> schreiben.

Kann man, sollte man aber nicht. Ein Link ist ein Link ist ein Link - nichts anderes. Wenn er nicht linkt, ist er kein Link.

Oder, um es mit Cheatahs Worten auszudrücken:

Eben. Ein Link verlinkt eine Ressource, nichts sonst. Er wird *nicht* eingesetzt als Platzhalter-Element für JavaScript-Funktionalität; er wird *nicht* eingesetzt um einen anderen Mauszeiger zu bekommen; er wird *nicht* eingesetzt um bei Mouseover eine Unterstreichung oder einen anderen Effekt zu erhalten. Das alles sind keine Aufgaben eines Link-Elements.

Ein Button wäre besser als ein bloßes "nichts" (was ein <span> ja prinzipiell ist), da gebe ich Dir recht. Aber ein Link ist das Dingenskirchen, das per Javascript einen Wert woanders reinschreibt und das aktuelle Fenster schließt, nicht, war es nie und wird es nie sein. Also ist und bleibt <a> falsch.

MfG,
EKKi

[molily]

Hallo,

Ein Link verlinkt eine Ressource, nichts sonst. Er wird *nicht* eingesetzt als Platzhalter-Element für JavaScript-Funktionalität; er wird *nicht* eingesetzt um einen anderen Mauszeiger zu bekommen; er wird *nicht* eingesetzt um bei Mouseover eine Unterstreichung oder einen anderen Effekt zu erhalten. Das alles sind keine Aufgaben eines Link-Elements.

Achja. Cheatahs apodiktische Art, als würde er geoffenbarte Wahrheiten aussprechen. Er spricht bloß moralische Dogmata aus (»Pfui, das macht man nicht!«), stichhaltige Argumente nennt er nicht.

Naja, sein einziges ist vielleicht: »das Element ist nicht dafür gedacht«. Korrekt, aber das Argument zählt nicht, weil es in HTML ohnehin kein besseres Element gibt, das für diese Aufgaben besser geeignet wäre.

Wir leben nicht mehr im Zeitalter von HTML 2, sondern im Jahr 2008, wo wir es mit abermillionen JavaScript-gestützten Webanwendungen zu tun haben. HTML ist nicht XUL oder sonst irgendeine Interface-Sprache. Niemand hat damals wirklich an Scripting gedacht, Einsprengsel wie <button type=button> sind marginale Ausnahmen. Es gibt kein wirklich »semantisch korrektes« Element für reine JavaScript-Schaltflächen. (button kommt aus dem Kontext der Formularfelder - als gäbe es eine Analogie.) Es gibt nur Argumente für und gegen bestimmte Elemente, weil diese bereits ein bestimmtes Verhalten haben. Und a hat da viele Vorteile - gerade weil es nicht bloß als »Ressourcen-Verweis«, sondern auch als dokumentinterne Schaltfläche bekannt und verbreitet ist.

Im Übrigen verzerrt Cheatahs Darstellung, warum man a einsetzt: Andere Elemente kann man mit CSS umformatieren, aber das Verhalten von a-Elementen lässt sich nicht auf diese Weise abbilden. Ein a-Element verhält sich browserübergreifend und unabhängig vom Autoren-Stylesheet in allen JavaScript-fähigen Browsern als eine fokussierbare und anspringbare Schaltfläche. Ob da nun eine HTTP-URI verlinkt ist oder nur JavaScript getriggert wird, ist praktisch irrelevant, sondern nur eine obskure und esoterische Frage der »Semantik«. button taucht bspw. nicht in generierten Linklisten auf, es ist nicht oder anders anspringbar und so weiter.

http://forum.de.selfhtml.org/archiv/2008/3/t168236/#m1097856
http://forum.de.selfhtml.org/archiv/2008/4/t169545/#m1107626

Aber ein Link ist das Dingenskirchen, das per Javascript einen Wert woanders reinschreibt und das aktuelle Fenster schließt, nicht, war es nie und wird es nie sein.

Ja! Weil HTML Hypertext Markup Language ist und nicht XUL, XAML, Qt- oder GTK-XML. Aber mit HTML schreiben wir immer noch Webseiten. Webseiten, die clientseitig dynamisch sind. Webseiten, die JavaScript-Schaltflächen beinhalten. Webseiten, die bestimmte vorgegebene und verbreitete Interface-Pattern nutzen müssen, um bedienbar zu sein. Also mach mal eine klare und brauchbare Ansage, wie du dir vorstellst, wie das »richtig« zusammengehen soll. Ich sehe nicht, dass das so einfach ist, wie ihr suggeriert.

Also ist und bleibt <a> falsch.

Sorry, aber weltfremder und praxisferner gehts gar nicht.

Nennt doch mal Argumente, anstelle bloß moralisch daherzusülzen. Echt, das kotzt mich an, welche Nicht-Bereitschaft es hier gibt, sich mit Problemstellungen und Lösungen vernünftig und argumentativ auseinanderzusetzen. Wenn ich Bock auf Litanei habe und meine Überzeugungen nicht hinterfragen will, trete ich einer Kirche bei, aber bewege mich nicht im SELFHTML-Forum und belästige Fragesteller mit meinen Glaubenssätzen (»Das darfst du nicht, das ist falsch!«).

Lasst die Leute doch machen - machen sie sowieso, schließlich gibt es Millionen Webanwendungen, die es »falsch« machen. Oh, und niemandem tats weh! Im Gegenteil: Die Welt dreht sich immer noch. Und das Web ist benutzbarer geworden. Aber das SELFHTML-Forum bleibt ein gallisches Dorf.

Mathias

[Siechfred]

Lasst die Leute doch machen - machen sie sowieso, schließlich gibt es Millionen Webanwendungen, die es »falsch« machen. Oh, und niemandem tats weh! Im Gegenteil: Die Welt dreht sich immer noch. Und das Web ist benutzbarer geworden. Aber das SELFHTML-Forum bleibt ein gallisches Dorf.

Wohl gesprochen, Miraculix ;)

Siechfred

[EKKi]

Mahlzeit molily,

Ein a-Element verhält sich browserübergreifend und unabhängig vom Autoren-Stylesheet in allen JavaScript-fähigen Browsern als eine fokussierbare und anspringbare Schaltfläche.

Mag sein, dass es sich so verhält - es IST aber keine. Es dient dazu, eine logische Verbindung zu einer anderen Ressource (oder zu einem bestimmten Punkt der aktuellen Ressource) herzustellen. Was der Browser dann mit der Information, die er in den Attributen des Elements findet, macht, ist erstmal irrelevant.

Ob da nun eine HTTP-URI verlinkt ist oder nur JavaScript getriggert wird, ist praktisch irrelevant, sondern nur eine obskure und esoterische Frage der »Semantik«.

Und allein die ist bei einer Markup Language relevant. Und es ist keineswegs irrelevant, ob eine HTTP-URI verlinkt ist oder nicht. Genau dafür und nur dafür gibt es schließlich das <a>-Element. Javascript kann man mittels der geeigneten Eventhandler von fast allen Elementen triggern.

button taucht bspw. nicht in generierten Linklisten auf,

Wozu auch? Es ist kein Link und gehört daher auch nicht in eine Linkliste. Eine Linkliste soll doch darstellen, wohin man von einem bestimmten Punkt aus gelangen soll. Da hat eine interaktive Funktionalität innerhalb einer Ressource mal gar nichts zu suchen.

es ist nicht oder anders anspringbar und so weiter.

DAS ist dann aber ein Problem des Browsers. Oder aber des Entwicklers, der den Button nicht mit einem http://de.selfhtml.org/html/formulare/tastatur.htm#tabreihenfolge@title=Tabindex versehen hat.

Aber mit HTML schreiben wir immer noch Webseiten.

Korrekt. Dokumente.

Webseiten, die clientseitig dynamisch sind.

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

Webseiten, die JavaScript-Schaltflächen beinhalten.

Es gibt keine "Javascript-Schaltflächen". Es gibt vielleicht Elemente, die sich dynamisch verhalten.

Also mach mal eine klare und brauchbare Ansage, wie du dir vorstellst, wie das »richtig« zusammengehen soll.

Ganz einfach: dem Element, das bei einem Klick irgendwie reagieren soll, den passenden Eventhandler geben - fertig. Wenn es darüber hinaus per Tastatus ansteuerbar sein soll, noch einen Tabindex verpassen. IMHO müsste das (und natürlich die gewünschte Formatierung des Aussehens mittels CSS) reichen.

Ich sehe nicht, dass das so einfach ist, wie ihr suggeriert.

Ich schon. Was soll daran nicht einfach sein? Oder falsch? Oder nicht funktionieren?

Also ist und bleibt <a> falsch.

Sorry, aber weltfremder und praxisferner gehts gar nicht.

Mag sein. Aber richtig. Und IMHO auch umsetzbar (s.o.).

Lasst die Leute doch machen - machen sie sowieso, schließlich gibt es Millionen Webanwendungen, die es »falsch« machen.

Machen sie ja auch. Aber wenn hier jemand fragt, warum was nicht geht oder wie er es besser machen sollte, dann darf man ihn doch wohl darauf hinweisen, dass das, was er bisher gemacht hat, eigentlich nicht richtig ist und ihm Tipps geben, wie er es besser machen kann? Ob und wie er das dann umsetzt, bleibt doch immer noch ihm selbst überlassen ... und wenn er derartige Hinweise und Tipps nicht möchte, ist er hier sowieso im falschen Forum, die sind hier ja an der Tagesordnung. :-)

Oh, und niemandem tats weh! Im Gegenteil: Die Welt dreht sich immer noch. Und das Web ist benutzbarer geworden. Aber das SELFHTML-Forum bleibt ein gallisches Dorf.

Nein. Ein verbohrter Haufen von Idealisten, die sich auf die Fahnen geschrieben haben, Erkenntnis in das von Unwissenheit erfüllte Röm^H^Hedmondsche Imperium zu tragen ...

MfG,
EKKi

[molily]

Hallo,

Es dient dazu, eine logische Verbindung zu einer anderen Ressource (oder zu einem bestimmten Punkt der aktuellen Ressource) herzustellen. Was der Browser dann mit der Information, die er in den Attributen des Elements findet, macht, ist erstmal irrelevant.

Also mir ist nicht egal, was beim Benutzer tatsächlich ankommt, ob das Ergebnis verständlich, benutzbar und robust ist. Neben dem Semantik-Elfenbeinturm gibts halt noch andere Sphären, die in Betracht zu ziehen wären.

Ob da nun eine HTTP-URI verlinkt ist oder nur JavaScript getriggert wird, ist praktisch irrelevant, sondern nur eine obskure und esoterische Frage der »Semantik«.

Und allein die ist bei einer Markup Language relevant.

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.

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?

Da hat eine interaktive Funktionalität innerhalb einer Ressource mal gar nichts zu suchen.

Kann man das so einfach trennen? Wir reden hier über die Paralleldarstellung von mehreren Ressourcen. Über Popups, Iframes und Ajax werden nicht mehr bloß statische Ressourcen im Browser angezeigt, die ausschließlich über Hyperlinks und Formulare (und einem anschließenden Ressourcen-Wechsel im gesamten Fenster) mit dem Server kommunizieren können.

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, JavaScript, Frames und so weiter.

Oder aber des Entwicklers, der den Button nicht mit einem http://de.selfhtml.org/html/formulare/tastatur.htm#tabreihenfolge@title=Tabindex versehen hat.

Wie gesagt - manche Browser trennen das Durchlaufen von Links und Formularfeldern. Screenreader haben spezielle Formular-Lesemodi. Zu welcher Gruppe gehören wohl Buttons mit tabindex? ;)

Webseiten, die clientseitig dynamisch sind.

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

Noch so ein moralisches Dogma.

Ich sehe das ganz anders, weil ich in der gegenwärtigen HTML-Anwendung keinen reinen Hypertext sehe. 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.

Natürlich hat dieses klassische Modell seine Vorzüge. Aber es stirbt aus, die meisten Webseiten werden mit immer mehr clientseitiger Logik aufgebrezelt. Ajax ebnet den Weg für Single-Page-Applications, die das klassisches Web im Sinne von Hypertext-Dokumenten, HTTP-Ressourcen und -URIs verdrängen.

Wenn du die Funktion von HTML auf eine bloße Beschreibungssprache für Hypertexte begrenzt, blendest du diese Realität aus. Und anstatt sich mit ihr auseinanderzusetzen, belegst du sie mit moralischen Verboten. Glaubst du, das das von Erfolg gekrönt ist?

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. Eigentlich wirst du keine nennenswerte Webanwendung mit »Dokumenten« mehr finden, die auf andere »Dokumente« verlinken.

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.

Ich weiß ehrlich gesagt nicht, wer dadurch einen Nachteil hatte. Im Gegenteil: Wenn man das Dogma »Nur button ist erlaubt« anwenden würde, müssten all diese Webanwendungen Hacks einsetzen, um button oder ein anderes Element dazu zu bringen, sich wie ein a zu verhalten. Die Benutzbarkeit würde dadurch eher geschmälert und die Entwicklung von solchen Anwendungen erschwert.

dem Element, das bei einem Klick irgendwie reagieren soll, den passenden Eventhandler geben - fertig. Wenn es darüber hinaus per Tastatus ansteuerbar sein soll, noch einen Tabindex verpassen. IMHO müsste das (und natürlich die gewünschte Formatierung des Aussehens mittels CSS) reichen.

Schön, aber warum so einen Kopfstand? Der »Semantik« wegen? Ich schreibe keine reinen Hypertexte, sondern Webanwendungen. Da HTML nicht XUL oder XAML ist, habe ich keinen Anspruch, etwas, was nicht vom HTML-Vokabular abgedeckt wird, in HTML korrekt auszuzeichnen (wobei ich a nicht weit hergeholt halte - eigentlich sogar weniger als button).

Wenn ich eine UI-Control haben will, die wie ein Hyperlink aussieht, sich wie ein Hyperlink anfühlt, setze ich einen Hyperlink. Auch wenn ich kein reines Hypertext-Dokument habe, sondern eine JavaScript-Anwendung auf HTML-Basis. 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.

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. Wenn du command, datagrid, progress, output usw. in HTML 5 seht, muss dir ja die Semantik-Hutschnur platzen. ;) Da wird genau das angegangen, was ich sagen will.

Aber wenn hier jemand fragt, warum was nicht geht oder wie er es besser machen sollte, dann darf man ihn doch wohl darauf hinweisen, dass das, was er bisher gemacht hat, eigentlich nicht richtig ist und ihm Tipps geben, wie er es besser machen kann?

Dann viel Glück dabei, mit abgehobenen Argumenten bei Leuten zu landen, die bloß funktionierende Websites bauen wollen. JavaScript-Logik einbauen geht nicht immer »semantisch«. Zumindest nicht mit dem derzeitigen HTML. Das ist nicht schlimm, sondern muss man akzeptieren, um sich der wichtigen semantischen Textauszeichnung zuwenden zu können.

Mathias

[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

[Tim Tepaße]

Hallo Mathias,

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.

Kleiner Einspruch: Hier kann das gefährlich sein, wenn man die in HTTP eingebaute Semantik von HTTP (die Sicherheit & Idempotenz der Verben) missachtet. Einfach, weil dies in Browsern und Proxies und sonstigen Caches sehr relevant und auch sehr praktisch ist. Siehe das Paradebeispiel des Google Web Accelerators.

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. Wenn du command, datagrid, progress, output usw. in HTML 5 seht, muss dir ja die Semantik-Hutschnur platzen. ;) Da wird genau das angegangen, was ich sagen will.

Hm? Da wird doch haufenweise Semantik eingebracht, mal ganz abgesehen von den ARIA-Annotationen, ob nun mit Doppelpunkt oder Hyphen. Hui!

Tim

[derMartin]

Hi,

erstmal danke an EKKi...ich hatte den Initialwert erst anders (mit einer PHP Funktion) eingefügt. Aber jetzt läuft es eigentlich so, wie ich es haben wollte.
Und ja, die 11.11.xxx war nur zur Verdeutlichung. Der Wert wird dynamisch generiert.
Span benutze ich erstmal nicht, da es nicht 100% ersichtlich ist, dass man da drauf klicken kann und es ja auch "dumme" User gibt (nicht böse gemeint).

So jetzt zu meinem anderen Problem.
Beispiel
Ich habe auf dem Elternformular den Wert 19.01.2008. Dieser wird an das PopUp übergeben. Wähle ich dann den 20.01.2008 aus wird das PopUp geschlossen und der 20.01.2008 erscheint auf dem Formular. Klicke ich jetzt aber nochmal auf den Kalenderlink öffnet sich das PopUp und der 20.01.2008 wird übergeben. ABER!! Wenn ich das PopUp einfach schliesse, ohne ein Datum ausgewählt zu haben wird der 19.01.2008 angezeigt. Ich hoffe das war jetzt verständlicher :)

[EKKi]

Mahlzeit derMartin,

Span benutze ich erstmal nicht, da es nicht 100% ersichtlich ist, dass man da drauf klicken kann und es ja auch "dumme" User gibt (nicht böse gemeint).

Dann formatiere dasjenige welche Ding, auf das man klicken soll (es ist kein Link, also ist <a> falsch!), entsprechend - dazu ist http://de.selfhtml.org/css/index.htm@title=CSS da.

Ich habe auf dem Elternformular den Wert 19.01.2008. Dieser wird an das PopUp übergeben. Wähle ich dann den 20.01.2008 aus wird das PopUp geschlossen und der 20.01.2008 erscheint auf dem Formular.

Klingt gut.

Klicke ich jetzt aber nochmal auf den Kalenderlink öffnet sich das PopUp und der 20.01.2008 wird übergeben. ABER!! Wenn ich das PopUp einfach schliesse, ohne ein Datum ausgewählt zu haben wird der 19.01.2008 angezeigt.

Klingt weniger gut. Was meinst du mit "einfach schließen"? Klick aufs Kreuzchen rechts oben? Oder hast Du vielleicht noch irgendwo eine Schaltfläche "Schließen" oder sowas und die übergibt noch irgendeinen Wert, den sie nicht übergeben soll?

MfG,
EKKi

[derMartin]

Klicke ich jetzt aber nochmal auf den Kalenderlink öffnet sich das PopUp und der 20.01.2008 wird übergeben. ABER!! Wenn ich das PopUp einfach schliesse, ohne ein Datum ausgewählt zu haben wird der 19.01.2008 angezeigt.

Klingt weniger gut. Was meinst du mit "einfach schließen"? Klick aufs Kreuzchen rechts oben? Oder hast Du vielleicht noch irgendwo eine Schaltfläche "Schließen" oder sowas und die übergibt noch irgendeinen Wert, den sie nicht übergeben soll?

Ja, mit einfach schliessen meine ich das fenster über das Kreuzchen rechts oben schliessen. Also falls der User doch kein Datum ändern will. Nur wird dann komischer weisse immer das Datumsfeld auf dem Elternformular "resetet".

[DerMartin]

Klingt weniger gut. Was meinst du mit "einfach schließen"? Klick aufs Kreuzchen rechts oben? Oder hast Du vielleicht noch irgendwo eine Schaltfläche "Schließen" oder sowas und die übergibt noch irgendeinen Wert, den sie nicht übergeben soll?

Ok, hab den Fehler. Der <a href> Tag resetet das komplette Formular beim klicken. Ist aber irgendwie schon komisch. Egal, mach es dann jetzt mit <span> :)

Trotzdem danke

[EKKi]

Mahlzeit DerMartin,

Egal, mach es dann jetzt mit <span> :)

Probier's doch vielleicht auch mal mit <button>, wie molily vorschlug. Wenn Dich das Aussehen stört: dafür ist http://de.selfhtml.org/css/index.htm@title=CSS da.

MfG,
EKKi

[molily]

Hallo,

Dann formatiere dasjenige welche Ding, auf das man klicken soll (es ist kein Link, also ist <a> falsch!), entsprechend - dazu ist http://de.selfhtml.org/css/index.htm@title=CSS da.

CSS ist für die Darstellung dar, aber »Schaltfläche sein« ist mehr als die Summe dieser Darstellungsteile. Es gibt nur Ärger, wenn man z.B. versucht, die span-Konstruktion Tastatur-bedienbar zu machen. Bei alternativen Darstellungen, die das Autoren-CSS aus Benutzbarkeitsgründen überschreiben, ignorieren oder abändern, und alternativen Lesetechniken wie Screenreadern bricht das ganze auseinander. span ist die ungeeignetste Möglichkeit. Bei button oder a wird in jedem Fall kommuniziert, dass es sich um ein UI-Widget handelt.

Mathias

[EKKi]

Mahlzeit molily,

span ist die ungeeignetste Möglichkeit. Bei button oder a wird in jedem Fall kommuniziert, dass es sich um ein UI-Widget handelt.

Ich habe ja bereits eingeräumt, dass <span> wohl keine gute Idee war - ich wollte einfach das unschadhafteste Element nehmen, das mir einfiel.

Mit <a> wird allerdings nicht kommuniziert, dass es sich um ein UI-Widget, sondern dass es sich um eine Verknüpfung handelt.

MfG,
EKKi

[DerMartin]

Hier mal der Code. Er ist nicht wirklich sehr dynamisch, aber egal:
Elternfenster:

  
<?php  
include 'main.php';  
?>  
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"  
"http://www.w3.org/TR/html4/loose.dtd">  
<html>  
<head>  
<title>MOD Task Management Tool</title>  
<link rel="stylesheet" href="style.css" type="text/css">  
</head>  
<body>  
<form name="task" action="task.php" method="POST">  
Datum:  
<input name="form[datum]" type="text" size="" maxlength="" value="<?php echo $task->getDatum(); ?>" readonly>  
<a href="" onClick="window.open('calendar.php?datum=' + document.task.elements['form[datum]'].value,'_blank', 'width=350, height=300, top=200, left=400')">Kalender</a>  
</form>  
</body>  
</html>  

[DerMartin]

PopUp (hab ich etwas gekürtzt):

  
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">  
<html>  
<head>  
<title>Kalender</title>  
<link rel="stylesheet" href="styles/style.css" type="text/css">  
</head>  
<body text="#000000" bgcolor="#FFFFFF" link="#FF0000" alink="#FF0000" vlink="#FF0000">  
  
<?php  
$tag = array();  
  
//Übergabe von Elternformular auslesen  
 if (isset($_GET["datum"])) {  
  $datum = explode(".",$_GET["datum"]);  
  $monat = $datum[1];  
  $jahr = $datum[2];  
?>  
  
<?php  
 }  
//Übergabe aus Kalender auslesen  
  if ($_SERVER["REQUEST_METHOD"] == "POST") {  
         $monat = $_POST["monat"];  
         $jahr = $_POST["jahr"];  
  }  
//Berechnung erster Wochentag im Monat für Addition zum Index (So = 0, Sa=6)  
$addIndex = 1 + date("w", mktime(0, 0, 0, $monat, 1, $jahr));  
//Samstag auf ersten Index setzen  
if ($addIndex == 7) { $addIndex = 0; }  
//Tage in Tabelle eintragen  
for ($i = 1; $i <= date("t", mktime(0, 0, 0, $monat, 1, $jahr)); $i++) {  
    $index = $i + $addIndex - 1;  
    if ($i < 10) {  
     $tag[$index] = "0".$i;  
    } else {  
     $tag[$index] = $i;  
    }  
}  
  
?>  
<form name="monatjahr" action="calendar.php" method="POST">  
<table width="320" border="0" cellpadding="0" cellspacing="2" style="calday">  
 <tr>  
  <td align="center">  
    <select name="monat" size="1" onchange="document.monatjahr.submit();">  
      <option value="01" <?php if ($monat == '01') { echo 'selected'; } ?>>Januar</option>  
      <option value="02" <?php if ($monat == '02') { echo 'selected'; } ?>>Februar</option>  
      <option value="03" <?php if ($monat == '03') { echo 'selected'; } ?>>März</option>  
      <option value="04" <?php if ($monat == '04') { echo 'selected'; } ?>>April</option>  
      <option value="05" <?php if ($monat == '05') { echo 'selected'; } ?>>Mai</option>  
      <option value="06" <?php if ($monat == '06') { echo 'selected'; } ?>>Juni</option>  
      <option value="07" <?php if ($monat == '07') { echo 'selected'; } ?>>Juli</option>  
      <option value="08" <?php if ($monat == '08') { echo 'selected'; } ?>>August</option>  
      <option value="09" <?php if ($monat == '09') { echo 'selected'; } ?>>September</option>  
      <option value="10" <?php if ($monat == '10') { echo 'selected'; } ?>>Oktober</option>  
      <option value="11" <?php if ($monat == '11') { echo 'selected'; } ?>>November</option>  
      <option value="12" <?php if ($monat == '12') { echo 'selected'; } ?>>Dezember</option>  
    </select>  
  </td>  
  <td align="center">  
    <select name="jahr" size="1" onchange="document.monatjahr.submit();">  
      <option value="2000" <?php if ($jahr == '2000') { echo 'selected'; } ?>>2000</option>  
      <option value="2001" <?php if ($jahr == '2001') { echo 'selected'; } ?>>2001</option>  
      <option value="2002" <?php if ($jahr == '2002') { echo 'selected'; } ?>>2002</option>  
      <option value="2003" <?php if ($jahr == '2003') { echo 'selected'; } ?>>2003</option>  
      <option value="2004" <?php if ($jahr == '2004') { echo 'selected'; } ?>>2004</option>  
      <option value="2005" <?php if ($jahr == '2005') { echo 'selected'; } ?>>2005</option>  
      <option value="2006" <?php if ($jahr == '2006') { echo 'selected'; } ?>>2006</option>  
      <option value="2007" <?php if ($jahr == '2007') { echo 'selected'; } ?>>2007</option>  
      <option value="2008" <?php if ($jahr == '2008') { echo 'selected'; } ?>>2008</option>  
      <option value="2009" <?php if ($jahr == '2009') { echo 'selected'; } ?>>2009</option>  
      <option value="2010" <?php if ($jahr == '2010') { echo 'selected'; } ?>>2010</option>  
      <option value="2011" <?php if ($jahr == '2011') { echo 'selected'; } ?>>2011</option>  
      <option value="2012" <?php if ($jahr == '2012') { echo 'selected'; } ?>>2012</option>  
      <option value="2013" <?php if ($jahr == '2013') { echo 'selected'; } ?>>2013</option>  
      <option value="2014" <?php if ($jahr == '2014') { echo 'selected'; } ?>>2014</option>  
    </select>  
  </td>  
 </tr>  
</table>  
</form>  
<br>  
<table width="320" border="1" cellpadding="0" cellspacing="2" style="calday">  
 <tr>  
  <th scope="col" bgcolor="#ECE9D8">&nbsp;Sa</th>  
  <th scope="col" bgcolor="#ECE9D8">&nbsp;So</th>  
  <th scope="col">&nbsp;Mo</th>  
  <th scope="col">&nbsp;Di</th>  
  <th scope="col">&nbsp;Mi</th>  
  <th scope="col">&nbsp;Do</th>  
  <th scope="col">&nbsp;Fr</th>  
 </tr>  
 <tr>  
  <td align="center" bgcolor="#ECE9D8">&nbsp;<a href="javascript:window.opener.document.task.elements['form[datum]'].value='<?php echo $tag[0].".".$monat.".".$jahr ?>';window.close();"><?php echo $tag[0]; ?></a></td>  
  <td align="center" bgcolor="#ECE9D8">&nbsp;<a href="javascript:window.opener.document.task.elements['form[datum]'].value='<?php echo $tag[1].".".$monat.".".$jahr ?>';window.close();"><?php echo $tag[1]; ?></a></td>  
  <td align="center">&nbsp;<a href="javascript:window.opener.document.task.elements['form[datum]'].value='<?php echo $tag[2].".".$monat.".".$jahr ?>';window.close();"><?php echo $tag[2]; ?></a></td>  
  <td align="center">&nbsp;<a href="javascript:window.opener.document.task.elements['form[datum]'].value='<?php echo $tag[3].".".$monat.".".$jahr ?>';window.close();"><?php echo $tag[3]; ?></a></td>  
  <td align="center">&nbsp;<a href="javascript:window.opener.document.task.elements['form[datum]'].value='<?php echo $tag[4].".".$monat.".".$jahr ?>';window.close();"><?php echo $tag[4]; ?></a></td>  
  <td align="center">&nbsp;<a href="javascript:window.opener.document.task.elements['form[datum]'].value='<?php echo $tag[5].".".$monat.".".$jahr ?>';window.close();"><?php echo $tag[5]; ?></a></td>  
  <td align="center">&nbsp;<a href="javascript:window.opener.document.task.elements['form[datum]'].value='<?php echo $tag[6].".".$monat.".".$jahr ?>';window.close();"><?php echo $tag[6]; ?></a></td>  
 </tr>  
 </table>  
</body>  
</html>