[ie7] GetElementById kijkt naar name ipv id attribute

[flowerp]

Het viel me op dat voor elementen binnen forms, Internet Explorer 7 naar de name attribute kijkt i.p.v. het id attribute bij gebruik van de javascript functie getElementById. Als je bijvoorbeeld ergens een element hebt met name="foo", ergens anders eentje met id="foo", dat geeft getElementById( 'foo' ) dat eerste (verkeerde) element terug.

Aangezien de HTML van IE7 de defacto web standaard is, moet ik dus nu overal mijn javascript aan passen. Gaat de hele rest van de web wereld nu ook alles aanpassen, of wacht iedereen tot MS met een patch komt?

[ Voor 5% gewijzigd door flowerp op 13-02-2007 20:59 ]

[crisp]

flowerp schreef op dinsdag 13 februari 2007 @ 20:57:
Het viel me op dat voor elementen binnen forms, Internet Explorer 7 naar de name attribute kijkt i.p.v. het id attribute bij gebruik van de javascript functie getElementById. Als je bijvoorbeeld ergens een element hebt met name="foo", ergens anders eentje met id="foo", dat geeft getElementById( 'foo' ) dat eerste (verkeerde) element terug.

Dat klopt, is al heel lang bekend en is inderdaad foutief behavior.

Aangezien de HTML van IE7 de defacto web standaard is

Sinds wanneer? IE wordt juist steeds minder relevant in de browser-wereld. En je praat hier over het Document Object Model, niet over HTML.

moet ik dus nu overal mijn javascript aan passen.

Ja, je zal moeten voorkomen dat je dezelfde naam gebruikt voor een name-attribuut als je die elders al voor een id-attribuut hebt gebruikt.

Gaat de hele rest van de web wereld nu ook alles aanpassen

Op dit moment heb je erg weinig keus...

of wacht iedereen tot MS met een patch komt?

MS heeft zich vastgelegd op het (correct) ondersteunen van standaarden in toekomstige versies van IE. IE7 bracht nog niet echt veel verbetering wat dat betreft maar hopelijk kunnen we daar in IE8 wel resultaat van gaan zien...

[flowerp]

crisp schreef op dinsdag 13 februari 2007 @ 21:38:
[...]
Dat klopt, is al heel lang bekend en is inderdaad foutief behavior.

Dit is toch wel een vrij grote bug. Je vraagt je af hoe zoiets door alle QA heen kan komen

Sinds wanneer? IE wordt juist steeds minder relevant in de browser-wereld.

Dat is opzich wel zo, maar de overgrote meerderheid blijft (helaas) toch IE gebruiken. Bij ons op het werk is de goude regel dan ook dat als iets niet op IE werkt, alles op alles gezet moet worden om het te fixen. Gewoon omdat meer dan 60% van de gebruikers IE heeft. Natuurlijk, als iets met firefox niet werkt mag het ook de deur niet uit, maar simpel zeggen "Oh, het is een bug in IE zelf, dat fixen wij niet" zit er dus niet in

Ja, je zal moeten voorkomen dat je dezelfde naam gebruikt voor een name-attribuut als je die elders al voor een id-attribuut hebt gebruikt.

Er zit niets anders op begrijp ik. Zouden al die miljoenen websites wereldwijd dit nou momenteel ook allemaal doen?

[BtM909]

Het is natuurlijk ook niet echt common om zowel name als id door elkaar te gebruiken hoor

[--MeAngry--]

Sterker nog, als iets bij mij een name attribuut heeft geef ik het vaak uit voorzorg al hetzelfde ID mee. (Zeker als het mogelijk ergens nog door JavaScript gebruikt gaat worden.)

[flowerp]

BtM909 schreef op dinsdag 13 februari 2007 @ 22:27:
Het is natuurlijk ook niet echt common om zowel name als id door elkaar te gebruiken hoor

Is dat zo?

Stel je hebt ergens op je page een form staan, hier staan gewoon input elementen in die een name attribute hebben. Ergens anders op je page staat een 2de form waar alle of enkele elementen een id hebben, bijvoorbeeld omdat hun waarde gezet wordt aan de hand van een script.

Dat is toch niet zo'n rare situatie?

Als je er normaal op let dat alle ids altijd pagewide uniek zijn, maar op names geen acht slaat omdat die al gescoped zijn door hun eigen form, dan sta je toch raar te kijken als IE7 opeens de waarde van een element in een geheel ander form gaat veranderen, terwijl je toch in het bedoelde form ids hebt gebruikt die uniek zijn voor de hele pagina.

[BtM909]

Dat klopt, maar dan praat je over twee forms en dus meerdere elementen op één pagina.

Want jij doelt erop dat je tweede form dan ineens alleen id's bevat die ook nog eens waren gebruikt in je eerste form

Enige wat ik me kan bedenken waar ik problemen mee had, was de submit button

[crisp]

Mwa, form-elementen spreek ik meestal toch aan via de form-elements collection. De enige reden om form-elementen een ID te geven is voor labels.

[flowerp]

crisp schreef op woensdag 14 februari 2007 @ 01:10:
Mwa, form-elementen spreek ik meestal toch aan via de form-elements collection. De enige reden om form-elementen een ID te geven is voor labels.

Er zijn nog andere redenen denk ik. De belangrijkste is wel de situatie waarin je helemaal niet weet welke name je form heeft. Dit is een vrij veel voorkomende situatie, en dan heb je dus wel echt een ID nodig voor je form elementen.

[disjfa]

flowerp schreef op woensdag 14 februari 2007 @ 22:47:
[...]
De belangrijkste is wel de situatie waarin je helemaal niet weet welke name je form heeft.

En dit heb je zelf niet in de hand? Ik neem aan dat als je een formulier maakt je er zelf ook een naam aan meegeeft.

[Verwijderd]

flowerp schreef op woensdag 14 februari 2007 @ 22:47:

Er zijn nog andere redenen denk ik. De belangrijkste is wel de situatie waarin je helemaal niet weet welke name je form heeft. Dit is een vrij veel voorkomende situatie, en dan heb je dus wel echt een ID nodig voor je form elementen.

Wat een onzin? Daar hebben we nou this en this.form voor.

[SWINX]

en document.forms[0] bied anders ook nog wel uitkomst

[flowerp]

disjfa schreef op woensdag 14 februari 2007 @ 22:49:
[...]
En dit heb je zelf niet in de hand?

Nee natuurlijk heb je dat niet altijd zelf in de hand

In JSF wordt er bijvoorbeeld voor een HTML weergave een form voor jou gegenereerd. De exacte naam daarvan staat onder controlle van JSF. Als je dan in je eigen componenten een speciaal effect via client-side code wilt bereiken (javascript dus), dan geef je de elementen die je zelf genereerd een uniek ID. De runtime opgeving kan helpen met het genereren van deze ID, maar het belangrijkse is dat jij dan in code die ID hebt. Met deze ID in de hand kun je javascript genereren die hiervan gebruik maakt.

In enkele gevallen heb je ook een referentie naar het form nodig waarbinnen de elementen die je gerendert hebt vallen. Deze kun je dan bereiken met getElementById( id_in_kwestie ).form.

Volgens mij kun je noch in RI noch in MyFaces een specifieke name voor een gegeven form afdwingen, waardoor je dus bijna altijd die IDs nodig hebt voor je elementen.

en document.forms[0] bied anders ook nog wel uitkomst

Dat is wel de meest fragiele oplossing die er is. Dat kun je alleen doen als jij een super specificiek component bouwt dat 1:1 aan 1 specificieke page gebonden is die 100% onder jouw controlle staat. In de praktijk werkt dat echt niet zo. Page designers kunnen altijd jouw component op een page plaatsen waar al andere forms in staan.

[ Voor 16% gewijzigd door flowerp op 14-02-2007 23:10 ]

[crisp]

flowerp: dat is dan gewoon een beperking van je ontwikkel-omgeving. Markup-generators zijn gewoon over het algemeen 'poor' en abstracties brengen vaak beperkingen en andere nadelen met zich mee.

In dit geval een behoorlijk performance nadeel aangezien document.getElementById behoorlijk wat meer nodes moet testen dan document.forms['myFormID'].elements['myFormElementName'] (hoewel dat browser-implementatie afhankelijk is - vaak worden ID's gewoon in een hashmap gestopt waarin geprikt kan worden - desalniettemin is het wel meer intensief om al je form-controls apart een uniek ID te geven dan enkel je form-elementen zelf).

(overigens is het name-attribute voor een <form> deprecated en in sommige doctypes zelfs niet meer toegestaan - gebruik gewoon ID, of kan je die ook niet setten in JSF?)

[ Voor 20% gewijzigd door crisp op 15-02-2007 01:47 ]

[flowerp]

crisp schreef op donderdag 15 februari 2007 @ 01:42:
flowerp: dat is dan gewoon een beperking van je ontwikkel-omgeving. Markup-generators zijn gewoon over het algemeen 'poor' en abstracties brengen vaak beperkingen en andere nadelen met zich mee.

Tis eigenlijk een andere discussie (en volgens mij hebben we die wel eens gedeeltelijk in een ander topic gevoerd), maar met een 'poor' abstraction bedoel je net zoiets als dat compilers een poor abstraction zijn van de onderliggende assembly die ze genereren?

Als je de allerhoogste kwaliteit assembly wil met top performance en je hebt de benodigde man-uren er voor over, dan heb je een punt. Er hangt inderdaad een prijs aan abstractie. In de meeste andere situaties is productivity echter belangrijker.

In dit geval een behoorlijk performance nadeel aangezien document.getElementById behoorlijk wat meer nodes moet testen dan document.forms['myFormID'].elements['myFormElementName']

Ik denk dat je serieus echt hele gekke dingen moet gaan doen voordat een dergelijke micro (nano?) optimalisatie een meetbaar performance verschil geeft. Begrijp me niet verkeerd, ik snap je denkwijze. Ik ben zelf opgegroeid in de C64 tijd waarbij we in assembly de cycles moesten tellen voor elke instructie en dan binnen een bepaald cycle budget moesten blijven.

Tijden veranderen echter.

Vroeger moest je 10 keer nadenken of een functie call echt nodig was t.o.v. de code direct in een langere functie hebben staan. Functie call overhead was op een 0.8mhz machine echt meetbaar. Tegenwoordig is het zo'n enorme non-issue, dat je er absoluut geen tijd en aandacht meer aan besteed.

(overigens is het name-attribute voor een <form> deprecated en in sommige doctypes zelfs niet meer toegestaan - gebruik gewoon ID, of kan je die ook niet setten in JSF?)

Een form ID wordt gegenereerd in JSF.
Ik kan deze ID overigens toch wel verkrijgen in code (in tegenstelling tot mijn eerdere post), door serverside de component tree omhoog te lopen en dan de ID op te vragen van het eerste form dat ik tegenkom. Dit werkt eigenlijk net zoals DOM, maar dan voor de serverside components. Dat is b.t.w. ook een verschil tussen een simpele 'markup generator' en echte web components. De eerste genereerd alleen text die naar de response gestuurd wordt, terwijl voor de tweede echt een component tree opgebouwd wordt.

Het probleem was hier dat een element binnen het form (<input>) een ID had. Er was een ander <input> element binnen een andere form die als name hetzelfde had als het andere element als ID had. getElementById in IE7 kijkt eerst naar de name van alle elemenen op de hele pagina, en dan pas in een 2de pass naar de ID.

Pseudo code voorbeeld:

HTML:

<form id="some_id">
   <input name="bar" />
</form>

<form id="_idJsp0" name="_idJsp0">
  <input name="foo" id="bar" />
</form>

Als je nu in javascript iets doet als:

JavaScript:

document.getElementById( 'bar' );

Welk element zou je dan verwachten? De eerste uit het voorbeeld of de tweede? Vanwege de IE7 bug krijg je dus de eerste. Bij alle andere browsers, inclusief IE6, de tweede. Gelukkig kijkt IE7 nadat ie de geen element met een dergelijke name kan vinden ook nog naar de ID. Hierdoor kun je dus de workaround toepassen die jij voorstelde.

[chris]

De makkelijkste oplossing is gewoon zorgen dat je unieke id's genereert. Met JSF moet dat volgens mij geen probleem zijn. Volgens mij kan je een custom clientId genereren. Verder is het volgens mij ook geen probleem om een wrapper om getElementById te schrijven die verder zoekt als het element geen id-attribuut heeft maar wel een name-attribuut.

[crisp]

flowerp schreef op zondag 18 februari 2007 @ 12:24:
[...]
Ik denk dat je serieus echt hele gekke dingen moet gaan doen voordat een dergelijke micro (nano?) optimalisatie een meetbaar performance verschil geeft.

DOM-lookups zijn ontzettend duur. Eea is natuurlijk wel afhankelijk van de implementatie - de meeste browsers gebruiken tegenwoordig wel een vorm van hashmap voor ID-lookups - maar helaas zijn er ook nog browsers die niet zo met hun tijd meegaan... Dit soort optimalisaties zijn dan echt geen micro- of nano-optimalisaties...

Funny overigens om te zien dat JSF blijkbaar invalid ID-tokens genereerd:

HTML:

<form id="_idJsp0" name="_idJsp0">

http://www.w3.org/TR/html4/types.html#type-id

(het name-attribute voor een form-element is overigens type CDATA en geen type NAME - daar is de leading underscore dus wel valid).


Overigens wat betreft abstractions: je vergelijking mbt compilers gaat een beetje mank omdat je dan over een behoorlijk homogene omgeving praat (of in ieder geval over een omgeving waar de betreffende standaarden toch bijna volledig uniform gevolgd worden en geimplementeerd zijn) - dat gaat helaas nog niet echt op voor browser-omgevingen.
Ook is clientside performance nog steeds een real-life issue. Je wilt niet weten hoeveel truuken ik wel niet heb moeten uithalen om een paar jaar terug een JS-implementatie van Lemmings redelijk performant te krijgen...

[ Voor 49% gewijzigd door crisp op 18-02-2007 23:13 ]

[flowerp]

crisp schreef op zondag 18 februari 2007 @ 22:58:
[...]
Funny overigens om te zien dat JSF blijkbaar invalid ID-tokens genereerd:

Inderdaad. Hoewel "jsf" zelf natuurlijk eigenlijk helemaal niks genereerd (dat is alleen een specificatie in een document). In dit geval is de html render kit van de MyFaces 1.1 implementatie de schuldige

Overigens wat betreft abstractions: je vergelijking mbt compilers gaat een beetje mank omdat je dan over een behoorlijk homogene omgeving praat (of in ieder geval over een omgeving waar de betreffende standaarden toch bijna volledig uniform gevolgd worden en geimplementeerd zijn)

ja en nee.

Nee, omdat bijvoorbeeld een C++ compiler nog meer targets heeft dan een JSF renderkit, en het dan ook nog eens om hele verschillende targets gaat. Daarbij heeft 1 target ook gewoon verschillende implementaties. Bijvoorbeeld MIPS wordt door meerdere vendors geimplementeerd en x86 natuurlijk ook. Daar gaan dan zeker ook wel eens wat dingen fout, zeker in het verleden. Een CPU die de opgestelde standaard niet 100% implementeerde of bepaalde punten waarbij b.v. de ABI gewoon op meerdere manieren te interpreteren is. En compiler kunnen ook gewoon foute code genereren. Zo zat er lange tijd een bug in GCC 3.x die invalid code genereerde voor de AMD64 target.

Ja, omdat er op dit moment nog zeer weinig renderkits zijn die specificiek voor een bepaalde variant van een target renderen. Zo kun je een JSF layout wel naar totaal verschillende targets renderen (bv telnet, XUL, of HTML), maar heeft de renderkit geen expliciete varianten zodat je apart code kunt genereren voor Firefox, IE6, IE7, etc.

Het concept van de vergelijking is wel valide denk ik. In C++ programmeer je in een high-level taal die abstraheerd van de hardware zelf. De compiler transformeert de ene taal (C++) naar de andere taal (assembly of machine code). Assembly is zelf ook weer een abstractie, namelijk van microcode of logische datapath operations binnen in de CPU.

Met web componenten doe je hetzelfde. Je 'programmeert' je pagina in een high-level taal die abstraheerd van de browser zelf. De renderkit transformeert de ene taal (JSF taglibs en EL) naar de andere taal (HTML en javascript). Javascript is zelf ook weer een abstractie, namelijk van de native widgets in het host OS en natuurlijk (via de browser) van de machine zelf.

Ook is clientside performance nog steeds een real-life issue. Je wilt niet weten hoeveel truuken ik wel niet heb moeten uithalen om een paar jaar terug een JS-implementatie van Lemmings redelijk performant te krijgen...

Dat geloof ik natuurlijk meteen, maar Lemmings in JS maken valt toch wel onder de 'gekke' dingen in deze context. JSF abstraheert dan ook niet van JS als een general purpose programmeer taal, maar als page layout taal met complexe widgets. Dat betekent dat javascript operaties zich dus beperken tot typische dingen als: user clicked field, ander field wordt op disabled gezet. Zelfs al zouden dat 10 tallen andere fields zijn dan ga je nog het verschil niet merken tussen een referentie verkrijgen via de forms collectie of direct via een ID.

Daarnaast, en je zegt het zelf al, het aantal browsers is te verschillend om te kunnen spreken van -de- performance. Mischien gebruikt de ene browser een snelle hashmap, terwijl voor de andere je inderdaad de DOM moet aflopen.

[crisp]

flowerp schreef op maandag 19 februari 2007 @ 00:08:
[...]


Inderdaad. Hoewel "jsf" zelf natuurlijk eigenlijk helemaal niks genereerd (dat is alleen een specificatie in een document). In dit geval is de html render kit van de MyFaces 1.1 implementatie de schuldige

Ik ben dan ook geen java-goeroe, dus die kreten zeggen mij verder weinig

[...]

Zo kun je een JSF layout wel naar totaal verschillende targets renderen (bv telnet, XUL, of HTML), maar heeft de renderkit geen expliciete varianten zodat je apart code kunt genereren voor Firefox, IE6, IE7, etc.

Dat laatste moet je ook zeker niet willen; die fout heeft Microsoft al gemaakt in .NET. Serverside browser-sniffing is ten eerste al onbetrouwbaar en ten tweede weinig forwards-compatible. Je clientside libraries zullen die verschillen dus moeten opvangen dmv capability-sniffing.

[...]

Dat geloof ik natuurlijk meteen, maar Lemmings in JS maken valt toch wel onder de 'gekke' dingen in deze context. JSF abstraheert dan ook niet van JS als een general purpose programmeer taal, maar als page layout taal met complexe widgets. Dat betekent dat javascript operaties zich dus beperken tot typische dingen als: user clicked field, ander field wordt op disabled gezet. Zelfs al zouden dat 10 tallen andere fields zijn dan ga je nog het verschil niet merken tussen een referentie verkrijgen via de forms collectie of direct via een ID.

I agree dat DHTML-Lemmings wel een uiterste is, maar met de opmars van Ajax-like web-applications is JS toch wel tot iets meer verworden dan een manier om clientside form-validation te doen

Daarnaast, en je zegt het zelf al, het aantal browsers is te verschillend om te kunnen spreken van -de- performance. Mischien gebruikt de ene browser een snelle hashmap, terwijl voor de andere je inderdaad de DOM moet aflopen.

True, daarom is het ook belangrijk om vooral zelf te blijven testen en niet sec 'recommendations' van browservendor X op te gaan volgen

Met betrekking tot abstractions op client-level niveau moet een oplossing ook transparant zijn en vooraf bekend zijn wat de mogelijkheden maar vooral ook de beperkingen zijn. Een slecht voorbeeld is hier Microsoft's Ajax-framework waarvan de client-component 81KB aan obfuscated javascript is.

[ Voor 6% gewijzigd door crisp op 19-02-2007 00:37 ]

[chris]

crisp schreef op maandag 19 februari 2007 @ 00:29:
Dat laatste moet je ook zeker niet willen; die fout heeft Microsoft al gemaakt in .NET. Serverside browser-sniffing is ten eerste al onbetrouwbaar en ten tweede weinig forwards-compatible. Je clientside libraries zullen die verschillen dus moeten opvangen dmv capability-sniffing.

Mwah, als je alleen voor FF/IE6/IE7 developt kom je een aardig eind met browser sniffing hoor. En dat kan natuurlijk prima op de client (ff terugsturen naar de server). Met capability sniffing kom je natuurlijk nergens als je getElementById gaat testen, daarvoor heb je echt browser sniffing nodig.

Sorry voor het offtopic-geblaat .

[JKVA]

Licht offtopic, maar misschien heeft de TS er iets aan. Tomahawk kent het attribuut forceId="true", waarmee je forceert wat een client side ID wordt.

XML:

<(anyCustomComponent) forceId="true" id="yourIdValue"/>

http://myfaces.apache.org/tomahawk/forceId.html

[flowerp]

JKVA schreef op maandag 19 februari 2007 @ 07:17:
Licht offtopic, maar misschien heeft de TS er iets aan. Tomahawk kent het attribuut forceId="true", waarmee je forceert wat een client side ID wordt.

XML:

<(anyCustomComponent) forceId="true" id="yourIdValue"/>

http://myfaces.apache.org/tomahawk/forceId.html

offtopic:
Die heb ik een tijdje geleden wel eens geprobeerd, maar toen werd mijn ID alleen opgenomen in de gegenereerde ID, dus iets van _idJsp1:comp1:myID werd het dan, waarbij myID is wat ik opgaf.

[flowerp]

crisp schreef op maandag 19 februari 2007 @ 00:29:
[...]
Ik ben dan ook geen java-goeroe, dus die kreten zeggen mij verder weinig

Samengevat; Java EE is alleen een API spec. Elke vendor of open source partij kan daarvan een implementatie maken. Dingen als hoe de HTML eruit moet zijn valt heel expliciet buiten de spec, dat is een implementatie detail.

Dat laatste moet je ook zeker niet willen; die fout heeft Microsoft al gemaakt in .NET.

Nu is MS mischien niet de meeste betrouwbare partij om specificiek HTML voor firefox, opera, safari, etc te laten genereren.

Toch ben ik er niet 100% van overtuigt dat het iets slechts is. Het is eigenlijk juist 1 van de potentiele voordelen van abstractie. Een andere vorm van abstractie in Java vind je in OR mapper die onderdeel is van het platform. Ook hier schrijf je niet low-level SQL, maar defineer je queries in een hogere taal. Java genereerd dan voor jou SQL. Deze SQL is wel zeer zeker specificiek voor het DBMS wat jij gebruikt. Compilers werken natuurlijk ook weer zo. Zelfs binnen een familie kun je sub families targetten en zelfs sub-sub families. Bv x86 -> Pentium -> Pentium II of x86 -> K7, etc.

Serverside browser-sniffing is ten eerste al onbetrouwbaar en ten tweede weinig forwards-compatible.

Das waar, maar je kunt je systeem ook zo instellen dat je alleen specificieke code genereerd voor een exacte match (eventueel een van te voren opgegeven range) en niet voor hogere versies.

I agree dat DHTML-Lemmings wel een uiterste is, maar met de opmars van Ajax-like web-applications is JS toch wel tot iets meer verworden dan een manier om clientside form-validation te doen

Inderdaad ja, maar daar maken serverside componenten ook dankbaar gebruik van hoor Veel nieuwe JSF componenten gebruiken gewoon client-side libraries. Het punt blijft natuurlijk dat JSF relatief nieuw is, zeker als standaard onderdeel van java. Het gebruik en de best practices moeten nog duidelijk groeien. Maar ook hier geldt weer een parallel met C++ compilers. De eerste versies waren echte gedrochten, die vrij brakke code uitbraakten. Voor een hele generatie programmeurs heeft C++ nog steeds de naam van traag en brak. Ondertussen is dit allang niet meer zo en genereren b.v. de laatste versies van gcc of icl.exe hoog geoptimaliseerde code, en dat uit dezelfde source code als 10 jaar geleden.

Dat is tevens nog een voordeel van abstractie. Ik geloof jou absoluut op je woord dat jij nu 10x zo effeciente javascript met de hand kan schrijven als de huidige componenten genereren. Echter, jij zal het wel moeten blijven bijhouden als er nieuwe browsers komen. Elke door jou gemaakte site zal kwa code geupgrade moeten worden bij het uitkomen van nieuwe browser technieken.

Met (java) web componenten kan een gehele web applicatie geupgrade worden kwa markup en script door gewoon java zelf te updaten. Als niet bestaand voorbeeld (maar even voor het idee): Stel dat getElementById nu inderdaad een performance nadeel heeft en dat de snellere access via de form nog niet bestaat. Op een gegevent moment wordt deze veel snellere methode toegevoegd aan de standaard. Er komt dan even later een nieuwe versie uit van de JSF componenten die jij gebruikt, die deze methode toepassen. Op dit moment hoef jij alleen je component lib te updaten, en je hele web app wordt gratis sneller, zonder iets aan de code zelf te veranderen.

Ok, de realiteit is nog niet zo mooi hoor, maar het -concept- belooft veel moois

[crisp]

flowerp schreef op maandag 19 februari 2007 @ 21:25:
[...]

Dat is tevens nog een voordeel van abstractie. Ik geloof jou absoluut op je woord dat jij nu 10x zo effeciente javascript met de hand kan schrijven als de huidige componenten genereren. Echter, jij zal het wel moeten blijven bijhouden als er nieuwe browsers komen. Elke door jou gemaakte site zal kwa code geupgrade moeten worden bij het uitkomen van nieuwe browser technieken.

Niet noodzakelijk aangezien ik in mijn code toch doorgaans ga voor standards-based technieken en uitzonderingen op een forwards-compatible manier implementeer

chris schreef op maandag 19 februari 2007 @ 04:21:
[...]

Met capability sniffing kom je natuurlijk nergens als je getElementById gaat testen, daarvoor heb je echt browser sniffing nodig.

Uiteraard valt dat best wel met capability-sniffing te doen: maak dynamisch een element aan met een name-attribuut. Doe vervolgens een lookup mbv getElementById en kijk of je je named item terugkrijgt

[ Voor 25% gewijzigd door crisp op 19-02-2007 23:38 ]

[flowerp]

crisp schreef op maandag 19 februari 2007 @ 23:36:
[...]

Niet noodzakelijk aangezien ik in mijn code toch doorgaans ga voor standards-based technieken en uitzonderingen op een forwards-compatible manier implementeer

Nu ik het zelf teruglees zie ik dat ik het wat onduidelijk zei, maar wat ik bedoelde is dat jouw code niet automatisch van nieuwe (performance improving) features gebruik zal gaan maken. Ik ga er vanuit dat je correcte code schrijft die het opzich wel zal blijven doen op elke toekomstige browser (tenzij ze opeens dingen gaan deprecaten die nu heel gewoon zijn mischien)

[crisp]

flowerp schreef op dinsdag 20 februari 2007 @ 00:09:
[...]


Nu ik het zelf teruglees zie ik dat ik het wat onduidelijk zei, maar wat ik bedoelde is dat jouw code niet automatisch van nieuwe (performance improving) features gebruik zal gaan maken. Ik ga er vanuit dat je correcte code schrijft die het opzich wel zal blijven doen op elke toekomstige browser (tenzij ze opeens dingen gaan deprecaten die nu heel gewoon zijn mischien)

Dat is zeker waar, maar voordat je op grote schaal dergelijke nieuwe features kan gebruiken (lees: in 's werelds meest gebruikte browser) ben ik allang met pensioen

[soap]

edit:

opgelost, laat maar weer zakken

Excuses voor deze kick maar ik zit met hetzelfde probleem en kan er niets anders over vinden;

Ik gebruik het volgende in mijn forum bij een reply-form:

HTML:

<input type="image" name="submit" value="preview" id="preview">
<input type="image" name="submit" value="submit' id="submit">

etc...

[ Voor 40% gewijzigd door soap op 07-03-2007 15:21 ]

[Verwijderd]

Uit de oude doos: [Alg] Naamgeving

Kort gezegd: gebruik nooit "button" of "submit" als naam of id voor een button.
Verder kun je aan de syntax higlighting al zien dat je quotes niet matchen. Je opent de name attribuut van het tweede element met een dubbele quote, maar sluit hem af met een enkele.

[crisp]

Zie Cheatah. Daarbij is dit niet hetzelfde probleem; met een name-attribuut maak je een element property van een form. Als die name hetzelfde is als een bestaande form-method dan wordt die laatste overschreven, dat is in alle browsers zo.