Baustellen im Wiki - helfende Hände gesucht

[Matthias Scharwies]

Die bestehenden Seiten im Wiki müssen immer wieder angepasst werden. Oft sind es nur Kleinigkeiten wie das Einfügen eines Links, manchmal die Verbesserung eines Beispiels. Leider hat der Tag aber auch nur 24 Stunden und wir können nicht immer so viel schaffen, wie wir wollen.

Deshalb nun unser Aufruf:

HELP WANTED

Auf unserer Baustellenseite finden sich alle Seiten mit ToDos. Trotzdem wollen wir einzelne Baustellen, die immer wieder auffallen, Euch hier besonders ans Herz legen:

1. 🛠 CSS/Tutorials/Grid/Verschachtelte_Raster
   subgrid wird von allen Browsern unterstützt; jetzt fehlt ein gutes Beispiel!

2. 🛠 Datenvisualisierung/Baumdiagramm
   Ursprünglich dachte ich an eine Umsetzung mit SVG, mittlerweile glaube ich, dass eine verschachtelte Liste mit @container besser geeignet wäre.
   Im Netz schlug jemand ein x-card-Element vor.

3. 🛠 File Upload
   war bereits ein ToDo im Januar 2023 - wer erbarmt sich?^[1]

4. 🛠 HTML/Tutorials/Multimedia/Playlists
   Audio, Video und JS - klingt doch interessant, oder?

5. 🛠 Zeit & Datum Alles rund um das Date-Objekt

   • JavaScript/Tutorials/Timer und Countdown
   • JavaScript/Tutorials/Monatskalender

Fertig:

✓ JavaScript und CSS

✓ PHP/Tutorials/Symfony Mailer

Herzliche Grüße

Matthias Scharwies

---

1. SELF-Forum: ToDo im Januar: File Upload vom 15.01.2023 ↩︎

[Robert B.]

Moin Matthias,

3. 🛠 File Upload
   war bereits ein ToDo im Januar 2023 - wer erbarmt sich?

gehört der dortige Abschnitt Direkter Upload einer einzelnen Datei an einen Server eigentlich inhaltlich zur vorherigen Auswahl mit Drag und Drop?

Viele Grüße
Robert

[Matthias Scharwies]

Servus!

Moin Matthias,

3. 🛠 File Upload
   war bereits ein ToDo im Januar 2023 - wer erbarmt sich?

gehört der dortige Abschnitt Direkter Upload einer einzelnen Datei an einen Server eigentlich inhaltlich zur vorherigen Auswahl mit Drag und Drop?

Das weiß keiner so genau. Damals(tm) gab es leider

1. HTML/input/File
2. HTML/File upload
3. JS/File Upload

Es wäre gut, wenn das jemand einfach mal vorzeigbar machen könnte.

Herzliche Grüße

Matthias Scharwies

[Robert B.]

Moin Matthias,

3. 🛠 File Upload
   war bereits ein ToDo im Januar 2023 - wer erbarmt sich?

gehört der dortige Abschnitt Direkter Upload einer einzelnen Datei an einen Server eigentlich inhaltlich zur vorherigen Auswahl mit Drag und Drop?

Das weiß keiner so genau.

Meine Frage zielt darauf ab, dass ich eine Datei auch ohne Javascript an den Server senden kann – das ist im Artikel ja auch weiter oben schon beschrieben. Gemäß des KISS-Prinzips leuchtet mir ohne Kontext nicht ein, warum man für eine Zeile HTML so viel Javascript bräuchte.

Viele Grüße
Robert

[Matthias Scharwies]

Servus!

Moin Matthias,

3. 🛠 File Upload
   war bereits ein ToDo im Januar 2023 - wer erbarmt sich?

gehört der dortige Abschnitt Direkter Upload einer einzelnen Datei an einen Server eigentlich inhaltlich zur vorherigen Auswahl mit Drag und Drop?

Das weiß keiner so genau.

Meine Frage zielt darauf ab, dass ich eine Datei auch ohne Javascript an den Server senden kann – das ist im Artikel ja auch weiter oben schon beschrieben. Gemäß des KISS-Prinzips leuchtet mir ohne Kontext nicht ein, warum man für eine Zeile HTML so viel Javascript bräuchte.

Ich weiß es auch nicht. Imho wollten die Baustellenersteller dort eine Prüfung des Dokument vor dem Upload zeigen, sind aber nicht fertig geworden.

Die Fetch API wäre eben etwas Moderneres, was man hier parallel zeigen oder zumindest im ==Siehe auch == verlinken könnte.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo,

TIL: <input type="file"> kennt ein accept-Attribut, in dem man File-Extensions und MIME-Typen hinterlegen kann, die der User auswählen darf.

Und wie sich herausstellt: hic sunt dracones!

Der Vergleich HTML/Attribute/accept mit der HTML Spec ergab: Die Begriffe "Medientyp" und "MIME-Typ" sind verknäuelt. Selbst die IANA dreht dieses Rad, sie schreiben in der MIME-Typregistry von „Media Type, formerly known as MIME Type“.

Damit gibt es keine vernünftige begriffliche Unterscheidung zwischen "audio", "audio/*" und "audio/mp3". "audio" ist in meinem Wortschatz ein MIME-Typ. "mp3" ist ein MIME Subtyp für audio. "audio/*" ist eine Sammelangabe für "Alle Audiodateien". Und "audio/mp3" ist eigentlich ein Medientyp, bestehend aus MIME-Typ und MIME-Subtyp. Wenn die IANA nun sagt, dass MIME-Typen jetzt Medientypen heißen, dann bekommt meine Tischkante neue Bissspuren…

Die HTML Spec macht es auch nicht besser: „Ein gültiger MIME type string ist ein String, auf den die media-type Produktion in RFC7231 passt.“ Diese Produktion enthält Typ, Subtyp und optionale Parameter…

Wir können das durch Begriffsfindung nicht lösen (damit sind wir schon bei den Stilelementen gescheitert…) und auf der Wiki-Seite für's accept-Attribut helfen dann nur klare Beispiele.

Das accept-Attribut erwartet aber keine Medientypen, sondern Dateitypen. Das ist wieder etwas anderes. Eine Dateitypangabe kann ein Medientyp sein, es kann aber auch einfach eine File Extension sein wie ".docx". Und es gibt die Sammelangaben wie "audio/*".

Bei diesen Sammelangaben spuckt dann wieder einer Feuer. Die HTML Spec sagt, dass als MIME-Typ Sammelangaben lediglich "audio/*", "video/*" und "image/*" zulässig seien. Von "text/*" ist keine Rede. Aber genau das verwenden wir im Wiki als Beispiel, und es funktioniert auch noch. Ob in jedem Browser und in jedem Betriebssystem, ist natürlich eine gute Frage. Betriebssysteme müssen für ihre Dateien einen Medientyp kennen, entweder indem sie ihn im Directory speichern oder - wie Windoof - indem sie ihn via Verzeichns aus der File Extension herleiten.

Wie erklär ich das nur meiner Oma?

Rolf

[Gunnar Bittersmann]

@@Rolf B

Wenn die IANA nun sagt, dass MIME-Typen jetzt Medientypen heißen, dann bekommt meine Tischkante neue Bissspuren…

Du hättest deinen Tisch doch längst aufgefuttert haben sollen in all den Jahren.

Kwakoni Yiquan