nicht angemeldet
Matthias Apsel
Matthias Apsel
Rolf B
Rolf B
kai345
Rolf B
Matthias Apsel
Rolf B
Matthias Apsel
kai345
Matthias Apsel
Auge
Ich weiß nicht, wohin ichs melden soll 😕 Thread kann aber nach Korrektur gelöscht werden...
Beispiel
var gesetzt = new Date(2017, 1, 11); // heutiges Datum ist der 11.02.2017
gesetzt.setDate(jetzt.getDate() + 50);
console.log(gesetzt.toLocaleDateString()); //angezeigt wird der 02.04.2017
Hallo Jörg,
vielen Dank für deine Aufmerksamkeit.
Ich weiß nicht, wohin ichs melden soll 😕
Es ist ein Wiki. Wenn es nicht das Beispiel selbst ist, kannst du direkt bearbeiten
Thread kann aber nach Korrektur gelöscht werden...
Beispiel var gesetzt = new Date(2017, 1, 11); // heutiges Datum ist der 11.02.2017 gesetzt.setDate(jetzt.getDate() + 50); console.log(gesetzt.toLocaleDateString()); //angezeigt wird der 02.04.2017
Ich verstehe nicht, was geändert werden muss. Kannst du das bitte genauer beschreiben?
Bis demnächst
Matthias
Hallo Matthias,
Ich verstehe nicht, was geändert werden muss. Kannst du das bitte genauer beschreiben?
Ich habs jetzt nicht ausprobiert, aber ich würde behaupten, dass jetzt.getDate() undefined ist und stattdessen gesetzt.getDate() stehen sollte.
Gruß, Jörg
Hallo Jörg,
Ich habs jetzt nicht ausprobiert, aber ich würde behaupten, dass
jetzt.getDate()undefinedist und stattdessengesetzt.getDate()stehen sollte.
Ja, das stimmt wohl. Das hättest du auch selbst ändern können. 😀
Bis demnächst
Matthias
Hi Matthias,
Ja, das stimmt wohl. Das hättest du auch selbst ändern können. 😀
Dafür fühle ich mich in JS nicht sicher genug und ich habs auch nur überflogen. Zudem muss auch nachgeschaut werden, was nachfolgend fehlerhaft ist.
Das Beispiel erzeugt ein neues Datumsobjekt
jetztmit dem aktuellen Datum, zu dessen mit getDate() ermitteltem Tageswert der Wert des Sliders addiert wird.
Der ausgedruckte Quelltext stimmt hier wohl auch nicht ganz, der im Beispiel verwendete ist aber korrekt. Da muss einer mal gründlicher nachgucken. 😉
Hallo Jörg,
da ist grundsätzlich Quark im Artikel oder in den Beispielen. Es gibt beide Variablen, aber "jetzt" wird einmal beim Start gesetzt und bleibt dann unverändert.
Die Variable "gesetzt" wird dann ebenfalls auf new Date() gesetzt, um einen Bezugspunkt für setDate zu haben. Verändert wird sie dann aber basierend auf jetzt.
Unsinn. Da braucht man keine zwei Variablen für, und wenn ich das am 31.01. um 23:55 starte und 10 Minuten später damit rumspiele, ist die Ausgabe Müll.
Rolf
Hallo Rolf,
da ist grundsätzlich Quark im Artikel oder in den Beispielen.
Ich sagte ja:
Da muss einer mal gründlicher nachgucken. 😉
Ich weiß halt nur, dass ich dieser "einer" nicht sein kann, da ich mich mit JS nun wirklich nicht gut genug auskenne 😉
Jörg
Hallo Jörg,
done.
Rolf
da ist grundsätzlich Quark im Artikel oder in den Beispielen.
Ja, das ist – aus heutiger Sicht wahrscheinlich noch mehr als aus meinem rückständigen Wissensstand – für ein Lehrbeispiel ziemlich unschön..
Zum Beispiel die Verwendung von <span> als Ausgabe statt <output> und Zuweisung des Wertes mit innerHTML statt textContent; die Verwendung von <b> statt <strong>, die Verwendung von parseInt() ohne Radix und diverse andere Dinge.
Der Bereich
if (tage < 0) {
label_resultierend.innerHTML = "vor " + (-1) * tage + " Tagen: ";
if (tage == -1) {
label_resultierend.innerHTML = "gestern: ";
}
} else if (tage > 0) {
label_resultierend.innerHTML = "in " + tage + " Tagen: ";
if (tage == 1) {
label_resultierend.innerHTML = "morgen: ";
}
} else {
label_resultierend.innerHTML = "heute: "
}
ist auch unschön, weil es schlechter Programmierstil ist.
tage == -1 und tage == 1
gehören auf die gleiche Ebene wie die Anderen 'if', sonst wir der Wert doppelt geschrieben (erst in den < 0 bzw > 0 Bereichen und direkt danach noch mal in den spezifischen Abfragen).
Ich würde hier auch noch den Text einer Variable zuweisen und einmalig am Schluss in das Zielelement schreiben (ich belasse es hier erst mal beim ursprünglichen innerHTML, damit es nicht zu verwirrend wird). Damit muß man nur an einer Stelle ändern, wenn sich das Element ändert.
Man kann das alles natürlich noch viel besser und eleganter machen als ich auf die Schnelle, aber zur Zeit ist selbige für mich etwas limitiert 😉
let txt;
if (tage == -1) {
txt = "gestern: ";
} else if (tage == 1) {
txt = "morgen: ";
} else if (tage < 0) {
txt = "vor " + (-1) * tage + " Tagen: ";
} else if (tage > 0) {
txt = "in " + tage + " Tagen: ";
} else {
txt = "heute: "
}
label_resultierend.innerHTML = txt;
…
Hallo kai345,
unabhängig von Dir schon alles erledigt 😀
Warum ist parseInt ohne Radix schlechter Stil? Es ist ja nun nicht so, dass parseInt("010") 8 liefern würde. Und "0x10" kann man in einem Slider nicht erzeugen.
Ich geh aber trotzdem nochmal 'ran. parseInt ist hyperfluid, valueAsNumber ist korrekt.
Rolf
Hallo kai345,
die Verwendung von <b> statt <strong>,
Die unreflektierte Ersetzung aller b- durch strong-Elemente (oder aller i- durch em-Elemente) ist ebenfalls mindestens unschön. Häufig werden Hervorhebungen nur gesetzt, weil es fett bzw. kursiv aussehen soll. Dann wäre b resp. i das richtige Element.
Bis demnächst
Matthias
Hallo Matthias,
<b> oder <i> sind für mich bestenfalls sinnvoll, wenn innerhalb eines Fließtextes einzelne Worte oder Phrasen hervorzuheben sind. <strong> hat Semantik:
<strong> indicates that its contents have strong importance, seriousness, or urgency.
Die Bedeutung "Boldface" für <b> wurde aufgehoben. MDN schreibt:
The HTML Bring Attention To element (<b>) is used to draw the reader's attention to the element's contents, which are not otherwise granted special importance. (...) The <b> element doesn't convey (...) special semantic information; use it only when no others fit.
Okay. Könnte man also tun. Es ist aber nicht nötig. Im Beispiel befindet sich der hervorzuhebende Text komplett in einem <label> Element. Das habe ich per CSS eingefettet und damit ist's gut.
Wenn man das Markup nicht so
<label for="resultat">...</label><output id="resultat"></output>
sondern so
<label id="resultat_label">...<output id="resultat"></output></label>
gestalten würde, dann wäre ein <b> Element als Zielobjekt für JavaScript sinnvoll. Im Beispiel identifiziere ich das Label über querySelector("label[for=resultat]"), das ist eigentlich ganz praktisch und spart eine eigene ID. Ich hatte tatsächlich eine Weile hin- und herüberlegt, was - auch in Hinblick auf die JavaScript Programmierung - das beste Markup ist. Ganz sicher bin ich mir nicht. Diese Version ist eigentlich auch nicht schlecht - mich störte nur das zusätzliche Kindelement:
<label id="resultat">
<b></b>
<output></output>
</label>
const resultat_label = document.querySelector("#resultat b"),
resultat_wert = document.querySelector("#resultat output");
aber dann hat man eine relativ starke Abhängigkeit zwischen der Struktur des Markup und dem JavaScript. Vermutlich ist das auch nicht das Beste. Die ursprüngliche Implementierung verwendete eine eigene ID für das Element, in das der Label-Text geschrieben wird. Das ergibt Markup, das mit IDs vollgestopft ist. Was ist besser?
Rolf
Hallo Rolf B,
<b> oder <i> sind für mich bestenfalls sinnvoll, wenn innerhalb eines Fließtextes einzelne Worte oder Phrasen hervorzuheben sind. <strong> hat Semantik:
Eben.
Okay. Könnte man also tun. Es ist aber nicht nötig.
Ich bezog mich auf Kais Rant gegen b-Elemente.
Was ist besser?
Das kann ich dir nicht sagen. Eine absolute Wahrheit wird es nicht geben. Wir sind nicht in der Mathematik.
Bis demnächst
Matthias
Ich bezog mich auf Kais Rant gegen b-Elemente.
geht's noch? 😠
Hallo kai345,
Ich bezog mich auf Kais Rant gegen b-Elemente.
geht's noch? 😠
Stimmt, war kein Rant. Entschuldige bitte.
Dennoch haben auch die b-Elemente noch ihre Berechtigung und es war in vielen Fällen verkehrt, pauschal und unreflektiert alle strong-Elemente in b-Elemente umzuwandeln.
Bis demnächst
Matthias
Hallo
Dennoch haben auch die b-Elemente noch ihre Berechtigung und es war in vielen Fällen verkehrt, pauschal und unreflektiert alle strong-Elemente in b-Elemente umzuwandeln.
… oder umgekehrt … 😆
Tschö, Auge