Rolf B: Frage zum Styling im Wiki

problematische Seite

Hallo alle,

im "problematischen" Artikel habe ich einiges Überarbeitet und möchte unter "Event-Objekt" drei Zeilen darstellen. Dafür habe ich <br> in den Wiki-Text eingesetzt.

Das Wiki erzeugt für die Zeilen 2 und 3 den HTML Code

<p>ProgressEvent (XMLHttpRequest und FileReader)<br>SVGEvent
</p>

Aber weil im Stylesheet p br:only-child { display:none; } steht, wird das br Element unterdrückt. Es ist ja das einzige Kind-Element, der Rest ist Text.

Welchen mutmaßlichen Sinn hat dieser Style?!

Bzw. wie kann ich es besser lösen? Das hier klappt nicht, weil die erste Zeile, hinter dem =, als einfacher Text in die Zelle gestellt wird und die beiden anderen zu einem <p> zusammengefasst werden.

 | Event-Objekt = Event (AbortSignal, Dokument, Medien)
ProgressEvent (XMLHttpRequest und FileReader)
SVGEvent

Das hier sieht einfach nur sch...eußlich aus, im Edit und im Browser (weil zu enge Zeilenabstände)

 | Event-Objekt = Event (AbortSignal, Dokument, Medien)<br>ProgressEvent (XMLHttpRequest und FileReader)<br>SVGEvent

Dadurch, dass die erste Zeile hinter dem Parameternamen nicht wikifiziert ist, klappt auch dies nicht:

 | Event-Objekt = 
* Event (AbortSignal, Dokument, Medien)
* ProgressEvent (XMLHttpRequest und FileReader)
* SVGEvent

Wie bringt man in einem Vorlagenparameter wikifizierbaren Text korrekt unter? Im Abschnitt davor habe ich getrickst und eine "Einleitungszeile" geschrieben. Ist das die einzige Möglichkeit?

Rolf

--
sumpsi - posui - obstruxi
  1. problematische Seite

    Hi,

    Das Wiki erzeugt für die Zeilen 2 und 3 den HTML Code

    <p>ProgressEvent (XMLHttpRequest und FileReader)<br>SVGEvent
    </p>
    

    Aber weil im Stylesheet p br:only-child { display:none; } steht, wird das br Element unterdrückt. Es ist ja das einzige Kind-Element, der Rest ist Text.

    Welchen mutmaßlichen Sinn hat dieser Style?!

    für schmale Viewports ist die Umbruchstelle definiert, für breite Viewports kann's mit diesem CSS zu einer Zeile werden.

    cu,
    Andreas a/k/a MudGuard

    1. problematische Seite

      Hallo MudGuard,

      glaubichnich - FileReader)<br>SVGEvent wird als FileReader)SVGEvent dargestellt. Umbrüche finden davor und dahinter statt, nicht da, wo das <br> steht. Hast Du das mit <wbr> verwexelt?

      Rolf

      --
      sumpsi - posui - obstruxi
  2. problematische Seite

    Hallo Rolf,

    eins hab ich rausgefunden: Es liegt nicht an der Vorlage, die verwendet wird. Die Vorlage generiert eine Mediawiki-Tabelle. Und wenn ich das von Hand mache:

    {|
     ! cancelable
     | Yep
    |-
     ! Auslöser
     | Ich
    Du
    Wir
    |}
    

    Dann entsteht im td hinter dem "Auslöser" th genau das gleiche:

    <td>Ich
    <p>Du Wir</p>
    <td>
    

    D.h. das Problem lautet: Wie geht man richtig mit Mediawiki-Tabellen um?

    Immerhin hab ich eins gefunden - Mediawiki-Doku:

    Content that uses wiki markup that itself needs to start on a new line, such as lists, headings, or nested tables, must be on its own new line.

    Ich habe die Vorlage so geändert, dass sie die Parameterwerte auf einer neuen Zeile beginnen lässt. Und Bingo, ich kann jetzt zumindest Listen einsetzen.

    Rolf

    --
    sumpsi - posui - obstruxi
  3. problematische Seite

    Tach!

    Welchen mutmaßlichen Sinn hat dieser Style?!

    Die Antwort kann man herausfinden. Mediawiki hat einen Mechanismus eingebaut, der mehrere Ressourcen zusammenfasst. Wenn man an die URL ein debug=true anhängt (mit ? oder & je nach Kontext), findet diese Zusammenfassung und Komprimierung nicht statt. Da du die fragliche Passage schon durch eine Liste ersetzt hast, muss man eine historische Version aufrufen. (Der Link enthält bereits das debug=true.) Nun kann man im Inspektor das fragliche <br> suchen, und neben der Regel findet man auch einen Verweis auf die Quelle. Dort sieht man einen Kommentar zur Regel, und ganz oben auch, wo die Definitionen herkommen. In dem Fall ist das MediaWiki:Common.css.

    dedlfix.

    1. problematische Seite

      Servus!

      Tach!

      Welchen mutmaßlichen Sinn hat dieser Style?!

      Die Antwort kann man herausfinden. Mediawiki hat einen Mechanismus eingebaut, der mehrere Ressourcen zusammenfasst. Wenn man an die URL ein debug=true anhängt (mit ? oder & je nach Kontext), findet diese Zusammenfassung und Komprimierung nicht statt. Da du die fragliche Passage schon durch eine Liste ersetzt hast, muss man eine historische Version aufrufen. (Der Link enthält bereits das debug=true.) Nun kann man im Inspektor das fragliche <br> suchen, und neben der Regel findet man auch einen Verweis auf die Quelle. Dort sieht man einen Kommentar zur Regel, und ganz oben auch, wo die Definitionen herkommen. In dem Fall ist das MediaWiki:Common.css.

      @dedlfix Vielen Dank, dass mit debug=true wusste ich noch nicht!

      @Rolf B Die leeren Absätze hatte Matthias im Januar entfernt:

      https://wiki.selfhtml.org/index.php?title=MediaWiki%3ACommon.css&type=revision&diff=75340&oldid=71247

      Einerseits konnten wir so die (über)großen Abstände zwischen code-Beispielen und der Siehe auch-Überschrift in den CSS-Referenzen entfernen, andererseits hatte ich manchmal doch Leer-Absätze zum Formatieren, bzw. stärkerem räumlichen Trennen verwendet.

      Herzliche Grüße

      Matthias Scharwies

      --
      Einfach mal was von der ToDo-Liste auf die Was-Solls-Liste setzen.“
      1. problematische Seite

        Hallo Matthias,

        Einerseits ..., andererseits ...

        Danke, das war genau das, was ich wissen wollte.

        Der Hinweis auf den Debug-Mode ist auch wertvoll, aber der Kommentar beantwortet die Frage nach dem Warum nicht.

        Es ist aber ein zu weit reichender Workaround. <p><br></p> zu entfernen ist eine Sache. Es ist aber suboptimal, <p>Hallo<br>Welt</p> zu "HalloWelt" zu verändern. Ich habe allerdings keine Idee, wie man das lösen kann. Mit CSS allein vermutlich gar nicht.

        Und nun habe ich eine Folgefrage: Warum wird common.css zweimal eingebunden?

        Einmal so:

        https://wiki.selfhtml.org/load.php?debug=true&lang=de&modules=site&only=styles&skin=selfhtml

        Und einmal so:

        https://wiki.selfhtml.org/load.php?debug=true&lang=de&modules=site&only=styles&skin=selfhtml&version=3f916a2008df

        Das liegt nicht am Debug-Schalter. Ohne Debug findet sich die br:only-child Regel ebenfalls zweimal. Einmal im <style> Bereich der Seite, und einmal als externe Ressource. Ist das der Workaround für einen Bug oder wurde da was übersehen?

        Und ist hier der richtige Ort, um über Wiki-interna zu reden?!

        Rolf

        --
        sumpsi - posui - obstruxi
      2. problematische Seite

        Hallo Matthias,

        so, jetzt hab ich das im Testwiki mal etwas beleuchtet. Ich würde dort gerne auch die common.css bearbeiten dürfen - im Mainwiki darf ich...

        In der common.css des Testwiki fehlt nämlich die Flexbox-Definition für den .flexcontainer, der für die Referenzvorlagen gebraucht wird. Deswegen kann ich meinen Vorschlag dort nicht abschließend testen.

        Das Problem mit den Leerzeilen kommt aus den Vorlagen. Wenn dort steht

        {{#if:{{{variable|}}}|
           Hier ist {{{variable}}}
        }}↵
        ↵
        {{if:...
        

        werden die Zeilenumbrüche ↵ außerhalb der Funktionsblöcke 1:1 mitgenommen.

        Aber auch hier entstehen Leerzeilen, wenn die Variablen leer sind:

        {{#if:{{{variable1|}}}|Hier ist {{{variable1}}}|}}↵
        {{#if:{{{variable2|}}}|Hier ist {{{variable2}}}|}}↵
        {{#if:{{{variable3|}}}|Hier ist {{{variable3}}}|}}↵
        {{#if:{{{variable4|}}}|Hier ist {{{variable4}}}|}}↵
        

        Die Leerzeilen unterliegen dann der weiteren Wikifizierung, z.B. der Paragraphenbildung oder dem Generieren von <br>.

        Die Lösung ist nicht, die Paragraphen auszublenden, sondern man darf sie gar nicht erst entstehen lassen.

        Zum Beispiel so:

        {{
        #if:{{{variable1|}}}|
           Hier ist {{{variable1}}}
        }}{{
        #if:{{{variable2|}}}|
           Hier ist {{{variable2}}}
        }}↵
        

        Oder so:

        {{#if:{{{variable1|}}}|
           Hier ist {{{variable1}}}
        }}<!--
        
        -->{{#if:{{{variable2|}}}|
           Hier ist {{{variable2}}}
        }}
        

        Zeilenumbrüche innerhalb der Templates und auch die Kommentare werden von der Template-Engine ignoriert bzw. entfernt.

        Und schon braucht man diesen br:only-child Würgherum nicht mehr. Da können wir z.B. nachher im Stammtisch drüber schnacken.

        Rolf

        --
        sumpsi - posui - obstruxi
        1. problematische Seite

          Servus!

          Hallo Matthias,

          so, jetzt hab ich das im Testwiki mal etwas beleuchtet. Ich würde dort gerne auch die common.css bearbeiten dürfen - im Mainwiki darf ich...

          Im Test-Wiki (jetzt) auch. BTW: Was ist ein SMW-Kurator?

          In der common.css des Testwiki fehlt nämlich die Flexbox-Definition für den .flexcontainer, der für die Referenzvorlagen gebraucht wird. Deswegen kann ich meinen Vorschlag dort nicht abschließend testen.

          Das Problem mit den Leerzeilen kommt aus den Vorlagen. Wenn dort steht

          {{#if:{{{variable|}}}|
             Hier ist {{{variable}}}
          }}↵
          ↵
          {{if:...
          

          werden die Zeilenumbrüche ↵ außerhalb der Funktionsblöcke 1:1 mitgenommen.

          Aber auch hier entstehen Leerzeilen, wenn die Variablen leer sind:

          {{#if:{{{variable1|}}}|Hier ist {{{variable1}}}|}}↵
          {{#if:{{{variable2|}}}|Hier ist {{{variable2}}}|}}↵
          {{#if:{{{variable3|}}}|Hier ist {{{variable3}}}|}}↵
          {{#if:{{{variable4|}}}|Hier ist {{{variable4}}}|}}↵
          

          Die Leerzeilen unterliegen dann der weiteren Wikifizierung, z.B. der Paragraphenbildung oder dem Generieren von <br>.

          Die Lösung ist nicht, die Paragraphen auszublenden, sondern man darf sie gar nicht erst entstehen lassen.

          Zum Beispiel so:

          {{
          #if:{{{variable1|}}}|
             Hier ist {{{variable1}}}
          }}{{
          #if:{{{variable2|}}}|
             Hier ist {{{variable2}}}
          }}↵
          

          Oder so:

          {{#if:{{{variable1|}}}|
             Hier ist {{{variable1}}}
          }}<!--
          
          -->{{#if:{{{variable2|}}}|
             Hier ist {{{variable2}}}
          }}
          

          Zeilenumbrüche innerhalb der Templates und auch die Kommentare werden von der Template-Engine ignoriert bzw. entfernt.

          Und schon braucht man diesen br:only-child Würgherum nicht mehr. Da können wir z.B. nachher im Stammtisch drüber schnacken.

          Perfekt! ich bin da!

          Herzliche Grüße

          Matthias Scharwies

          --
          Einfach mal was von der ToDo-Liste auf die Was-Solls-Liste setzen.“
        2. problematische Seite

          Hallo Rolf,

          Zeilenumbrüche innerhalb der Templates und auch die Kommentare werden von der Template-Engine ignoriert bzw. entfernt.

          Und das geschieht viel zu radikal - ich habe das CSS-Eigenschaften Template gerade geändert und erstmal gekotzt.

          }}{{
          #if: {{{Weblinks|}}}|
          ==Weblinks==
          {{{Weblinks}}}
          }}
          

          Irgendwie ist mir das heute nachmittag nicht aufgefallen - aber das funktioniert nicht. Der Block davor endet auf </div>, und das ==Weblinks== wird, wenn man das so macht, direkt da drangeklebt. Weil Mediawiki Whitespace bei Parametern gnadenlos entfernt. Die Folge: Es gibt keine Überschrift. Weil das == ja am Zeilenanfang stehen muss. Das ist schon ziemlich bescheuert vom Mediawiki. Man wollen sie Leerzeilen, und dann hindern sie einen daran, sie da, wo sie nötig sind, einzufügen.

          Ich hab (im Testwiki) eine {{LF}} Vorlage gemacht, die eine Leerzeile erzeugen sollte. Hahaha. Whitespace zu Beginn eines Includes wird ebenfalls gekillt.

          Aber so geht's - da muss man erstmal drauf kommen. Bin ich natürlich nicht, aber Tante Google hat's verpetzt.

          }}{{
          #if: {{{Weblinks|}}}|<nowiki />
          ==Weblinks==
          {{{Weblinks}}}
          }}
          

          Rolf

          --
          sumpsi - posui - obstruxi