onClick in <a href...
0 0 0 0 0 command-Element
molily
0 Tim Tepaße
0 molily
0 
Der Martin
1 molily
onClick in <a href...
Hallo,
warum funktioniert folgender Code nicht, um einen Text über einen Link zu markieren?
<form name="eins">
<textarea rows=4 cols=50 name="eins">
Hier steht der zu markierende Text. Bla Bla, bla, bla bla.
</textarea>
</form>
<a href="#" onClick="this.form.eins.select();">Text markieren</a>
Danke!
LG
PhanTobi
-
Hi,
<a href="#" onClick="this.form.eins.select();">Text markieren</a>[/code]
A ist kein Formularelement, also kennt es auch keine form-Eigenschaft.
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.-
Danke, und wie lässt es sich dann mit Text umsetzen, wenn nicht mit A? ;)
Hi,
»» <a href="#" onClick="this.form.eins.select();">Text markieren</a>[/code]
A ist kein Formularelement, also kennt es auch keine form-Eigenschaft.
MfG ChrisB
-
Hi,
Danke, und wie lässt es sich dann mit Text umsetzen, wenn nicht mit A? ;)
welches Element innerhalb des <body> kennt denn keinen onclick-Eventhandler? Nimm ein semantisch sinnvolles Element und verwende es.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Danke für eure Tipps!
Ich hab allerdings kaum Ahnung und kann deshalb eure gut gemeinten Tipps nicht umsetzen. Sagt mir doch bitte direkt wie ich den Text umsetzen kann, bitte nicht als Button.
Ich weiß, das klingt jetzt so, als hätte ich gerne alles vorgekaut :-S
LG
Hi,
»» Danke, und wie lässt es sich dann mit Text umsetzen, wenn nicht mit A? ;)
welches Element innerhalb des <body> kennt denn keinen onclick-Eventhandler? Nimm ein semantisch sinnvolles Element und verwende es.
Cheatah
-
Mahlzeit Phantobi,
Ich weiß, das klingt jetzt so, als hätte ich gerne alles vorgekaut :-S
Ja. Und genau damit bist Du bei "SELF"HTML falsch. Dir wurden genug Hinweise gegeben, um Dich SELF zu informieren und SELF zu verstehen, was zu tun ist.
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
-
-
Nimm ein semantisch sinnvolles Element und verwende es.
<!doctype html> <html> <head> <title>Semantisch korrektes Element für JavaScript-Buttons (HTML 5)</title> <style> [code lang=css]command { color: blue; cursor: pointer; text-decoration: underline; } command:hover { color: #00a; }</style>
<script>window.onload = initSelectButton; function initSelectButton () { var pEl = document.createElement("p"), commandEl = document.createElement("command"); commandEl.tabIndex = 0; commandEl.onclick = selectTextareaText; commandEl.innerHTML = "Text markieren"; pEl.appendChild(commandEl); document.forms[0].appendChild(commandEl); } function selectTextareaText () { document.getElementById("textarea").select(); }</script>
</head>
<body><form>
<p><textarea id="textarea">Moo</textarea></p>
</form></body>
</html>[/code]http://molily.de/temp/command.html
Mathias
-
Hallo Mathias,
Nimm ein semantisch sinnvolles Element und verwende es.
commandEl.innerHTML = "Text markieren";pEl.appendChild(commandEl);“command elements are not rendered unless they form part of a menu.”
(Siehe auch unter Rendering)Die ganze menu/command-Struktur zur Erzeugung von Kontextmenüs und Toolbars ist ein bisschen merkwürdig, finde ich. Einerseits gibt es command, andererseits werden a, input, button, option, bb und jedes andere fokussierbare Element mit einem accesskey mit einbezogen stellen also genauso, anscheinend gleichwertige Kommandos dar. Das command-Element existiert also wirklich nur für den Fall eines Klick-Handlers in Kontextmenüs oder Toolbars – für Rendering im Dokument wäre es letztendlich nur mit CSS 3 Generated Content nutzbar, aber eben anscheinend nicht dafür vorgesehen.
(Meine Privat-Ästhetik würde übrigens buttons nehmen.)
Tim
-
Macht für mich keinen Sinn, das Label in einem Attribut unterzubringen.
Aber danke für den Hinweis.“command elements are not rendered unless they form part of a menu.”
Okay, das dürfte das kleinere Problem sein.
Die ganze menu/command-Struktur zur Erzeugung von Kontextmenüs und Toolbars ist ein bisschen merkwürdig, finde ich.
Aber menu type=toolbar ist doch genau das, was hier angebracht ist, wenn ich diese Beispiele für wahr nehme:
http://www.ibm.com/developerworks/library/x-html5/Das command-Element existiert also wirklich nur für den Fall eines Klick-Handlers in Kontextmenüs oder Toolbars – für Rendering im Dokument wäre es letztendlich nur mit CSS 3 Generated Content nutzbar, aber eben anscheinend nicht dafür vorgesehen.
Du meinst, ein <command label="..."> würde gar nicht dargestellt?
Aber es heißt doch: »label: The name of the command, as shown to the user.«Einerseits gibt es command, andererseits werden a, input, button, option, bb und jedes andere fokussierbare Element mit einem accesskey mit einbezogen stellen also genauso, anscheinend gleichwertige Kommandos dar.
Ja. Witzigerweise wäre a aus HTML-5-Sicht durchaus ein Kandidat für ein semantisch korrektes Element in diesem Kontext.
Mathias
-
Hallo Mathias,
Aber menu type=toolbar ist doch genau das, was hier angebracht ist, wenn ich diese Beispiele für wahr nehme:
http://www.ibm.com/developerworks/library/x-html5/Ich las “The element is expected to have, by default, the appearance of a tool bar on the user agent's platform. It is expected to contain the menu that is built from the element.” weiter unten unter Rendering und hatte Browser-Toolbars im Kopf, ähnlich den Link Relationship Toolbars in Opera oder früher Mozilla. Sprich: nichts im Dokument, menu würde dann nur im Dokument gerendert, wenn das type-Attribut fehlt.
Allerdings jetzt wo Du's sagst .. in der Spec unter 4.6.12 gibt es ein Beispiel, das das so einsetzt, wie Du vorschlägst.
Du meinst, ein <command label="..."> würde gar nicht dargestellt?
Aber es heißt doch: »label: The name of the command, as shown to the user.«Gezeigt in Kontextmenüs oder aber in den von mir spekulierten, aber falschen Fall der Browser-Toolbars.
Tim
-
-
-
-
-
-
Hallo,
»» <a href="#" onClick="this.form.eins.select();">Text markieren</a>[/code]
A ist kein Formularelement, also kennt es auch keine form-Eigenschaft.erschwerend kommt dazu, dass das Element nicht einmal im Formular steht, und somit -selbst wenn es eine form-Eigenschaft hätte- 'this' nicht auf das Formular zeigen würde.
Und ein a-Element ist hier prinzipiell falsch gewählt - der OP möchte keine neue Ressource verlinken, also ist hier kein Link angesagt. So ziemlich jedes andere Element, einschließlich eines button-Elements, wäre hier sinnvoller.So long,
Martin--
Lieber arm dran als Arm ab.-
Und ein a-Element ist hier prinzipiell falsch gewählt
Wenn hier irgendetwas prinzipiell falsch ist, dann höchstens die abgehobene Denkweise der Antwortenden. Ungefähr jede JavaScript-unterstützte Webanwendung tut dies. Hier ein »prinzipielles« Verbot aufzustellen, weil in der Markup-Theorie nicht sein darf, was tausendfach bestens funktioniert, lenkt die Sicht weg von praxisrelevanten Fragen wie Usability und User Experience. Aber du hast sicher schlagkräftige Argumente, wieso teilst du sie dem Fragenden nicht mit.
Mathias
-
Hallo,
»» Und ein a-Element ist hier prinzipiell falsch gewählt
Wenn hier irgendetwas prinzipiell falsch ist, dann höchstens die abgehobene Denkweise der Antwortenden.die ist nicht "abgehoben", sondern ergonomisch gelenkt.
Hier ein »prinzipielles« Verbot aufzustellen, weil in der Markup-Theorie nicht sein darf, was tausendfach bestens funktioniert, lenkt die Sicht weg von praxisrelevanten Fragen wie Usability und User Experience.
Im Gegenteil: Usability und User Experience ist genau das, was man hier bedienen möchte.
Aber du hast sicher schlagkräftige Argumente, wieso teilst du sie dem Fragenden nicht mit.
"User Experience" meint wahrscheinlich Erwartungskonformität. Der Mensch ist an bestimmte Eigenschaften oder Konventionen seiner Umwelt oder eines Produkts, das er benutzt, gewöhnt. Interessanterweise findet man im Internet zum Stichwort "Erwartungskonformität" fast ausschließlich Artikel, die sich unter diesem Aspekt mit Software beschäftigen. Dabei gibt es auch reichlich Beispiele aus dem Alltag:
* Jeder Radio- und Fernsehtechniker wird dem Kunden die Sender am Fernseher so einstellen, dass ARD auf Programmplatz 1, ZDF auf Programmplatz 2 liegt (wenn das nicht sogar die automatische Sortierung nach dem Sendersuchlauf schon tut).
* Wenn wir in ein Auto einsteigen, setzen wir (wenn's nicht gerade ein Automatik-Fahrzeug ist) instinktiv eine klassische H-Schaltung voraus - dabei gibt es einige andere Konzepte, sie sind aber unüblich.
* Lichtschalter sind meist in Griffhöhe direkt neben der Tür zu einem Raum, obwohl ein Fußschalter vielleicht sogar praktischer wäre, könnte man ihn doch auch bedienen, wenn man keine Hand frei hat.Ebenso haben wir uns in jahrelanger Gewöhnung an das Internet darauf eingeschossen, dass man durch Klicken auf einen Link eine neue Seite aufruft, und nicht irgendeine -vielleicht praktische- Funktion innerhalb der aktuell angezeigten Seite.
Wenn jemand mit solchen Konventionen bricht, muss er also zunächst damit rechnen, dass diese Idee nicht verstanden, nicht angenommen oder ihr sogar Widerstand entgegengebracht wird, und sei sie noch so pfiffig (denn mal im Ernst: Einen zwingenden Grund für die oben genannten, "üblichen" Konventionen gibt es nicht). Eine neue Idee muss entweder so gut sein, dass sie spontant als "praktisch" oder "genial" anerkannt wird, oder der Urheber wird es schwer haben, seine Idee an den Mann (an die Frau) zu bringen. Das Festhalten an Gewohnheiten wirkt bei den meisten Menschen stärker als die Bereitschaft, Neues auszuprobieren (bei mir auch, ja). Nicht umsonst heißt das Sprichwort: "Der Mensch ist ein Gewohnheitstier." Dieser menschlichen Grundeigenschaft sollten wir Rechnung tragen, anstatt uns immer wieder neue Varianten bekannter Konzepte auszudenken.
So long,
Martin--
"So schnell waren wir noch nie am Unfallort", sagte der Polizist zu seinem Kollegen, als er einen Laternenmast gerammt hatte.-
Ebenso haben wir uns in jahrelanger Gewöhnung an das Internet darauf eingeschossen, dass man durch Klicken auf einen Link eine neue Seite aufruft
Das ist schlicht eine Behauptung. Hyperlinks werden nämlich genauso jahrelang dazu benutzt werden, JavaScript-Aktionen zu triggern. Da kann ich dir tausende Beispiele von großen Sites und populären Webanwendungen nennen. Das ließe genauso den Schluss zu, dass Hyperlink = JavaScript-Aktion den Leuten hinreichend bekannt und geläufig ist.
Hier werden ja gerne Formular-Buttons als Alternative gepriesen. Nun: Dass Formular-Buttons in den meisten Fällen dazu benutzt werden, Formulare abzusenden und damit eine neue Seite aufzurufen, macht sie, nur weil sie angeblich semantisch besser geeignet sind, auch nicht gerade prädestiniert. Insofern gibt es gar kein UI-Pattern, was nicht in irgendeiner Weise mit Bedeutung »vorbelastet« ist. Aber es ist gerade Sinn der Sache, eine bekannte UI-Control zu verwenden.
Wenn jemand mit solchen Konventionen bricht
Es ist keine Konvention. Die Konvention lautet nämlich seit Erfindung von JavaScript, a zu missbrauchen. Das kann man sehen, wie man will, aber 14 Jahre nach JavaScript-Erfindung und 4-5 Jahre nach dem Boom von Ajax-Webanwendungen plötzlich zu behaupten, die User seien völlig darauf eingeschossen, dass a immer ein klassischer Hyperlink bedeutet und es würde »nicht verstanden, nicht angenommen«, ist unhaltbar.
Sofern hier keine empirischen oder zumindest plausiblen und stimmigen Argumente genannt werden, sehe ich keinen Grund, wieso man nicht machen sollte, was breiter Usus ist. Ich würde sogar behaupten, dass es die am häufigsten verbreitete Methode ist, Links (bzw. dem Schema blauer Text mit Unterstrich) eine JS-Funktionalität zu geben im Vergleich zu anderen Elementen.
Mathias
-
Hi,
Ebenso haben wir uns in jahrelanger Gewöhnung an das Internet darauf eingeschossen, dass man durch Klicken auf einen Link eine neue Seite aufruft, und nicht irgendeine -vielleicht praktische- Funktion innerhalb der aktuell angezeigten Seite.
Und was machen Formularbuttons? I.a.R. auch "eine neue Seite aufrufen".
Wenn jemand mit solchen Konventionen bricht, muss er also zunächst damit rechnen, dass diese Idee nicht verstanden, nicht angenommen oder ihr sogar Widerstand entgegengebracht wird
Als ob Otto Normaluser überhaupt ziwschen einem Link und einem Button unterscheidet - unterscheiden kann, unterscheiden will.
Da ist ein Element, wo man draufklicken kann, also klickt Otto drauf. Von <a>, <input> oder <button> hat der noch nie was gehört, und es ist ihm auch furzegal.
Manchmal sehen Links aus wie Buttons ("Retro"-Navigationsmenüs), und manchmal Buttons wie Links.
Manche Seiten nutzen Buttons/Formulare zur "Verlinkung" von Folgeseiten, und manche Seiten nutzen Links (+JS) zum Abschicken von Formularen.
Ist Otto vermutlich alles höchstegal, er klickt und erreicht damit, was er erreichen will.Eine neue Idee muss entweder so gut sein, dass sie spontant als "praktisch" oder "genial" anerkannt wird, oder der Urheber wird es schwer haben, seine Idee an den Mann (an die Frau) zu bringen.
Wie Mathias schon sagte, an <a href=Javascript:..."> bzw. onclick ist eigentlich gar nichts neu.
Das Festhalten an Gewohnheiten wirkt bei den meisten Menschen stärker als die Bereitschaft, Neues auszuprobieren (bei mir auch, ja).
Otto klickt, wo er klicken kann.
Otto klickt, und bekommt irgendeine Art von Reaktion - *das* ist Ottos Gewohnheit, und Ottos Erwartungshaltung.Dieser menschlichen Grundeigenschaft sollten wir Rechnung tragen, anstatt uns immer wieder neue Varianten bekannter Konzepte auszudenken.
Das Konzept heisst klick hier, bekomme Reaktion auf deinen Klick. That's all.
Hinsichtlich Zugänglichkeit und Barrierearmut kann/sollte man da noch ein bisschen mehr druber nachdenken. Ohne JavaScript funktionslose Links wären natürlich ärgerlich. Und nicht jeder nutzt eine Maus beim Surfen, also sollte man wenn z.B. reine Textelemente klickbar gemacht werden, diese auch fokussierbar machen (tabindex) - was ein A-Element schon "build-in" hätte.
Aber so lange es benutzbar ist, benutzt Otto es gerne und bereitwillig - ohne viel darüber nachzudenken, und sich für die Technik im Hintergrund zu interessieren.
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.
-
-
-
-
-
<form name="eins">
<textarea rows=4 cols=50 name="eins">
Hier steht der zu markierende Text. Bla Bla, bla, bla bla.
</textarea></form>
<a href="#" onClick="this.form.eins.select();">Text markieren</a>
Wie du auf Formularelemente zugreifst, findest du hier: <http://de.selfhtml.org/javascript/objekte/forms.htm> <http://de.selfhtml.org/javascript/objekte/elements.htm> Z.B. document.forms.eins.elements.eins.select() (»eins« sind nicht so pralle Namen, vor allem wenn das Formular und sein Feld gleich nennst.) Mathias -- [JavaScript-Erweiterung für das SELFHTML-Forum](http://molily.de/selfhtml-forum-js/)