type="time"

[dedlfix]

Tach!

Einerseits hat Javascript eine automatische Typumwandlung, so dass es kein Problem ist, dass du mit Variablen vom Typ String Rechenoperationen ausführen kannst (bei timeInputElement.min und timeInputElement.max)

Ja, timeInputElement.min-- sieht doch schöner aus als
timeInputElement.min = String(parseInt(timeInputElement.min) - 1)

So sehe ich das auch. Zur Philosophie von Javascript gehört diese automatische Typkonvertierung, da kann man sie auch nutzen. In produktiv genutzem Code müsste man in dem Fall zwar auch nicht solch eine explizite Umwandlung vornehmen, aber über eine Fehleingabenprüfung nachdenken. Ist es wichtig, dass Fehleingaben verhindert werden müssen? Oder kann man sie durchgehen lassen, so dass Müll rauskommt, wenn man Müll eingibt und der Anwender dann eben, selbst schuld, Pech gehabt hat.

und numerische Werte zuweisen kannst (bei timeInputElement.value), andererseits verwendest du typsichere Vergleiche. Du musst dich also darauf verlassen, dass das Javascript im Browser die Numbers stets zu Strings konvertiert, damit der typsichere Vergleich nicht fehlschlägt.

Ich bin davon ausgegangen, dass ich mit timeInputElement.value = 23 den Attributwert ändere und beim Auslesen von timeInputElement.value den Attributwert auslese, also einen String bekomme.

Das wird man wohl auch können. Andererseits, ist es überhaupt wichtig, was für ein konkreter Typ da kommt, oder kann man notwendige Konvertierungen dem Automatismus überlassen? In dem Fall wohl: nein und ja.

Sieht mir recht paradox aus, und ich sehe auch keinen technischen Grund, warum die Typsicherheit hier notwendig wäre.

Aber mit „schönem Typmischmasch“ haste wohl recht. Ich hab da mal === in == geändert.

Ich hab noch keine mir schlüssige Erklärung gefunden, warum man aus Prinzip den typsicheren Vergleich vorziehen sollte. Irgendwann hat das mal jemand in die Welt gerufen, und alle machen es nach. Man findet das auch an Stellen, wo es überhaupt nicht darauf ankommt, dass die Typen exakt gleich sind. Zum Beispiel ist es oft egal, ob null oder undefined ankommt, und so kann man ruhig auch null == undefined vergleichen. Und ich hab auch in der Vergangenheit vor Zeiten des === nicht gesehen, dass ebenso großflächig, wie heute === verwendet wird, die Notwendigkeit der Typgleichheit in Code gegossen wurde.

In einem Blog-Beitrag von Heise hat mal jemand Performance ins Feld geworfen. Aber mal ganz abgesehen von der Sinnhaftigkeit eventueller Mikrooptimierung hat der Autor auf meinen skeptischen Kommentar nicht geantwortet. In der Javascript-Spezifikation findet man die Algorithmen, die bei Vergleichen mit == und === zu verwenden sind. Wenn die Werte gleichen Typs sind, vermag ich da keinen Performance-Unterschied zu erkennen, denn ob die Typen gleich sind, wird da in jedem Fall geprüft. Wenn ja, geht es in beiden Fällen gleichwertig mit dem eigentlichen Vergleich weiter. Wenn nicht, muss man an dieser Stelle mit dem Vergleich aufhören, denn Effizienzbetrachtungen sind unsinnig, wenn die Effekte unterschiedlich sind. Bei ungleichen Typen steht nun bei === das Ergebnis fest, bei == hängt es von den Werten nach der Typkonvertierung ab. Da kann nur noch der Anwendungsfall entscheiden, mit welchen Auskommen er besser abgedeckt ist.

dedlfix.