Matthias Scharwies: HTML-Referenz - was soll mit den Attributen passieren?

Servus!

Wir hier schon besprochen, sind unsere Referenzen nicht so übersichtlich, wie sie eigentlich sein sollte.

Mittlerweile habe ich die Attribute nach oben vor die "Siehe_auch" gezogen.

Da stellen sich mir aber einige Fragen:

1. keine Attribute

Bei …

gibt es nur die Universalattribute. Drinlassen oder weg damit?

2. mit Attributen

Bei …

gibt es welche!

Was soll mit den Universalattributen passieren? Einerseits ist die Verbergen-Vorlage genial, aber sie benötigt eben JS.

Tabelle oder dl?

Die Tabelle hat 4 Spalten, aber wenn man genau hinschaut, könnte man es so lösen:

<dl>
      <dt>href</dt>
      <dd>CDATA</dd>
      <dd>bestimmt einen Download-Link auf eine Ressource, die als lokale Datei gespeichert werden kann. </dd>
      <dt>target</dt>
      <dd>_blank, '''_self''', _parent, _top</dd>
      <dd>bestimmt den Fensternamen des Verweisziels. </dd>
</dl>

Den Standardwert könnte man eigenlich weglassen, bzw. in den vorgegebenen Werten fett markieren.

Was meint ihr?

Herzliche Grüße

Matthias Scharwies

--
Ich habe heute rausgefunden, dass in das Pizzafach meines Rucksacks auch ein Laptop passt!
  1. Hallo Matthias Scharwies,

    Einerseits ist die Verbergen-Vorlage genial, aber sie benötigt eben JS.

    Unser Wiki ist ohne JS ohnehin Müll, wir bauen mit JS derart viel dazu und um, dass es an der Stelle auch nicht mehr drauf ankommt.

    Eine Attributliste nur mit "Universalattribute" drin wäre für mich ok. Ggf. könnte man den "Eingeklappt" und "Ausgeklappt" Text so ändern, dass die Darstellung mehr einem Details-Element ähnelt. Das dürfte eine einzele Änderung in der H5 Vorlage sein (kann ich machen, wenn es Zustimmung findet). Irgendwann gibt's dann mal <details> im Wiki und man passt die H5-Vorlage an.

    Aber:

    Problem: Tabelle oder dl?

    <details> geht weder in einer Tabelle noch in einer dl, bzw. man muss Tabelle oder dl aufteilen. Beides Käse. Ohne JS werden wir da nie auskommen. Ein Checkbox-Hack wäre verlockend, ist aber schlicht nicht zugänglich (weil sich von der Checkbox keine controls- oder expanded-Beziehung aufbauen lässt), das dürfen gerade wir nicht bauen. Einzige Lösung ohne JS wäre demnach ein Link auf eine Seite mit Universalattributen. Aber, wie gesagt, ohne JS ist das Wiki eh kaputt.

    Ob das Ding rein formal der Anforderung "tabellarische Daten" genügt? Weiß nicht. Der Umstand, dass es Überschriften je Spalte gibt, deutet darauf hin. Eine <dl> bräuchte eine Heading-Gruppe mit Spaltenüberschriften, aber diese Heading-Gruppe wäre mit dt/dd falsch markiert, weil in dieser Gruppe nichts definiert wird.

    Im Moment ist es auch so, dass das Aside-TOC zusammen mit der Attributtabelle in schmalen Viewports das Layout zerreißt. Was unter anderem daran liegt, dass die attribute-reference Tabelle eine min-width von 600px (sic!) hat. Das Aside-TOC faltet sich zwar bei schmalen Viewports zusammen, aber (a) zu spät und (b) ist die Attributtabelle Teil des Layout-Grid und wird deshalb nicht vollbreit, wenn sich das Toc einfaltet.

    Hier besteht also ohnehin ein Todo, das man nicht über's Knie brechen sollte.

    Gunnar hatte doch mal über Tabellen berichtet, die sich bei schmalen Viewports automagisch auf Liste umbauen. Ich glaube, sowas wäre hier nützlich.

    Rolf

    --
    sumpsi - posui - obstruxi
  2. Hallo

    Wie wir hier schon besprochen, sind unsere Referenzen nicht so übersichtlich, wie sie eigentlich sein sollte.

    Mittlerweile habe ich die Attribute nach oben vor die "Siehe_auch" gezogen.

    Da stellen sich mir aber einige Fragen:

    1. keine Attribute

    Bei …

    gibt es nur die Universalattribute. Drinlassen oder weg damit?

    Drin lassen.

    2. mit Attributen

    Bei …

    gibt es welche!

    Was soll mit den Universalattributen passieren?

    Drin lassen. Was ist falsch an einer vollständigen Liste der verfügbaren Attribute?

    Einerseits ist die Verbergen-Vorlage genial, aber sie benötigt eben JS.

    Ich verstehe ehrlich gesagt nicht, warum diese Inhalte verborgen werden sollen.

    Tabelle oder dl?

    Die Tabelle hat 4 Spalten, aber wenn man genau hinschaut, könnte man es so lösen:

    <dl>
          <dt>href</dt>
          <dd>CDATA</dd>
          <dd>bestimmt einen Download-Link auf eine Ressource, die als lokale Datei gespeichert werden kann. </dd>
          <dt>target</dt>
          <dd>_blank, '''_self''', _parent, _top</dd>
          <dd>bestimmt den Fensternamen des Verweisziels. </dd>
    </dl>
    

    Aber wenn's doch eine Tabelle ist …

    Den Standardwert könnte man eigenlich weglassen, bzw. in den vorgegebenen Werten fett markieren.

    Was meint ihr?

    Das liest sich prinzipiell gut. Aber es muss dem geneigten Benutzer auch klar sein (beziehungsweise klar gemacht werden), dass der fett markierte Wert der Vorgabewert ist. Und da der Benutzer über alle möglichen Wege – auch direkt – auf die Seite gekommen sein kann, muss ihm diese Erklärung mMn an allen relevanten Stellen dargeboten werden.

    Tschö, Auge

    --
    „Habe ich mir das nur eingebildet, oder kann der kleine Hund wirklich sprechen?“ fragte Schnapper. „Er behauptet, nicht dazu imstande zu sein“ erwiderte Victor. Schnapper zögerte (…) „Nun …“ sagte er schließlich, „ich schätze, er muss es am besten wissen.“ Terry Prattchett, Voll im Bilde
  3. @@Matthias Scharwies

    Bei …

    gibt es welche!

    Eins davon hab ich mal berichtigt. Aber warum wird TARGETNAME nicht richtig verlinkt wie bspw. NAME, obwohl ich das auf https://wiki.selfhtml.org/wiki/HTML/Elemente#TARGETNAME hinzugefügt habe?

    🖖 Живіть довго і процвітайте

    --
    „Ukončete, prosím, výstup a nástup, dveře se zavírají.“
    1. Hi,

      @@Matthias Scharwies

      Bei …

      gibt es welche!

      Eins davon hab ich mal berichtigt. Aber warum wird TARGETNAME nicht richtig verlinkt wie bspw. NAME, obwohl ich das auf https://wiki.selfhtml.org/wiki/HTML/Elemente#TARGETNAME hinzugefügt habe?

      Im Quelltext steht da nur [[TARGETNAME]]. Also keine explizite Url-Angabe.

      Da müßte dann eher sowas stehen: [[/HTML/Elemente#TARGETNAME|TARGETNAME]], also URL(teil) + Anzeigetext

      cu,
      Andreas a/k/a MudGuard

      1. Hallo MudGuard,

        Da müßte dann eher sowas stehen: [[/HTML/Elemente#TARGETNAME|TARGETNAME]], also URL(teil) + Anzeigetext

        Nein. Kein / vorneweg.

        Wenn ich im Artikel Foo den Link [[/Bar]] setze, ist das Linkziel der Artikel Foo/Bar. Doof, aber wahr. Die [[...]] Links sind keine URLs, Mediawiki hat eigene Regeln.

        Absolute Linkziele: Kein Sonderzeichen vorneweg
        Relative Linkziele: ein / vorneweg

        Rolf

        --
        sumpsi - posui - obstruxi
        1. Hi,

          Da müßte dann eher sowas stehen: [[/HTML/Elemente#TARGETNAME|TARGETNAME]], also URL(teil) + Anzeigetext

          Nein. Kein / vorneweg.

          darum mein "eher sowas" - die genaue Syntax hab ich mir jetzt nicht angelernt - es ging mir vor allem um den Unterschied "nur Beschriftung" vs. "Url-Teil + Beschriftung".

          Wenn ich im Artikel Foo den Link [[/Bar]] setze, ist das Linkziel der Artikel Foo/Bar. Doof, aber wahr. Die [[...]] Links sind keine URLs, Mediawiki hat eigene Regeln.

          Absolute Linkziele: Kein Sonderzeichen vorneweg
          Relative Linkziele: ein / vorneweg

          hm. Also genau umgekehrt zum HTML-üblichen …

          Wi ki-mmt ma denn auf so an Schmarrn …

          cu,
          Andreas a/k/a MudGuard

    2. Hallo Gunnar,

      mit [[TARGETNAME]] verlinkst Du auf den Wiki-Artikel TARGETNAME. Den gips nich.

      Mit [[HTML/Elemente#TARGETNAME|TARGETNAME]] verlinkst Du auf die ID TARGETNAME im Artikel HTML/Elemente

      Aber warum hat das mit [[NAME]] funktioniert?

      Inhalt des Artikels NAME (Angelegt am 01.04.2015 von einem gewissen Matthias Scharwies) ist:

      #redirect [[HTML/Elemente#NAME]]
      

      Ich habe jetzt auch einen Redirect für TARGETNAME erzeugt, der Konsistenz halber.

      Rolf

      --
      sumpsi - posui - obstruxi