[js] array met id's

[Verwijderd]

het lukt me maar niet ...
ik wil als je op één checkbox klikt 5 andere laten "checken"
maar niet met de naam van die checkboxen maar met de ID
dit hieronder heb ik maar het werkt niet ...

code:

<script language="javascript">

function allcb() {

for (i = 0; i < cbox.length; i++)
{
cbox[i].checked = true;
}

}

</script>

<form method="post">

<input type="checkbox" name="checkall" onclick="allcb()">
|
<input type="checkbox" id="cbox">
<input type="checkbox" id="cbox">
<input type="checkbox" id="cbox">
<input type="checkbox" id="cbox">
<input type="checkbox" id="cbox">

</form>

iemand een id waarom het niet werkt ?

[[eNeRGy]]

Een id is iets unieks, je kan meerdere objecten niet met 1 id aanroepen zover ik weet.

Wat je kan proberen is om ze de zelfde name te geven en ze dan in een array te zetten d.m.v. document.getElementsByName('cbox');

[Bosmonster]

bovendien roep je ze aan met 'cbox'. Lijkt me handiger om dat op de juist manier te doen via bijvoorbeeld:

onclick="allcb(this.form)"

PHP:

function allcb(frm) {

for (i = 0; i < frm.cbox.length; i++)
{
frm.cbox[i].checked = true;
}

}

En inderdaad name gebruiken ipv id.

[[eNeRGy]]

Bosmonster schreef op 13 augustus 2002 @ 13:26:
bovendien roep je ze aan met 'cbox'. Lijkt me handiger om dat op de juist manier te doen via bijvoorbeeld:

onclick="allcb(this.form)"

PHP:

function allcb(frm) {

for (i = 0; i < frm.cbox.length; i++)
{
frm.cbox[i].checked = true;
}

}

En inderdaad name gebruiken ipv id.

*kuch*

Nette manier? In welke standaard staat deze methode beschreven ?

[Verwijderd]

mhm zoiets dacht ik al ...

ja ik had het eerst met name's maar dat gaat niet omdat ik die nodig heb voor php, waardoor niet elke checkbox meer dezelfde name heeft, het principe is ongeveer hetzelfde als hotmail dat heeft bij de inbox ...

maar zij verwerken berichten die je aangeklikt hebt met de id van het bericht (sturen ze naar cgi) volgens mij, maar hoe ze dat doen verwerken week dus niet

[RM-rf]

PHP:

function allcb(frm) {
  for (i=0;frm.elements[i]; i++)
      frm.elements[i].checked = true;
}

lijkt me ook te werken, enkel checked dat altijd _alle checkboxes in het gehele form frm

[Thijsmans]

als het voor zo'n doeleinde is, kan je ook gewoon een input type=hidden maken, en bij elk checkboxje de id van het bericht erin zetten:

code:

<INPUT type="checkbox" onClick="document.forms[0].elements['naamvhhiddenfield'].value+='|3'">

en dan in php die string splitten op '|' en met een for-loopje alle berichten verwijderen

just a guess

[[eNeRGy]]

je kan ook nog wel andere truukjes gebruiken hoor, document.getElementsByTagName('input'); geeft je een array met alle input elementen (goh ). Als je die door een for() lus haalt en vergelijkt op element.type=='checkbox' ben je al weer een eind verder zonder id's of name's te gebruiken.

[Verwijderd]

thanks ik heb em al

toppie !

[Bosmonster]

[eNeRGy] schreef op 13 augustus 2002 @ 13:28:
[...]

*kuch*

Nette manier? In welke standaard staat deze methode beschreven ?

Zijn voorbeeld al eens geprobeerd onder Mozilla? Ik had het niet over een nette manier, maar een juiste manier.

[[eNeRGy]]

Dat Mozilla het ondersteund betekent niet dat het daardoor minder fout is hoor.

[Verwijderd]

Bosmonster rtfm

[Bosmonster]

[eNeRGy] schreef op 13 augustus 2002 @ 14:23:
Dat Mozilla het ondersteund betekent niet dat het daardoor minder fout is hoor.

? Ik snap helemaal niet meer wat je bedoelt. Het gaat hier om een script en om dat Xbrowser te krijgen moet je geen IE-only methodes gaan hanteren. Vandaar dat er inderdaad een betere methode is om dat te doen, omdat zijn voorbeeld niet werkt onder Mozilla bijvoorbeeld en alle andere browsers behalve IE.

En over het algemeen geldt wel qua standaarden dat Mozilla het meestal bij het rechte eind heeft.

[[eNeRGy]]

Mozilla ondersteund meer dingen die niet in de standaarden zijn opgenomen dan IE tegenwoordig, dus daar kan je niet van uit gaan.

Gelukkig ondersteunen IE en Mozilla wel op veel punten de DOM L2 standaard ver genoeg om dit soort dingen te maken, daarom is een 'document.getElementsByTagName()' beter dan de 'document.forms.etc' constructie.

Mozilla bouwt alle IE dingen na om meer backwards compatibilteit te krijgen, zo is iemand bezig om document.all in te bouwen, etc.

Het meest veilig is het om de standaarden zover mogelijk aan te houden waar dat kan, en in dit geval is dat heel goed mogelijk.

Veel standaarden kan je trouwens hier vinden: http://docs.flox.org

[ Voor 0% gewijzigd door [eNeRGy] op 13-08-2002 14:37 . Reden: typo ]

[crisp]

[eNeRGy] schreef op 13 augustus 2002 @ 14:36:
Mozilla ondersteund meer dingen die niet in de standaarden zijn opgenomen dan IE tegenwoordig, dus daar kan je niet van uit gaan.

Gelukkig ondersteunen IE en Mozilla wel op veel punten de DOM L2 standaard ver genoeg om dit soort dingen te maken, daarom is een 'document.getElementsByTagName()' beter dan de 'document.forms.etc' constructie.

Mozilla bouwt alle IE dingen na om meer backwards compatibilteit te krijgen, zo is iemand bezig om document.all in te bouwen, etc.

Het meest veilig is het om de standaarden zover mogelijk aan te houden waar dat kan, en in dit geval is dat heel goed mogelijk.

Veel standaarden kan je trouwens hier vinden: http://docs.flox.org

Ik denk niet dat je Bosmonster hoeft uit te leggen wat de standaarden zijn hoor
Standaarden zoals de DOM2 zijn ook hardstikke leuk, en als je puur ontwikkeld voor de nieuwste generatie browsers dan ben ik het met je eens dat je het beste deze standaards kan adopteren.
Echter gebruiken veel mensen nog oudere browsers, die niet altijd met de nieuwste standaards overweg kunnen; de document.forms[] manier is dan gewoon nog steeds de beste optie omdat die de breedste ondersteuning geniet.

Wb het inbouwen van document.all in Mozilla; dat lijkt me nogal een sterk verhaal en ook totaal niet wenselijk...

[[eNeRGy]]

Dat sterke verhaal staat wel in bugzilla ergens, en ik kwam het ook al in de nieuwsgroepen tegen. Niet iedereen was er even enthousiast over idd.

Mijn instelling op dit moment is om alles IE en Mozilla compatible te bouwen, dit is niet al te moeilijk. Elke browser die zich verder aan de standaard houdt kan er dan ook mee overweg, degene die zich er niet aan houdt heeft pech gehad. (En IE4 en NS4 zijn sowieso niet meer relevant naar mijn mening).

[ Voor 0% gewijzigd door [eNeRGy] op 13-08-2002 15:16 . Reden: typo (yeah again) ]

[crisp]

[eNeRGy] schreef op 13 augustus 2002 @ 15:15:
Dat sterke verhaal staat wel in bugzilla ergens, en ik kwam het ook al in de nieuwsgroepen tegen. Niet iedereen was er even enthousiast over idd.

Mijn instelling op dit moment is om alles IE en Mozilla compatible te bouwen, dit is niet al te moeilijk. Elke browser die zich verder aan de standaard houdt kan er dan ook mee overweg, degene die zich er niet aan houdt heeft pech gehad. (En IE4 en NS4 zijn sowieso niet meer relevant naar mijn mening).

Niet iedereen heeft de keuze om IE4/NS4 zomaar uit te sluiten; voor de profs onder ons is dat altijd nog de opdrachtgever die dat bepaald.
Ik ben zelf geen prof, en besteed er ook steeds minder aandacht aan, dus wat dat betreft kan ik me wel vinden in je argumenten.

Ik zal eens in bugzilla gaan spitten over dat sterke verhaal. Waar ik problemen mee voorzie is in het feit dat document.all bijna overal wordt gebruikt om onderscheid te kunnen maken tussen IE en Netscape/Mozilla, juist om compatibility issues te voorkomen....

[[eNeRGy]]

Dat document.all gebruikt wordt voor compatibilty checks en dus eventueel problemen gaat geven had ik ook al bedacht, Mozilla.org geeft ook aan dat je zo niet moet testen. Ik geloof dat er in dit document iets over staat: http://www.mozilla.org/docs/web-developer/upgrade_2.html

Ik ben zelf ook een 'prof' en bij ons is op dit moment de eis IE5.5 of IE 6.0. Iets anders bouwen wij niet, nu gaat het bij ons wel om intranet applicaties waar zulke eisen mogelijk zijn. Met een beetje mazzel is de volgende versie helemaal op de DOM gebouwd en ondersteunen we ineens IE5+ en Mozilla.

[crisp]

[eNeRGy] schreef op 13 augustus 2002 @ 16:10:
Dat document.all gebruikt wordt voor compatibilty checks en dus eventueel problemen gaat geven had ik ook al bedacht, Mozilla.org geeft ook aan dat je zo niet moet testen. Ik geloof dat er in dit document iets over staat: http://www.mozilla.org/docs/web-developer/upgrade_2.html

Ik ben zelf ook een 'prof' en bij ons is op dit moment de eis IE5.5 of IE 6.0. Iets anders bouwen wij niet, nu gaat het bij ons wel om intranet applicaties waar zulke eisen mogelijk zijn. Met een beetje mazzel is de volgende versie helemaal op de DOM gebouwd en ondersteunen we ineens IE5+ en Mozilla.

Ik gebruik als het aankomt op het bepalen van ondersteuning van bepaalde features meestal de 'object sniffing' methode; echter als het aankomt op het onderscheiden van verschillen in implementatie van bepaalde features, dan ontkom je niet aan een generieke browser-check.
Een check op document.all ligt dan eigenlijk het meest voor de hand, en is mijns inziens ook beter dan de userAgent string uitpluizen.

[[eNeRGy]]

Het ligt eraan hoever je er in wil gaan natuurlijk, er zijn hele mooie js functies voor die alle browsers kunnen detecteren, incl OS.

Dat script stond eerst ook gelinkt in dat document op Mozilla.org, helaas is dat nu weg, moet eens zoeken

[crisp]

[eNeRGy] schreef op 13 augustus 2002 @ 16:32:
Het ligt eraan hoever je er in wil gaan natuurlijk, er zijn hele mooie js functies voor die alle browsers kunnen detecteren, incl OS.

Dat script stond eerst ook gelinkt in dat document op Mozilla.org, helaas is dat nu weg, moet eens zoeken

Beetje overkill lijkt me; ik wil bijvoorbeeld alleen snel even weten of een browser IE of NS/Mozilla is zodat ik er bijvoorbeeld rekening mee kan houden dat NS/Mozilla borders 'buiten' de box renderen, en IE erbinnen. Hier zijn ook wel andere manieren voor (eerst box laten renderen en vervolgens kijken of er verschil is tussen de binnenbreedte en de buitenbreedte), maar dat is allemaal veel omslachtiger.
De userAgent moet je eigenlijk niet op willen vertrouwen, dus als Mozilla besluit om document.all te adopteren, dan hou je eigenlijk alleen maar nog obscurere methodes over om IE en NS/Moz uit elkaar te houden.
Ik heb trouwens denk ik de discussie op bugzilla gevonden, hier

[Bosmonster]

[eNeRGy] schreef op 13 augustus 2002 @ 16:32:
Het ligt eraan hoever je er in wil gaan natuurlijk, er zijn hele mooie js functies voor die alle browsers kunnen detecteren, incl OS.

Dat script stond eerst ook gelinkt in dat document op Mozilla.org, helaas is dat nu weg, moet eens zoeken

Dat zegt crisp. Het gaat er alleen om dat je beter kunt kijken naar de MOGELIJKHEDEN van de browser, ipv naar een userAgent string die je toevallig meegestuurd krijgt. Die laatste is namelijk nooit 100% betrouwbaar en vraagt ook veel meer scripting in de uiteindelijke checks.

[crisp]

Discussie op bugzilla even helemaal gelezen; lijkt er vooralsnog op dat er meer tegenstanders dan voorstanders zijn, o.a. om de reden die ik zelf al aangaf.
Een belangrijk argument tegen was, dat als je eenmaal begint met Mozilla volledig IE-compliant te maken het einde zoek is. Je moet dan namelijk *alles* gaan ondersteunen, en niet maar een deel. Zelfs fout geimplementeerde features zou je dan moeten gaan mimieken, en dat druist natuurlijk tegen de hele gedachte van het Mozilla project in

[Verwijderd]

nu we het toch over twee browsers hebben (dankzij jullie hebben ik het nu trouwens werkend in NS en IE, ik ben nu mozilla aan ut downloaden) ...

door verschillende in interpretaties van style sheets door deze browsers ziet mijn checkbox er in netscape heel erg verrot uit, nu kan ik allerlei browserchecks erin gaan stoppen, maar er ook zonder classes iets te gebruiken zodat een style-command alleen geld voor text-inputs ?

[crisp]

Verwijderd schreef op 13 augustus 2002 @ 18:32:
nu we het toch over twee browsers hebben (dankzij jullie hebben ik het nu trouwens werkend in NS en IE, ik ben nu mozilla aan ut downloaden) ...

door verschillende in interpretaties van style sheets door deze browsers ziet mijn checkbox er in netscape heel erg verrot uit, nu kan ik allerlei browserchecks erin gaan stoppen, maar er ook zonder classes iets te gebruiken zodat een style-command alleen geld voor text-inputs ?

Ja, met:

code:

@import url("altstylesheet.css");

kan je je stylesheet voor de moderne browsers importeren; oudere browsers (zoals NS4) hebben deze mogelijkheid niet en voeren het dus ook niet uit

[[eNeRGy]]

Let wel, bij Mozilla moet @import op de eerste regel van je <style> staan, anders werkt het niet (heb ik gelezen, niet uitgeprobeerd), maar het kan verder geen kwaad om het te doen

[Clay]

is't misschien handig hier een los topic voor te openen?

[Clay]

het verschil tussen IE en MOZ is idd raar. Ik wist trouwens niet van het verschil tussen borders in IE en Moz, ik wist wel dat nested layers met borders wat gevrot met positioning vereisen als je er borders indoet, maar meer niet.
Wat ik irritanter vind is dat moz anders met padding omgaat. Een div van 200px breed met een padding van 2 wordt 204 pixels breed, en 4px hoger dan de initiele height. als je een padded layer nest in een niet padded layer gaat die geneste dus "uitsteken" uit zijn parent, en dat is geen gezicht. IE laat de afmetingen wel met rust

heb hier een kleine css test, geeft het verschil aan

[crisp]

Clay schreef op 13 augustus 2002 @ 21:11:
is't misschien handig hier een los topic voor te openen?

Het valt hier ook niet zo op nee, terwijl het imho wel weer een leuk discussie onderwerp is
Zal wel even een aftrapje maken _{of bedoelde je de d.all discussie niet, gaan nu 3 onderwerpen door elkaar heen; anyway, ik heb er toch maar een topic van gemaakt}

Clay schreef op 13 augustus 2002 @ 21:32:
het verschil tussen IE en MOZ is idd raar. Ik wist trouwens niet van het verschil tussen borders in IE en Moz, ik wist wel dat nested layers met borders wat gevrot met positioning vereisen als je er borders indoet, maar meer niet.
Wat ik irritanter vind is dat moz anders met padding omgaat. Een div van 200px breed met een padding van 2 wordt 204 pixels breed, en 4px hoger dan de initiele height. als je een padded layer nest in een niet padded layer gaat die geneste dus "uitsteken" uit zijn parent, en dat is geen gezicht. IE laat de afmetingen wel met rust

heb hier een kleine css test, geeft het verschil aan

Dat zijn inderdaad dingen waar ik de laatste tijd ook tegenaan loop; door document.all uit te vragen pas ik dan meestal de positionering en/of breedte/hoogte aan aan de browser...