Newsgroup: it.comp.lang.javascript
Titolo: Impedire TAB o _blank

Ciao a tutti,
mi domandavo se l'unico modo di impedire ad un link di essere aperto in una
nuova tab o una nuova finestra (cliccando contemporaneamente ctrl o shift)
fosse quello di sostituire il link con una span adeguatamente "eventizzato"
mi sarei aspettato che un bel return false sul onmousedown facesse al caso
mio ma mi sbagliavo...

 mio ma mi sbagliavo...
Il "return false" sull'onmousedown serve a poco, dovresti farlo
sull'onclick.
-- 
~ "Chi ci priva della libertà in nome della sicurezza,
non si merita nessuna delle due cose, nè la libertà,
nè la sicurezza." (Henry Adams)

 sull'onclick.
è la prima cosa che ho fatto è ho sempre creduto di non aver questo
problema (cioè a dire il vero non mi sono mai posto la questione) e cioè
che il browser se ne stesse non propagasse nient'altro e che fossimo tutti
felici e contenti :)
Tuttavia, ho scoperto che così non è :(
Allora ho pensato inutilmente che "annullando" a partire da un evento
evocato precedentemente potesse servire a qualcosa, ma chiaramente nemmeno
così è stato :(
Quindi per ora non ho trovato alternative se non un bottone o qualsiasi
cosa con onclick...

 cosa con onclick...
Ribadisco, puoi agire tranquillamente sull'onclick.
Se non puoi, dovresti spiegarci il perché. O se c'è qualche altra cosa
che t'impedisce di usare l'event handler in quel modo, nel contesto in
cui sei.
Volendo, andrebbe anche visto perché sei costretto a fare una cosa del
genere, e se quella è effettivamente la soluzione migliore.
-- 
~ "Ho avuto la fortuna di unire mestiere e passione,
che secondo Stendhal equivale alla felicità."
(Roland Barthes)

 genere, e se quella è effettivamente la soluzione migliore.
mi rendo conto che, ammesso che sia l'approccio corretto, avrei dovuto
prevedere all'onload anche un cambio di url sul "#" almeno non si fa
comparire la pagina che segnalerebbe un avviso errato...

 comparire la pagina che segnalerebbe un avviso errato...
Ecco, appunto. :) Oppure, modifica la pagina d'avviso.
Per quanto riguarda la correttezza dell'approccio, va visto di cosa
stiamo parlando: se è un sito web, se è un'applicazione web, se sei
in una intranet o su internet... Soprattutto va vista la quantità e
il tipo d'impiego che hai fatto di JS.
Ad esempio, su di un sito web con una quantità modesta di codice, è
tendenzialmente l'approccio migliore.
-- 
~ Tenete la morte lontano dalle strade. Guidate sul marciapiede.

 tendenzialmente l'approccio migliore.
allora vediamo:
si tratta di un'applicazione web all'interno di un sito con la limitazione
di JS abilitato senza versione alternativa (cosa che i commisionari del
lavoro ignorano) dove l'azione più importante di JS è quella di
visualizzare 4-5 step percorribili avanti e indietro senza fare richieste
al server (avendo precaricato tutto all'inizio e sistemato in livelli
opportunamente nascosti che via via sono resi visibili grazie ai link di
cui prima)

 di JS abilitato senza versione alternativa
Allora direi che il controllo lo puoi fare anche "a monte".
-- 
~ Un computer e'  fondamentalmente stupido. Non fa cio'  che vuoi che
faccia,  ma cio' che gli  dici di fare.

 Allora direi che il controllo lo puoi fare anche "a monte".
Sě, l'idea era di trovare una soluzione poco costatosa per intercettare
quelli che disabilitano a "runtime"...   :)

 quelli che disabilitano a "runtime"...   :)
Conosci qualcuno che disabilita JS a "runtime", il cui scopo non sia
manipolare il codice?
