[DOM] document.anchors versus document.getElementsByTagName

[0528973]

Hi allemaal,

Bedankt voor het openen van dit topic.

In HTML 4.01 Strict mag je geen gebruik meer maken van target="_blank" bij <a> tags. Geen probleem denk ik dan, we maken een javascript functie die dat voor mij regelt . Na wat rondgekeken te hebben op het internet kwam ik een aantal oplossingen tegen op basis van de getElementsByTagName() functie. Voor deze functie is echter geen W3C standaard,
bron http://www.w3schools.com/htmldom/dom_obj_document.asp

En toen viel mijn oog op de property anchors, anchors is een array met daarin alle <a> tags in het document waarvan het name property is gezet. En voor anchors bestaat wel een W3C standaard.

Nu heb ik de site waar dit in verwerkt zit, in mijn ogen keurig opgezet(ondanks het n00b zijn op dit gebied) en dus neig ik zelf meer naar het gebruik van document.anchors icm het vullen van de name-property van elke <a> tag die relevant is.

Mijn vraag:
Welke optie gebruiken jullie eerder als jullie een HTML 4.01 Strict pagina moeten maken, waarin een aantal <a> tags zitten welke in een nieuwe pagina geopend moeten worden. Gebruiken jullie liever de functie getElementsByTagName(waar geen W3C standaard van bestaat) of gebruiken jullie liever de property anchors.

==============================
Nu niet gaan klagen, dat dit niet netjes is en lelijk enzo AUB, wat ik tot nu toe gelezen heb(bron: http://www.sitepoint.com/article/standards-compliant-world). HTML moet de structuur van een site weergeven, niet hoe de site exact werkt. Voor het uiterlijk van een site, gebruiken we namelijk CSS en voor bepaalde leuke effecten gebruiken we javascript icm CSS. Het openen van een <a> tag valt niet onder structuur van een site en valt niet onder het uiterlijk van een site, dus dan zou je zoiets met javascript moeten oplossen denk ik zo. Niet iedereen zal het met deze stelling eens zijn, mocht je echt goede argumenten hebben om het niet met javascript oid te doen dan hoor ik ze graag.

En oh ja, nu kunnen we ook gaan neuzelen over, als je target="_blank" toch wilt, dan moet je maar HTML 4.01 Transisitional gebruiken ipv Strict maar dat is niet de discussie, dus laten we dat liever niet doen.

[ Voor 32% gewijzigd door 0528973 op 26-08-2004 16:25 ]

[BtM909]

target=_blank niet gebruiken

Ik gebruik tegenwoordig geen van beide opties. Nu zet ik met css een extra plaatje achter external links. Mogen bezoekers zelf bepalen in welke window zij het openen

[Verwijderd]

geen W3C standaard?

Volgens mij zie ik hem er toch echt tussen staan.

[Verwijderd]

Wat ik gewoon doe is:

code:

<a href="http://example.com" rel="external" onclick="target='_blank';">

Dat werkt ook

[ Voor 75% gewijzigd door Verwijderd op 26-08-2004 17:43 ]

[Skaah]

Verwijderd schreef op 26 augustus 2004 @ 17:41:
Wat ik gewoon doe is:

code:

<a href="http://example.com" rel="external" onclick="target='_blank';">

Dat werkt ook

Moet dat niet zijn

code:

<a href="http://example.com" rel="external" onclick="this.target='_blank';">

[simon]

is dan weer erg onzinnig om je dan aan de standaarden te houden, als je je er eigenlijk niet aanhoudt...

[Clay]

vertel dat een klant of manager.

Vind het persoonlijk dan wel aardig werken om het rel attribuut te misbruiken, en dat met een script op te vangen. Als het dan b.v. een popup zou moeten zijn kan je de link gewoon in de href laten, en aan de hand van de rel en wat eventgescript een popup laten openen. Bovendien kan je dan de ctrl en shift nog bekijken en de gebruiker alsnog laten kiezen de link in een nieuwe tab of window te openen, ipv altijd je popup.

[Genoil]

Clay schreef op 26 augustus 2004 @ 19:18:
vertel dat een klant of manager.

ja, vertel dat dan aan je klant of manager ! denk je nou werkelijk dat het target attribute uit Strict DOCTYPEs gehaald is om webdesigners en standaardofielen te pesten, zodat ze hun toevlucht moeten zoeken in "ranzige" scriptjes?

target hoort gewoon niet bij HTML, omdat het gaat over een ander dat het eigen browservenster. Aangezien HTML gaat over de inhoud van het venster en niet wat daarbuiten ligt, is target overbodig.

daarnaast doet target de aanname dat een HTML pagina altijd in een GUI met venster-metafoor zit. dat is lang niet altijd zo en het beperkt je in het bedenken van alternatieven.

op de lange duur raken dit soort rare omweggetjes hopelijk in de vergetelheid en leren mensen dat target="_blank" eigenlijk een browser-feature hoort te zijn ipv een HTML feature...

edit:
ow..je bent helemaal niet TS...je bent Clay..ik helemaal preken enzo...laat maar

[ Voor 14% gewijzigd door Genoil op 26-08-2004 19:30 ]

[Clay]

_{geeft niet hoor}

[Verwijderd]

Skaah schreef op 26 augustus 2004 @ 18:21:
[...]

Moet dat niet zijn

code:

<a href="http://example.com" rel="external" onclick="this.target='_blank';">

Dat dacht ik eerst ook, maar zonder this. werkt het uitstekend in alle browsers... blijkbaar wordt die self reference automatisch uitgevogeld

[0528973]

Deze antwoorden helpen me nu niet echt verder op weg,

@Genoil opzich heb je idd wle gelijk, het hoort een browser feature te zijn... maar waarom zou het een feature zijn die je compleet aan de gebruiker over wilt laten...

Als ik dat vertel aan mijn huidige opdrachtgever zal die me met ogen die water zien branden aankijken en zeggen, ja leuk maar die site kan het toch ook... Gelukkig is deze site dan ook niet voor de baas

Oftewel jij stelt dus voor om dan geen gebruik te maken van Strict maar om gebruik te maken van Transitional.

Btw. als jij een site bezoekt, vind jij het dan vervelender als je op een link klinkt en in het huidige venster wordt gesprongen naar de nieuwe site, terwijl je eigenlijk ook de oude site nog wilt bekijken en terug moet via een 'back optie' van je browser, of dat de site zich opent in een nieuw venstern? Nu ga jij natuurlijk zeggen, als ik het in een nieuw venster wil, dan doe ik dat zelf toch lekker.... nou, helaas zijn niet alle mensen het daar mee eens. Die willen het namelijk op een mooi gouden presenteerblaadje aangereikt krijgen

@shadow3333
idd hij staat er bij het w3c wel tussen, waarom staat er op de site van w3schools.com dan duidelijk NO achter de functie getElementsByTagName onder het kopje W3C?

@Jaap
Persoonlijk gebruik ik liever dit Javascriptje, mocht ik dan ineens beslissen om alle linkjes die in een nieuw venster openen niet meer te willen gebruiken dan hoef ik alleen maar het stukje javascript niet meer te runnen en hoef ik nergens meer te controleren of ik nog een onclick="target='_blank'" heb staan..
Ondanks dat dit geen ijzersterke reden is om jou manier niet over te nemen. Het enige voordeel met jouw methode is dat het niet meer tijdens het window.onload event hoeft te worden uitgevoerd, waardoor de pagina sneller kan inladen.

Komop mensen, geef me eens argumenten waarom ik voor het 1 of het ander moet kiezen. Of geef me eens argumenten waarom ik geen Strict maar Transitional moet gebruiken. Opzich heeft Simon wel gelijk, waarom je aan een standaard houden als je je er niet helemaal aan houdt... Maar Simon heeft toch ook weer geen gelijk, wat ik gemaakt heb, houdt zich in elk geval aan de Transitional Standaard, dus ik gebruik nog steeds een standaard, het is echter een standaard die ik liever niet gebruik omdat er een in mijn ogen betere standaard is waar ik echter niet 100% aan kan voldoen. Dit zie ik echter niet als reden om mjin site zich niet zoveel mogelijk aan de stricste standaard te laten voldoen.

[ Voor 30% gewijzigd door 0528973 op 26-08-2004 21:43 ]

[CrashOne]

Strict houdt natuulijk meer in dan het alleen valideren van je site, het is ook een stukje usability. Als iedere link in het huidige venster geopent wordt beslist de gebruiker zelf wat er met zijn vensters gebeurt, niet de maker van de site.

Ik zelf zou kiezen voor de manier met het rel attribuut. Javascript welke niet direct aan de link gekoppeld zodat je inderdaad je JS er los van kunt koppelen.

Ik zelf ben er aan gewent dat externe links in een nieuw venster openen, iets wat klanten ook vaak verwachten. Ze willen immers de potentiele klant niet van hun site deze willen ze weer terug zien wanneer het geopende venster gesloten wordt.

Als dit geen gewenning is kan ik me voorstellen dat je alles in 1 venster wilt houden.

Zo zou je zelf moeten beslissen wat jij wilt.

[0528973]

Mensen,
Waarom negeren jullie mijn feitelijk vraag en antwoorden jullie op een deel-probleem.
De meeste argumenten en oplossingen(behalve dan die van Jaap) had ik ookal zelf verzonnen. Ondertussen blijkt dat ik een aanname fout heb gemaakt,
de functie document.getElementsByTagName() zit toch in de W3C specificatie en dus vraag ik me tevens af waarom w3schools.com zegt van niet. Ik ga hier maar eens verder voor zoeken op het web, mochten jullie weten waarom meld het hier dan even aub.

Niemand hier heeft tot nu toe mijn vraag feitelijk beantwoord, jullie geven allemaal aan dat er ook nog andere soorten van oplossingen zijn, of dat het geen goede methode is. HTML is hier namelijk niet voor bedoeld, de gebruiker moet dat zelf maar beslissen.

Laten we er even vanuit gaan, dat HTML niet de plaats is om dit te regelen, maar dat Javascript de plaats is om dit te doen. Welke van de 2 opties zou je dan gebruiken en wanneer zou je die laten uitvoeren, tijdens je window.onload event of op een ander moment.

[crisp]

ik gebruik amper nog onload; meestal run ik mijn scripts vlak voor de </body> tag zodat het al tijdens het parsen wordt uitgevoerd, en niet pas nadat ook alle images e.d. ingeladen zijn. Nadeel is dat je toch weer script in je document hebt, maar onload is in veel gevallen gewoon te laat...

[0528973]

Thanx Crisp, ik weet niet precies wanneer het event window.onload plaats vind. dat gaat ik eens uitzoeken. Als ik je antwoord zo lees, verwacht dat ik window.onload pas plaats vind als de site compleet is ingeladen en getoond wordt. Anders zou het namelijk nooit veel te laat zijn.

Heeft nog steeds niemand een voorkeur voor getElementsByTagName of voor document.anchors?

Verschillen:
document.getElementByTagName levert een lijst met referenced objecten op, welke je eerst nog in een variable moet opvangen en dan met functie calls kan doorlopen(getNext ed functies). Ik vermoed dat document.getElementByTagName eerst nog het hele document moet doorzoeken en dan pas het resultaat teruggeeft.
In dit resultaat zitten dan zelfs nog alle <A> tags, waarvan de link niet in een nieuw venster geopend moet worden. Dit is ten opzichte van document.anchors dus al een flink perfomance verlies...

Het nadeel van document.anchors is dus dat je elke <A> tag een naam moet geven anders wordt de <A> niet opgenomen in de array. Dit betekent dus gemiddeld
( aantal <A> tags voor externe link * (8+lengte naam) ) aan characters meer in je HTML document. Let op, <A> tags komen voor zover ik heb kunnen testen alleen in de anchors array als hun 'name' property is ingevuld.

Verder heb je in beide situaties als het goed is niet de mogelijkheid om out-of-bounds of no object excepties te krijgen omdat je gewoon de mogelijkheden van beide opties gebruikt om er doorheen te lopen.

Oftewel de performance winst die je behaald door het direct benaderen van de anchors array kan je kwijt raken wanneer je veel <A> tags hebt die in een nieuw venster moeten openen. Wanneer je echt veel <A> tags hebt die in een nieuw venster moeten openen verwacht ik dat je wel overgaat op Transitional ipv Strict, al kan ik deze verwachting niet onderbouwen.

Mijn conclusie, ik gebruik toch liever de anchors array, voor zover ik kan zien wordt deze array gewoon netjes ondersteund en blijft tie nog wel even rondhangen in de DOM specificatie.

Om niet alle stukjes javascript die nodig zijn in een window.onload te stoppen maar vlak voor het einde van je HTML document klinkt als een handige tip. Ik ga hier nog is over nadenken. Het levert idd wat javascript code op in je HTML document, maar dat zullen niet veel functie calls zijn. De rest kan je namelijk toch nog steeds netjes wegstoppen in een extern javascript bestandje.... Het tijdens het parsen van je document uitvoeren van de benodigde functies is idd zeer handig, wanneer de gebruiker je pagina dan bekijkt heb je namelijk niet het probleem dat hij eerder ergens op kan klikken als dat jou functie klaar is met het juist zetten van de targets van elke <A> tag.

Misschien dat mijn vraag, toch bij de buren thuishoort ipv hier ondanks dat het clientside scripting is.

[ Voor 17% gewijzigd door 0528973 op 27-08-2004 00:01 ]

[Genoil]

crisp schreef op 26 augustus 2004 @ 23:13:
maar onload is in veel gevallen gewoon te laat...

in dit geval inderdaad

Maar om even op je laatste vraag aan mij terug komen 0528973, persoonlijk vind ik dat als een opdrachtgever (of je dat zelf nu bent of niet) vraagt om Strict, hij of zij daar ook de consequenties van moet aanvaarden. Als je Strict wilt, impliceert dat volgens mij dat je geen target="_blank" nodig hebt.

Het valideren van je pagina tegen een bepaald DOCTYPE is een bijzaak voor de eigenlijke functie van een DOCTYPE en hetgeen deze voorschrijft.

Je geeft zelf aan dat je gebruikers verwacht die verwachten dat die nieuwe vensters vanzelf open gaan. Kies er dan ook een geschikt DOCTYPE bij, Transitional is er ook niet voor niets. Transitional is er juist voor gemaakt om toch aan een aantal zeer grote en belangrijke wensen tegemoet te komen. Ze verwachten daar bij W3C uiteindelijk wel dat je tot hun Strict evangelie over gaat, je bent immers transitional .

Maar ik ben ook weer niet te beroerd om door jou te kijken en een advies uit te brengen over een funky scriptje waarmee je de heren van W3C het bos in stuurt:
document.getElementsByTagName, zonder twijfel.

[0528973]

@Genoil.

Thanx je bent de 1ste die mijn vraag echt beantwoord echter wel pas nadat ik een keus gemaakt heb. Zou je je keuze voor de functie ipv de property kunnen onderbouwen, op een manier zoals ik in mijn vorige post(welke ik net editte) voor mijn keus ook gedaan heb.

[disjfa]

0528973 schreef op 26 augustus 2004 @ 23:54:
Heeft nog steeds niemand een voorkeur voor getElementsByTagName of voor document.anchors?

Het verschil daarin is dat het ene een IE feature is en het andere een algemene feature is.

Verschil tussen dat je wilt dat een pagina in een nieuw venster word geopend ipv een huidig venster is alleen een handigheidsoptie die is ingebouwd door mensen die dat wilden ipv mensen die correcte sites maakten

Als jij dat nog wilt gebruiken moet je dat vooral doen.

[0528973]

Hmm... ik kijk is rond op msdn.microsoft.com enzo en zie daar toch echt staan en ook in de w3c documentatie, dat document.anchors in dom level 1 gespecificeerd wordt. Er wordt nergens gerept over het feit dat het een IE-feature zou moeten zijn.

anchors of type HTMLCollection, readonly
A collection of all the anchor (A) elements in a document with a value for the name attribute.Note. For reasons of backwards compatibility, the returned set of anchors only contains those anchors created with the name attribute, not those created with the id attribute.

Opzich maakt het dus weinig uit en werkt deze functionaliteit dus half vanwege backwards-compatibility.... naja, dan idd maar de functie getElementsByTagName gebruiken.... Helaas, zo zie je maar weer hoe een mens verkeerde aannamens kan maken

[ Voor 55% gewijzigd door 0528973 op 27-08-2004 00:19 ]

[mullah]

Het voordeel van getElementsByTagName is dat je met

code:

var allAnchors = document.getElementsByTagName("A");
 for (i=0; i<allAnchors.length; i++) {
  if (allAnchors[i].className=="external") {
   // doe iets voor alle links met class external
  }
 }

heel makkelijk alle links van een bepaalde class kunt aanpassen, ik weet niet of dat met document.anchors zo makkelijk kan

---
Wat is rel="external" trouwens... zit dat ook in de specs?

[ Voor 18% gewijzigd door mullah op 27-08-2004 00:38 . Reden: eerst tiepfaudjes kijken, dan submitten ]

[disjfa]

mullah schreef op 27 augustus 2004 @ 00:35:
heel makkelijk alle links van een bepaalde class kunt aanpassen, ik weet niet of da met document.anchors zo makkelijk kan

Ik gooi nu een wilde gok in het midden hoor, maar in document.anchors[i].className zitten waarschijnlijk dezelfde waardes als document.getElementByTagname("a").className

Maaja ik ben weer is gek bezig

Heb ook wat fouten erin zitten. Verzin die zelf maar

[ Voor 8% gewijzigd door disjfa op 27-08-2004 00:38 ]

[mullah]

Doen we het toch zo:

code:

function changeElements (tag, tagClass) {
 var allElements = document.getElementsByTagName(tag);
 for (i=0; i<allElements.length; i++) {
  if (allElements[i].className==tagClass) {
   // doe iets voor alle tags met tagClass
  }
 }
}

.. heb je weer een ander voordeel getElementsByTagName kun je voor alle tags gebruiken

[0528973]

@mullah
De huidge code:

code:

/* Wanneer alleen de <A> tags met een external link hun 'name' vullen
    dan voldoet de onderstaande code, dit werkt alleen maar zo vanwege
    backwards compatibility en is dus eigenlijk 'not done' */

for(var i = 0; i < document.anchors.length; i++)
{
     document.anchors[i].target = "_blank";
}

Als ik alles goed doorheb, dan kan de bovenstaande oplossing ook zo:

while( anchor = document.anchors.nextSIbling )
{
     anchor.target = "_blank";
}

de eventueel andere oplossing
var anchors = document.getElementsByTagName( "A" );

code:

while( anchor = anchors.nextSibling )
{
     /* Even controleren of het niet om een echt ankertje gaat, echte ankers
        willen we nooit en te nimmer in een nieuw venster openen. */
     if( anchor.href != "#" && anchor.getAttribute( "rel" ) == "external" ) {
          anchor.target = "_blank";
     }
}

In essentie dus niet veel verschil, ondertussen weet ik dat beide opties gedefinieerd zijn in het DOM level 1 W3C... document.anchors is backwards compatible en levert idd alleen de <A> tags op waarvan de name="" is gevuld. Dus de eerdere opmerking dat document.anchors een IE-feature is heb ik nog steeds nergens teruggevonden. Echter het feit dat document.anchors backwards compatible is en vereist dat de name="" parameter gevuld moet zijn, maakt een handige optie om te "misbruiken".

[ Voor 74% gewijzigd door 0528973 op 27-08-2004 01:13 ]

[crisp]

0528973 schreef op 26 augustus 2004 @ 23:54:
Thanx Crisp, ik weet niet precies wanneer het event window.onload plaats vind. dat gaat ik eens uitzoeken. Als ik je antwoord zo lees, verwacht dat ik window.onload pas plaats vind als de site compleet is ingeladen en getoond wordt. Anders zou het namelijk nooit veel te laat zijn.
[...]

Het onload event wordt pas getriggered op het moment dat de gehele pagina inclusief plaatjes etcetera binnengehaald en geparsed is. Stel dat je een formulier hebt met wat plaatjes en je zet onload de focus op het eerste input element; wat er dan gebeurd als je een trage internetverbinding hebt is dat de HTML gerenderd wordt, de gebruiker alvast begint te typen in het eerste veld, een tab geeft naar het volgende veld, en op dat moment wordt de onload getriggered en de focus weer op het eerste veld gezet. Da's niet handig...
Als je direct na de </form> al het script plaatst wat die focus zet heb je nergens last van.

Overigens gaat mijn voorkeur uit naar getElementsByTagName. Wat betreft snelheid: zelfs met heel veel links in je document zijn dat soort dingen nog steeds rete-snel, ik heb daar nog nooit problemen mee gehad, zelfs niet op trage PC's.
Tevens heb ik een voorkeur om het rel-attribuut te gebruiken ipv een class of name:

JavaScript:

function external_links()
{
    var a = document.getElementsByTagName('a'), i = a.length;
    while (i--)
    {
        if (a.item(i).getAttribute('rel') == 'external')
        {
            a.item(i).onclick = function() { window.open(this.href); return false; }
        }
    }
}

[Verwijderd]

Ik mis jullie drijfveer hiervoor eigenlijk een beetje.

Je wil het "target" attribuut niet gebruiken, dus maak je een script die het target stiekumpjes later invult, aan de hand van een ander attribuut.

een onclick=function(){window.open(...)} vind ik dan netter, maar dan nog snap ik de redenering niet.

Als de reden alleen is om aan de standaarden te voldoen vind ik het eigenlijk een beetje klets, want je zit er nu omheen te werken. Het target attribuut is er uit, juist omdat de user zelf zou moeten bepalen waar ie z'n link opent. Als jij (of je baas) het niet eens bent met die stelling, waarom zou je dan nog moeite doen om je ingewikkeld toch om de standaard te vouwen.

Je legt de idee van de standaard toch al naast je neer, waarom dan toch willen voldoen aan de implementatie ervan (op een bijzonder kromme manier)

Overigens is het toevoegen van een betekenisvolle "rel" (en evt rev) attribuut imho een goede bezigheid.

[Clay]

Eigenlijk vind ik het 2 verschillende dingen. het "target" attribuut uit html halen impliceert naar mijn mening helemaal niet dat je nooit links in nieuwe windows mag openen, de beweegredenen daarachter komen heel ergens anders vandaan. In screen media is het wel degelijk een functionaliteit die de client biedt. Het gevolg ervan is alleen wel dat als je het perse wil, dat je het op een andere manier moet doen.

Neem b.v. een actiesite ergens van, die in een passende popup van 780 bij 420 ofzo moet openen. Met iets ala:

code:

<a href="kekkeactiesite.html" rel="actiesite">woei!</a>

kan je dan best die rel oppakken om met script een window.open() te doen en daarmee de achterliggende site open te laten staan. Iets ala:

code:

document.attachEvent('onclick', function(event){
   if(event.ctrlKey || event.shiftKey) return true; // new window, tab, user == koning
   var target = event.srcElement;

   if(/actiesite/.test(target.getAttribute('rel')) {
      window.open(target.getAttribute('href'), 'actiesite', 'width=780,height=420');
      return false;
   }
});

_{</duim> en dan wat generiekers en xbrowsers in het echt enzo}

[0528973]

Hey mensen,

bedankt voor alle reacties tot nu toe, ik heb helaas nog niet de antwoorden voorbij zien komen die ik graag had willen zien. Ik wil me graag aan de standaard houden en het liefst de Strict standaard, echter kan ik het bij deze site niet ten koste laten gaan van de target="_blank" voor minimaal 2 linkjes op de site.

Wat ik dan kan doen, is of via javascript een in menig mening ranzige functie maken die er voor zorgt dat al mijn externe links in een nieuw venster geopend worden. Of ik valideer de site tegen Strict, pas alles aan totdat het door de Strict validatie heen komt en wijzig de 2 linkjes terug naar een target="_blank" en het doctype weer naar Transitional.

Niemand van jullie komt met een gefundeerde reden om de functie getElementsByTagName ipv de anchors collectie te gebruiken en dat is mijn feitelijke vraag. Nu heb ik hier gelukkig wel weer een paar goede tips gehad dus het is zeker een nuttige thread.

Feitelijk weet ik nog steeds niet wat ik moet doen, wel of geen javascript of anders het doctype aanpassen... moeilijk moeilijk moeilijk... Naja, eigenlijk heel makkelijk, maak de site in me vrije tijd voor iemand anders en die ander wilt de linkjes in een nieuw venster laten openen en dus zal ik Transitional gaan gebruiken. Er is tenslotte een standaard waar het wel in kan en dan kan ik idd beter die standaard gebruiken op de correcte manier, ipv een standaard gebruiken en hem dan maar voor 99% gebruiken vanwege wat javascript hacks...

Jammer, maar waar... iedereen bedankt voor zijn input. Heb een aantal interessante tips gehad. Ondertussen ben ik ook weer dingen wijzer geworden en heb ik een beslissing kunnen maken.

[crisp]

Verwijderd schreef op 27 augustus 2004 @ 09:15:
Ik mis jullie drijfveer hiervoor eigenlijk een beetje.

Je wil het "target" attribuut niet gebruiken, dus maak je een script die het target stiekumpjes later invult, aan de hand van een ander attribuut.

een onclick=function(){window.open(...)} vind ik dan netter, maar dan nog snap ik de redenering niet.

Als de reden alleen is om aan de standaarden te voldoen vind ik het eigenlijk een beetje klets, want je zit er nu omheen te werken. Het target attribuut is er uit, juist omdat de user zelf zou moeten bepalen waar ie z'n link opent. Als jij (of je baas) het niet eens bent met die stelling, waarom zou je dan nog moeite doen om je ingewikkeld toch om de standaard te vouwen.

Je legt de idee van de standaard toch al naast je neer, waarom dan toch willen voldoen aan de implementatie ervan (op een bijzonder kromme manier)

Overigens is het toevoegen van een betekenisvolle "rel" (en evt rev) attribuut imho een goede bezigheid.

Het ligt iets genuanceerder; je kan een dergelijke JS oplossing bijvoorbeeld toepassen op het moment dat een gebruiker aangeeft bepaalde links altijd in een nieuw window te willen openen, maar daarbij niet elke keer eraan hoeft te denken de shift-key eerst in te drukken. Op GoT is zoiets natuurlijk heel mooi met een pref te regelen: "Externe links default in nieuw window openen ja / nee"