[HTML] event-handling

[JeromeB]

In HTML kan men via event-handlers data (bijvoorbeeld het aanroepen van een functie) naar een scriptengine (bijvoorbeeld een javascript-interpreter) sturen. Hoe weet een browser naar welke scriptengine het de data moet sturen?

Ik zal mijn vraag illustreren met een voorbeeld:

Mijn denkbeeldige browser ondersteund HTML en kent drie scripttalen die alledrie gebruik maken van een aparte scriptengine.
De desbetreffende talen zijn javascript, onzinscript1 en onzinscript2.

Mijn HTML-pagina ziet er alsvolgt uit:

code:

<script type="text/javascript">
function bloeb()
{
    window.alert("javascript");
}
</script>

<script type="text/onzinscript1">
function bloeb()
{
    window.alert("onzinscript1");
}
</script>

<script type="text/onzinscript2">
function bloeb()
{
    window.alert("onzinscript2");
}
</script>

<p onClick="bloeb()">bloeb</p>

In bepaalde browsers krijgt "javascript" voorrang, maar dat is volgensmij niet correct. Het staat immers niet in de HTML-specificaties hoe een browser hier mee om moet gaan.

Bij bepaalde browser kan men gebruik maken van een javascript-keyword.
Dan gebruik je de eventhandler dus alsvolgt:

code:

<p onClick="javascript:bloeb()">bloeb</p>

Op deze wijze zou je het probleem kunnen verhelpen, maar volgensmij staat dat niet in de HTML-specificaties.

------------------------

Ook zou ik graag willen weten hoe men dit in XML-subsets (zoals XHTML of SVG) oplost.

[Verwijderd]

dat laatste is niet correct in een event handler toch? alleen in een href attribuut.

Verder niet echt een antwoord op je vraag.. ben eigenlijk ook wel nieuwschierig. Ik weet ook eigenlijk niet of de scope van een functie beperkt blijft binnen 1 taal, volgens mij kon je in het geval van IE vbscript en javascript ook functies van elkaar aanroepen. Als de scope dus het hele document is, dan is het gewoon de laatste functie die aangeroepen wordt, die overschrijft immers de rest.

[JeromeB]

Verwijderd schreef op donderdag 07 juli 2005 @ 23:42:
dat laatste is niet correct in een event handler toch? alleen in een href attribuut.

Tja, wat wel correct is in een event-handler en wat niet correct is in een event-handler staat volgensmij niet gedocumenteerd.

------------------------------------------

Het wordt trouwens nog ingewikkelder wanneer men alles een beetje gaat mixen. Stel dat ik eerst de functie bloeb() van javascript wil aanspreken en daarna de functie bloeb() van onzinscript1.

Een ander voorbeeld:

code:

<script type="text/javascript">
function bloeb()
{
    window.alert("javascript bloeb");
}
function haidiho()
{
    window.alert("javascript haidiho");
}
</script>
<script type="text/onzinscript1">
function bloeb()
{
    window.alert("onzinscript1 bloeb");
}
function haidiho()
{
    window.alert("onzinscript1 haidiho");
}
</script>

<p onClick="bloeb();haidiho()">bloeb en haidiho</p>

Ik wil de javascriptfunctie bloeb() en de onzinscript1functie haidiho() aanspreken.

[crisp]

In principe moet je via een meta-element een default scripting language opgeven.
Het gebruik van pseudo-protocols in event-handlers is fout; een event-handler mag enkel script-data bevatten en een protocol is geen script-data.

Overigens hanteerd zo'n beetje elke browser javascript als default scripting language.

[ Voor 14% gewijzigd door crisp op 08-07-2005 01:39 ]

[JeromeB]

Dat verklaart al een hoop, maar stel dat ik javascript als default instel terwijl ik in onzinscript1 en onzinscript2 functies heb met dezelfde namen. Dan zit je nog steeds met een probleem.

edit:

Crisp, in de specificaties (onder het kopje Local declaration of a scripting language) staat het volgende:

The type attribute must be specified for each SCRIPT element instance in a document. The value of the type attribute for a SCRIPT element overrides the default scripting language for that element.

In mijn voorbeelden maak ik gebruik van het type-attribuut voor SCRIPT elementen. Er staat nergens in de specificaties dat de default-language voorrang heeft bij functies met dezelfde naam.

[ Voor 60% gewijzigd door JeromeB op 08-07-2005 02:50 ]

[JeromeB]

Ik hoop dat iemand nog nuttige antwoorden heeft. Ik heb zelf geen antwoorden kunnen vinden.

[Clay]

Waarom zou je je markup vervuilen met event attributen als elk script ook zelf toegang heeft tot de dom en deze events dynamisch zou kunnen toewijzen? Dan heb je dit hele probleem namelijk niet meer. Scheiding van markup en gedrag enzo

[Bosmonster]

Ik snap het probleem niet zo. Browsers herkennen simpelweg maar bepaalde content-types van scripts toch? text/javascript is er een van, text/onzinscript1 wordt gewoon genegeerd omdat ie voor dat content-type geen parser aan boord heeft.

javascript: in een event is sowieso fout, aangezien javascript: niks anders is dan een soort interne url-wrapper voor script.

[Verwijderd]

is het nu niet in je opgekomen gewoon eens te testen?
dan doe ik het wel

code:

<script type="text/vbscript">
function foo() 
  MsgBox "VBscript"
end function
</script>

<script type="text/javascript">
function foo() {
  alert('javascript');
}
</script>

<body onload="foo()">
</body>

in IE natuurlijk
Dit levert "vbscript" draai je de functies in volgorde om wordt er "javascript" ge alert.

[Bosmonster]

Ah en ja.. herdefinities van functies overschrijven uiteraard oude definities

[Verwijderd]

dan lees je niet goed,
degene die als eerste komt wordt 't.

[AtleX]

Verwijderd schreef op maandag 11 juli 2005 @ 11:01:
dan lees je niet goed,
degene die als eerste komt wordt 't.

En IE luistert duidelijk ook niet naar een meta-tag met de default scripting language, iig niet in het volgende script:

HTML:

<html>
<head>
<title>Testcase eventhandling</title>

<script type="text/vbscript">
function foo() 
  MsgBox "VBscript"
end function
</script>

<script type="text/javascript">
function foo() {
  alert('javascript');
}
</script>

<meta http-equiv="Content-Script-Type" content="text/javascript">

</head>

<body onload="foo()">
</body>
</html>

Het maakt niet uit of ik die meta-tag boven of onder de <script>..</script> tags zet (logisch natuurlijk).

[Bosmonster]

Verwijderd schreef op maandag 11 juli 2005 @ 11:01:
dan lees je niet goed,
degene die als eerste komt wordt 't.

hmm.. apart..

maar moet toegeven dat ik nog nooit vbscript en javascript samen gebruikt heb in een pagina

[JeromeB]

Clay schreef op maandag 11 juli 2005 @ 09:14:
Waarom zou je je markup vervuilen met event attributen als elk script ook zelf toegang heeft tot de dom en deze events dynamisch zou kunnen toewijzen? Dan heb je dit hele probleem namelijk niet meer. Scheiding van markup en gedrag enzo

Ik regel de eventhandling ook liever middels het script, maar daar draait deze discussie niet om.

Verwijderd schreef op maandag 11 juli 2005 @ 11:01:
dan lees je niet goed,
degene die als eerste komt wordt 't.

Dat geldt voor IE, maar is dat standaard gedrag? Ik kan nergens in de specificatie vinden dat het op deze wijze moet.

Bosmonster schreef op maandag 11 juli 2005 @ 10:25:
Ik snap het probleem niet zo. Browsers herkennen simpelweg maar bepaalde content-types van scripts toch? text/javascript is er een van, text/onzinscript1 wordt gewoon genegeerd omdat ie voor dat content-type geen parser aan boord heeft.

Het gaat niet om implementatie van bestaande browsers. Stel dat ik mijn eigen browser wil maken met ondersteuning voor javascript, onzinscript1 en onzinscript2 dan weet ik niet hoe ik dit moet afhandelen. De specificaties zijn niet duidelijk wat betreft dit probleem.

AtleX schreef op maandag 11 juli 2005 @ 11:21:
[...]

En IE luistert duidelijk ook niet naar een meta-tag met de default scripting language

Je gebruikt het type-attribute op SCRIPT-elementen. Default Scripting Language is in jouw script dus ook helemaal overbodig.


-------------------------------------------------

Iedereen bedankt. Misschien moet ik dit gewoon zien als een onvolkomenheid in de specificaties.

[ Voor 18% gewijzigd door JeromeB op 11-07-2005 11:29 ]