a href - Selektion des Elements bei Click verhindern

[Klaas]

Wenn ich einen Link mit a href setze, so wird das element dahinter bei einem click darauf mit einem rahmen markiert. das möchte ich gerne verhindern. wie kann ich das erreichen ?

[Cheatah]

Hi,

Wenn ich einen Link mit a href setze, so wird das element dahinter bei einem click darauf mit einem rahmen markiert. das möchte ich gerne verhindern.

aus welchem Grund möchtest Du die Navigation auf Deiner Site verhindern und somit unter Aufwand die Qualität der Site erheblich mindern?

Cheatah

[Mike]

Moin Klass,

»» Wenn ich einen Link mit a href setze, so wird das element

so:
http://de.selfhtml.org/navigation/faq.htm

Gruß
Mike

[H2O]

Hallo.

Wenn ich einen Link mit a href setze, so wird das element dahinter bei einem click darauf mit einem rahmen markiert. das möchte ich gerne verhindern. wie kann ich das erreichen ?

Schon mal an die FAQ gedacht?
</faq/#Q-32h>

Ich ändere meine Signatur wirklich um.
Die liest sowieso niemand!

Schönen Tag noch, H2O

[Cybaer]

Hi,

Schon mal an die FAQ gedacht?
</faq/#Q-32h>

Der Tip in der FAQ ist katastrophal schlecht - und selfHTML mehr als unwürdig ... =:-o

Gruß, Cybaer

[molily]

Hallo,

Schon mal an die FAQ gedacht?
</faq/#Q-32h>

Der Tip in der FAQ ist katastrophal schlecht - und selfHTML mehr als unwürdig ... =:-o

Falls du noch nicht verstanden hast, wie SELF funktioniert: Wenn du einen besseren Tip hast, steuere ihn bei, dann wird die FAQ angepasst.

Mathias

[Cybaer]

Hi,

Falls du noch nicht verstanden hast, wie SELF funktioniert: Wenn du einen besseren Tip hast, steuere ihn bei, dann wird die FAQ angepasst.

So wie selfHTML andauernd von gefundenen Fehlern befreit wird? ;->

Aber mal sehen: Wohin muß ich mich in FAQ-Dingen wenden? Steht nicht in der FAQ drin. :)

Gruß, Cybaer

[H2O]

Hallo.

Aber mal sehen: Wohin muß ich mich in FAQ-Dingen wenden? Steht nicht in der FAQ drin. :)

Schon mal im Impressum nachgesehen?
http://www.selfhtml.org/de.impressum.html

Schönen Tag noch, H2O

[Tim Tepaße]

Hallo Cybaer,

Falls du noch nicht verstanden hast, wie SELF funktioniert: Wenn du einen
besseren Tip hast, steuere ihn bei, dann wird die FAQ angepasst.

Im Prinzip ja.

So wie selfHTML andauernd von gefundenen Fehlern befreit wird? ;->

SELFHTML ist wegen der Verbreitung ein höherer Aufwand. Deswegen gibt es
dafür gesammelte Errata.

Aber mal sehen: Wohin muß ich mich in FAQ-Dingen wenden? Steht nicht in der
FAQ drin. :)

Im Moment bin ich der Verantwortliche. Bei den häufigen Fachfragen hätte ich
gerne so eine Rückmeldungsmöglichkeit. Danke, daß Du mich auf die Idee
gebracht hast.

Wenn Du immer noch was SELF machen willst: Meine Mailadresse steht drüber. ;o)

Tim

[Cybaer]

Hi,

Wenn Du immer noch was SELF machen willst: Meine Mailadresse steht drüber. ;o)

Geht klar - nächste Woche melde ich mich ... :-)

Gruß, Cybaer

[Martin Speiser]

Hi Cybaer,

Der Tip in der FAQ ist katastrophal schlecht - und selfHTML mehr als unwürdig ... =:-o

was gefällt dir denn daran nicht? Ich hab ihn gerade angeschaut, und finde, das die Lösung auf den Punkt gebracht da steht. Wer wissen will, warum und wieso das klappt, kann in SelfHTML genauer nachlesen was die verwendeten Attribute und JS-Funktionen machen.

Gruß,
Martin

[Cybaer]

Hi,

was gefällt dir denn daran nicht?

Dort steht: onFocus="if(document.all) this.blur()"

Nachteile:
 - onFocus unterdrückt die Tabulatorsteuerung *komplett* (unnötig -> Maus-only-Bedienung)
 - document.all ist IE-Syntax (einschränkend -> was ist mit anderen Browsern?)
 - es wird nicht überprüft, ob blur() überhaupt eine erlaubte Methode für dieses Element ist (fehleranfällig -> ältere Browser lassen blur() auf Anker gar nicht zu)

Alles weitere: Siehe Archiv.

Gruß, Cybaer

[H2O]

Hallo.

Dort steht: onFocus="if(document.all) this.blur()"

Du kannst ja sogar lesen ;)

Nachteile:
 - onFocus unterdrückt die Tabulatorsteuerung *komplett* (unnötig -> Maus-only-Bedienung)

Angenommen.

- document.all ist IE-Syntax (einschränkend -> was ist mit anderen Browsern?)

Gibt es denn viele andere Browser, die das auch machen?

- es wird nicht überprüft, ob blur() überhaupt eine erlaubte Methode für dieses Element ist (fehleranfällig -> ältere Browser lassen blur() auf Anker gar nicht zu)

Ebenfalls ein berechtigter Nachteil, aber nur ein kleinerer.

Fazit: Gute Idee einen neuen Vorschlag zu machen. Kannst dich ja drum kümmern.

Schönen Tag noch, H2O

[Bubax]

Hi,

• document.all ist IE-Syntax (einschränkend -> was ist mit anderen Browsern?)

Gibt es denn viele andere Browser, die das auch machen?

Z.B. Opera und Konqueror. Also vielleicht auch Safari?! - Die "anderen" Browser werden in gegenwärtigem Fall vielleicht sogar froh sein...

Viele Grüße,
Bubax

[Cybaer]

Hi,

Du kannst ja sogar lesen ;)

Nein, nur markieren & kopieren! ;)

- document.all ist IE-Syntax (einschränkend -> was ist mit anderen Browsern?)
Gibt es denn viele andere Browser, die das auch machen?

Z.B. der Mozilla. IMHO gilt prinzipiell: Niemals speziell arbeiten, wenn es allgemein geht. Niemals Browser-spezifisch arbeiten, wenn man einen Effekt bewirken will. Man weiß ja nie, ob es in Zukunft nicht Browser gibt, die davon ebenfalls profitieren (also prinzipiell gesagt - die Meinungen über den "Profit" gehen hier ja auseinander ;-)).

Und Opera unterstützt ja ggf. document.all, käme aber ggf. ...

- es wird nicht überprüft, ob blur() überhaupt eine erlaubte Methode für dieses Element ist (fehleranfällig -> ältere Browser lassen blur() auf Anker gar nicht zu)
Ebenfalls ein berechtigter Nachteil, aber nur ein kleinerer.

... hier ins Schleudern (ebenso wie der IE 4 und möglicherweise sogar noch der IE 5.0).

Gruß, Cybaer

[Der Martin]

Hallo Klaas,

ist dir bekannt, dass nicht alle Browser so reagieren, wie du es beschreibst?

Und ist dir vielleicht schon einmal in den Sinn gekommen, dass manche Leute dieses Verhalten sogar gut finden?

Ich zum Beispiel verwende mal den IE, mal den Opera. Und beim Opera vermisse ich immer den gepunkteten Rand um den zuletzt angeklickten Link.
Warum?
Weil ich gern Links im neuen Fenster öffne. Wenn ich dann die verlinkte Stelle gelesen habe, mache ich das neue Fenster wieder zu und bin wieder im ursprünglichen Dokument. Bei langen Linklisten ist die "Markierung", die der IE gesetzt hat, sehr hilfreich. Dann sehe ich nämlich genau, wo ich eigentlich weiterlesen wollte.
Beim Opera fehlt mir diese Lesehilfe. :(
Und auf Seiten, die dieses Verhalten absichtlich außer Kraft setzen, wird sie mir auch mit dem IE fehlen.

Denk mal drüber nach.

So long,

Martin

Wenn ich einen Link mit a href setze, so wird das element dahinter bei einem click darauf mit einem rahmen markiert. das möchte ich gerne verhindern. wie kann ich das erreichen ?

[Cybaer]

Hi,

Und ist dir vielleicht schon einmal in den Sinn gekommen, dass manche Leute dieses Verhalten sogar gut finden?

Zuerst einmal: Der HTML-Autor macht die Seite. Es ist seine Seite. Was er damit macht, ist auch seine Sache.

Der Surfer kann das mögen, hassen oder die Seite fortan ignorieren.

Ein HTML-Autor, der dem Surfer solche Funktionalität bieten möchte, der kann mit den CSS-Pseudoklassen dies selbst veranlassen - und zwar in einer Optik, die zum Inhalt auch paßt (wenn er möchte auch mit "gestricheltem Rahmen"). Man ist absolut nicht auf die bevormundende, optisch mehr als umstrittene "Zwangsbeglückung" durch den Browser angewiesen! :-))

Ich zum Beispiel verwende mal den IE, mal den Opera. Und beim Opera vermisse ich immer den gepunkteten Rand um den zuletzt angeklickten Link.

Du könntest ein eigenes Stylesheet einbinden, das diesen Effekt in CSS erledigt.

Wenn es schon der Seiten-Betreiber nicht getan hat.

Gruß, Cybaer

[Thomas Meinike]

Hallo,

Wenn ich einen Link mit a href setze, so wird das element dahinter bei einem click darauf mit einem rahmen markiert. das möchte ich gerne verhindern. wie kann ich das erreichen ?

Im Archiv werden sich etliche Threads zu diesem Thema finden. Wenn man <a ... onclick="if(this.blur)this.blur()"> verwendet, dann bleibt immerhin die Navigierbarkeit via TAB-Taste erhalten (was bei onfocus="..." nicht gegeben waere).

Um das nicht bei jedem Link machen zu muessen, waere eine globale Ereignisbehandlung angesagt, z. B. so:

var lnkarr,lnkanz;

function Init()
{
  lnkarr=document.links;
  lnkanz=lnkarr.length;

if(document.attachEvent)
  {
    for(i=0;i<lnkanz;i++)lnkarr[i].attachEvent("onclick",HandleLinks);
  }
  else if(document.addEventListener)
  {
    for(i=0;i<lnkanz;i++)lnkarr[i].addEventListener("click",HandleLinks,false);
  }
}

function HandleLinks()
{
  if(this.blur)this.blur();
}

Aufruf:
<body onload="Init()">

BTW: Auch Mozilla-Derivate verhalten sich mittlerweile wie der IE und zeigen die Linkumrandung an. Das genannte Skript habe ich mit IE 6.0 [hier greift attachEvent()] und Firefox 0.9.2 [hier greift addEventListener()] probiert, aber eigentlich sollte man die Funktionalitaet eines Browsers ohne Not nicht einschraenken.

MfG, Thomas

[molily]

Hallo,

Wenn man <a ... onclick="if(this.blur)this.blur()"> verwendet, dann bleibt immerhin die Navigierbarkeit via TAB-Taste erhalten (was bei onfocus="..." nicht gegeben waere).

Andererseits feuern die gängigen Browser beim Aktivieren eines durch Tab (o.ä.) ausgewählten Links durch die Enter Taste (o.ä.) den onclick-Event. So wird blur() beim Folgen des Links ausgeführt. Das ist nicht direkt problematisch, weil direkt die neue Seite geladen wird, aber z.B. bei der Rückkehr auf die Seite stört es eventuell, weil der interne »Cursor« bzw. auch konkret die Markierung nicht mehr auf dem Link liegt und die Links gegebenenfalls wieder vom Dokumentanfang durchlaufen werden müssen.

Mathias

[MudGuard]

Hi,

Andererseits feuern die gängigen Browser beim Aktivieren eines durch Tab (o.ä.) ausgewählten Links durch die Enter Taste (o.ä.) den onclick-Event. So wird blur() beim Folgen des Links ausgeführt. Das ist nicht direkt problematisch, weil direkt die neue Seite geladen wird

Benutze im Mozilla Ctrl-Return und die alte Seite bleibt erhalten - die neue wird im neuen Fenster bzw. Tab geöffnet.

cu,
Andreas

[molily]

Hallo,

Andererseits feuern die gängigen Browser beim Aktivieren eines durch Tab (o.ä.) ausgewählten Links durch die Enter Taste (o.ä.) den onclick-Event. So wird blur() beim Folgen des Links ausgeführt. Das ist nicht direkt problematisch, weil direkt die neue Seite geladen wird

Benutze im Mozilla Ctrl-Return und die alte Seite bleibt erhalten - die neue wird im neuen Fenster bzw. Tab geöffnet.

Was willst du damit sagen? Ich weiß, dass solche Möglichkeiten existieren. Sie lösen das beschriebene Problem aber nicht, weil der onclick-Event weiterhin gefeuert wird. Auch mit Strg+Enter und Shift+Enter wird die Markierung des Links aufgehoben. Dadurch bleibt im Mozilla zwar der interne Fokus auf dem Link (denn beim nächsten Drücken der Tab-Taste wird der darauffolgende, nicht der erste Link angesprungen), die Markierung ist jedoch nicht sichtbar. Opera merkt sich den Fokus normalerweise sogar dann, wenn der Link nur über Enter aktiviert wird. Ein blur() führt dazu, dass der Fokus intern komplett zurückgesetzt wird. Ob man den Link im selben Fenster/Tab oder in einem neuen öffnet, spielt keine Rolle. Im MSIE ist es ähnlich, hier bleibt der Fokus normalerweise zumindest beim Aktivieren über Shift+Enter erhalten. Gerade diese einzige Möglichkeit durchkreuzt blur(), indem es den Fokus zurücksetzt (und auf MSIE setzen die meisten Screenreader auf).

Mathias

[MudGuard]

Hi,

Andererseits feuern die gängigen Browser beim Aktivieren eines durch Tab (o.ä.) ausgewählten Links durch die Enter Taste (o.ä.) den onclick-Event. So wird blur() beim Folgen des Links ausgeführt. Das ist nicht direkt problematisch, weil direkt die neue Seite geladen wird
Benutze im Mozilla Ctrl-Return und die alte Seite bleibt erhalten - die neue wird im neuen Fenster bzw. Tab geöffnet.

Was willst du damit sagen?

Du schriebst, daß das "nicht direkt problematisch" sei, weil die Seite ja ersetzt wird. Und ich wollte sagen, daß die Seite eben nicht zwangsläufig ersetzt wird.

Ich weiß, dass solche Möglichkeiten existieren. Sie lösen das beschriebene Problem aber nicht, weil der onclick-Event weiterhin gefeuert wird. Auch mit Strg+Enter und Shift+Enter wird die Markierung des Links aufgehoben. Dadurch bleibt im Mozilla zwar der interne Fokus auf dem Link (denn beim nächsten Drücken der Tab-Taste wird der darauffolgende, nicht der erste Link angesprungen), die Markierung ist jedoch nicht sichtbar.

Also wenn ich Ctrl-Enter in meinem Mozilla (1.7) drücke, bleibt die Markierung sichtbar - es sei denn sie wird per Javascript onclick unterdrückt.
Ach ja, ich laß den neuen Tab im Hintergrund öffnen - vielleicht spielt das ja eine Rolle ...

cu,
Andreas

[Cybaer]

Hi,

Im Archiv werden sich etliche Threads zu diesem Thema finden. Wenn man <a ... onclick="if(this.blur)this.blur()"> verwendet, dann bleibt immerhin die Navigierbarkeit via TAB-Taste erhalten (was bei onfocus="..." nicht gegeben waere).

Die Markierung/die aktuelle Position wird, wie molily schrieb, bei Tastaturnavigation trotzdem gelöscht.

Wenn man mit einem kurzen Aufblitzen des Rahmens leben kann: onMouseUp() statt onClick()

Ansonsten kann man ja den Rahmen mittels CSS und/oder MS-HTML ja ganz unterdrücken ...

BTW: Auch Mozilla-Derivate verhalten sich mittlerweile wie der IE und zeigen die Linkumrandung an.

Ja, aber nur bei Textlinks. Wirklich stören tun die Rahmen jedoch eher bei den Image-Links (und insbesondere Image-Maps). Und dort hält sich der Mozilla zurück ... :-))

Gruß, Cybaer