base tag aushebeln?

[Miriam]

Hallo,

unsere Website verwendet den BASE Tag, um URLs entsprechend der Angabe zu vervollständigen.

http://de.selfhtml.org/navigation/suche/index.htm?Suchanfrage=base

Nun habe ich aber das Problem, dass dieses Tag dafür sorgt, dass auch ein Javascript Aufruf wie folgender die Seite neu lädt, anstatt nur das Javascript auszuführen:

<a href="#" onclick="js()">link</a>

kann ich das verhindern?

Danke,
Miriam

[rfb]

Moin

kann ich das verhindern?

versuch mal:

<a href="#" onclick="js();return false">link</a>

Gruß
rfb

[Thomas J.S.]

Hallo,

Nun habe ich aber das Problem, dass dieses Tag dafür sorgt, dass auch ein Javascript Aufruf wie folgender die Seite neu lädt, anstatt nur das Javascript auszuführen:

Das Passiert auch ohne <base>.

<a href="#" onclick="js()">link</a>

<a href="javascript:js()">link</a>

Grüße
Thomas

[Mathias Brodala]

Hallo Thomas.

<a href="#" onclick="js()">link</a>

<a href="javascript:js()">link</a>

<input type="button" onclick="js()" />

Ein Link ohne Ziel ist in meinen Augen kein Link.

Einen schönen Donnerstag noch.

Gruß, Mathias

[rfb]

Moin

<input type="button" onclick="js()" />

Ein Link ohne Ziel ist in meinen Augen kein Link.

ein Button, der nur mittels Maus betätigt werden kann, ist nicht barrierefrei.
Nur onclick zu nutzen ist mE wesentlich schlimmer als der Missbrauch eines (für alle Eingabegeräte zugänglichen) Links für JavaScript-Funktionsaufrufe.

Gruß
rfb

[Mathias Brodala]

Hallo rfb.

<input type="button" onclick="js()" />

Ein Link ohne Ziel ist in meinen Augen kein Link.

ein Button, der nur mittels Maus betätigt werden kann, ist nicht barrierefrei.

Wer sagt, dass er das ist? Der onclick-Event feuert auch bei Tastaturevents.

Nur onclick zu nutzen ist mE wesentlich schlimmer als der Missbrauch eines (für alle Eingabegeräte zugänglichen) Links für JavaScript-Funktionsaufrufe.

Der Optimalzustand wäre natürlich wie folgt:

1. Die Funktionalität wird alternativ serverseitig bereit gestellt:

HTML: <a href="foo">Foo</foo>
JS: ~~~javascript window.onload = function() {

document.links[0].onclick = function() {

alert('Funktioniert.');
    return false;
  };
};

  
2) Die jeweilige Funktionalität wird alleinig von JS zur Verfügung gestellt:  
  
HTML:  
(Ja, nichts.)  
JS: ~~~javascript
window.onload = function() {  
  
  var b = document.createElement('input');  
      b.type = 'button';  
      b.value = 'Foo';  
      b.onclick = function() {  
  
        alert('Funktioniert.');  
      };  
  
  document.body.appendChild(b);  
};

Dass letztere Methode nicht im geringsten barrierearm ist, dürfte aber klar sein.

Einen schönen Donnerstag noch.

Gruß, Mathias

[rfb]

Moin

Der onclick-Event feuert auch bei Tastaturevents.

Hör ich gerne. Bei allen Browsern? Weil doch in den Beispielen zur BITV so großen Wert auf Einfügen weiterer Eventhandler bei Nutzung von onclick gelegt wird.

HTML:
(Ja, nichts.)

sehr schön!

JS: ~~~javascript

window.onload = function() {

var b = document.createElement('input');
      b.type = 'button';
      b.value = 'Foo';
      b.onclick = function() {

alert('Funktioniert.');
      };

document.body.appendChild(b);
};

>   
  
Hm, müsste dabei nicht noch ein form-Element erschaffen werden? Nur der Vollständigkeit halber?  
  

> Dass letztere Methode nicht im geringsten barrierearm ist, dürfte aber klar sein.  
  
seh ich das richtig als doppelte Verneinung? Sprich: es ist eine Barriere? Dann doch nicht mehr als die Nutzung von JavaScript überhaupt.  
  
  
Gruß  
rfb

[molily]

Hallo,

Der onclick-Event feuert auch bei Tastaturevents.

Hör ich gerne. Bei allen Browsern? Weil doch in den Beispielen zur BITV so großen Wert auf Einfügen weiterer Eventhandler bei Nutzung von onclick gelegt wird.

Die üblichen Ratschläge rund um WCAG und BITV halte ich für Unsinn, die sind inpraktikabel, unnötig und eher kontraproduktiv.

Wenn man sich wirklich sicher sein will, nutzt man ein Formular mit Submit und ruft das JavaScript onsubmit auf. Damit kann man sich von Eingabegerät-spezifischen Events ganz lösen.

Allerdings reicht onclick wie gesagt aus - zumindest im IE, Firefox, Opera, Safari, Konqueror und auch in den wichtigsten Screenreadern. Mit onkeypress usw. begibt man sich hingegen auf gefährliches Terrain.

Abhilfe kann höchstens der Event DOMActivate bringen, der aber noch schlecht unterstützt wird.

Mathias

[Mathias Brodala]

Hallo rfb.

Der onclick-Event feuert auch bei Tastaturevents.

Hör ich gerne. Bei allen Browsern?

AFAIK ja.

JS: ~~~javascript

window.onload = function() {

var b = document.createElement('input');
      b.type = 'button';
      b.value = 'Foo';
      b.onclick = function() {

alert('Funktioniert.');
      };

document.body.appendChild(b);
};

> >   
>   
> Hm, müsste dabei nicht noch ein form-Element erschaffen werden? Nur der Vollständigkeit halber?  
  
Nein, das ist nicht erforderlich. (In einem Strict-Dialekt müsste natürlich noch ein Blockelement um den Button gepackt werden, da dieser nicht direkt im body-Element stehen darf.)  
  

> > Dass letztere Methode nicht im geringsten barrierearm ist, dürfte aber klar sein.  
>   
> seh ich das richtig als doppelte Verneinung? Sprich: es ist eine Barriere?  
  
Diese Methode ist zu 100% von JavaScript abhängig, stellt also eine Barriere dar.  
  
  
Einen schönen Donnerstag noch.  
  
Gruß, Mathias  

-- 
ie:% fl:| br:< va:) ls:& fo:) rl:( n4:~ ss:) de:] js:| mo:| zu:)  
  
debian/rules

[Mathias Brodala]

Hallo rfb.

Nochmal etwas ausführlicher:

Nur onclick zu nutzen ist mE wesentlich schlimmer als der Missbrauch eines (für alle Eingabegeräte zugänglichen) Links für JavaScript-Funktionsaufrufe.

<a href="#" onclick="alert('foo')">Clickme</a>  
<a href="javascript:alert('foo')">Clickme</a>  
<input type="button" onclick="js()" />

Die Auswirkung ohne JS ist bei allen drei Varianten hier nahezu identisch: es tut sich (fast) nichts. Doch im Gegensatz zu den Links täuscht der Button wenigstens nicht vor, dass eine Ressource aufgerufen werden könnte. Denn – und ich wiederhole mich – dazu sind Links eigentlich gedacht.

Deswegen ist der Idealzustand für mich zwischen den beiden beschriebenen Methoden zu wählen.

Einen schönen Donnerstag noch.

Gruß, Mathias

[Thomas J.S.]

Hallo,

<a href="#" onclick="js()">link</a>

<a href="javascript:js()">link</a>

<input type="button" onclick="js()" />

Ein Link ohne Ziel ist in meinen Augen kein Link.

Natürlich ist es viel viel schöner mit JavaScript und Ajax ein ganzes Framework aufzubauen um beliebigen Elementen beiliebige Eventhandler zuzuweisen. [tm]

Grüße
Thomas

PS: ziel --> taget. <a target=" ..."> muss ich noch was dazu sagen?

[Mathias Brodala]

Hallo Thomas.

<a href="#" onclick="js()">link</a>

<a href="javascript:js()">link</a>

<input type="button" onclick="js()" />

Ein Link ohne Ziel ist in meinen Augen kein Link.

Natürlich ist es viel viel schöner mit JavaScript und Ajax ein ganzes Framework aufzubauen um beliebigen Elementen beiliebige Eventhandler zuzuweisen. [tm]

Unnötige Polemik.

PS: ziel --> taget. <a target=" ..."> muss ich noch was dazu sagen?

Eine Erläuterung wäre in der Tat nicht verwerflich. Da wir beide wissen, was ich mit „Ziel“ meinte, würde mich dies interessieren.

Einen schönen Donnerstag noch.

Gruß, Mathias

[Thomas J.S.]

Hallo,

Natürlich ist es viel viel schöner mit JavaScript und Ajax ein ganzes Framework aufzubauen um beliebigen Elementen beiliebige Eventhandler zuzuweisen. [tm]

Unnötige Polemik.

Nicht wirklich.
Ich arbeite mit dem ganzen "Zeug" täglich und sehe auch, wo und welche "Lösungen" eingesetzt werden. Ich bin immer wieder doch erstaunt (und auch "zorning") wenn/weil ich sehe wie schnell gerade in diesem Bereich mit Kanonen auf Spatzen geschossen wird. Es gibt viele JavaScript-Frameworks und sehe auch bei denen welchen Aufwand es eigentlich beduetet, diese einzusetzen und an die gegebene Umgebung anzupassen. Oft kann ich dabei die Kosten-Nutzen Relation so eines Frameworks gegnüber einer lokaler (aber auch eben lokal wiederverwendbarer) Lösung überhaupt nicht nachvollziehen.
Abgesehen davon stellst sich natürlich bei solchen Antworten (input button) durchaus die Frage nach Desingvorgaben und Umsetzungsaufwand. (Nein, ich möchte jetzt keineswegs eine Diskussion über diese Thematik anfangen, wollte sie aber in Erinnerung rufen.)

PS: ziel --> taget. <a target=" ..."> muss ich noch was dazu sagen?

Eine Erläuterung wäre in der Tat nicht verwerflich. Da wir beide wissen, was ich mit „Ziel“ meinte, würde mich dies interessieren.

Ich weiss was du meinstest, aber du hast so an der "ein Link ist ein Link ist ein Link" festgehalten, dass ich das mit dem "Ziel" (das als traget ja in keinem stirkt-DTD gibt) schon erwähnen musste. (Wortspielerei also)

Grüße
Thomas

[Mathias Brodala]

Hallo Thomas.

Es gibt viele JavaScript-Frameworks und sehe auch bei denen welchen Aufwand es eigentlich beduetet, diese einzusetzen und an die gegebene Umgebung anzupassen.

Kann ich sehr gut nachvollziehen. Solch Monstren wie prototype.js konnte ich bisher immer recht gut umgehen. Ich schreibe mir da lieber selbst etwas, was ich überschauen und bei Bedarf auch problemlos erklären kann.

Abgesehen davon stellst sich natürlich bei solchen Antworten (input button) durchaus die Frage nach Desingvorgaben und Umsetzungsaufwand.

Diese stellt sich doch praktisch immer.

PS: ziel --> taget. <a target=" ..."> muss ich noch was dazu sagen?

Eine Erläuterung wäre in der Tat nicht verwerflich. Da wir beide wissen, was ich mit „Ziel“ meinte, würde mich dies interessieren.

Ich weiss was du meinstest, aber du hast so an der "ein Link ist ein Link ist ein Link" festgehalten, …

… was ich auch weiterhin tun werde. Es sollten aus meiner Sicht nun einmal stets die passenden Mittel gewählt werden, um ein Ziel zu erreichen.

Einen schönen Donnerstag noch.

Gruß, Mathias

[Miriam]

Hat wunderbar geklappt, vielen Dank für Eure schnelle Hilfe.

Die Miri