Matthias Scharwies: Baustellen im Wiki - helfende Hände gesucht

problematische Seite

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. 🛠 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.

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

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

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

Fertig:

JavaScript und CSS

PHP/Tutorials/Symfony Mailer

CSS/Tutorials/Grid/Verschachtelte_Raster

Herzliche Grüße

Matthias Scharwies


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

  1. problematische Seite

    Moin Matthias,

    1. 🛠 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

    1. problematische Seite

      Servus!

      Moin Matthias,

      1. 🛠 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

      --
      Die Signatur findet sich auf der Rückseite des Beitrags.
      1. problematische Seite

        Moin Matthias,

        1. 🛠 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

        1. problematische Seite

          Servus!

          Moin Matthias,

          1. 🛠 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

          --
          Die Signatur findet sich auf der Rückseite des Beitrags.
    2. problematische Seite

      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

      --
      sumpsi - posui - obstruxi
      1. problematische Seite

        @@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

        --
        Ad astra per aspera
      2. Dieser Beitrag wurde gelöscht: Beitrag ist Spam.
      3. problematische Seite

        Wie erklär ich das nur meiner Oma?

        Rolf

        Klein Rolfi wollte seine Dateien auf seinem Server speichern, aber der wurde plötzlich sehr SEHR traurig und schluchzte, wie sehr er sich doch nach "Medientypen" und "MIME-Typen" sehnte. Leider verstand Rolfi nicht genau, was das bedeutete.

        Der Computer erklärte, dass MIME-Typen Informationen darüber enthalten, ob es sich zum Bleistift um ein Bild von Mama und Papa oder um ein Video von Omas 90er - oder vielleicht gar um das lustige Schlumpfenlied handelte! Dabei musste Klein Rolfi entsetzt feststellen, dass es wohl keine klare Unterscheidung zwischen den Begriffen "Medientypen" und "MIME-Typen" gab!

        Klein Rolfi lernte, dass er Dateiendungen wie ".mp3", MIME-Typen wie "audio" oder aus MIME-Typ und MIME-Subtyp bestehende Medientypen wie "audio/mp3" angeben musste, um zu sagen, welche Arten von Dateien erlaubt sind, erwartet und gefeiert werden. Sammelangaben wie "image/*" funktionierten meist, waren aber nicht überall definiert. Letztlich ging es darum, dass Computer verschiedene "Sprachen" verwenden, um Dateien zu verstehen. Rolfi teilte seinem Server fortan mit, welche Art von Datei er wie behandelt sehen wollte und sie lebten beide quietschvergnügt und glücklich bis an ihr ... ?

        1. problematische Seite

          Also sprach der Schlaufuchs Chrissi und glaubte nun, dass alles klar sei.

          Was Schlaufuchs Chrissi übersehen hat, ist, dass Klein Rolfi eigentlich schon kapiert hat, was Medientypen und MIME-Typen sind, sich aber fragt, wie man das der Oma so erklärt, dass sie sich darüber nicht ins Gram gräbt. Oder so ähnlich.

          Was Schlaufuchs Chrissi auch übersieht, ist, dass das accept-Attribut mit dem Server nichts zu tun hat, sondern mit dem Browser. Für den Server ist es nämlich wurscht, ob eine Bytefolge in "oma.gif", "klein_rolfi_am_strand.mov" oder "duett_oma_mit_klein_rolfi.ogg" gespeichert ist, oder gar aus einem Blob kommt, der niemals auf der Platte war. Wie Gunnar schon zitierte, weiß HTTP nichts von Dateien, nur von Ressourcen und Content-Streams, und der böse Server will im Content-Type Header einen MIME-Typ mit Subtyp sehen. Oder er fängt an, zu raten, mit wechselndem Erfolg. Und bricht darüber gelegentlich in Tränen aus.

          Das ist aber wiederum dem <input>-Element wurschtegal, DAS weiß nämlich was von Dateien, und auch von Dateiendungen, und muss daraus ein File-Objekt schnitzen, das dann wieder einen gültigen MIME-Typ hat. Das letzte, was meiner Oma dazu dann einfiel, war: Ach Rolfi, du musst mal wieder an die frische Luft 😉

          Rolf

          --
          sumpsi - posui - obstruxi
          1. problematische Seite

            Für den Server ist es nämlich wurscht, ob eine Bytefolge in "oma.gif", "klein_rolfi_am_strand.mov" oder "duett_oma_mit_klein_rolfi.ogg" gespeichert ist, oder gar aus einem Blob kommt, der niemals auf der Platte war.

            Auch wieder wahr. Schlaufuchs Chrissi ist eben nicht umsonst Schlaufuchs Chrissi!

            Das letzte, was meiner Oma dazu dann einfiel, war: Ach Rolfi, du musst mal wieder an die frische Luft 😉

            Rolf

            Wenn die Oma meint, Rolfi solle an die frische Luft gehen, dann hat Rolfi gefälligst an die frische Luft zu gehen!

            Klingt sehr sympathisch und vor allem weise, die Oma - leider hat es hier halt gerade ein richtiges Sauwetter