Tæller på input felter

<script>
function CountMax(txt, max){
  var out = document.getElementById("count");
 
  if(txt.value.length > max)
  {
      txt.value = txt.value.substr(0,30);
  }
  out.innerHTML = txt.value.length;
}

</script>

<input type="text" onKeyup="CountMax(this, 30)" />
<span id="count"></span>

doh (du ville jo have den skulle tælle ned)


<script>
function CountMax(txt, max){
  var out = document.getElementById("count");
 
  if(txt.value.length > max)
  {
      txt.value = txt.value.substr(0,30);
  }
  out.innerHTML = max - txt.value.length;
}

</script>

<input type="text" onKeyup="CountMax(this, 30)" />
<span id="count"></span>

evt kan man lave den lidt smartere

<script>
function CountMax(txt, max, spn){
  var out = document.getElementById(spn);
 
  if(txt.value.length > max)
  {
      txt.value = txt.value.substr(0,30);
  }
  out.innerHTML = txt.value.length;
}

</script>

<input type="text" onKeyup="CountMax(this, 30, 'cnt1')" />
<span id="cnt1"></span>

<input type="text" onKeyup="CountMax(this, 50, 'cnt2')" />
<span id="cnt2"></span>

Hej, tak for svaret.. :) det varer lige nogle timer før jeg skal bruge det, men tror jeg når dertil i dag :) du får lige point der hvis det virker ;D (hvilket det ser ud til ;))

Ser i hvert fald væsentligt smartere ud end mig keyno hack ;D

-- og så kan det anbefales at fremtidssikre det en anelse ved at bruge de nuværende DOM-bindings og ikke fortidens hack:

<script type="text/javascript">
function CountMax(txt, max, spn){
  var out = document.getElementById(spn);
 
  if(txt.value.length > max)
  {
      txt.value = txt.value.substr(0,max);
  }
  out.firstChild.nodeValue = txt.value.length;
}

</script>

<input type="text" onKeyup="CountMax(this, 30, 'cnt1')">
<span id="cnt1">&nbsp;</span>

<input type="text" onKeyup="CountMax(this, 50, 'cnt2')">
<span id="cnt2">&nbsp;</span>

-- bemærk specielt at konstruktionen kræver, at der er noget i span'erne fra start, her &nbsp;

-- og jeg rettede så også lge et par fejl ...

vis mig en browser som ikke har innerHTML - eller drop det fis med 'fremtidssikring'

substr rettelsen = nice

Tak for rettelserne :) læser selv lige op på det :) PT kan alle browsere jeg kender til innerHTML :) Men læser lige op på det ;)

Jeg nåede ikke lige at teste koderne da mine marsvin skulle til dyrlæge ;D hehe.. men de overlever ;)

Jeg tester lige så snart jeg får tid til det :) forhåbentlig i aften :D

Jeg kom til at tænke lidt selv... det er jo noget farligt noget ;)

det eneste den skal bruges til er at skrive hvor mange tegn der er tilbage... den skal ikke stoppe folk fra at skrive flere end der er plads til, det bruger jeg maxlength til, og for at være helt sikker checker jeg selvf. også i min POST inden jeg smider noget afsted :)

hvad synes i om:

function countMax(oSender, iMax, strContainerID)
{
    var iCharactersLeft = iMax - oSender.value.length;

    $(strContainerID).innerHTML = iCharactersLeft;
}

Meget simpel og kort med inspiration fra jeres :)

roenving hvis du mener at innerHTML er outdated og forkert, må du gerne forklare hvorfor? Jeg er åben for nye inputs hvis jeg ikke er up to date :)

og tak for jeres udførlige svar btw :)

innerHTML er som sådan ikke forkert eller outdated, det er bare på vej ud af DHTML verdenen, specielt efter der er blevet åbnet op for DOM manipulation. Derudover virker "innerHTML" ikke på alle elementer, hvilket "firstChild.nodeValue" gør. Så vidt jeg hved.

SÅ anbefalingen vil være at smide innerHTML ud og bruge firstChild.nodeValue for eftertiden :)?

innerHTML er ikke på vej nogen steder hen.

Mozilla og WebKit sørger fortsat for at implementere den, samt forfine dens implementering - så hvidt jeg har læst, arbejder Mozilla på at gøre innerHTML fuldt ud XHTML valid hvis man da kan kalde det dét...


innerHTML er ikke det samme som firstChild.nodeValue

- firstChild.nodeValue referere til text-noden inde i block/span elementer

- innerHTML sætter hele HTML'en med noder og hele baduljen inde i det valgte element

de kan derfor ikke erstatte hinanden.

f.eks. kan du ikke gøre følgende:

$(strContainerID).firstChild.nodeValue = "<b>Antal tegn:</b><i>" + iCharactersLeft "</i>";

Ja så må du bede roenving om at forklare det. Var bare sådan jeg havde forstået det.

Jeg har ringet lidt rundt til tidligere kollegaer for at hører hvad de mener... Det lader til at enigheden ligger mest hos montago. bruger også selv meget innerHTML, men er da naturligvis altid åben for nye inputs :) jo pænere ting er kodet jo bedre :)

men tror jeg holder mig til:

function countMax(oSender, iMax, strContainerID)
{
    var iCharactersLeft = iMax - oSender.value.length;

    $(strContainerID).innerHTML = iCharactersLeft;
}

Inspirationen kommer mest fra montago så du får points :)

Men tak for inspirationen, jeg var igang med noget hacket KeyCode og kunne ikke lige finde inspiration til at lave andet :)

takker for point ;-)


jeg kan fortælle dig, at der i ny og næ er åben krig mellem mig og især Olebole (til dels også et par andre brugere) omkring brugen af innerHTML

sagen er, at det er ren religion om man bruger DOM eller en blanding af innerHTML + DOM

*nogen* mener at, fordi de arbejder et sted i det offentlige, eller arbejder på projekter i million-klassen, hvor arbejdsgiverens krav er 100% W3C standard - så skal alle os herinde på eksperten også føje de regler...

hvis man kender innerHTML's 'shotcommings' og det samme for DOM - og bruger begge i deres bedste mønstre (design patterns) - så får man en super fed JS/Ajax hjemmeside.


læs evt. lidt om emnet på disse sider:
http://www.dengodekode.dk (DOM evangelilst)
http://blog.mdk-photo.com (innerHTML evangelilst)

tak for tippet :D

desuden skal du lige se hvad jeg har tryllet frem med brug af innerHTML

www.mdk-photo.com/Editor

som ikke umiddelbart kan lade sig gøre med DOM

innerHTML er en M$-opfindelse fra de tidligste javascript-tider, hvor det stort set kun var muligt at manipulere input-felters indhold og billeders src-attribut, men selvfølgelig interessant at gøre ting ved andre elementer og/eller deres indhold ...

Datidens DOOM-binding var lidt tilfældig og ikke bundet af nogle egentlíge standarder og regler, så browser-fabrikanterne måtte selv opfinde de dybe tallerkener, hvilket de så gjorde med større eller mindre opfindsomhed ...

innerHTML er dog et decideret misfoster, hvor en ganske rimelig sammenligning ift. DOM-binding kunne være, at man erstattede rattet i en bil med et papskilt med teksten 'Rat' på ...

Ift. XHTML bliver det dog helt skørt, da selve xhtml bygger på, at noderne skal opfattes som objekt-bærende, hvorfor ovenstående allegori kan udbygges til, at rattet fjernes og skiltet smides i bagagerummet eller måske nærmere i samme skuffe som registreringsattesten (og det gør det jo ikke nemmere at styre kræet igennem Monte Carlos gader !-)

Men det er korrekt, at alle nulevende nogenlunde moderne browsere understøtter den, og det er ligeledes korrekt, at man på nogle leder kan manipulere html-dokumenter med innerHTML, som det vil være meget svært at gøre med ordentlig DOM-scripting ...

Men det forandrer ikke ved, at en ægte xhtml-browser ville falde sammen med et hult suk, ligesom computere i 60'erne gjorde, når der kom insekter (bugs !-) ind i deres ferritkernelagre !o]

det gælder om at bruge sine værktøjer rigtigt

ikke lade værktøjerne bruge dig ;-)

<ole>

- og det er jo præcis, hvad roenving advokerer for  =)

/mvh
</bole>

- og endda ganske uden at behøve at blande religion og godt håndværk sammen  ;o)

"Men det forandrer ikke ved, at en ægte xhtml-browser ville falde sammen med et hult suk, ligesom computere i 60'erne gjorde, når der kom insekter (bugs !-) ind i deres ferritkernelagre !o]"

dette er lidt af en halv sætning... og fortæller egentlig ikke noget

en ægte XHTML browser (hvis en sådanne kan findes i en verden af forandring) ville jo netop ikke have innerHTML implementeret .. ergo ville den ikke gå i stykker... vel ?


sagen er at der er 2 måder at fylde HTML indhold ind i sin hjemmeside - den ene hedder innerHTML og er super nem at forstå og at bruge - samtidig med at den er afsindig hurtig til sit arbejde !

den anden hedder DOM og er omstændig, svær at forstå og langsom at bruge - men følger den skrevne standard.

- DOM har sine fordele og ulemper
- innerHTML har sine fordele og ulemper

det gælder derfor om at bruge hver af disse hvor det kan betale sig.

"dette er lidt af en halv sætning... og fortæller egentlig ikke noget" >> Nå!? Her taler du vist helt for dig selv  =)

"en ægte XHTML browser (hvis en sådanne kan findes i en verden af forandring) ville jo netop ikke have innerHTML implementeret .. ergo ville den ikke gå i stykker... vel ?" >> Jo, det må bero på en misforståelse af, hvad XML er - og hvordan XML fungerer i en browser. Et forsøg på at kalde invalide DOM metoder skal resultere i en XML-fejl, som det f.eks. kendes ved forsøg på at loade et ikke-velformateret xml-dokument.

Der er én valid måde at manipulere et HTML-dokuments elementer på - og den burde kun volde intellektuelle problemer for de færreste  =)

du er og bliver en fjols ole...

- og for den uindviede, plejer det vist at betyde, jeg er uenig med dig  =)

www.mdk-photo.com/Editor <- Haha cute editor :) men tror jeg kommer til at savne code completion ect. :) så tilgiv mig at jeg bliver hos NuSphere :)

leshrac:

Min editor HAR code completion... til HTML og CSS indtil videre...
Javascript er jeg kommet et stykke med, men mangler at skrive parseren færdig så den rekursivt forstår Javascript (ikke nogen let opgave med sådan et smadret sprog)

funktionelt ligner min editor Visual Studio og mange af dennes genvejstaster osv.

Kan man ændre dette script sådan at den tæller ned i stedt for op?