Browserens standard handlinger

Mange events følger automatisk med bestemte handlinger, som udføres af browseren.

For eksempel:

• Et klik pÃ¥ et link – starter navigation til dens URL.
• Et klik pÃ¥ en form submit-knap – starter indsendelsen af formen til serveren.
• Tryk pÃ¥ en museknap over en tekst og flytter den efterfølgende – vælger teksten.

Hvis vi håndterer et event i JavaScript, vil vi måske ikke ønske den tilsvarende browserhandling skal ske. Det kan være, at vi ønsker at implementere en anden adfærd i stedet.

Forhindring af browserhandling

Der er to måder at sige til browseren, at vi ikke vil have den til at handle:

• Standardmetoden er at bruge event-objektet. I den er der metode event.preventDefault().
• Hvis handleren er tildelt ved hjælp af on<event> (ikke ved hjælp af addEventListener), sÃ¥ virker det samme, hvis man returnerer false.

I dette HTML vil et klik på et link ikke føre til navigation; browseren gør ikke noget:

<a href="/" onclick="return false">Klik her</a>
eller
<a href="/" onclick="event.preventDefault()">her</a>

I det næste eksempel vil vi bruge denne teknik til at skabe et menu baseret på JavaScript.

Eksempel: en menu

Forestil dig en menu på et websted, som denne:

<ul id="menu" class="menu">
  <li><a href="/html">HTML</a></li>
  <li><a href="/javascript">JavaScript</a></li>
  <li><a href="/css">CSS</a></li>
</ul>

Her er hvordan det ser ud med noget CSS:

Menupunkter implementeres som HTML-links <a>, ikke knapper <button>. Der er flere grunde til at gøre det pÃ¥ denne mÃ¥de, for eksempel:

• Mange brugere foretrækker at bruge “højreklik” – “åbn i et nyt vindue”. Hvis vi bruger <button> eller <span>, virker det ikke.
• Søgemaskiner følger <a href="..."> links mens de indexerer.

SÃ¥ vi bruger <a> i markup’en. Men normalt vil vi hÃ¥ndtere klik i JavaScript. SÃ¥ vi bør forhindre den standard browserhandling.

SÃ¥dan her:

menu.onclick = function(event) {
  if (event.target.nodeName != 'A') return;

  let href = event.target.getAttribute('href');
  alert( href ); // ...kan være at der hentes fra en server, generering af UI osv.

  return false; // forhindrer browserhandling (gå ikke til URL'en)
};

Hvis vi udelader return false, vil browseren efter vores kode eksekveres køre sin “standardhandling” – navigere til URL’en i href. Det har vi ikke brug for her, da vi hÃ¥ndterer klikket selv.

Forresten vil event delegation gøre vores menu meget fleksibel. Vi kan tilføje indre lister og style dem så de “glider ned” ved hjælp af CSS.

<input value="Fokus virker" onfocus="this.value=''">
<input onmousedown="return false" onfocus="this.value=''" value="Klik mig">

Den “passive” handler mulighed

Den frivillige indstilling passive: true i addEventListener signalerer til browseren, at handleren ikke vil kalde preventDefault().

Hvorfor vil det være nødvendigt?

Der findes events som touchmove pÃ¥ mobile enheder (nÃ¥r brugeren flytter sin finger over skærmen), som forÃ¥rsager rulning (scrolling) som standard, men hvor denne rulning kan forhindres ved hjælp af preventDefault() i handleren.

SÃ¥ nÃ¥r browseren registrerer et sÃ¥dant event, skal den først behandle alle handlers, og derefter, hvis preventDefault ikke kaldes nogen steder, kan den fortsætte med rulningen. Det kan forÃ¥rsage unødige forsinkelser og “hakker” i brugerfladen.

Indstillingen passive: true fortæller browseren, at handleren ikke vil annullere rulningen. Derefter ruller browseren umiddelbart, hvilket giver bedst mulighed for en flydende oplevelse, og eventet hÃ¥ndteres pÃ¥ den mÃ¥de.

For noglebrowsere (Firefox, Chrome), er passive sat til true som standardværdi for touchstart og touchmove events.

event.defaultPrevented

Egenskaben event.defaultPrevented er true, hvis standardhandlingen blev forhindret, og false ellers.

Der er et interessant case for det.

Du husker mÃ¥ske kapitlet Bubbling og capturing hvor vi talte om event.stopPropagation() og hvorfor det er dÃ¥rligt at stoppe bubbling?

Nogle gange kan vi bruge event.defaultPrevented i stedet for at signalere andre event handlers, at eventet er blevet hÃ¥ndteret.

Lad os se et praktisk eksempel.

Som udgangspunkt viser browseren ved et contextmenu-event (højre museklik) en kontekstmenu med standardindstillinger. Vi kan forhindre dette og vise vores egen menu, pÃ¥ følgende mÃ¥de:

<button>Højreklik viser browserens kontekstmenu</button>

<button oncontextmenu="alert('Tegn vores kontekstmenu'); return false">
  Højreklik viser vores kontekstmenu
</button>

Nu, udover den kontekstmenu, vi har, vil vi gerne implementere en kontekstmenu på dokumentniveau.

Ved højre museklik skal den nærmeste kontekstmenu vises.

<p>Højreklik her for dokumentets kontekstmenu</p>
<button id="elem">Højreklik her for knappens kontekstmenu</button>

<script>
  elem.oncontextmenu = function(event) {
    event.preventDefault();
    alert("Knappens kontekstmenu");
  };

  document.oncontextmenu = function(event) {
    event.preventDefault();
    alert("Dokumentets kontekstmenu");
  };
</script>

Problemet er, at nÃ¥r vi klikker pÃ¥ elem, fÃ¥r vi to menuer: den ene pÃ¥ knapniveau og (eventet bobler op) den anden pÃ¥ dokumentniveau.

Hvordan fikser vi det? En løsning kunne være at tænke: “NÃ¥r vi hÃ¥ndterer højre museklik i knap-hÃ¥ndteringen, sÃ¥ stopper vi dens bobling” og bruger event.stopPropagation():

<p>Højreklik for dokumentets kontekstmenu</p>
<button id="elem">Højreklik for knappens kontekstmenu (rettet med event.stopPropagation)</button>

<script>
  elem.oncontextmenu = function(event) {
    event.preventDefault();
    event.stopPropagation();
    alert("Knappens kontekstmenu");
  };

  document.oncontextmenu = function(event) {
    event.preventDefault();
    alert("Dokumentets kontekstmenu");
  };
</script>

Nu virker knappens kontekstmenu som forventet. Men prisen er høj. Vi forhindrer for altid adgang til information om højre museklik for enhver ydre kode, herunder tællere, der indsamler statistik og så videre. Det er ikke helt klogt.

En alternativ løsning ville være at tjekke i document-hÃ¥ndteringen, om standardhandlingen blev forhindret? Hvis det er tilfældet, sÃ¥ blev eventet hÃ¥ndteret, og vi behøver ikke reagere pÃ¥ det.

<p>Højreklik for dokumentets kontekstmenu (tilføjet en kontrol af event.defaultPrevented)</p>
<button id="elem">Højreklik for knappens kontekstmenu</button>

<script>
  elem.oncontextmenu = function(event) {
    event.preventDefault();
    alert("Knappens kontekstmenu");
  };

  document.oncontextmenu = function(event) {
    if (event.defaultPrevented) return;

    event.preventDefault();
    alert("Dokumentets kontekstmenu");
  };
</script>

Nu virker alt som forventet. Hvis vi har indlejrede elementer, og hvert enkelt har sin egen kontekstmenu, vil det ogsÃ¥ virke. Sørg blot for at tjekke for event.defaultPrevented i hver contextmenu-hÃ¥ndtering.

Opsummering

Der er mange standard browser-handlinger:

• mousedown – starter valg (flyt musen for at vælge).
• click pÃ¥ <input type="checkbox"> – markerer/afmarkerer et input.
• submit – Klik pÃ¥ <input type="submit"> eller tast Enter inde i et formularfelt medfører at denne event opstÃ¥r, og browseren sender formen.
• keydown – tryk pÃ¥ en tast kan medføre tilføjelse af et tegn i et felt, eller andre handlinger.
• contextmenu – denne event opstÃ¥r ved et højreklik, og handlingen er at vise browserens kontekstmenu.
• …og der er flere…

Alle de standard handlinger kan forhindres, hvis vi ønsker at håndtere eventen udelukkende med JavaScript.

For at forhindre en standard handling – brug enten event.preventDefault() eller return false. Den anden metode virker kun for hÃ¥ndteringer, der er tildelt med on<event>.

Indstillingen passive: true pÃ¥ addEventListener fortæller browseren, at handlingen ikke vil blive forhindret. Det er nyttigt for nogle mobile events, som touchstart og touchmove, for at fortælle browseren, at den ikke skal vente pÃ¥, at alle hÃ¥ndteringer er færdige, før den begynder at scrolle.

Hvis en standard handling blev forhindret, bliver værdien af event.defaultPrevented til true, ellers er det false.