E-Mail ist nicht implementiert, auch wenn man (wie ich) den internen Mailclient benutzt.

»slider« ist ein unpraktischer Name, weil er auch bestimmt, wie das Element dargestellt werden muss. Manche Browser könnten für »range« vielleicht auch so ein drehknopfförmiges Teil anbieten oder für Blinde etwas ganz anderes. In HTML soll schließlich stehen, was ein Element repräsentiert, nicht wie es dargestellt wird.

Den Fehler gibt es schon viel zu deutlich bei »select« (hast du in deiner Auflistung oben übrigens vergessen) und »radiobuttons/checkboxes« sie haben die selbe Funktion, schauen aber anders aus.

Der »search«-Typ ist anscheinend — wie <a type=»search«> — dafür gedacht, dass Browser das Suchfeld automatisch erkennen können (bestimmt nützlich für Blinde und der Browser kann auch automatisch anbieten, die Seite zu seiner eigenen Suchfunktion hinzuzufügen, siehe http://en.wikipedia.org/wiki/OpenSearch )

Wie wärs mit UTF-8? :-/

select ist zwar ein Formularelement, wird aber nicht über input type= realisiert. Also kein Eingabefeld, sondern ein Auswahlfeld.

ok@search. Da gehe ich ja noch durchaus mit.

zu slider/range: Du hast natürlich Recht, das Aussehen ist nicht festgelegt. Man überläßt es dem Browser. Allerdings benötigen unterschiedliche Steuerelemente auch unterschiedlich viel Platz. Wenn ich ein Formular konstruiere und beispielsweise drei (semantisch) zugehörige Drehregler nebeneinander positioniere, dann würde es mit Schiebereglern den zur Verfügung stehenden Platz sprengen. Und dann helfen auch keine Breiten- und Höhenangaben im CSS. Im umgekehrten Fall hätte man dann eierförmige Drehregler ;-)

Daß es heute select / radio bzw. select multiple / checkbox ist meiner Meinung auch sinnvoll. Mein neues Formular auf der Startseite der zweitwohnsitzsteuer würde als radio den Rahmen sprengen. Das ändert aber nichts daran, daß beide Elemente für Blinde gleich aussehen können.

Würden wir allerdings es wirklich dem Browser überlassen, bräuchten wie auch kein range, sondern der Browser könnte bereits number so darstellen, vorausgesetzt min/max/step sind gegeben.

Was UTF-8 angeht: ja, es wird in absehbarer Zeit eine Generalüberholung geben. Dann werde ich es berücksichtigen, an diesen Skripten möchte ich nicht mehr viel ummodeln ;)

Den Unterschied zwischen number und range sehe ich darin, dass man bei number eine exakte Zahl eingibt, die man auch sieht, während man range eher nach Gefühl geht und der Nutzer mit der genauen Zahl nicht unbedingt in Berührung kommen muss (»Wie viele Eier möchten Sie bestellen?« vs. »Wie hart sollen Ihre Eier sein?«, blödes Beispiel).

Die Dimensionen sind natürlich problematisch, aber das haben viele Formularelemente bereits jetzt an sich (wo steht, dass ein type=»file«-Feld ein Inputfeld ist mit einem Knopf daneben? Es könnte ja auch an der Stelle bereits ein vollständiger Filebrowser sein). Leider müssen da die Browser ständig voneinander abschauen, um nicht vollständiges Chaos anzurichten.

@range: da haben ja die ganzen Hot-or-Not-Portale ein neues Spielzeug ;-)

Was den Datentyp file angeht, da hast du wohl recht. So exakt ist es in der Spezifikation nicht beschrieben:

This control type allows the user to select files so that their contents may be submitted with a form. The INPUT element is used to create a file select control.

Interessant ist, daß mit HTML5 das Attribut multiple dazukommt. Also: mehrere Dateien in einem Formular. Das ist durchaus eine wirklich wichtige Erweiterung.

Mehrere Dateien sind echt sinnvoll, man sieht ja recht oft Seiten, die »vorsichtshalber« einfach zehn file-inputs untereinander haben, damit man mehrere Dateien hochladen kann. Und dann könnte das Opera ja so ähnlich handhaben wie bei e-mail-attachments, wo man im Dateidialog gleich mehrere Dateien mit CTRL/shift auswählen kann.

Bloß scheint das Opera noch nicht zu unterstützen :-(

Oder wie bei mir: ich habe mir drei Zeilen für Bilder/Dateien je Beitrag gegönnt — und im Zweifelsfall muß ich halt per (s)FTP drauf, wenn ich mehr brauch.

email wird in der Version 9.6.3 schon unterstützt. Es prüft nach, ob die Eingabe der Syntax übereinstimmt und macht ein entsprechendes Symbl vor die Zeile.

Vielleicht ein Gedanke einer sinnvollen Erweiterung: ein neues Attribut (z.B. valid), dem ich einen regulären Ausdruck mit auf den Weg geben kann — und dieser wird dann im Browser geprüft.

bytheway: du kannst dich auch gerne mal per E-Mail melden.

Vielleicht ein Gedanke einer sinnvollen Erweiterung: ein neues Attribut (z.B. valid), dem ich einen regulären Ausdruck mit auf den Weg geben kann — und dieser wird dann im Browser geprüft.

In etwa so wie pattern?

Das Icon hab ich schon gesehen, und du hast Recht, die Validität von den Mails wird geprüft (wobei das nicht so trivial ist, »hi there«@example.com wäre in der Theorie, und in dem RFC dazu steht noch viel mehr), daran hab ich gar nicht gedacht. Aber ich würd mir so was ähnliches vorstellen wie im »An«-Feld von Operas Mailclient.

Zu dem Mail-Angebot: Das werd ich annehmen, wenn die Diskussion noch lange weitergeht und ich zu faul werd, dauernd hier nach einer Antwort zu schauen :-)

Ich habe keinen blassen Schimmer, was (jedenfalls die Vorschaufunktion) aus meinen Anführungszeichen macht, aber die Backslashes gehören da nicht hin (falls sie im endgültigen Post erscheinen)

Zu den Pattern: Ja, das ist es (Ich schaue mir später an, wie mächtig das ist).

Was das E-Mail-Formular angeht: in Opera 9.1 war email noch nicht belastet. Ich gehe davon aus, daß bei den richtigen Umsetzungen auch das E-Mail-Format korrekt implementiert ist. Wenn jetzt noch Schwachstellen gibt, ist das nicht dramatisch (Wenn bei datetime am Tag X nach 8 Uhr gefordert ist, bekomme ich im Moment auch am Tag 7 Uhr durch.)

Anführungszeichen: Ja, im Moment ein Relikt. Entdecktes Sicherheitsloch übervorsichtig gelöst. Da die ganze Seite demnächst rundumerneuert wird, will ich mich darum nicht mehr kümmern.

(Alternativ zum regelmäßigen Vorbeischauen wäre die Kommentar-RSS dieses Artikels zu empfehlen.)