Matthias Apsel: Entwurf CSS-Eigenschaftsreferenz

Om nah hoo pez nyeetz, alle!

unter http://wiki.selfhtml.org/wiki/Benutzer:Apsel/Entwurf_CCS_Eigenschaftsreferenz habe am Beispiel von font-family einen Entwurf für die Referenz der CSS-Eigenschaften im Wiki erstellt. Ich bitte um (vor allem inhaltliche) Meinungen.

Matthias

--
1/z ist kein Blatt Papier.

  1. hi,

    Om nah hoo pez nyeetz, alle!

    unter http://wiki.selfhtml.org/wiki/Benutzer:Apsel/Entwurf_CCS_Eigenschaftsreferenz habe am Beispiel von font-family einen Entwurf für die Referenz der CSS-Eigenschaften im Wiki erstellt. Ich bitte um (vor allem inhaltliche) Meinungen.

    Matthias

    Hi, ich würde es gut finden, wenn man, grade bei dem Beispiel, auf die Anführungszeichen (") bei Leerzeichen hinweisen würde. Das ist zwar für Fortgeschrittene klar, für Anfänger aber wesentlich und schnell zu übersehen.
    Eventuell auch gleich den Hinweis rein, dass es, in dem konkreten fall, aus CSS1 stammt. Manche Leute interessiert so was ja, da es wesentliche Grundinfos sind, für Browserkompatibilitäten.

    Sonnst aber gute Idee, so mit der Tabelle

    Gruß Niklas

    --
    Man muss nicht alles wissen, man sollte aber wissen, wo das nicht gewusste zu finden ist.
    1. Om nah hoo pez nyeetz, niklaskamenisch!

      Hi, ich würde es gut finden, wenn man, grade bei dem Beispiel, auf die Anführungszeichen (") bei Leerzeichen hinweisen würde. Das ist zwar für Fortgeschrittene klar, für Anfänger aber wesentlich und schnell zu übersehen.

      zusätzliche Zeile "Hinweis"?

      Eventuell auch gleich den Hinweis rein, dass es, in dem konkreten fall, aus CSS1 stammt. Manche Leute interessiert so was ja, da es wesentliche Grundinfos sind, für Browserkompatibilitäten.

      ist eigentlich drin (Zeile "Eigenschaft")

      Matthias

      --
      1/z ist kein Blatt Papier.

      1. gudn tach!

        [...] auf die Anführungszeichen (") bei Leerzeichen hinweisen [...]

        zusätzliche Zeile "Hinweis"?

        ja, oder nach alter selfhtml-manier: "Beachten Sie:" ;-)

        prost
        seth

        1. hi,

          gudn tach!

          [...] auf die Anführungszeichen (") bei Leerzeichen hinweisen [...]

          zusätzliche Zeile "Hinweis"?

          ja, oder nach alter selfhtml-manier: "Beachten Sie:" ;-)

          prost
          seth

          Das sieht gut aus, wobei man die icons mal überarbeiten müsste ;)
          Toll das du es direkt ausprobiert hast!

          Gruß Niklas

          --
          Man muss nicht alles wissen, man sollte aber wissen, wo das nicht gewusste zu finden ist.
  2. gudn tach!

    unter http://wiki.selfhtml.org/wiki/Benutzer:Apsel/Entwurf_CCS_Eigenschaftsreferenz habe am Beispiel von font-family einen Entwurf für die Referenz der CSS-Eigenschaften im Wiki erstellt. Ich bitte um (vor allem inhaltliche) Meinungen.

    "alle Elemente" sollte mit einer uebersicht ueber alle elemente verlinkt werden. gleiches gilt fuer "Vererbung".

    hmm, zur begriffswahl: bei "Voreinstellung" musste ich kurz ueberlegen, was gemeint ist. haette da "default" oder "Default-Wert" gestanden, haette ich es sofort verstanden. aber das mag auch mehr an mir liegen.

    dass ein beispiel dabei ist, finde ich sehr gut!

    wie wird die css-referenz spaeter dann mal eingebunden? bleibt es bei einer einzelnen seite oder wird das in eine laengere liste eingebettet?

    prost
    seth

    1. Hi,

      "alle Elemente" sollte mit einer uebersicht ueber alle elemente verlinkt werden.

      auf eine Übersicht aller Elemente aller möglichen Auszeichnungssprachen?

      cu,
      Andreas

      --
      Warum nennt sich Andreas hier MudGuard?
      O o ostern ...
      Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
      1. gudn tach!

        "alle Elemente" sollte mit einer uebersicht ueber alle elemente verlinkt werden.

        auf eine Übersicht aller Elemente aller möglichen Auszeichnungssprachen?

        :-) aeh, oder auf den glossar-eintrag "element"...

        jedenfalls ist die unterscheidung zwischen element, attribut etc. etwas, das man nicht voraussetzen sollte. mit den begriffen kommen selbst leute durcheinander, die schon html-erfahrung gesammelt haben.

        prost
        seth

    2. Om nah hoo pez nyeetz, seth!

      "alle Elemente" sollte mit einer uebersicht ueber alle elemente verlinkt werden. gleiches gilt fuer "Vererbung".

      Ich möchte einen deutlichen Unterschied zwischen Dokumentation und Referenz. Also vielleicht dort eher nicht zur Elementliste verweisen. Bei z-index beispielsweise kommt ja "positionierte Elemente" hin, da wäre ein Link zur Elementliste kontraproduktiv. Besser zum Glossar verlinken, wie du(?) an anderer Stelle geschrieben hast

      hmm, zur begriffswahl: bei "Voreinstellung" musste ich kurz ueberlegen, was gemeint ist. haette da "default" oder "Default-Wert" gestanden, haette ich es sofort verstanden. aber das mag auch mehr an mir liegen.

      deshalb ja die Diskussion ;-) In die Referenz könnte der Fachterminus, in der Doku habe ich meist "Voreinstellung" verwendet.

      wie wird die css-referenz spaeter dann mal eingebunden? bleibt es bei einer einzelnen seite oder wird das in eine laengere liste eingebettet?

      mMn mehrere längere Listen, wie jetzt auch.

      Matthias

      --
      1/z ist kein Blatt Papier.

      1. Hallo

        hmm, zur begriffswahl: bei "Voreinstellung" musste ich kurz ueberlegen, was gemeint ist. haette da "default" oder "Default-Wert" gestanden, haette ich es sofort verstanden. aber das mag auch mehr an mir liegen.

        deshalb ja die Diskussion ;-) In die Referenz könnte der Fachterminus, in der Doku habe ich meist "Voreinstellung" verwendet.

        "Voreinstellung" finde ich als Begriff nicht gelungen. Wie wäre es mit dem "Vorgabewert"? Einerseits ist das die passende Übersetzung des "default value", andererseits ist es gegenüber seths "Default-Wert" ein "vollständig" deutsches Wort.

        Tschö, Auge

        --
        Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
        Terry Pratchett, "Wachen! Wachen!"
        ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
        Veranstaltungsdatenbank Vdb 0.3
        1. gudn tach!

          "Voreinstellung" finde ich als Begriff nicht gelungen. Wie wäre es mit dem "Vorgabewert"? Einerseits ist das die passende Übersetzung des "default value", andererseits ist es gegenüber seths "Default-Wert" ein "vollständig" deutsches Wort.

          "default" ist auch ein deutsches wort. es steht sogar im duden. dass es urspruenglich aus den englischen kommt, macht es nicht schlechter oder weniger verstaendlich als eine deutsche entsprechung. zum vergleich: "oheim" waere auch die "vollstaendig" deutsche version des aus dem franzoesischen stammenden "onkel". trotzdem verstehen "oheim" wesentlich weniger leute als "onkel". man kann durchaus ueber gute/verstaendliche/... begriffe diskutieren. der grad an etymologischer deutschhaftigkeit ist jedoch von vernachlaessigbar geringer bedeutung.

          prost
          seth

          1. Hallo

            gudn tach!

            Um die Uhrzeit? ;-)

            "Voreinstellung" finde ich als Begriff nicht gelungen. Wie wäre es mit dem "Vorgabewert"? Einerseits ist das die passende Übersetzung des "default value", andererseits ist es gegenüber seths "Default-Wert" ein "vollständig" deutsches Wort.

            "default" ist auch ein deutsches wort. es steht sogar im duden. dass es urspruenglich aus den englischen kommt, macht es nicht schlechter oder weniger verstaendlich als eine deutsche entsprechung.

            Ob "default" im Duden steht oder nicht oder es mittlererweile ein allgemein verständliches Lehnwort ist, ist mMn unerheblich. In entsprechend interessierten Kreisen sollten wir auch davon ausgehen können, dass das Wort bekannt ist oder (jetzt mal ganz optimistisch) der Benutzer fähig ist, sich die Bedeutung mit Wörterbuch oder der Suchmaschine der Wahl zu erschließen.

            man kann durchaus ueber gute/verstaendliche/... begriffe diskutieren.

            Das, und nur das wollte ich anstoßen.

            der grad an etymologischer deutschhaftigkeit ist jedoch von vernachlaessigbar geringer bedeutung.

            An dieser Stelle kein Widerspruch von mir. Der verwendete Begriff – welcher es auch immer sei – sollte möglichst auf Anhieb verständlich sein. Das ist alles.

            Tschö, Auge

            --
            Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
            Terry Pratchett, "Wachen! Wachen!"
            ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
            Veranstaltungsdatenbank Vdb 0.3
            1. gudn tach!

              gudn tach!

              Um die Uhrzeit? ;-)

              na klar! :-)

              In entsprechend interessierten Kreisen sollten wir auch davon ausgehen können, dass [...]

              das hast du schoen gesagt. denn wir werden ja nicht nur fuer profis schreiben, und nicht nur fuer anfaenger. was man aber allen lesern unterstellen koennen muessen darf (aeh), ist das _interesse_. und da trifft dann genau das zu, was du sagtest.

              man kann durchaus ueber gute/verstaendliche/... begriffe diskutieren.

              Das, und nur das wollte ich anstoßen.

              ok, da war ich mir zunaechst nicht sicher. danke, dass du das klargestellt hast. :-)

              Der verwendete Begriff – welcher es auch immer sei – sollte möglichst auf Anhieb verständlich sein. Das ist alles.

              ganz genau.
              leider gibt es immer wieder leute, die bullshit-bingo spielen und andere, die (aus antipathie den erstgenannten gegenueber) fremdwoerter hassen, und dabei vergessen, dass es nicht um (sprach-)politik, sondern um verstaendlichkeit geht. wenn ich die ansaetze von sowas glaube zu sehen, werfe ich hin und wieder profylaktisch sowas wie meine antwort an dich in die runde.

              prost
              seth

  3. Hi,

    unter http://wiki.selfhtml.org/wiki/Benutzer:Apsel/Entwurf_CCS_Eigenschaftsreferenz habe am Beispiel von font-family einen Entwurf für die Referenz der CSS-Eigenschaften im Wiki erstellt. Ich bitte um (vor allem inhaltliche) Meinungen.

    Am Ende der Liste sollte immer eine der 5 generischen Schriftarten (serif, sans-serif, ...) stehen.
    Gehört m.E. noch in die Tabelle mit rein.

    cu,
    Andreas

    --
    Warum nennt sich Andreas hier MudGuard?
    O o ostern ...
    Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
    1. gudn tach!

      Am Ende der Liste sollte immer eine der 5 generischen Schriftarten (serif, sans-serif, ...) stehen.
      Gehört m.E. noch in die Tabelle mit rein.

      das geht schon fast in richtung best practise. wenn es also eine neue zeile "Hinweise" oder "Beachten Sie" gibt, dann koennte sowas noch in eine zusaetzliche zeile "Tipps" oder so. eine trennung hielte ich jedenfalls fuer sinnvoll.

      prost
      seth

      1. hi,

        gudn tach!

        Am Ende der Liste sollte immer eine der 5 generischen Schriftarten (serif, sans-serif, ...) stehen.
        Gehört m.E. noch in die Tabelle mit rein.

        das geht schon fast in richtung best practise. wenn es also eine neue zeile "Hinweise" oder "Beachten Sie" gibt, dann koennte sowas noch in eine zusaetzliche zeile "Tipps" oder so. eine trennung hielte ich jedenfalls fuer sinnvoll.

        Da stimme ich ihm voll zu, das wäre sehr sinnvoll, wobei man auf "Standart-Schriftart setzen sollte. ("Am Ende sollte ein Schriftart sein, die von allen gängigen OS unterstützt sind!)

        Gruß Niklas

        --
        Man muss nicht alles wissen, man sollte aber wissen, wo das nicht gewusste zu finden ist.
      2. Hi,

        gudn tach!

        Am Ende der Liste sollte immer eine der 5 generischen Schriftarten (serif, sans-serif, ...) stehen.
        Gehört m.E. noch in die Tabelle mit rein.

        das geht schon fast in richtung best practise.

        Wird auch im Standard schon dazu "ermutigt": "Style sheet designers are encouraged to offer a generic font family as a last alternative. ".

        cu,
        Andreas

        --
        Warum nennt sich Andreas hier MudGuard?
        O o ostern ...
        Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
      3. Am Ende der Liste sollte immer eine der 5 generischen Schriftarten (serif, sans-serif, ...) stehen.
        Gehört m.E. noch in die Tabelle mit rein.

        das geht schon fast in richtung best practise. wenn es also eine neue zeile "Hinweise" oder "Beachten Sie" gibt, dann koennte sowas noch in eine zusaetzliche zeile "Tipps" oder so. eine trennung hielte ich jedenfalls fuer sinnvoll.

        Was unterscheidet diese Referenz dann noch von den detaillierten Beschreibungsseiten? :)

        1. Om nah hoo pez nyeetz, suit!

          Was unterscheidet diese Referenz dann noch von den detaillierten Beschreibungsseiten?

          Bei solchen einfachen Eigenschaften ist der Unterschied sicher nicht so groß. Hier ist die Referenzseite die Zusammenfassung der Beschreibungsseite. Bei float etwa fällt der Unterschied deutlicher aus.

          Matthias

          --
          1/z ist kein Blatt Papier.

  4. [latex]Mae  govannen![/latex]

    Ich bitte um (vor allem inhaltliche) Meinungen.

    Habe vorerst nur was zum Aussehen:

    Ich würde es schön finden, wenn der Eigenschaftsname in der ziemlich dominanten Tabelle nicht so verloren ginge. Also entweder als Überschrift oberhalb der Tabelle oder bspw. mit entsprechend großer Schriftgröße innerhalb. Und dann auf jeden Fall auf gleicher Höhe mit dem Wort „Eigenschaft“ ausgerichtet.

    Und, wie gesagt ist die Tabelle doch sehr dominant. Vielleicht anders (offener, lockerer) stylen oder eine dl?

    Stur lächeln und winken, Männer!
    Kai

    P.S. Was zum Geier ist eine CCS Eigenschaftsreferenz? ;)

    --
    It all began when I went on a tour, hoping to find some furniture
     Followed a sign saying "Beautiful Chest", led to a lady who showed me her best)
    SelfHTML-Forum-Stylesheet
    1. Om nah hoo pez nyeetz, Kai345!

      P.S. Was zum Geier ist eine CCS Eigenschaftsreferenz? ;)

      Vielen Dank für die Hinweise.

      Ich habe jetzt die inhaltlichen Anmerkungen eingearbeitet. Es gibt jetzt zwei CCS-[sic!]-Varianten. Einmal mit der Eigenschaft als Überschrift und einmal faktisch mit der Beschreibung als Überschrift.

      * Variante 1
      * Variante 2

      schön kommt später, beispielsweise könnte man für "Beachten Sie" eine ähnliche Formatierung verwenden, wie auch jetzt bei "Beachten Sie" im Text.

      Matthias

      --
      1/z ist kein Blatt Papier.

      1. Tach!

        Ich habe jetzt die inhaltlichen Anmerkungen eingearbeitet. Es gibt jetzt zwei CCS-[sic!]-Varianten. Einmal mit der Eigenschaft als Überschrift und einmal faktisch mit der Beschreibung als Überschrift.

        Die Überschrift ergibt sich doch am Ende aus dem Seitentitel - jedenfalls dann, wenn du der Mediawiki-Philosophie folgst: "Jedes Lemma ist eine eigene Seite". Dann brauchst du keine zusätzliche H2-Überschrift, weil der Eigenschaftenname bereits in H1 steckt. Es wäre dann näher am Endergebnis, wenn du auch gleich die Seite à la .../CSS-Referenz-Entwurf/font-family benennen würdest.

        dedlfix.

        1. Om nah hoo pez nyeetz, dedlfix!

          Die Überschrift ergibt sich doch am Ende aus dem Seitentitel - jedenfalls dann, wenn du der Mediawiki-Philosophie folgst: "Jedes Lemma ist eine eigene Seite". Dann brauchst du keine zusätzliche H2-Überschrift, weil der Eigenschaftenname bereits in H1 steckt. Es wäre dann näher am Endergebnis, wenn du auch gleich die Seite à la .../CSS-Referenz-Entwurf/font-family benennen würdest.

          Das ist ja genau die Frage: Soll die Seite. ...Schriftart oder Font-family  heißen? Die Einzelseiten können dann in übergeordnete includiert werden.

          Matthias

          --
          1/z ist kein Blatt Papier.

          1. Tach!

            Das ist ja genau die Frage: Soll die Seite. ...Schriftart oder Font-family  heißen? Die Einzelseiten können dann in übergeordnete includiert werden.

            Für eine Referenz sollte der Originalname des dokumentierten Elements Verwendung finden und keine Umschreibung. Zielpublikum sind fortgeschrittene Anwender, die bereits den Namen kennen und nur noch ein paar Einzelheiten zu den erlaubten Werten etc. nachschlagen wollen.

            dedlfix.

            1. Om nah hoo pez nyeetz, dedlfix!

              Macht es Sinn, alle CSS-Versionen aufzuführen, in denen die Eigenschaft vorkommt? Wenn ja, bekomm ich das mit der Vorlage nicht gebacken. Ich müsste beispielsweise css1{{!}}css2 übergeben, damit sollte an entsrechender Stelle {{Iconset|css1|css2}} werden.

              Vorlage und Beispielseite im Test-Wiki

              Wie geht man mit Werten um, die später hinzugekommen sind?

              Matthias

              --
              1/z ist kein Blatt Papier.

        2. gudn tach!

          Die Überschrift ergibt sich doch am Ende aus dem Seitentitel - jedenfalls dann, wenn du der Mediawiki-Philosophie folgst: "Jedes Lemma ist eine eigene Seite". Dann brauchst du keine zusätzliche H2-Überschrift, [...]

          naja, das hoert sich fuer mich etwas zu pauschal an. im wiki sind durchaus ueberschriften auf verschiedenen niveaus vorgesehen. pro lemma ein artikel ist grundsaetzlich erst mal richtig. aber ein lemma muss ja nicht "font-familiy" oder (ums mal zu uebertreiben) "Tahoma" oder "5pt" heissen, sondern kann ja auch "Schriftformatierung" oder "Liste von CSS-Formatierungen" heissen.

          deswegen hatte ich ja in einem anderen thread auch danach gefragt, wie bzw. in was das ganze eingebettet werden soll.

          prost
          seth

          1. Tach!

            pro lemma ein artikel ist grundsaetzlich erst mal richtig. aber ein lemma muss ja nicht "font-familiy" oder (ums mal zu uebertreiben) "Tahoma" oder "5pt" heissen, sondern kann ja auch "Schriftformatierung" oder "Liste von CSS-Formatierungen" heissen.

            Die Referenz ist schon deutlich mehr ein stichwortbasierendes Nachschlagewert als der ausführliche Teil. Insofern sollte da schon ein Thema = eine Seite gelten. Ich sehe auch keinen Sinn in dieser Übertreibung, die bringt die Diskussion nicht voran. Für Zusammenfassungen kann man jedenfalls Zusammenfassungsseiten erstellen - als Linkliste oder auch mit Einbindung der Einzelseitentexte.

            Wenn du eine große Seite erstellst, dann musst du diese immer als Monolith betrachten [*]. Die Anwender müssen sie immer (wieder) vollständig laden, selbst wenn sie mittels Anker auf nur einen Abschnitt geleitet werden. Einzelseiten hingegen können auch einzeln verlinkt und aufgerufen werden. Zusätzlich kann man sie in andere Seiten einbetten, damit den Monolith emulieren und so ohne Verzicht auf die anderen die Vorteile einer großen Seite haben, beispielsweise die Suche innerhalb der gesamten Seite mittels der im Browser eingebauten Find-Funktion nutzen.

            [*] Ausnahme ist der im Gegensatz zum Lesen eher selte Bearbeitungsvorgang, bei dem man auch gezielt nur Abschnitte wählen kann.

            dedlfix.

            1. gudn tach!

              pro lemma ein artikel ist grundsaetzlich erst mal richtig. aber ein lemma muss ja nicht "font-familiy" oder (ums mal zu uebertreiben) "Tahoma" oder "5pt" heissen, sondern kann ja auch "Schriftformatierung" oder "Liste von CSS-Formatierungen" heissen.

              Die Referenz ist schon deutlich mehr ein stichwortbasierendes Nachschlagewert als der ausführliche Teil. Insofern sollte da schon ein Thema = eine Seite gelten.

              ja, schon. die frage ist halt, auf welcher stufe man das thema ansetzt.

              Ich sehe auch keinen Sinn in dieser Übertreibung, die bringt die Diskussion nicht voran.

              die sollte nur verdeutlichen, dass wikiseiten nicht winzig sein muessen und auch nicht sein sollen.

              Für Zusammenfassungen kann man jedenfalls Zusammenfassungsseiten erstellen - als Linkliste oder auch mit Einbindung der Einzelseitentexte.

              kommt auf verschiedene sachen an.

              Wenn du eine große Seite erstellst, dann musst du diese immer als Monolith betrachten [*]. Die Anwender müssen sie immer (wieder) vollständig laden, selbst wenn sie mittels Anker auf nur einen Abschnitt geleitet werden.

              das geht heutzutage in sekundenbruchteilen. viele wikipedia-artikel sind mehrere hundert kB gross. der groesste derzeit knapp 1MB. bei den ganz grossen merkt man dann auch einen gewissen kleinen geschw.-unterschied beim laden. aber bei <250kB-seiten ist das fast vernachlaessigbar. und wir koennen davon ausgehen, dass das internet kuenftig nicht wesentlich langsamer wird...

              Einzelseiten hingegen können auch einzeln verlinkt und aufgerufen werden. Zusätzlich kann man sie in andere Seiten einbetten, damit den Monolith emulieren und so ohne Verzicht auf die anderen die Vorteile einer großen Seite haben, beispielsweise die Suche innerhalb der gesamten Seite mittels der im Browser eingebauten Find-Funktion nutzen.

              aus erfahrung in der wikipedia kann ich sagen: viele kleine seiten lassen sich wesentlich schwerer warten als wenige groessere seiten. im self-wiki haben wir derzeit noch den luxus, dir globalen recent-changes beobachten zu koennen. das wird aber nicht zwangslaeufig so bleiben, sondern irgendwann werden sich die meisten nur noch mit der persoenlichen watchlist vergnuegen und dabei koennen dann sachen sehr leicht uebersehen werden.

              in unserem wiki sehe ich teilweise die tendenz und gefahr, zu viele, extrem kleine artikel und entsprechend viele uebersichtsseiten zu erstellen. das blaeht das ganze nur auf und vermittelt einem user (egal, ob leser oder autor) ein gefuehl von unuebersichtlichkeit. in selfhtml 8.1.2. gibt's teilweise sehr lange artikel, aber ich habe sich noch niemanden darueber beschweren hoeren/lesen, dass ihm die seiten zu lang waeren (auch wenn ich nicht abstreiten moechte, dass es vielleicht einzelnen leuten so gehen mag). dagegen habe ich persoenlich schon haeufig gemerkt, dass ich bei hilfe-seiten, die nur eine kleinigkeit erklaeren, erst mal nach dem kontext _suchen_ musste. ein beispiel dazu: auf http://perldoc.perl.org/functions/index.html erwarte ich eigentlich auch einen hinweis auf http://perldoc.perl.org/functions/rindex.html und eigentlich sind diese beiden funktionen so nah beieinander, dass man sie gleich am besten auf einer seite erklaeren sollte.

              was wir uns aber auf jeden fall mal ueberlegen koennten, ist, ob/wie wir zusaetzliche indexe auf die seiten klatschen. ich glaube, ich habe das auch schon mal irgendwo (auf einer der viel zu vielen meta-seiten) im wiki praezisiert. ein beispiel, wie so ein index aussehen kann, sieht man z.b. auf https://de.wikipedia.org/wiki/Hilfe:Poem (rechts der kasten).

              prost
              seth

              1. Tach!

                Ich sehe auch keinen Sinn in dieser Übertreibung, die bringt die Diskussion nicht voran.
                die sollte nur verdeutlichen, dass wikiseiten nicht winzig sein muessen und auch nicht sein sollen.

                Ich dachte, du schätzt deine Gesprächspartner für so intelligent ein, dass sie im Wesentlichen unsinnige Verkleinerungen erkennen. Einzelnen Werten eigene Seiten spendieren zu wollen wird sicher niemand forderen. Insofern könntest du auch bei Übertreibungen in einem einigermaßen sinnvollen Rahmen bleiben.

                aus erfahrung in der wikipedia kann ich sagen: viele kleine seiten lassen sich wesentlich schwerer warten als wenige groessere seiten.

                Wenn ich mal in die andere Richtung übertreiben darf, dann wäre quasi eine einzige Wikipedia-Seite mit allen Artikeln drauf am wartungsfreundlichsten. Bei Einheiten, die sich sinnvoll voneinander abgrenzen lassen, sehe ich nicht unbedingt pauschal den Bedarf, sie ständig gemeinsam warten zu müssen. Für Massenänderungen kann man einen Bot ensprechend programmieren.

                in unserem wiki sehe ich teilweise die tendenz und gefahr, zu viele, extrem kleine artikel und entsprechend viele uebersichtsseiten zu erstellen.

                Dann erheb bitte Einspruch in konkreten Fällen. Ich sehe weder die eine noch die andere Richtung als pauschal richtig an.

                dagegen habe ich persoenlich schon haeufig gemerkt, dass ich bei hilfe-seiten, die nur eine kleinigkeit erklaeren, erst mal nach dem kontext _suchen_ musste.

                Das ist ein inhaltliches Problem, wenn der Leser den Kontext nicht erkennen kann oder keinen gescheiten Einstieg ins Thema bekommt. Mit der Seitengröße hat das meines Erachtens nicht viel zu tun.

                ein beispiel dazu: auf http://perldoc.perl.org/functions/index.html erwarte ich eigentlich auch einen hinweis auf http://perldoc.perl.org/functions/rindex.html und eigentlich sind diese beiden funktionen so nah beieinander, dass man sie gleich am besten auf einer seite erklaeren sollte.

                Da fehlt also ein "See also", was ein inhaltliches Problem ist. Wenn beides auf einer Seite steht, hast du ein Verlinkungsproblem. Entweder .../index.html und .../index.html#rindex oder .../rindex.html als Weiterleitung auf .../index.html#rindex. Der erste Fall führt zu inkonsistenten Seitenbenennungen, weil es kein rindex.html gibt, die Umgehung des Problems mittels einer zusätzlichen Weiterleitungsseite ist auch nicht besser als zwei einzelne Seiten.

                was wir uns aber auf jeden fall mal ueberlegen koennten, ist, ob/wie wir zusaetzliche indexe auf die seiten klatschen [...] z.b. auf https://de.wikipedia.org/wiki/Hilfe:Poem (rechts der kasten).

                Ja, bin dafür, wenns dem Leser nutzt. Aber auch das steigert wieder beides, die Übersichtlichkeit und die Komplexität beim Warten.

                dedlfix.

                1. gudn tach!

                  Ich sehe auch keinen Sinn in dieser Übertreibung, die bringt die Diskussion nicht voran.
                  die sollte nur verdeutlichen, dass wikiseiten nicht winzig sein muessen und auch nicht sein sollen.

                  Ich dachte, du schätzt deine Gesprächspartner für so intelligent ein,

                  dich schon. aber hier lesen ja auch ganz viele andere leute mit. unter anderem vielleicht auch leute, die noch keine oder nur sehr wenig wiki-erfahrung haben.

                  und bei so relativen begriffen wie "gross" und "winzig" helfen einem (extreme) beispiele normalerweise zum verstaendnis.

                  Einzelnen Werten eigene Seiten spendieren zu wollen wird sicher niemand forderen.

                  hoffen wir's mal. aber ein paar faelle sind mir (und dir ja auch) schon aufgefallen, in denen die meinungen im wiki auseinandergingen.

                  aus erfahrung in der wikipedia kann ich sagen: viele kleine seiten lassen sich wesentlich schwerer warten als wenige groessere seiten.

                  Wenn ich mal in die andere Richtung übertreiben darf, dann wäre quasi eine einzige Wikipedia-Seite mit allen Artikeln drauf am wartungsfreundlichsten.

                  jein. es gibt, wie angedeutet, auch obere grenzen. ab derzeit etwa 1MB beginnt's schon langsam ungemuetlicher zu werden. (was aber auch nicht heissen soll, dass ich der meinung bin, dass man alle seiten auf etwa dieses maximum bringen sollte, bevor man splitting in erwaegung zieht.)

                  Bei Einheiten, die sich sinnvoll voneinander abgrenzen lassen, sehe ich nicht unbedingt pauschal den Bedarf, sie ständig gemeinsam warten zu müssen. Für Massenänderungen kann man einen Bot ensprechend programmieren.

                  es geht auch um kontrolle.
                  es passiert leicht, dass irgendjemand (egal, ob absichtlich oder im irrtum) auf irgendeiner unterseite ein paar sachen abaendert, sodass auf der seite anschliessend etwas falsches steht. je weniger leute dann eine solche tiefe unterseite auf ihrem radar haben, desto laenger dauert es im mittel, bis sowas bemerkt und behoben wird.
                  (und je mehr unterseiten es gibt, desto geringer ist normalerweise die anzahl der user pro seite, welche die seiten in ihren watchlists haben.)

                  in unserem wiki sehe ich teilweise die tendenz und gefahr, zu viele, extrem kleine artikel und entsprechend viele uebersichtsseiten zu erstellen.

                  Dann erheb bitte Einspruch in konkreten Fällen. Ich sehe weder die eine noch die andere Richtung als pauschal richtig an.

                  ja, pauschal kann/darf man das nicht beurteilen. aber man muss auch aufpassen, dass das nicht in strukturierungsanarchie ausartet.

                  dagegen habe ich persoenlich schon haeufig gemerkt, dass ich bei hilfe-seiten, die nur eine kleinigkeit erklaeren, erst mal nach dem kontext _suchen_ musste.

                  Das ist ein inhaltliches Problem, wenn der Leser den Kontext nicht erkennen kann oder keinen gescheiten Einstieg ins Thema bekommt. Mit der Seitengröße hat das meines Erachtens nicht viel zu tun.

                  darauf will ich ja hinaus. die seitengroesse sollte nicht als so wichtiges strukturierungskriterium herangezogen werden (mal abgesehen von den besagten seiten jenseits von 1MB). aaaber: die groesse laesst sich ja nicht voellig unabhaengig vom inhalt betrachten. ich fand bisher an selfhtml unter anderem so gut, dass man funktionalitaeten themenbezogen gruppiert auf (grossen) seiten gefunden hat und sehr gut stoebern konnte nach irgendwie verwandten funktionalitaeten. das wird schwieriger, wenn man sowas zerhackt.

                  ein beispiel dazu: auf http://perldoc.perl.org/functions/index.html erwarte ich eigentlich auch einen hinweis auf http://perldoc.perl.org/functions/rindex.html und eigentlich sind diese beiden funktionen so nah beieinander, dass man sie gleich am besten auf einer seite erklaeren sollte.

                  Da fehlt also ein "See also", was ein inhaltliches Problem ist.

                  richtig. wobei ich nicht nur ein "see also" moechte, sondern eben auch gleich die erklaerung, was das andere zeug so macht. und das moechte ich, ohne die seite wechseln zu muessen. wenn ich nur scrollen muss, verliere ich als user weniger die orientierung, weil ich die abschnitte aehnlich wie bei einem buch bildlich/geografisch ordnen kann und nicht im kopf die sitemap in teilen nachbilden muss. aber vielleicht bin ich da auch altmodisch?

                  Wenn beides auf einer Seite steht, hast du ein Verlinkungsproblem. Entweder .../index.html und .../index.html#rindex oder .../rindex.html als Weiterleitung auf .../index.html#rindex.

                  nein, das ist kein problem. bezogen auf unser wiki wuerden wir einen artikel [[Perl/Funktionen fuer Zeichenketten]] anlegen und zusaetzlich zwei redirects z.b. [[Perl/index]] und [[Perl/rindex]] (oder/und eine bks [[index]] und einen redirect [[rindex]]) auf die entsprechenden abschnitte.

                  was wir uns aber auf jeden fall mal ueberlegen koennten, ist, ob/wie wir zusaetzliche indexe auf die seiten klatschen [...] z.b. auf https://de.wikipedia.org/wiki/Hilfe:Poem (rechts der kasten).

                  Ja, bin dafür, wenns dem Leser nutzt.

                  da, das gilt es herauszufinden. meiner erfahrung nach helfen diese index-boxes den lesern sehr, vor allem wiki-newbies.

                  Aber auch das steigert wieder beides, die Übersichtlichkeit und die Komplexität beim Warten.

                  ja, definitiv. templates in wikitext sind bzgl. wartung fast so usability-unfreundlich wie deren namensvetter in c++. aber das ist etwas, das man zum glueck ganz gut vom eigentlich inhalt getrennt betrachten kann.

                  prost
                  seth

    2. Om nah hoo pez nyeetz, Kai345!

      Ich würde es schön finden, wenn der Eigenschaftsname in der ziemlich dominanten Tabelle nicht so verloren ginge. Also entweder als Überschrift oberhalb der Tabelle oder bspw. mit entsprechend großer Schriftgröße innerhalb. Und dann auf jeden Fall auf gleicher Höhe mit dem Wort „Eigenschaft“ ausgerichtet.

      http://wiki-test2.selfhtml.org/wiki/Referenz:CSS/Eigenschaft/font-family

      Und, wie gesagt ist die Tabelle doch sehr dominant. Vielleicht anders (offener, lockerer) stylen oder eine dl?

      Ma[ch|l] mal einen Vorschlag.

      Matthias

      --
      1/z ist kein Blatt Papier.

  5. Om nah hoo pez nyeetz, alle!

    neue Variante im Test-Wiki auf einer Vorlage beruhend.

    Jetzt sind auch CSS-Ideen gefragt.

    Matthias

    --
    1/z ist kein Blatt Papier.

  6. Om nah hoo pez nyeetz, alle!

    Ich möchte diesen Entwurf noch einmal hier zur Diskussion stellen.

    Matthias

    --
    1/z ist kein Blatt Papier.

    1. Hi,

      Ich möchte diesen Entwurf noch einmal hier zur Diskussion stellen.

      Mich stört hier, daß bei "Eigenschaft" nicht der Eigenschaftsname an erster Stelle steht.
      Das Icon, seit welcher Version von CSS die Eigenschaft bekannt ist, gehört m.E. da nicht hin.

      Das Icon gehört entweder in eine eigene Zeile, oder (platzsparender) ans rechte Ende der "Eigenschaft"-Zeile.
      Vielleicht auch näher an die Browser-Unterstützung, ggf. sogar in diese Zeile (die dann eine noch zu bestimmende andere Bezeichnung tragen müßte - ggf. einfach "Unterstützung").
      Als erstes Icon dann die CSS-Version, dann (mit einer kleinen Lücke dazwischen) die Browser-Symbole (die vermutlich dann auch eine Browser-Version bekommen?) ...

      Die Schriftartfamilien stehen irgendwie verloren außerhalb der Tabelle. Hm. Da weiß ich aber auch keine perfekte Lösung. Ggf. eine Zeile in der Tabelle "Schriftartfamilien" mit der Auflistung in der rechten Spalte.
      Ist dann halt eine Zeile, die nur bei font-family vorkommt.

      cu,
      Andreas

      --
      Warum nennt sich Andreas hier MudGuard?
      O o ostern ...
      Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
      1. Om nah hoo pez nyeetz, MudGuard!

        Als erstes Icon dann die CSS-Version, dann (mit einer kleinen Lücke dazwischen) die Browser-Symbole (die vermutlich dann auch eine Browser-Version bekommen?) ...

        Es gab dazu schon eine lange Diskussion, die ich jetzt aber nicht wiederfinde. Browsericon ohne Versionsnummer bedeutet: passt in allen relevanten Versionen.

        Matthias

        --
        1/z ist kein Blatt Papier.

        1. [latex]Mae  govannen![/latex]

          Als erstes Icon dann die CSS-Version, dann (mit einer kleinen Lücke dazwischen) die Browser-Symbole (die vermutlich dann auch eine Browser-Version bekommen?) ...

          Es gab dazu schon eine lange Diskussion, die ich jetzt aber nicht wiederfinde. Browsericon ohne Versionsnummer bedeutet: passt in allen relevanten Versionen.

          Was sind relevante Versionen? Da wohl so gut wie niemand ausschließlich für die jeweils aktuellste Browser-Version entwickelt, hat ein generisches Icon keinerlei Aussagekraft und man kann die Angabe der Browser-Unterstützung auch komplett weglassen.

          Stur lächeln und winken, Männer!
          Kai

          --
          It all began when I went on a tour, hoping to find some furniture
           Followed a sign saying "Beautiful Chest", led to a lady who showed me her best)
          SelfHTML-Forum-Stylesheet
          1. Om nah hoo pez nyeetz, Kai345!

            Was sind relevante Versionen? Da wohl so gut wie niemand ausschließlich für die jeweils aktuellste Browser-Version entwickelt, hat ein generisches Icon keinerlei Aussagekraft und man kann die Angabe der Browser-Unterstützung auch komplett weglassen.

            Ja, so ähnlich lief die Diskussion damals auch. Es kommt noch hinzu, dass Eigenschaften aus dem Standard verschwinden können und diese dann ab einer bestimmten Version nicht mehr unterstützt werden.

            Matthias

            --
            1/z ist kein Blatt Papier.

    2. Om nah hoo pez nyeetz, Matthias!

      Ich möchte diesen Entwurf noch einmal hier zur Diskussion stellen.

      Ich würde es sehr begrüßen, wenn die Kurzform(en) bei den entsprechenden Eigenschaften (also wo existent) noch dabei stünden.

      Im übrigen kann man natürlich auch immer mal bei anderen "abgucken" ... ;-)
      u.a. bei w3schools (nur im Bezug auf den inhaltlichen Aufbau der Referenz).
      So finde ich bspw. auch die Angabe der jeweiligen JavaScript Syntax sehr praktisch.

      Und die Frage ist natürlich die nach dem Aufwand, aber die Icons alleine bei der Browserunterstützung sind wenig bis gar nicht hilfreich. Auch hier kann man wieder bei anderen "abgucken" ... - siehe When can I use...
      Auf der anderen Seite muss man ja nicht bereits vorhandene Quellen im Prinzip kopieren - evt. reicht ja auch ein entsprechender Link!?

      Gruß Gunther

      1. Om nah hoo pez nyeetz, Gunther!

        Ich würde es sehr begrüßen, wenn die Kurzform(en) bei den entsprechenden Eigenschaften (also wo existent) noch dabei stünden.

        Du meinst zusammenfassende Eigenschaften, wie font oder border?

        Matthias

        --
        1/z ist kein Blatt Papier.

        1. Om nah hoo pez nyeetz, Matthias!

          Du meinst zusammenfassende Eigenschaften, wie font oder border?

          Ja, genau die meine ich. ;-)
          Manchmal sind einem einfach die deutschen Begriffe nicht so geläufig ...!
          "Kurznotation" ist glaube ich der richtige Begriff, oder einfach "shorthand properties".

          Gruß Gunther