Hvorfor virker denne event-håndtering kun i IE?

Udover din kode er rodet, ser det umiddelbart ikke forkert ud. Andre browsere som Firefox burde give din en fejlmeddelse, så hvis du kan finde sådan en og poste den ville det være rart.

Ellers skal vi til at fabrikere et HTML document først, og det er træls :/

der er ingen fejl, ellers kan jeg ikke finde ud af hvordan FF viser mig dem :)

Funktioner -> Fejlkonsol

siden kan forresten ses på sums.dk/admin så i kan se hvorledes det funker :)

var åbenbart min setfocus der voldte besværet :S

hvorfor må den ikke kaldes med document.login i stedet for at kalde den med document.getElementById('login') ?

Name vs. id ? Name er måske ikke ok i xhtml ?
Har ikke lige checket hvad årsagen er ...

okay det kunne ske det er det der gør det.

tømmer ff altid cachen når en ny version findes? fx i IE er jeg nødt til at sætte den til at deaktive cache når jeg oploader nye js-filer, det er ikke nødvendig for at teste i ff?

ang. min indsættelse af submit-event så er den stadig ikke helt i top i ff... den afbryder ikke afsendelsen som den gør i ie - hvad gør jeg galt der?

smider i et par svar? :)

fejlkonsollen siger:

Fejl: syntax error
Kildefil: http://sums.dk/admin/_js/login.js
Linje: 24, Kolonne: 52
Kildekode:
    addevent(document.getElementById('login'),'submit',return function(){return validate(document.getElementById('login'))});

argh gammel fejl, den fejl er rettet med to returner! tror jeg sover, men den afbryder stadig ikke afsendelsen

document.login skulle være fin nok når du har en <form name="login"> (note: name, ikke id!) men document.getElementById('login') er meget bedre, så brug den.

desuden er addevent lidt overkill i dit tilfælde.

var login = document.getElementById('login');
    login.submit = function() { return validate(login); }

er noget mere simpelt.

ups, det er login.onsubmit ikke login.submit

jamen er login.submit valid? mente man skulle bruge det andet hvis det skal være i xhtml?

Selvom jeg kører:
function events() {
    addevent(document.getElementById('login'),'submit',function(){return false;});
}

- Så submitter den stadig ... tester lidt, det virker umiddelbart somom at FF ikke accepterer nedkortningen. Jeg rodede selv med short events og endte vist med noget eval() som jeg droppede da det ikke var så slemt at skrive alt ind på min side


Windcape, vi er i xhtml så login.submit er vel ikke ok?

eval, er det ikke php? eller har javascript noget tilsvarende?

jeg kunne godt tænke mig at have det så nemt som muligt da det skal være grundstenen for mine fremtidige sider (ved at lave mig en administrationsskabelon)

login.onsubmit er en property af form-element, så kan ikke se hvorfor det ikke skulle være godkendt i xhtml ?

Checker lige :)

men hvis det er meningen at dine event funktioner skal virke, prøver jeg lige at bixe noget sammen.

Joh, både php og javascript har eval

<input type="text" value="5*5" onclick="this.value=eval(this.value);">

- eval er dog ikke en standard men en "browser proprietær" ting hedder det vist
(har vist fået det forklaret af Rønving eller Olebole for x antal måneder siden)

elm.attachEvent('on' + event,func);

bare et hint, ikke alle events starter med "on"

windcape, joh - det var skam meningen det skulle virke c",)

mclemens, det lyder skam ganske fornemt - hvordan brugte du det?

mclements eval() er ikke en del af ECMAscript standarden , det er hvad de mente :-)

Nej, i firefox gør de ikke derfor har han

function addevent(elm,event,func) {
    if (browser() == "IE") {
        elm.attachEvent('on' + event,func);
    }
    else elm.addEventListener(event,func,false);
}

- Som bruger henholdsvis Eventlistener eller attachEvent
afhængig af om det er den ene eller anden browser ...

så vidt jeg kan se er alle med on foran (når det skal gennems microsofts tilføjer)

http://www.oznet.ksu.edu/throckmorton/tutorials/javascript/events.htm

29/12-2006 01:09:29 Ah, ok det var sådan :D

elskermad.dk har lige ledt og ledt, men kan
ikke lige finde det, min pc er et værre rod,
jeg havde det liggende i test, men da jeg altid
har fået at vide at eval var "uha" så er det muligt
at det er røget ud ... men tester ( lang tid siden
jeg har rodet med js efterhånden ... )

mclements forkert!

problemet har hele tiden været at det også er omsubmit i Firefox :-)

function events() {
    var login = document.getElementById('login');
    addEvent(login,'onsubmit',function(){
      return validate(login);
    });
}

virker

og addevent skal så rettes til

function addevent(elm,event,func) {
    if(browser() == "IE") {
        elm.attachEvent(event,func);
    } else {
        elm.addEventListener(event,func,false);
    }
}

eller addEvent, jeg kan bedst lide camelCase :p tror godt du kan rette mine tastefejl selv.

så kommer ikke engang valideringen igang windcape?

ok, jeg skal vist styre min begrejstning, og starte det rigtige testmiljø op :)

kan godt se at det ikke var rigtig :p

ja det bliver nok nødvendigt ;)

men jeg er nødt til at hoppe i gryden nu - er jo også en tidlig morgen imorgen! nat nat

løst :-)

function events() {
    var login = document.getElementById('login');
    addEvent(login,'submit',function(e){
      var valid = validate(login);;
      if(!valid) {
          if(e && e.preventDefault)
              e.preventDefault(); // DOM style
      } 
      return valid; // IE style
    });
}

og addEvent skal se sådan her ud:

function addEvent(elm,event,func) {
    if(browser() == "IE") {
        elm.attachEvent("on" + event,func);
    } else {
        elm.addEventListener(event,func,false);
    }
}

Super fedt Windcape :)

...

function validate(f) {

document.login.action = '?login';
rettes til:
document.getElementById('login').setAttribute('action','?login');

...

function setfocus() {
    if (document.getElementById('login').brugernavn.value == '') ...
rettes til: if (document.getElementById('login').brugernavn.getAttribute('value') == '') ...

...

Og en lille bi-ting - bør addonloadevent(func){}
ikke baseres på attachEvent og addEventListener
istedet for window.onload som benyttes p.t. ...

mange tak for jeres indlæg, kigger det lige igennem :)

det ser lidt mere indviklet ud end jeg havde håbet, men åbenbart eneste måde at gøre det på.

og jo mclemens, resten burde nok os xhtml optimeres c",)

ehmn, jeg kan stadig ikke få det til at virke - i IE bliver valideringen kørt to gange hvorefter den afbryder afsendelsen. i ff bliver valideringen kørt én gang men den afbryder ikke afsendelsen.

siden kan som før ses her: sums.dk/admin

Status pt.:

Det virker som det skal i IE, men i FF bliver valideringen ikke gennemført korrekt. Den er begyndt at overholde return false, men den kommer ikke videre fra valideringen af brugernavnet, selvom man indtaster noget...

Kode er som følger:
-------------------------------------------------------------

function browser() {
    var browser    = navigator.userAgent;
   
    if (browser.indexOf('Gecko')>-1) return "FF"; //Mozilla og Netscape
    else if (browser.indexOf('Opera')>-1) return "Opera"; //Opera
    else if (browser.indexOf('MSIE')>-1) return "IE"; //Internet Explorer
    else return false;
}

function addEvent(elm,event,func) {
    if (browser() == "IE") {
        elm.attachEvent('on' + event,func);
    }
    else elm.addEventListener(event,func,false);
}

function addonloadevent(func) {
    var oldonload = window.onload;
   
    if (typeof window.onload != 'function') {
        window.onload = func;
    }
    else {
        window.onload = function() {
            if (oldonload) {
                oldonload();
            }
           
            func();
        }
    }
}

function validate() {
    if (document.getElementById('brugernavn').getAttribute('value') == '') {
        alert('Du skal indtaste dit brugernavn');
        document.getElementById('brugernavn').focus();
        return false
    }
    else if (document.getElementById('password').getAttribute('value') == '') {
        alert('Du skal indtaste dit password');
        document.getElementById('password').focus();
        return false
    }
   
    document.getElementById('login').setAttribute('action','?login');
   
    return true
}

function events() {
    addEvent(document.getElementById('login'),'submit',function(e){
        var func = validate();
       
        if (!func && e && e.preventDefault) e.preventDefault(); // DOM style
       
        return func; // IE style
    });
}

addonloadevent(events);

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

hvordan vil du omskrive addonloadevent så den overholder xhtml mclemens?

function validate() {
    if (document.getElementById('brugernavn').value == '') {
        alert('Du skal indtaste dit brugernavn');
        document.getElementById('brugernavn').focus();
        return false
    }
    else if (document.getElementById('password').value == '') {
        alert('Du skal indtaste dit password');
        document.getElementById('password').focus();
        return false
    }
   
    document.getElementById('login').setAttribute('action','?login');
   
    return true
}


... der er fejl i FF's getAttribute("value")
- så det er en af ulemperne ved xhtml, jeg håber
at de snart får det rettet. Jeg har stødt på den
flere gange selv. getAttribute("value") returnerer
"" hvad der svarer til defaultValue hele tiden :-(

"hvordan vil du omskrive addonloadevent så den overholder xhtml mclemens?"
Det kan jeg ikke hitte ud af ... Jeg synes ikke at jeg kunne få tilføjet flere funktioner i enden af hinanden ved brug af xhtml standard ...

- Lad os se hvad Windcape siger :)

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html><head><meta http-equiv="content-type" content="text/html; charset=iso-8859-1"><title>Ingen titel</title><meta name="robots" content="index, follow">

<script type="text/javascript">

function browser() {
    var browser    = navigator.userAgent;
 
    if (browser.indexOf('Gecko')>-1) return "FF"; //Mozilla og Netscape
    else if (browser.indexOf('Opera')>-1) return "Opera"; //Opera
    else if (browser.indexOf('MSIE')>-1) return "IE"; //Internet Explorer
    else return false;
}

function addEvent(elm,event,func) {
    if (browser() == "IE") {
        elm.attachEvent('on' + event,func);
    }
    else elm.addEventListener(event,func,false);
}


addEvent(window,"load",function(){alert(";)");});
addEvent(window,"load",function(){alert("næsten - dog spejlvendt fra den ene browser til den anden");});
addEvent(window,"load",function(){alert("virker");});
addEvent(window,"load",function(){alert("Det");});

</script>

</head><body>

</body></html>

Problemstillingen med .getAttribute('value') vs.
.value vs. .defaultValue ses i dette eksempel:


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html><head><meta http-equiv="content-type" content="text/html; charset=iso-8859-1"><title>Ingen titel</title><meta name="robots" content="index, follow">

<script type="text/javascript">

function browser() {
    var browser    = navigator.userAgent;
    if (browser.indexOf('Gecko')>-1) return "FF"; //Mozilla og Netscape
    else if (browser.indexOf('Opera')>-1) return "Opera"; //Opera
    else if (browser.indexOf('MSIE')>-1) return "IE"; //Internet Explorer
    else return false;
}

function addEvent(elm,event,func) {
    if (browser() == "IE") {
        elm.attachEvent('on' + event,func);
    }
    else elm.addEventListener(event,func,false);
}

addEvent(window,"load",function(){addEvent(document.getElementById("test"),"keyup",function(){alert(".getAttribute('value') returnerer:\n"+document.getElementById("test").getAttribute('value')+"\n\n.value returnerer:\n"+document.getElementById("test").value+"\n\n.defaultValue returnerer:\n"+document.getElementById("test").defaultValue);});});

</script>

</head><body>
<input type="text" id="test" value="a">
</body></html>

Der er overhovedet ikke fejl i Firefox getAttribute('value'), getAttribute vil retunere den værdi du har skrevet i din HTML, hvis værdien er ændret senere af en bruger skal du bruge inputField.value :-) Samme gælder forresten for at lave persistant data i XUL.

D.v.s. at der er fejl i IE istedet så :)
- Vil det sige at .value helt ok i xhtml ?

Man kan ikke rigtig sige at der er fejl i IE i dette tilfælde :-) Jeg hælder også til at det ville være ligeså korrekt at gøre som IE gør, men jeg tror Firefox har valgt at lade getAttribute hente værdien fra det orginale DOM pga. opbygningen i XUL (Firefox er jo baseret på et XML+javascript API, som tilsammen danner XUL).

Men Forms er et specielt interface defineret i DOM level 2.
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357

Her kan i også læse definitionerne for de forskellige FORM elements og se at hvilke der har en value attribute.

Se også
http://developer.mozilla.org/en/docs/DOM:form#HTML_Form_Element_Interface

Jeg har lige surfet lidt rundt nu og fandt så:
http://www.eksperten.dk/spm/751439#rid6561509
olebole "Her er problemet blot, at FF ikke
understøtter getAttribute-metoden på
et elements value, korrekt."

Og for de dovne, så gælder DOM level 2 specifikationen også for XHTML 1.0 :-)

Windcape , 13:14:30
Update, ah ok - så er det
nok manglende standarder :-(

Jeg vil tillade mig at være lidt uenig med OleBole , da http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-666EE0F9 (getAttribute defintionen) ikke definere at det SKAL være værdien som brugeren har indskrevet.

Firefox's interface som henter den statiske værdi med getAttribute overholder da fint DOM level 2 :-)

http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-637646024

"The attribute's effective value is determined as follows: if this attribute has been explicitly assigned any value, that value is the attribute's effective value; otherwise, if there is a declaration for this attribute, and that declaration includes a default value, then that default value is the attribute's effective value; otherwise, the attribute does not exist on this element in the structure model until it has been explicitly added. Note that the nodeValue attribute on the Attr instance can also be used to retrieve the string version of the attribute's value(s)."

Hvis jeg forstå dette korrekt, så er gør IE det faktisk forkert :-) Selvom det er den mest logiske vej.

http://dragons-lair.org/projects/xhtml.php XHTML test af .value

Firefox = Virker fint :-)
IE = Forsøger at downloade dokumentet, så meget for IEs support af xhtml, HAH

Hmm, det bunder jo ud i at
den skal hente attributtens værdi
"Retrieves an attribute value by name."

Det er så en vurdering, om hvorvidt værdien er
den oprindelige eller den, som brugeren har givet
den. Jeg vil her være enig med Ole på punktet om
at attributtens værdi ikke længere er default værdien,
men istedet den nye værdi, som brugeren skriver ind.

- Det er altsammen en vurdering da det
selvfølgelig kan læses på to måder afhængig
af hvad man vurderer som værende en attributs værdi.

En ting er dog sikkert manglende standarder er
dræbende, og at value opfører sig som den gør i FF
er ikke sjovt, da det gør det en smule mere besværligt.
( Selvfølgelig blot min holdning til det )

At firefox snupper .value i et xhtml dokument
gør ikke at .value er optimalt under xhtml.

- Hvis du læser frem og tilbage i de tråde
hvor Olebole har snakket om xhtml ser du omtalt
at Firefox accepterer htmldom bindinger af hensyn
til sloppy coders. Og det er på dette punkt at det
er vigtigt at man har det hele oppe i xhtml niveau
da det ikke er meningen at browsere bør tage hensyn
til sloppy coders, specielt dumt er IE's sikkerhedsnet:
http://www.eksperten.dk/spm/734465#rid6443411

At IE ikke understøtter xhtml er ikke en overraskelse.

huha hvor i lyder kloge :) at man fattede lidt mere af hvordan browseren håndtere hvad man propper i den !

jeg kunne godt tænke mig at vide lidt mere omkring hvordan nedenstående virker mere konkret. forstår ikke det e og preventdefault:

function events() {
    addEvent(document.getElementById('login'),'submit',function(e){
        var func = validate();
       
        if (!func && e && e.preventDefault) e.preventDefault();
       
        return func;
    });
}

ellers ser det ud til at både ie og ff håndtere min login rigtigt nu

Der står lidt herinde: http://developer.mozilla.org/en/docs/DOM:event.preventDefault
- Jeg har ikke læst så meget om det, men accepter lige Windcape's
svar, det var rart at komme til at kende den preventDefault :)

mclemens: Hvis OleBole tror det er pga. Sloppy coders, er det måske fordi har ikke har arbejdet med XUL (hvilket jeg har, og jeg havde præcis samme problem i XUL, derfor jeg kendte løsningen).

Men ECMAscript standarden er ret gammel, og Firefox har allerede Javascript 1.7
hvilket betyder at Mozilla er en del foran de andre browsere.
Jeg tror ikke rigtig man kan sætte en rettesnor for Javascript, så i tilfælde som dette vil jeg nok bare kode efter hvad der virker, og være lidt ligeglad med hvad der er etisk korrekt :-)

Mozilla/Netscape har trosalt været en af de helt store standardsættere inden for Javascript. (JScript var Microsofts pendant).

preventDefault virker ikke iIE, det er derfor man til sidst returnerer funktionens værdi?

ja :-) glemte jeg vist at skrive.

hvordan mente du, windcape, at addonloadevent skulle omskrives hvis det skulle bruge attachevent mv.?

function addonloadevent(func) {
    var oldonload = window.onload;
   
    if (typeof window.onload != 'function') {
        window.onload = func;
    }
    else {
        window.onload = function() {
            if (oldonload) {
                oldonload();
            }
           
            func();
        }
    }
}

og faktisk virker preventDefault i IE, bare ikke til denne her ting :-)

Jeg bruger den for at tillade ctrl+b/ctrl+i/ctrl+u i http://dragons-lair.org/projects/rte/ , http://dragons-lair.org/projects/rte/RTE.js

Næh, jeg er ikke sikker på hvad Olebole tror på det punkt. Han har bare sagt at det ikke er godt at den accepterer htmldom. Jeg siger at det må være p.gr.a. Sloppy coders - nu har jeg selv været en Sloppy coder for 1½ år siden (ren html baseret med attribut design samt topmargin, center m.v.) og laver til tider selv noget Sloppy noget, når det lige skal gå hurtigt for at klaske et eksempel op til demo. I ordet Sloppy lægger jeg at man laver noget for at det skal virke efter hensigten uden at gå helt op i standarder, etik eller effektivitet.

- Blot for at skrive at Olebole ikke
har brugt udtrykket Sloppy coders.

Artikeler fra Olebole:
http://www.eksperten.dk/artikler/537
http://www.eksperten.dk/artikler/538

... Godt nytår til jer begge
og tak for preventDefault :)

<ole>

windcape >> Det er korrekt, at der ikke står noget sted, det skal være den aktuelle værdi, man henter med getAttribute - men i så fald eksisterer der ikke en metode til at hente den aktuelle værdi under X(HT)ML i FF (eller for den sags skyld i W3C's ECMA-DOM bindinger) ... og det kan jo ikke være meningen  =)

I eksemplet (29/12-2006 13:29:14) tvinger du browseren til at bruge HTML-parseren til at behandle dokumentet ... så meget for FF's XHTML-understøttelse!  ;o)
Hvad IE angår, så er det ikke nogen hemmelighed, at MS - i modsætning til Mozilla - har valgt at vente med at understøtte XHTML, til de har et helt nyskrevet, toptunet markup-lag færdigt. Det har der været megen snak om på MS' udviklings-blog i forbindelse med udviklingen af version 7.0.

Den løsning, du tror, du har fundet p.gr.a. dit arbejde med XUL, er som sagt en ikke-løsning, der fjerner de væsentligste grunde til at bruge XHTML - nemlig at koden behandles som XML.
Jeg har også arbejdet en masse med XUL, men ved alligevel stadig, hvordan X(HT)ML skal behandles  =)
Derudover er der ikke så meget tale om JavaScript, men om de af W3C standardiserede ECMA-DOM bindinger.

FF er lysår bagud i forhold til dens forgængere Netscape og de første Mozilla'er. Hele dens DOM-lag er f.eks. komplet fucked og _intet_ valideres, når du bruger DOM-handlinger. Det var ikke tilfældet i de tidligere Gecko-baserede browsere - men det er lykkedes FF's udviklerhold at ødelægge mere end de har gjort godt!  :o|

De tilgængelige browsere er desværre nogenlunde lige elendige - omend deres elendigheder ligger på lidt forskellige områder. Mellem to dybe grøfter ligger ofte en farbar vej  ;o)

elskermad.dk >> preventDefault-metoden bruger du i f.eks. FF, ligesom du bruger event.returnValue=false i IE ... altså til at modvirke at browserens default-handling udføres, når en event fyres af

/mvh
</bole>

... Og godt nytår til Olebole også :)

Olebole http://dragons-lair.org/projects/xhtml.php benytter altså Firefox XML parser :-) var sågar nød til at sætte xmlns på for at det ikke fremstod som XML document.

Hvis den bruge HTML ville Firefox's Generated Source (webdev toolbar) vise en html4 version, dvs. /> konverteret til > etc. Så den bruger skam dens XML parser.

Men godt at vi er enige om at getAttribute ikke nødvendigvis skal hente brugerens data, selvom det er mest logisk , hehe.

Og rart at høre at du kender til XUL, det giver et rigtig godt indblik i hvordan spidermonkey fungerer.

Jamen, det er blot fordi, FF heller ikke på dette punkt opfører sig i overensstemmelse med standarderne - og fordi FF's XHTML-understøttelse i høj grad er en pseudo-understøttelse, der bygger på et XML-lag, som mere eller mindre grad er en dårlig klon af HTML-laget.
En XML-parser _må_ ikke håndtere den viste syntaks ... simple as that!  ;o)

FF kan såmænd også bruge innerHTML under XHTML - og det på trods af, at den property aldrig har været valid i nogen standard og heller aldrig bliver det. Hvad i alverden innerHTML har at gøre med XML (som XHTML jo er et subset af) er en lodret gåde!
Det er ovenikøbet med fuldt, overvejet overlæg, man har implementeret denne property (det skete for et årstid siden). Hvis ikke det er at forsøge at please sloppy kodere, ved jeg virkelig ikke, hvad man vil angive som undskyldning!

Når vi nu (med overgangen til 'nye' standarder) har chancen for at få stringente browsere, der faktisk tager standarderne højtideligt, er det jo pokkers ærgeligt, det kun er MS, som agter at deltage i dén del af festen.
Det ville have været klædeligt, om Mozilla levede op til sine forgængeres høje standarder ... men ak!  :o|

hehe ok :-) Dog synes jeg ikke MS har taget sig ordenlig sammen i IE7. Det er vel næsten kun Safari som har seriøse udviklere ? (Den bestod ACID2 for et stykke tid siden)

Men kan du lige bekræfte eller afkræfte ideen med at .value er en lovlig attribute for de elementer den er defineret for under XHTML også ? (Det er den jo så vidt jeg kan læse på DOM level 2 specifikationerne, men det er så nemt at misforstå noget).

Jeg forstod ikke dit sidste spørgsmål

"Det er vel næsten kun Safari som har seriøse udviklere ?"
Safari er vel heller ikke toppen ... http://www.eksperten.dk/spm/752814

olebole

Vi diskutterede omkring HTMLInputElement.value var en legal property under XHTML, eller om det kun er HTMLInputElement.getAttribute('value') der er korrekt.

Det er ikke en valid script-DOM binding under XML - og dét er det interessante  ;o)

Samt om eventhandlers bør sættes i dokumentet som her
<form action="" method="post" onsubmit="alert(this.foobar.value); return false;">
- Istedet for at tilføjes via. attachEvent / addEventListener ...

...

Har forstået den del om Safari nu ...

Faldt tilfældigt over denne tråd igen ... og er blevet lidt klogere i mellemtiden  :)

Problemet er ikke FF, men XHTML/W3C! getAttribute("value") _skal_ hente attributten, som den står skrevet i koden. Da man ikke må bruge ELEMENT.value, eksisterer der ikke idag en brugbar/valid måde at hente dynamiske værdier ud af element-objekter.

- vi venter med spænding på XForms  =)