onclick funktioniert erst beim 2.mal klicken

[markusp]

Hallo,
ich habe folgenden Link:
<a href="#" onclick="return show_status_cmnt(2, '2a')" id="2a"> Kommentar posten </a>

durch onklick soll show_status_cmnt aufgerufen werden, welche ein div sichtbar macht, diese ist:
function show_status_cmnt(id, id2){
  var id=document.getElementById(id);
  var id2=document.getElementById(id2);
  if(!id)return true;
  if(id.style.display=="none"){
    id.style.display="block"
id2.style.backgroundColor="#CCC"
  } else {
    id.style.display="none"
id2.style.backgroundColor="#FFF"
  }
  return true;
}

die funktion funktioniert richtig, jedoch erst beim 2. mal klicken. Kann man das irgendwie machen, das es beim 1. mal klicken auch funktioniert?

mfg

[Klawischnigg]

Hi there,

die funktion funktioniert richtig, jedoch erst beim 2. mal klicken. Kann man das irgendwie machen, das es beim 1. mal klicken auch funktioniert?

ja, in dem Du statt onclick="return showstatus..." einfach onclick="showstatus..." schreibst...

[Der Martin]

Hi,

<a href="#" onclick="return show_status_cmnt(2, '2a')" id="2a"> Kommentar posten </a>

ist es Absicht, dass bei deaktiviertem Javascript oder einem Fehler innerhalb der aufgerufenen Funktion zum Seitenanfang gescrollt wird? - Nein? Also ist der Link (das a-Element) hier nicht sinnvoll. Verwende stattdessen ein anderes sinnvolles Element, dem du den onclick-Handler gibst, beispielsweise ein button-Element.
Aber das nur als allgemeiner Rat; hat mit deiner Frage nichts zu tun.

if(id.style.display=="none"){
    id.style.display="block"
id2.style.backgroundColor="#CCC"
  } else {
    id.style.display="none"
id2.style.backgroundColor="#FFF"

die funktion funktioniert richtig, jedoch erst beim 2. mal klicken.

Ja, das ist ein Klassiker, über den Einsteiger sehr häufig stolpern - ich kann's ihnen nicht verdenken. Das style-Objekt, das du hier abfragst, enthält nur dann einen Wert, wenn er auch mit Javascript gesetzt wurde!
Du willst offensichtlich ein Element wechselweise ein- und ausblenden, das von Anfang an zunächst unsichtbar ist. Vergleiche daher in deiner Abfrage nicht auf =="none", sondern auf !="block".

Ciao,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Ja, das ist ein Klassiker, über den Einsteiger sehr häufig stolpern - ich kann's ihnen nicht verdenken. Das style-Objekt, das du hier abfragst, enthält nur dann einen Wert, wenn er auch mit Javascript gesetzt wurde!

Und auch, wenn er inline per @style-Attribut gesetzt wurde.

Selber Einsteiger‽ ;-)

Qapla'

[Der Martin]

Hallo,

Das style-Objekt, das du hier abfragst, enthält nur dann einen Wert, wenn er auch mit Javascript gesetzt wurde!
Und auch, wenn er inline per @style-Attribut gesetzt wurde.
Selber Einsteiger‽ ;-)

nö, Inline-Style-Gegner! :-P

Ciao,
 Martin

[dedlfix]

Hi!

if(id.style.display=="none"){
die funktion funktioniert richtig, jedoch erst beim 2. mal klicken.

Mit einer Kontrollausgabe hätte man auch ohne das nachfolgende Wissen sehen können, was da schief läuft.
alert(id.style.display) zeigt, dass da kein none drinsteht und somit Wunsch und Wirklichkeit nicht übereinstimmen.

Ja, das ist ein Klassiker, über den Einsteiger sehr häufig stolpern - ich kann's ihnen nicht verdenken. Das style-Objekt, das du hier abfragst, enthält nur dann einen Wert, wenn er auch mit Javascript gesetzt wurde!

Oder im style-Attribut des HTML-Elements, das war aber in dem Fall auch nicht da.

Lo!

[Don P]

Hallo,

Das style-Objekt, das du hier abfragst, enthält nur dann einen Wert, wenn er auch mit Javascript gesetzt wurde!

Das ist nicht ganz richtig.
Es enthält dann einen Wert, wenn es als inline-style gesetzt wurde, was JavaScript auch so macht, wenn man das style-Objekt benutzt.

Folgendes Klingonenschiff

<div id="Vogel1" class="Raubvogel" style="display:none;"></div>

kann problemlos mit

var hülle = document.getElementById("Vogel1").style,  
    getarnt = hülle.display === 'none';  
  
hülle.display = getarnt ? 'block' : 'none';  

wechselweise getarnt/enttarnt werden.
Klingonen machen das immer so. Stimmt's, @Gunnar? ;)

Gruß, Don P

[Gunnar Bittersmann]

@@Don P:

nuqneH

Klingonen machen das immer so. Stimmt's, @Gunnar? ;)

Nein, natürlich nicht! Du petaQ solltest nicht von Tischsitten auf Coding-Styles schließen! ;-)

Per JavaScript CSS-Eigenschaften zu verändern ist unehrenhaft. (Das hat schon einige ins Gre'thor befördert.)

Ehrenhaft ist es, per JavaScript Klassenzugehörigkeiten zu ändern und die Darstellung für diese Klassen im Stylesheet anzugeben.

Qapla'

[Don P]

Hallo,

Per JavaScript CSS-Eigenschaften zu verändern ist unehrenhaft. (Das hat schon einige ins Gre'thor befördert.)

Aha, du must es ja wissen. Den Code hatte ich während einer Schlacht aus einem unverchlüsselten Subraumkanal gefischt. Da waren die Jungs wohl sehr in der Bredoullie, dass sie sogar unehrenhaften Code in Kauf nahmen, nur um noch schnell enttarnen und feuern zu können... es hat ihnen aber nichts genützt :p

Ehrenhaft ist es, per JavaScript Klassenzugehörigkeiten zu ändern und die Darstellung für diese Klassen im Stylesheet anzugeben.

Wer hat eigentlich dieses Gesetz aufgestellt, und wieso ist es so wichtig?
Wenn man doch gewisse style-Eigenschaften ohnehin nur per JavaScript setzen will, warum muss es dann unbedingt über das stylesheet laufen? Immerhin verlangt das zwei Schritte (JS-Funktion *und* Definition im Stylesheet), mit gezwungermaßen "Magic Values" (den Klassennamen), einem bekannten Anti-Pattern.

Gruß, Don P

[Gunnar Bittersmann]

@@Don P:

nuqneH

Ehrenhaft ist es, per JavaScript Klassenzugehörigkeiten zu ändern und die Darstellung für diese Klassen im Stylesheet anzugeben.

Wer hat eigentlich dieses Gesetz aufgestellt

Der gesunde Klingonenverstand. ;-)

und wieso ist es so wichtig?

Wegen der Wartbarkeit des Codes. Um spätere Änderungen einfacher und an der richtigen Stelle vorzunehmen.

Was, wenn nicht ausgeblendet, sondern ausgegraut werden soll? Die Programmlogik ist davon nicht im geringsten betroffen, warum sollte man die Stelle der Änderung im Script vermuten?

Es ändert sich doch lediglich die Darstellung, klarer Fall für Änderung am Stylesheet.

Anti-Pattern.

Trennung von Inhalt, Darstellung und Verhalten ist mitnichten ein solches.

Qapla'

[ChrisB]

Hi,

Ja, das ist ein Klassiker, über den Einsteiger sehr häufig stolpern - ich kann's ihnen nicht verdenken.

Dass das Wissen um solch ein Detail nicht da ist, kann man nicht verdenken.

Dass aber kein bisschen debugt wird, sondern in schönster Naivität davon ausgegangen wird, dass „alles richtig“ sei (und trotzdem komischerweise nur bei jedem zweiten Mal „funze“), m.E. schon.
Anfänger scheinen irgendwie immer automatisch davon auszugehen, alles richtig gemacht zu haben - und mit der Begründung wird dann der Kopf abgeschaltet, und gefragt.

MfG ChrisB

[MudGuard]

Hi,

und mit der Begründung wird dann der Kopf abgeschaltet

Du setzt hier implizit voraus, daß der Kopf vorher eingeschaltet war - ich weiß nicht, ob diese Voraussetzung immer gegeben ist ...

cu,
Andreas

[Hopsel]

Hi markusp!

Martin hat dir ja schon die Antwort gegeben.
Beachte zusätzlich außerdem, dass IDs mit einem Buchstaben beginnen müssen.

MfG H☼psel

[ChrisB]

Hi,

Beachte zusätzlich außerdem, dass IDs mit einem Buchstaben beginnen müssen.

Noch, bzw. eigentlich auch jetzt schon nicht mehr. (Unterstützen wohl schon alle Browser, auch wenn sie noch keinen HTML5-Parser verwenden.)

MfG ChrisB

[Gunnar Bittersmann]

@@ChrisB:

nuqneH

Beachte zusätzlich außerdem, dass IDs mit einem Buchstaben beginnen müssen.

Noch, bzw. eigentlich auch jetzt schon nicht mehr. (Unterstützen wohl schon alle Browser, auch wenn sie noch keinen HTML5-Parser verwenden.)

Hm, das heißt, dass in XHTML5 @id nicht vom Typ ID ist. [XML §3.3.1]

Sollte das problematisch für die XML-Verarbeitung sein?

Qapla'

[ChrisB]

Hi,

Hm, das heißt, dass in XHTML5 @id nicht vom Typ ID ist. [XML §3.3.1]

Sieht wohl so aus, ja.

Sollte das problematisch für die XML-Verarbeitung sein?

Es wird ja m.W. nicht ohne Grund spezifiziert, wie genau ein HTML5-Parser zu arbeiten hat - der sollte dann keine Probleme damit haben, das zu verarbeiten.

Gängige DOM-Implementationen (abseits von JavaScript) besitzen ja aber oftmals gar keine getElementById-Methode - eben weil id in XML erst mal ein Attribut wie jedes andere ist, so lange es nicht explizit als xml-id in der DTD gekennzeichnet ist, oder liege ich da falsch?

Dumm nur, dass HTML5 gar keine DTD hat, in der man die genau Natur dieses Attributes klarer spezifizieren könnte.

MfG ChrisB

[Gunnar Bittersmann]

@@ChrisB:

nuqneH

Sollte das problematisch für die XML-Verarbeitung sein?

Es wird ja m.W. nicht ohne Grund spezifiziert, wie genau ein HTML5-Parser zu arbeiten hat - der sollte dann keine Probleme damit haben, das zu verarbeiten.

Das nicht. Aber sollte XHTML5 nicht auch als XML verarbeitbar sein?

Qapla'

[ChrisB]

Hi,

Aber sollte XHTML5 nicht auch als XML verarbeitbar sein?

Ja - aber ist es das durch sowas nicht mehr?

Solch ein XML

<?xml version='1.0'?>  
<root>  
<elem1 id="$">elem1 inhalt</elem1>  
<elem2 id="$">elem1 inhalt</elem2>  
<elem3 id="#">elem1 inhalt</elem3>  
</root>

„fressen“ bspw. PHPs SimpleXML und die DOM Extension problemlos und ohne zu meckern. (Nicht, dass ich daraus jetzt fachliche Korrektheit unbedingt ableiten wollte.)

Das Manual zu DOMDocument::getElementById sagt bspw.,

“For this function to work, you will need either to set some ID attributes with DOMElement::setIdAttribute or a DTD which defines an attribute to be of type ID. In the later case, you will need to validate your document with DOMDocument::validate or DOMDocument->validateOnParse before using this function.”

Nach meinem Verständnis ist id erst mal ein Attribut wie jedes andere auch.
Wenn man ihm die „Sonderbedeutung“ einer XML-ID geben möchte, muss man das entweder in der DTD (gibt's nicht für HTML5) festlegen, oder bspw. mittels Namespace-Angabe explizit darauf hinweisen, also xml:id stattdessen nutzen.

Wenn ich letzteres mache (xml:id="$"), dann geben mir sowohl SimpleXML als auch DOMDocument entsprechende Warnings aus,

validity error : xml:id : attribute value $ is not an NCName

Und selbst wenn ich aus dem zwei mal benutzten $ einfach ein doppeltes xml:id="a" mache, bekomme ich

element elem2: validity error : ID a already defined

Benutze ich hingegen nur id="a" und das doppelt, gibt es kein Gemecker.

MfG ChrisB

[EKKi]

Mahlzeit markusp,

<a href="#" onclick="return show_status_cmnt(2, '2a')" id="2a"> Kommentar posten </a>

Ein Link ist ein Link, weil er linkt. Ein Link, der nicht linkt, ist kein Link. Entferne also das <a>-Element (denn offenbar führt dieser "Verweis" nirgendwohin) und nutze stattdessen ein semantisch sinnvolleres.

function show_status_cmnt(id, id2){
  var id=document.getElementById(id);
  var id2=document.getElementById(id2);

Du rufst die Funktion mit dem numerischen Wert 2 als ersten Parameter auf - und verwendest diesen dann innerhalb der Funktion als Parameter für getElementById(), d.h. Du betrachstest ihn als id-Attribut eines HTML-Elements. IDs müssen aber nicht nur dokumentweit eindeutig sein, <http://de.selfhtml.org/html/referenz/attribute.htm#id_idref_name@title=sie dürfen darüber hinaus auch nicht mit Ziffern beginnen oder gar nur als Ziffen bestehen>. Mit anderen Worten: rein numerische IDs sind ungültig. Korrigiere dies.

if(id.style.display=="none"){

Hast Du Dir *vor* dieser Abfrage mal den entsprechenden Wert ausgeben lassen? Ich wette, dass der Wert nicht "none" ist, so dass in den else-Teil gesprungen wird ... und dadurch sieht es vermutlich so aus, als täte sich nichts.

die funktion funktioniert richtig, jedoch erst beim 2. mal klicken. Kann man das irgendwie machen, das es beim 1. mal klicken auch funktioniert?

Ja: korrekten Code schreiben. :-)

MfG,
EKKi

[Gunnar Bittersmann]

@@EKKi:

nuqneH

<a href="#" […]>
offenbar führt dieser "Verweis" nirgendwohin

Schön wär’s.

Der Verweis führt aber doch irgendwohin, nämlich an den Seitenanfang. Das dürfte sich störend bemerkbar machen, wenn der Nutzer schon runtergescrollt hat.

Qapla'

[markusp]

Danke für die schnellen Antworten!
hat geholfen :P