Jeena Paradies: SELFHTML-Aktuell-Artikel - Benutzerfreundliche Viewportweiche oh

Hallo,

Vor ein paar Tagen wurde der Artikel Benutzerfreundliche Viewportweiche ohne Javascript veröffentlicht. Daraufhin gab es berechtigte Kritik in den Kommentaren des Weblogs.

Ich persönlich finde es ja so wie Dedlfix es da weiter unten gemacht hat vorbildlich, dass er seinen Artikel hier erst einmal reinstellt und Leute bittet ihn zu verbessern. Und wie man sieht gibt es genügend Leute die das freiwillig ohne sie dazu zwingen zu müssen tun.

So weit ich das sehe geschah das nicht beim oben genannten Artikel was ich sehr schade finde. Ich bin mir sehr sicher dass man da genau die Punkte, die Jens und Dirk in den Weblogkommentaren ansprechen ausgemerzt. Vielleicht wollen wir das gemeinsam nachholen?

Jeena

  1. Hallo,

    Ich persönlich finde es ja so wie Dedlfix es da weiter unten gemacht hat vorbildlich, dass er seinen Artikel hier erst einmal reinstellt und Leute bittet ihn zu verbessern. Und wie man sieht gibt es genügend Leute die das freiwillig ohne sie dazu zwingen zu müssen tun.

    So weit ich das sehe geschah das nicht beim oben genannten Artikel was ich sehr schade finde. Ich bin mir sehr sicher dass man da genau die Punkte, die Jens und Dirk in den Weblogkommentaren ansprechen ausgemerzt. Vielleicht wollen wir das gemeinsam nachholen?

    das würde ich persönlich für eine sehr gute Idee halten. Wobei ich eher der Meinung bin, dass man den Artikel am besten wieder ganz löschen sollte, denn mal abgesehen von dem bereits mehrfach kritisierten Quellcode, gibt es dafür imho eine klare Argumente.

    Wie ich in den letzten Jahren vorallem hier im Forum "gelernt" habe, sollte man vor der Verwendung einer "Technik" immer die Frage stellen:"Welchen Nutzen hat das für den User (oder für die Serverauslastung, den Traffic, etc.)?". Und wenn man auf diese Frage nicht mind. einen wirklichen Punkt nennen kann, dann sollte man besser auf den Einsatz dieser Technik verzichten.

    Die in dem Artikel vorgestellte "Technik" wird nach meinem Verständnis als "besserere Alternative" zu einer noch grausigeren Variante angepriesen. Letztlich läuft sie aber auf dasselbe Ziel/ Ergebnis hinaus. Und bei diesem stellt sich mir zumindest die Frage, ob dieses erstrebenswert ist, bzw. wer das wofür "brauchen" könnte (worauf der Artikel keine Antwort gibt).

    Letztlich ist das nichts anderes wie eine typische Eingangsseite, von denen man sich AFAIK bereits vor Jahren verabschiedet hat.

    Desweiteren frage ich mich, was einem die so gewonnene Information nutzt? Wie verfahre ich, sobald der User eine zweite Seite meines Webangebots besuchen möchte? Oder soll ich dann jeder meiner Seiten die Seite vorschalten? Und muss ich dann meine komplette Website doppelt, dreifach oder noch öfter für jede mögliche Auflösung vorhalten?

    Und wenn mir jetzt jemand auf die obige Frage anwortet:"Mit Sessions!", dann sollte man bedenken, dass es hier speziell um User mit deaktiviertem Javascript geht. Ob dann gerade diese Gruppe Cookies zulässt, ist dann auch noch die Frage.

    Jedenfalls habe ich den Eindruck, der Artikel lässt mich mit all diesen Fragen "im Regen" stehen.

    Außerdem sollte man imho auf SELFHTML eine möglichst "konsistente & gradlinige" Philosophie vertreten, und nicht auf einmal "Techniken" propagieren (alles was auf SELFHTML veröffentlicht wird, kann man imo so bezeichnen), die allen anderen zuwider laufen. Hier sei nur mal Molilys Artikel "Optimierung für Bildschirmauflösungen" genannt. Und nicht zuletzt natürlich auch die hier im Forum (zumindest mehrheitlich) vertretenen Meinungen & Ansichten.

    Mein Fazit:
    Nicht jede (neue oder alte) Idee ist auch eine gute Idee!
    Manche Ideen sollte man besser ungenutzt in der Schublade "verschwinden" lassen.

    Gruß Gunther

  2. So, dann fang ich mal an:

    Erstmal danke für die Idee an Jeena, das Ganze hier fortzuführen bzw neu zu starten, was ich gerne annehme.
    Und danke an den Verfasser des letzten Kommentars aus dem glücklicherweise nun gelöschten Weblog, dessen Alias ich nicht mehr weiß. Es ist tatsächlich so wie du sagst, das Ganze fühlte sich von Anfang an wie eine öffentliche Hinrichtung an, da kann einem schon ein bißchen mulmig werden...

    Vielleicht noch ein allgemeines Wort zum Artikel und seiner Vorgeschichte: Ich bin weiterhin von der Idee der javascriptlosen Viewportweiche überzeugt, habe mich aber ehrlich gesagt auch ein bißchen gewundert, wie relativ einfach es war, ihn bei einer Institution wie SELFHTML unterbringen zu können, und das beim ersten Versuch. Aber zumindest habe ich den Wert der Idee an sich bestätigt gesehen. Ich kann in dieser Frage Jens' Kritik bezüglich der "Zeitgemäßheit" zwar nachvollziehen, aber nicht teilen. Für die Frage "Unterbringung des Artikels - ob und wenn ja wo" wird sich sicher irgendeine Lösung finden, dazu sollte Sven sich vielleicht nochmal äußern.

    Dass diese offensichtlichen Fehler in den Beispielcodes passiert sind, ist mehr als peinlich und zum Teil durch Schludrigkeit geschuldet, teilweise aber auch durch Nichtwissen über Details wie z.B. dass die Angabe von alt in img-Tags obligatorisch ist. Die Entwicklung der letzten Jahre hin zu mehr Semantik habe ich wohl nicht ganz mitbekommen. Da aber HTML-Coding nur einen kleinen Teil meiner beruflichen Tätigkeit ausmacht, hoffe ich, dass man mir meine Patzer verzeihen kann.

    Was bei SELFHTML los war, kann ich natürlich nicht sagen, ich denke mal Arbeitsüberlastung zu einem ungünstigen Zeitpunkt. Vermutlich ist diese ganze verquere Situation aus einer Verkettung unglücklicher Umstände entstanden. Aber zum Glück haben wir es bei einem Artikel ja nicht mit einem AKW oder Flugzeug zu tun...

    o.k, damit es nicht gleich zu viel wird, poste ich hier erstmal noch einen Teil meiner letzten Antwort aus dem Weblog (leicht modifiziert):

    • fehlendes Doctype: spielt das für das Verständnis der Beispiele irgend eine Rolle?

    • weil die Pixelgrafiken nichtssagende, rein funktionelle Bilder sind, und ein alt-Attribut im IE als Tooltip interpretiert und angezeigt würde, was in diesem Falle störend wäre, hatte ich es kurzerhand ganz wegelassen. O.k, ich weiß jetzt auch, dass es Pflicht ist, also sollte es rein, wenn auch leer. HOffe nur, dass der IE ein leeres alt nicht als Tooltip anzeigt, was schon blöd wäre.

    • o.k., Inline-Styles sind ab einer gewissen Länge grundsätzlich nicht besonders überschaubar. Sie lassen sich falls nötig in eine CSS- Datei auslagern. Aber vielleicht reicht es, wenn man (zumindest im Codebeispiel im Artikel) die einzelnen styles durch Umbruch trennt? Die Kritik hieran war ja nur Unübersichtlichkeit.

    • was die Tabelle betrifft, gebe ich zu, dass ich unter Zeitdruck schnell ein Mittel brauchte, den einzigen Absatz möglichst auffällig in der Mitte zu platzieren. Und dabei habe ich ordentlich gepatzt und bin dann auch noch durch die Qualitätskontrolle gerutscht, warum auch immer. ... Allerdings ist mir noch immer nicht klar, warum zum Teufel man ein Tabelle nicht zu Gestaltungszwecken missbrauchen darf. Was ist denn erlaubt für meine Zwecke?

    Für weitere (konkrete) Kritik bezüglich des Codes wäre ich dankbar (der Weblog ist ja nicht mehr da, also kann ich nicht nachlesen), aber auch bezüglich des Artikels als solchem sowie der Idee. Oder dürfen hier nur Codes diskutiert werden?

    1. @@Martin Suhr:

      nuqneH

      • fehlendes Doctype: spielt das für das Verständnis der Beispiele irgend eine Rolle?

      Wie Jens in seinem Kommentar sagte: „SELFTHML ist nicht irgendeine Seite sondern eine Institution. Und gerade Anfänger nutzen diese Seite als Referenz und Startpunkt fürs eigene Lernen.“

      Darum geht es: Dass ein SELFHTML-Artikel es nicht falsch vormacht.

      • o.k., Inline-Styles sind ab einer gewissen Länge grundsätzlich nicht besonders überschaubar. Sie lassen sich falls nötig in eine CSS- Datei auslagern. Aber vielleicht reicht es, wenn man (zumindest im Codebeispiel im Artikel) die einzelnen styles durch Umbruch trennt? Die Kritik hieran war ja nur Unübersichtlichkeit.

      Es sollten keine Inline-Styles verwendet werden. Punkt. Darum geht es: Dass ein SELFHTML-Artikel es nicht falsch vormacht.

      Allerdings ist mir noch immer nicht klar, warum zum Teufel man ein Tabelle nicht zu Gestaltungszwecken missbrauchen darf.

      (1) Tabellen werden in verschiedenen Browsern mitunter unterschiedlich gerendert. Darstellungsprobleme vorprogrammiert.

      (2) Selbst wenn die einzelnen Abschnitte des Inhalts zwar optisch richtig plaziert sein mögen, wenn sie in einer unsinnigen Abfolge im Quelltext stehen, haben Nutzer mit Screenreadern Probleme, sie zu erfassen.

      (3) Flexible, sich an die Gegebenheiten beim Nutzer anpassende Layouts sind mit Tabellen nicht zu machen.

      Es sollten keine Tabeleen zum Layouten verwendet werden. Punkt. Darum geht es: Dass ein SELFHTML-Artikel es nicht falsch vormacht.

      Was ist denn erlaubt für meine Zwecke?

      Du möchtest SELFHTML noch einmal von Anfang an lesen? <http://de.selfhtml.org/html/text/index.htm@title=Elemente zur Textstrukturierung> ist ziemlich weit vorne.

      Qapla'

      --
      Bildung lässt sich nicht downloaden. (Günther Jauch)
      1. Hi there,

        Wie Jens in seinem Kommentar sagte: „SELFTHML ist nicht irgendeine Seite sondern eine Institution. Und gerade Anfänger nutzen diese Seite als Referenz und Startpunkt fürs eigene Lernen.“

        Darum geht es: Dass ein SELFHTML-Artikel es nicht falsch vormacht.

        Wie erklärst Du eigentlich den Anfängern, daß diese Institution mit Tabellen aufgebaut ist? (Nicht mir Gunnar, ich kann mir vorstellen, daß es eine Heidenarbeit wäre/ist, das alles noch dazu für Gottes Lohn umzuarbeiten, aber entscheidend ist doch, es funktioniert, oder?)

        Allerdings ist mir noch immer nicht klar, warum zum Teufel man ein Tabelle nicht zu Gestaltungszwecken missbrauchen darf.

        (1) Tabellen werden in verschiedenen Browsern mitunter unterschiedlich gerendert. Darstellungsprobleme vorprogrammiert.

        Ja. Und alle Browser, besonders die gaaanz weit verbreiteten, interpretieren alle CSS-Anweisungen besonders einheitlich also keine Darstellungsprobleme, oder wie darf man das verstehen?

        Es sollten keine Tabeleen zum Layouten verwendet werden. Punkt.

        Technisch geb' ich Dir ja weitgehend recht. Aber Dein (und nicht nur Dein) Zugang zu dem Thema zeigt mittlerweile dermaßen dogamtische Züge, das ist schon fast lächerlich und entgeht der Dramatik nur dadurch, indem es um etwas so Unwichtiges wie Webdesign geht...

        1. Yerf!

          Darum geht es: Dass ein SELFHTML-Artikel es nicht falsch vormacht.

          Wie erklärst Du eigentlich den Anfängern, daß diese Institution mit Tabellen aufgebaut ist? (Nicht mir Gunnar, ich kann mir vorstellen, daß es eine Heidenarbeit wäre/ist, das alles noch dazu für Gottes Lohn umzuarbeiten, aber entscheidend ist doch, es funktioniert, oder?)

          Man könnte es als Warnung ausdrücken: das Grundkonzept einer Seite später zu ändern ist ein riesiger Aufwand, deshalb sollte man sich vorher gut überlegen, welche Technik man einsetzt und eine möglichst moderne und zukunftsfähige wählen.

          (1) Tabellen werden in verschiedenen Browsern mitunter unterschiedlich gerendert. Darstellungsprobleme vorprogrammiert.

          Ja. Und alle Browser, besonders die gaaanz weit verbreiteten, interpretieren alle CSS-Anweisungen besonders einheitlich also keine Darstellungsprobleme, oder wie darf man das verstehen?

          Die Unterschiede beim CSS sind nicht so groß im Gegensatz zu dem, was man bei Tabellen erleben kann (ich gehe jetzt mal von halbwegs modernen Browsern aus, also ab IE6 im CSS-kompat Mode)

          Tabellen führen teilweise ein richtiges "Eigenleben", das einen sehr schnell im Wege steht sobald man etwas mehr als nur Kästchenlayout haben will, z.B. die minimalen Spaltenbreiten anhand des größten Wortes in der Zelle, egal was man für Overflow angibt oder die Probleme mit absoluter Positionierung innerhalb von Tabellenzellen.

          Dies betrifft übrigens auch das Verhalten von display:table-cell, wie ich merken musste, als ich damit ein Layoutproblem lösen wollte. Ergebnis: zusätzlich musste ich noch absolute Positionierung und ein Wrapper-Div einsetzen... keine schöne Lösung.

          Gruß,

          Harlequin

          --
          <!--[if lt IE 8]>This page is best viewed with a webbrowser. Get one today!<![endif]-->
        2. @@Klawischnigg:

          nuqneH

          Wie erklärst Du eigentlich den Anfängern, daß diese Institution mit Tabellen aufgebaut ist?

          Nun, die Doku ist dafür gedacht, dass _sie_ gelesen wird, nicht deren Quelltext. ;-)

          Anders sieht es bei den Beispielcodes (gelbe Kästen) in der Doku aus: Ich hoffe doch, das in den Beispielen kein Tabellenlayout propagiert wird.

          Aber Dein (und nicht nur Dein) Zugang zu dem Thema zeigt mittlerweile dermaßen dogamtische Züge

          Nicht nur zu _dem_ Thema. ;-) Ich denke, das Dogmatische daran entsteht in den Augen des Betrachters. Dadurch, dass die Stammleserschaft dasselbe immer und immer wieder zu lesen bekommt, dabei ist es doch aber für immer wieder andere Noobs bestimmt.

          entgeht der Dramatik nur dadurch, indem es um etwas so Unwichtiges wie Webdesign geht...

          Ach, in manchen Threads gibt’s ja schon fast Mord und Totschlag, da würde ich nicht sagen, dass dort Dramatik entgangen wäre. ;-)

          Qapla'

          --
          Bildung lässt sich nicht downloaden. (Günther Jauch)
      2. Deine Argumente gegen Tabellenlayout in allen Ehren, aber nun wurde hier eine Tabelle mit einer Zelle zur vertikalen Zentrierung eingesetzt. Das ist immer noch einer der robustestes Umsetzungen und hat auf Screenreader keinen negativen Einfluss - und eine sonderliche Flexibilität ist bei den alternativen CSS-Lösungen auch nicht unbedingt gegeben. Wenn die robust sein sollen, verwenden sie ironischerweise wieder display:table. Aber ansonsten ist dir natürlich recht zu geben.

        Mathias

        1. Wenn die robust sein sollen, verwenden sie ironischerweise wieder display:table. Aber ansonsten ist dir natürlich recht zu geben.

          Nicht zwangsläufig - es gibt auch eine andere robuste Lösung, die lediglich ein einzelnes zusätzliches, leeres div-Element benötigt und somit über wesentlich weniger Markup als die 1-Zellen-Tabelle verfügt.

    2. hi,

      • was die Tabelle betrifft, gebe ich zu, dass ich unter Zeitdruck schnell ein Mittel brauchte, den einzigen Absatz möglichst auffällig in der Mitte zu platzieren. Und dabei habe ich ordentlich gepatzt und bin dann auch noch durch die Qualitätskontrolle gerutscht, warum auch immer. ... Allerdings ist mir noch immer nicht klar, warum zum Teufel man ein Tabelle nicht zu Gestaltungszwecken missbrauchen darf. Was ist denn erlaubt für meine Zwecke?

      Hmm, ein Absatz? Der _ganze_ Artikel ist Tabellen-Layout, so wie SELFHTML auch (seit Jahren).

      Wenn Du das nicht möchtest, Du kannst Deinen Artikel gerne auf meiner Site veröffentlichen, in strict und ohne Tabellenlayout.

      Kurze Mail und ich richte einen Ordner Gastartikel ein.

      Viele Grüße,
      Horst Haselhuhn

  3. Ich muss mich meinen Vorrednern leider anschließen. Ich sehe da ehrlich gesagt wenig Verbesserungspotenzial - die kleinen Markup-Fehler sind unschön, aber die machen den Artikel nicht schwächer, als er ohnehin schon ist.

    Anpassungsfähige Layouts sind eine tolle Sache und im SELFHTML-Raum noch viel zu sehr gewürdigt. Z.B. mit Media Queries und Unobtrusive JavaScript stehen gute Techniken zur Verfügung, wie man ein und dasselbe Layout flexibel umformatieren kann. CSS hat diese Fähigkeiten, sie werden nur noch nicht genutzt.

    Nicht die Layouttabelle, nicht der DOCTYPE, nicht das alt-Attribut ist das Problem. Wie Dirk Jesse schreibt: »Das beschriebene "Problem" stellt sich in der Praxis eigentlich nicht. Für die Anpassung eines Layouts an die Viewportbreite nutzt man JavaScript bzw. CSS-Layouttechniken - einschließlich Fallback-Techniken, falls JS oder CSS nicht verfügbar sind.«

    Schon der erste Artikel von Christian Seiler war (bewusst) die richtige JS-Umsetzung einer konzeptionell fragwürdigen Idee. Es ist kontraproduktiv, mehrere separate Layouts für »Auflösungen« zu erstellen. Es ist nicht »benutzerfreundlich«, den Benutzer mit einer inhaltslosen Vorschaltseite zu nerven. Es ist kontraproduktiv, eine solche überhaupt zu haben - ob nun mit oder ohne JavaScript.

    Ich halte es für einen Rückschritt und für anachronistisch, einen solchen Artikel zu veröffentlichen. Bessere Techniken wurden schon vor vielen Jahren diskutiert. Es würde schon viel bringen, wenn man diese einfach mal in einem Artikel referieren, zusammenfassen und bewerten würde, sozusagen in einer erweiterten Linksammlung (bitte keine Liste à la Smashing Mag ;-)).

    Eine solche wissenschaftliche Herangehensweise, die erst einmal den »Forschungsstand« mit seinen Erkenntnissen beachtet, ist m.E. das Mindeste. In diesem Bewusstsein kann man gerne eine vernichtende Kritik entfalten und eine abseitige Lösung vorstellen, wenn man denn meint, sie mit guten Gründen verteidigen zu können.

    Mathias

    1. hi,

      dieser Thread hier verwundert mich ein bischen, Ihr stellt einen Artikel online und diskutiert hinterher? Gibt es denn keine Redaktion, die das vorher macht?

      Hotte

      1. dieser Thread hier verwundert mich ein bischen, Ihr stellt einen Artikel online und diskutiert hinterher?

        Ich bin nicht Mitglied der Redaktion, falls du das vermutest, und habe daher auch erst mit der Veröffentlichung darauf Zugriff bekommen.

        Mathias

        1. hi,

          Ich bin nicht Mitglied der Redaktion, falls du das vermutest, und habe daher auch erst mit der Veröffentlichung darauf Zugriff bekommen.

          ok, Mathias, wusste ich nicht. Unabhängig davon empfehle ich der Redaktion, solche Sachen im Vorab zu klären.

          Viele Grüße,
          Horst

          --
          Ist der Ruf erst ruiniert, lebt es sich ganz ungeniert.
    2. Hallo,

      Ich muss mich meinen Vorrednern leider anschließen.

      Ich muss nicht nur, ich kann es auch nicht.

      Ich halte es für einen Rückschritt und für anachronistisch, einen solchen Artikel zu veröffentlichen. Bessere Techniken wurden schon vor vielen Jahren diskutiert. Es würde schon viel bringen, wenn man diese einfach mal in einem Artikel referieren, zusammenfassen und bewerten würde, sozusagen in einer erweiterten Linksammlung (bitte keine Liste à la Smashing Mag ;-)).

      Ja. Aber welche der Kritiker macht das?
      Ich muss es, denke ich sehr deutlich Formulieren: sie haben einfach Schieß hier was zu veröffentlichen, weil sie wissen, dass ihr Werk genau so zerlegt wird, wie sie es mit den Werken anderer tun.
      "Keine Zeit", "Eigene HP, Blog etc." Nichts als faule Ausreden.
      Dass es geht - und ich meine damit hervorragende Artikel zu schreiben trotz "Beschäftigt sein", hast gerade du hier bewiesen.

      Viele der Kritiker haben sich einen sehr guten Namen erarbeitet, aber was ist jetzt? Blogs als kommentierte Linksammlungen ist wohl auch nicht das, was ich als "am Puls der Zeit" oder mit "mitten drinn" bezeichnen würde.

      Dem fraglichen Artikel kann man technisch sicherlich einiges "vorwerfen" aber aus einem anderen Winkel betrachtet ist er genau das wofür "wir" eigentlich stehen: Selbst im Web mitmachen. Und damit steht der Artikel so weit über seine Kritiker, wie weit diese sich über den Artikel zu stehen glauben.
      _Wir_ mögen dabei als Redaktion patzer gemacht haben, was die redaktionelle Arbeit an dem Artikel angeht (codevalidität). Aber auch das erlaubt es keinem in dem Raum zu kotzen und dann das als Kritik hinzustellen. Denn das mindeste was ich dann erwartet hätte, wäre:

      Eine solche wissenschaftliche Herangehensweise, die erst einmal den »Forschungsstand« mit seinen Erkenntnissen beachtet, ist m.E. das Mindeste. In diesem Bewusstsein kann man gerne eine vernichtende Kritik entfalten und eine abseitige Lösung vorstellen, wenn man denn meint, sie mit guten Gründen verteidigen zu können.

      ganz genau so etwas gewesen.

      Grüße
      Thomas

      1. Hallo Thomas!

        Aber welche der Kritiker macht das?

        Nunja, Jens Grochtdreis und Dirk Jesse, die sich in den Blogkommentaren gemeldet haben, beackern das Thema flexible und anpassungsfähige Layouts seit längerem in Artikeln in ihren Weblogs, in Zeitschriftenartikeln und auch Fachbüchern. Die daran anschließenden Diskussionen sind oft kontrovers.

        _Wir_ mögen dabei als Redaktion patzer gemacht haben, was die redaktionelle Arbeit an dem Artikel angeht (codevalidität). Aber auch das erlaubt es keinem in dem Raum zu kotzen und dann das als Kritik hinzustellen.

        Ich wüsste nicht, wer hier »in den Raum gekotzt hat«. Wenn das auf mich gemünzt war: Ich habe bisher tatsächlich nicht versucht, dem Artikel eine bessere Abhandlung zum Thema entgegen zu stellen. Ich habe eine Vorgehensweise skizziert, wie sie meiner Meinung nach sinnvoll scheint, wenn man sich produktiv mit dem Thema befassen will. Beziehungsweise was ich mir als Leser wünsche und was mich weiterbrächte. Ich sehe es nicht ein, dass das Äußern dieses Zieles, das Aufstellen gewisser Anforderungen gleich darauf hinauslaufen muss, es gänzlich selbst in die Hand zu nehmen - falls du das meintest.

        Ich habe hier übrigens der Redaktion keine Vorwürfe gemacht und die Validität interessiert mich wie gesagt am wenigsten. Ich halte lediglich die im Artikel vorgestellte Technik für nicht vorteilhaft gegenüber anderen einschlägigen, aber nicht erwähnten Techniken. Die vorgestellte hat schwerwiegende Nachteile, die eine bessere Lösung vermeiden sollte - das lässt sich sagen, auch ohne gleich eine konkrete, perfekte Alternative vorzustellen. (Was ich auch nicht kann, ohne den beschriebenen Weg zu gehen.)

        Dass ein Artikel als einseitig, fehlerhaft oder unausgegoren wahrgenommen wird, ist nun alles andere als ein Drama. Artikel und Autoren wachsen mit der Zeit. Es gibt wenige Artikel, die ich hier veröffentlicht habe, die ich nicht nach der Veröffentlichung noch einmal substantiell überarbeitet habe. Ich habe auch viel Schelte einstecken müssen, entweder weil ich mich in der Sache oder im Ton zu weit aus dem Fenster gelehnt habe. Aus Fehlern kann man lernen, Feedback lässt sich einpflegen und in der kritischen Diskussion kann man seinen Standpunkt revidieren und schärfen.

        Mathias

        1. Hallo Mathias,

          Nunja, Jens Grochtdreis und Dirk Jesse, die sich in den Blogkommentaren gemeldet haben, beackern das Thema flexible und anpassungsfähige Layouts seit längerem in Artikeln in ihren Weblogs, in Zeitschriftenartikeln und auch Fachbüchern. Die daran anschließenden Diskussionen sind oft kontrovers.

          "Wo anderes", das reicht _mir_ nicht!

          Ich wüsste nicht, wer hier »in den Raum gekotzt hat«. Wenn das auf mich gemünzt war:

          War nicht auf dich gemützt. Das war die Fortsetzung eines Beispiels, dessen ich mich im Blog bediente.

          Dass ein Artikel als einseitig, fehlerhaft oder unausgegoren wahrgenommen wird, [...]

          Wie gesagt, ich hätte/habe mit der auf dem Artikel bezogenen sachlichen Kritik keinerlei Probleme. Die Probleme hatte ich mit all dem, was wortgewaltig rund um ein wenig Sach-Kritik aufgetischt wurde.

          Grüße
          Thomas

      2. Ich muss es, denke ich sehr deutlich Formulieren: sie haben einfach Schieß hier was zu veröffentlichen, weil sie wissen, dass ihr Werk genau so zerlegt wird, wie sie es mit den Werken anderer tun.

        Nein, das denke ich nicht. Es liegt vermutlich eher an fehlender Motivation.

        wofür "wir" eigentlich stehen: Selbst im Web mitmachen.

        Ich finde, dafür wird der Nachwuchs hier viel zu wenig gefördert. Mal überspitzt gesagt: Das Forum blockt ab, wer/was nicht ins Schema passt. Das Blog läuft nebenher und wirkt nicht so, als wäre es scharf auf interessierte Mitschreiber. Und die Mitarbeit an der Doku erfordert irgendwelchen XML-SVN-Compile-Hinundher-Kram, der die Hürde für »normale« Nutzer recht hoch legt.

        Für mein Empfinden wird sogar so wenig kommuniziert, dass die Welt da draußen nicht den blassesten Schimmer hat, ob eigentlich eine Aktivität rund um SELFHTML stattfindet, oder ob das Ding schon längst tot ist. Ich weiß, es steht irgendwo im Wiki. Aber Kommunikation ist nunmal nicht, Dinge einfach irgendwo hinzuschreiben.

        Viele Grüße
        _Dirk

        1. habe d'ehre Schuer

          XML-SVN-Compile-Hinundher-Kram, der die Hürde für »normale« Nutzer recht hoch legt.

          offenbar. :(

          Wollte mir das SVN-Zeugs mal lokal auf den Mac laden und endete bei

          "OPTIONS of 'https://vms.selfhtml.org/anon-repos/selfhtml/trunk': Server certificate verification failed: issuer is not trusted (https://vms.selfhtml.org)"

          Offenbar braucht man noch ein anderes Zertifikat als bei https://redaktion.selfhtml.org/

          oder es liegt daran
          Voraussetzung Wiki  Subversion-1.4.x.pkg.zip von Martin Ott
          verfügbar nur Version 1.5.5

          man liest sich
          Wilhelm

          1. Moin!

            XML-SVN-Compile-Hinundher-Kram, der die Hürde für »normale« Nutzer recht hoch legt.

            offenbar. :(

            Tja, was soll ich sagen. Du folgst veralteten Informationen, was natürlich schlecht ist, aber wenigstens sagst du was, was natürlich wieder gut ist, weil wir dann die Infos aktualisieren können.

            Wollte mir das SVN-Zeugs mal lokal auf den Mac laden und endete bei

            "OPTIONS of 'https://vms.selfhtml.org/anon-repos/selfhtml/trunk': Server certificate verification failed: issuer is not trusted (https://vms.selfhtml.org)"

            Offenbar braucht man noch ein anderes Zertifikat als bei https://redaktion.selfhtml.org/

            Eigentlich nicht, ein Zertifikatsproblem wäre aber auch nur ein eher einmaliges Problem. Der tatsächliche Grund ist, dass du die falsche URL anzapfen willst.

            https://vms.selfhtml.org/repos/selfhtml/trunk/ ist korrekt (ich habs im Wiki auch schon korrigiert), Username und Passwort: "anonymous".

            oder es liegt daran
            Voraussetzung Wiki  Subversion-1.4.x.pkg.zip von Martin Ott
            verfügbar nur Version 1.5.5

            Nein, eigentlich nicht, obwohl ich das nicht ausschließen will. Auf dem Server sollte SVN in der aktuellen Version 1.6.x sein, die sollte zu älteren Clients aber eigentlich kompatibel sein. Sowieso ist es eine gute Idee, den Client aktuell zu halten.

            Aber wenn du weiterhin Probleme hast, trotz der korrigierten URL, sag bitte Bescheid.

            - Sven Rautenberg

            1. habe d'ehre Sven

              Aber wenn du weiterhin Probleme hast, trotz der korrigierten URL, sag bitte Bescheid.

              immer noch

              OPTIONS of 'https://vms.selfhtml.org/repos/selfhtml/trunk': Server certificate verification failed: issuer is not trusted (https://vms.selfhtml.org)

              installierte Programme

              SCPlugin-0.7.3q-SVN.1.5.6.dmg
              Subversion-1.5.5.pkg
              Mac OS X 10.5.7

              man liest sich
              Wilhelm

              1. Moin!

                Aber wenn du weiterhin Probleme hast, trotz der korrigierten URL, sag bitte Bescheid.

                immer noch

                OPTIONS of 'https://vms.selfhtml.org/repos/selfhtml/trunk': Server certificate verification failed: issuer is not trusted (https://vms.selfhtml.org)

                Danke für's Feedback.

                Für mich sieht es so aus, als ob die Mac-Software ein Problem mit unserem teuren SSL-Zertifikat von GoDaddy hat.

                Ich habe Requests von deiner IP im Logfile, die mit "Safari" ausgeführt wurden. Hattest du den Aufruf der URL auch im Browser probiert? Probier' mal die ganze URL - die HTTP-Authentifizierung geht mit "anonymous/anonymous" durch.

                https://vms.selfhtml.org/repos/selfhtml/trunk

                installierte Programme

                SCPlugin-0.7.3q-SVN.1.5.6.dmg
                Subversion-1.5.5.pkg
                Mac OS X 10.5.7

                Da ich leider keinen Mac habe, bin ich drauf angewiesen, dass irgendein anderer Mac-Nutzer das Problem bestätigt und ggf. auch an seiner Behebung mitwirkt. Wer kann helfen?

                - Sven Rautenberg

                1. Da ich leider keinen Mac habe, bin ich drauf angewiesen, dass irgendein anderer Mac-Nutzer das Problem bestätigt und ggf. auch an seiner Behebung mitwirkt. Wer kann helfen?

                  Ich nutze das SCPlugin nicht, deshalb kann ich leider nicht helfen. Mein Versions hat allerdings keine Probleme mit dem Zertifikat, ich komme problemlos ins SVN.

                  Viele Grüße
                  _Dirk

                2. habe d'ehre Sven

                  Ich habe Requests von deiner IP im Logfile, die mit "Safari" ausgeführt wurden. Hattest du den Aufruf der URL auch im Browser probiert? Probier' mal die ganze URL - die HTTP-Authentifizierung geht mit "anonymous/anonymous" durch.

                  https://vms.selfhtml.org/repos/selfhtml/trunk

                  Da kriege ich die Anzeige vom Directory. Ich werd mein Zeugs mal löschen und mich der Lösung von Dirk bedienen. :)

                  man liest sich
                  Wilhelm

                  1. und mich der Lösung von Dirk bedienen. :)

                    fragt brav nach dem Zertifikat und tut was es soll :)

                    man liest sich
                    Wilhelm

                    1. habe d'ehre Sven

                      jetzt bin ich völlig verwirrt :)

                      https://redaktion.selfhtml.org/ funktionierte immer, Zertifikat sollte eigentlich bekannt sein

                      Der im Wiki beschrieben Weg funktionierte nicht

                      Versions von Dirk funktionierte

                      und siehe da
                      jetzt geht auch der im Wiki beschriebene Weg

                      man liest sich
                      Wilhelm

                      1. Moin!

                        jetzt bin ich völlig verwirrt :)

                        Kann passieren.

                        https://redaktion.selfhtml.org/ funktionierte immer, Zertifikat sollte eigentlich bekannt sein

                        Wir hatten da vor einiger Zeit das kostenlose CACert-Zertifikat, welches in keinem Browser authentifiziert werden konnte und vor allem durch das Handling des Firefox 3 mit unbekannten Zertifikaten extrem hohe Hürden aufgebaut hat, gegen ein unverschämt teures neues Zertifikat ausgetauscht.

                        Der im Wiki beschrieben Weg funktionierte nicht

                        Wobei ich da ja ein wenig dran gedreht hatte.

                        Versions von Dirk funktionierte

                        und siehe da
                        jetzt geht auch der im Wiki beschriebene Weg

                        Vermutlich irgendein Hänger beim OS X. ;)

                        - Sven Rautenberg

              2. immer noch

                OPTIONS of 'https://vms.selfhtml.org/repos/selfhtml/trunk': Server certificate verification failed: issuer is not trusted (https://vms.selfhtml.org)

                Hast Du das Zertifikat mal manuell hinzugefügt und dauerhaft akzeptiert?
                http://docs.info.apple.com/article.html?path=Mac/10.4/de/mh1779.html (10.4, geht aber sicherlich ähnlich in 10.5)

                Viele Grüße
                _Dirk

            2. Hallo Sven,

              Auf dem Server sollte SVN in der aktuellen Version 1.6.x sein,

              Nein, da ist wegen dem Authentifizierungskrams (authz-User-Gruppen-Relationen in LDAP) noch 1.5.x drauf. Wollte ich in den naechsten Tagen aktualisieren.

              Viele Gruesse,
              Christian

  4. Hallo allerseits,

    wir haben den Artikel wieder zurückgezogen, nähere Informationen finden sich im verlinkten Weblog-Beitrag.

    Viele Grüße,
    Christian