bronkZ: Frames

0 140

Frames

bronkZ
  • html
  1. 0
    Andre
    1. 0
      Steel
  2. 0
    bronkZ
    1. 0
      Gunnar Bittersmann
      1. 0
        Patrick Andrieu
        1. 0
          Gunnar Bittersmann
          1. 0
            Patrick Andrieu
            1. 0

              deutsch Sprech - schwer Sprech

              Gunnar Bittersmann
              • sonstiges
              1. 0
                frankx
              2. 0

                untrennbare Zusammensetzungen laut Regelwerk

                Vinzenz Mai
                1. 0
                  Christian Seiler
                  1. 0
                    Vinzenz Mai
  3. 0
    frankx
    1. 0
      Cybaer
      1. 0
        Don P
        1. 0
          frankx
          1. 0
            Don P
            1. 0
              Cybaer
              1. 0
                Don P
                1. 0
                  Cybaer
                  1. 0
                    Don P
                    1. 0
                      Cybaer
                      1. 0
                        Don P
                        • menschelei
                        1. 0
                          Cybaer
            2. 0
              frankx
              1. 0
                Don P
                1. 0
                  frankx
                  1. 0
                    Don P
                    1. 0
                      frankx
                      1. 0
                        Don P
                        1. 0
                          frankx
                        2. 0
                          Cybaer
                2. 0
                  Cybaer
        2. 0
          Cybaer
          1. 0
            Don P
            1. 0
              Cybaer
      2. 0
        Gunnar Bittersmann
        1. 0
          Cybaer
      3. 0
        frankx
        1. 0
          Cybaer
          1. 0
            frankx
            1. 0
              Cybaer
              1. 0
                frankx
      4. 0

        Never ending story

        gary
        • menschelei
        1. 0
          Don P
          1. 0
            frankx
          2. 0

            interessanter Ansatz

            Vinzenz Mai
            • meinung
            1. 0
              frankx
              1. 0
                frankx
                1. 0
                  gary
                  1. 0
                    frankx
                2. 0
                  Cybaer
                  1. 0
                    frankx
                    1. 0
                      Cybaer
                      1. 0
                        frankx
                3. 0
                  Struppi
                  1. 0
                    frankx
                  2. 0
                    Cybaer
                    1. 0
                      frankx
                      1. 0
                        Cybaer
                        1. 0
                          Don P
                          1. 0
                            Cybaer
                        2. 0
                          frankx
                          1. 0
                            Cybaer
                    2. 0
                      Don P
                      1. 0
                        frankx
                        1. 0
                          Don P
                          1. 0
                            frankx
                          2. 0
                            frankx
                      2. 0
                        Cybaer
                    3. 0
                      Gunnar Bittersmann
                      1. 0
                        Cybaer
                  3. 0
                    frankx
                  4. 0

                    Archiveinträge

                    Cybaer
                    1. 0
                      frankx
                      1. 0
                        Cybaer
                        1. 0
                          frankx
                        2. 0
                          frankx
                          1. 0
                            Siramon
            2. 0
              molily
              1. 0
                Vinzenz Mai
                1. 0
                  frankx
              2. 0
                Don P
                1. 0
                  frankx
                  1. 1
                    molily
                    1. 0
                      frankx
                2. 0
                  Gunnar Bittersmann
                3. 2
                  molily
                  1. 0
                    Don P
                    1. 0
                      frankx
                      1. 0
                        Don P
                        • menschelei
                4. 0
                  Struppi
                  1. 0
                    Gunnar Bittersmann
                    1. 0
                      frankx
                      1. 0
                        Gunnar Bittersmann
                        1. 0
                          frankx
                          1. 0
                            molily
                            1. 0
                              frankx
                              1. 0
                                molily
                                1. 0
                                  frankx
                                  1. 0
                                    Detlef G.
                                    1. 0
                                      frankx
                                      1. 0
                                        Detlef G.
                                        1. 0
                                          frankx
                                          1. 1
                                            Detlef G.
                                            1. 0
                                              frankx
                                              1. 0
                                                Detlef G.
                          2. 0
                            Gunnar Bittersmann
                            1. 0
                              frankx
                        2. 0
                          molily
                5. 0
                  Cybaer
                  1. 0
                    frankx
                    1. 0
                      Cybaer
                      1. 0
                        frankx
                        1. 0
                          Cybaer
                  2. 1
                    molily
                    1. 0
                      Cybaer
                      1. 0
                        molily
                        1. 0
                          Cybaer
        2. 0
          Gunnar Bittersmann
        3. 0
          Cybaer
          1. 0
            Gunnar Bittersmann
            1. 0
              Cybaer
              1. 0
                Gunnar Bittersmann
                1. 0
                  Cybaer
                  1. 0
                    Orlando
                    1. 0
                      Cybaer
                      1. 0
                        Orlando
                2. 0
                  Gunnar Bittersmann
                  1. 0
                    frankx
                    1. 0
                      molily
                      1. 0
                        frankx
                        1. 0
                          Gunnar Bittersmann
                          1. 0
                            frankx
                        2. 0
                          molily
                          1. 0
                            frankx
                            1. 0
                              molily
                              1. 0

                                Its done. self goes frameless

                                frankx
                                • html
                              2. 0
                                molily

Guten Tag,

ich bin noch recht neu in diesem Gebiet und habe nun ein Problem das ich irgendwie schlecht lösen kann. Also, mommentan besteht meine Seite aus einer Tabelle, nun habe ich allerdings viele HTML Dokumente und wenn ich was ändern möchte muss ich das ja in allen machen was sehr viel Arbeit ist. Nun habe ich an Frames gedacht, habe mir hier auch schon die Anleitungen durchgelesen, nur kommen mir folgende fragen:

Kann ich in Tabellenzellen Frames anzeigen lassen?
Kann man überhaupt Frames mit einer Tabelle zusammen benutzen?
Kann man ein Frameset zentrieren, oder eine bestimmte größe(höhe, breite) in Pixeln festlegen?
Wie würdet ihr es in HTML machen?
Was würdet ihr mir raten?

Link zur Seite: www.djs4ever-online.de.vu

  1. Kann ich in Tabellenzellen Frames anzeigen lassen?

    Jain... Das geht nur mit Iframes...

    Kann man überhaupt Frames mit einer Tabelle zusammen benutzen?

    Dementsprechend Ja!

    Kann man ein Frameset zentrieren, oder eine bestimmte größe(höhe, breite) in Pixeln festlegen?

    Das Iframe kannst Du wie ein Bild in deinem Code beliebig platzieren und auch eine Höhe und Breite festlegen.

    Wie würdet ihr es in HTML machen?

    Ich würde es mit PHP, DIVs und Include umsetzen, das ist aber für einen Anfänger zu kompliziert.

    Was würdet ihr mir raten?

    Auf jemanden warten, der eine bessere Idee hat ;).

    1. Hi!

      Andre hat recht. Ist aber ja nu auch keine aussergewoehnliche frage, die hier zum ersten Mal gestellt wird... :)

      Hier was ich machen wuerde, wenn ich Du waere:
      Ich wuerde mir jemanden suchen (der ahnung hat und keine tabellen oder Frames benutzt, wo nicht noetig) der mir n Template fuer ein CMS baut, dass ich nutzen moechte. Bei der Auswahl des CMS kaeme ein schoen einfach zu installierendes XAMP auf meinem Rechner zum Einsatz, wo alle moeglichen CMS getestet werden, bis mir eines zusagt. Mit Template und CMS bewaffnet ginge es dann los, die Seite auf dem Server im Internet einzurichten. Viele Provider liefern aber ja auch schon ein oder gar mehrere CMS mit. Joomla is z.B. bei mir dabei. Nicht dass ich Joomla benutzen moechte. Aber das waere definitiv keine schlechte Wahl, wenn ich nicht nen eigenen Kopf haette.

      Tja. Was ich sonst noch empfehlen kann: SSI. Du lagerst einfach die oft veraenderten Teile deiner Seiten aus und fuegst diese Dateien (z.B. Navigation) einfach ber Server Side Includes in deine Dateien ein. Damit musst du nur noch je eine Datei aendern. Das ist eine passable Loesung, auch wenn sie nicht ganz zufriedenstellend ist. (Die Navigation ist halt immer gleich und man kann z.b. die aktuell gewaehlte Kategorie nicht anders darstellen ohne Javascript zu nutzen)

      Natuerlich ist es auch eine baruchbare Option, einen Editor zu verwenden der Includes beherrscht und daraus dann HTML Dateien erstellt und am besten von allein hochlaedt. Das koennen mittlerweile viele Tools. Man hat dann ein paar kleine Dateien die dann automatisch in jede Seite iengefuegt werden. Oft bekommt man mit seinem Webspace ja auch Tools wie GoLive oder so. Die koennen soetwas eigentlich alle.

      Naja. Meine Lieblingsloesung ist aber halt ein CMS. Und soetwas laesst man sich, wenn man keine Ahnung hat, genauso konfiguerieren wie ein Auto, dass man kauft. Die baut man ja auch nicht selbst. Ansonsten hat jedes CMS eigentlich ne nette Palette von kostenlosen Templates, wenn man nicht unbedingt was ganz eigenes will.

  2. Erstmal danke für die Antowrten :)

    Ein CMS kommt für mich erstmal nicht in frage da es mein ziel ist meine page selbst zu schreiben. Von SSI und Includes hab ich leider keine Ahnung ^^.

    Werde das mit den iframes nochma durch gehen :)

    1. Hello out there!

      Von SSI und Includes hab ich leider keine Ahnung ^^.

      Das lässt sich ja ändern. SELFHTML hilft, die FAQ auch.

      Includes sind einfacher zu erlernen und handzuhaben als Frames. Letztere sind bringen dem Nutzer der Website massive Probleme und sind deshalb NICHT zur Aufteilung einer Webseite in Bereiche einzusetzen!

      Werde das mit den iframes nochma durch gehen :)

      Nicht ':)', sondern ':('. Beschäftige dich lieber mit was Sinnvollem, da hast du mehr davon - und vor allem die Nutzer deiner Seiten.

      See ya up the road,
      Gunnar

      --
      „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
      1. Hallo Gunnar!

        Includes sind einfacher zu erlernen und handzuhaben als Frames.

        Stimme ich voll zu. Bei SSI sollte man sich allerdings bei seinem Webhoster erkundigen, ob diese überhaupt angeboten werden.

        Aber »handzuhaben«... ist es noch richtiges neurechtgeschriebenes Deutsch? Ich kann nur vermuten, dass Du unter Stress stehst:

        Letztere sind bringen dem Nutzer der Website

        ^^^^^^^^^^^^

        *SCNR*

        Viele Grüße aus Frankfurt/Main,
        Patrick

        --

        _ - jenseits vom delirium - _
        [link:hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash]
        Nichts ist unmöglich? Doch!
        Heute schon gegökt?
        1. Hello out there!

          Bei SSI sollte man sich allerdings bei seinem Webhoster erkundigen, ob diese überhaupt angeboten werden.

          Und das am besten, bevor man mit diesem Hoster einen Vertrag eingeht. Bei negativer Antwort ist die Frage, ob man mit diesem Hoster einen Vertrag eingeht.

          Aber »handzuhaben«... ist es noch richtiges neurechtgeschriebenes Deutsch?

          Das hoffe ich doch. Infinitiv: "handhaben"; Infinitiv mit zu: "handzuhaben".

          Letztere sind bringen dem Nutzer der Website

          Das allerdings nicht.

          See ya up the road,
          Gunnar

          --
          „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
          1. Hallo Gunnar!

            Infinitiv: "handhaben"; Infinitiv mit zu: "handzuhaben".

            Definitiv? Intuitiv würde ich zu »zu handhaben« tendieren. Aber Sprachgefühl ist relativ, wenn man nicht german native ist ;)

            Viele Grüße aus Frankfurt/Main,
            Patrick

            --

            _ - jenseits vom delirium - _
            [link:hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash]
            Nichts ist unmöglich? Doch!
            Heute schon gegökt?
            1. Hello out there!

              Infinitiv: "handhaben"; Infinitiv mit zu: "handzuhaben".

              Definitiv? Intuitiv würde ich zu »zu handhaben« tendieren.

              Hört sich auch gut an. Hab die Regel jetzt nicht parat, bei welchen zusammengesetzen Verben das "zu" eingeschoben wird und bei welchen nicht. Vielleicht ist hier auch beides möglich.

              Hab mal das Thema geändert, um die Spezialisten anzulocken ...

              See ya up the road,
              Gunnar

              --
              „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
              1. Hellihello Zsammen,

                Hab mal das Thema geändert, um die Spezialisten anzulocken ...

                Nur leider mit geplenktem Deppenleerzeichen. Es müsste doch deuschSprech = schwerSprech heißen.

                http://por.proz.com/kudoz/492235

                Dank und Gruß,

                frankx

              2. Hallo

                Infinitiv: "handhaben"; Infinitiv mit zu: "handzuhaben".

                Definitiv? Intuitiv würde ich zu »zu handhaben« tendieren.

                Hört sich auch gut an. Hab die Regel jetzt nicht parat, bei welchen zusammengesetzen Verben das "zu" eingeschoben wird und bei welchen nicht. Vielleicht ist hier auch beides möglich.

                hilft http://www.deutsche-rechtschreibung.de/regelwerk.pdf#page=34 [1] weiter?

                "zu handhaben" sollte danach richtig sein.

                Freundliche Grüße

                Vinzenz

                [1] Kennst Du eine HTML-Quelle, damit ich noch benutzerfreundlicher
                    verlinken kann?

                1. Hallo Vinzenz,

                  [1] Kennst Du eine HTML-Quelle, damit ich noch benutzerfreundlicher
                      verlinken kann?

                  Die Version im Google-Cache wäre eine Möglichkeit...

                  Viele Grüße,
                  Christian

                  1. Hallo Christian,

                    [1] Kennst Du eine HTML-Quelle, damit ich noch benutzerfreundlicher
                        verlinken kann?

                    Die Version im Google-Cache wäre eine Möglichkeit...

                    eine lustige Idee. Trotz übelstem HTML über 25% kleiner :-)
                    Ich glaube, ich werde doch dabei bleiben, das PDF zu verlinken.

                    Freundliche Grüße

                    Vinzenz

  3. Hellihello bronkZ

    der Gunnar und ich diskutieren so gern über Frames:

    https://forum.selfhtml.org/?t=161540&m=1050938

    Ich bin nämlich der Ansicht, dass Frames auch Anfängern ein gutes Verständnis vermitteln können. Wenn Dein Hang, sich bei Suchmaschinen anzubiedern mäßig ist oder Du glaubst, dass Google mittlerweile auch herausfinden kann, was innerhalb eines Framesets steht, oder Du irgendwann rausbekommst, wie der no-Frame-Bereich sinnvoll nutzbar ist, du nicht zu sehr mit Direktverweisen auf Deine Untersteiten rechnest und/oder den Einbau eines kleinen Javascripts in die Navi nicht scheust, Du die Frames obendrein noch sinnvoll benennst, dann hat Gunnar als bekennender Frames-Hasser kaum noch echte Argumente (;-).

    Es gibt übrigens bereits ein Ticket hab ich gelesen, dass den SELFHTML-eigenen Artikel zu Frames zur Überarbeitung schickt.

    Valide sind sie allemal, nicht mal deprecated beim W3C und barrierefrei lassen sie sich auch gestalten. Zudem sind sie aus meiner Sicht u.U. sogar syntaktisch korrekter. Kleiner Spass hierzu noch: http://vergessichnicht.de/zu_Frames - auch unter o.g. Link zu finden.

    Dank und Gruß,

    frankx

    1. Hi,

      Wenn Dein Hang, sich bei Suchmaschinen anzubiedern mäßig ist

      Komisch. Meine Coding-Site ist ja eine Frames-Site und die Seiten sind bei relevanten Suchbegriffen (mitunter auch weniger relevanten) typischerweise auf der 1. Ergebnisseite von Google (mitunter auf Platz 1, oder auch einfach nur vor SELFHTML). Also das anbiedern klappt dann wohl auch ganz gut mit Frames ... :))

      Gruß, Cybaer

      PS: Die von Gunnar (dem No-Frames-Taliban) standardmäßig verlinkte Subotnik-Seite, ist inhaltlich ohnehin ziemlicher Stuß ...

      --
      Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
      1. Hallo,

        Komisch. Meine Coding-Site ist ja eine Frames-Site und die Seiten sind bei relevanten Suchbegriffen (mitunter auch weniger relevanten) typischerweise auf der 1. Ergebnisseite von Google [...]

        Google hat nicht wirklich ein Problem mit Frames, aber eine Unterseite deiner angemeldeten Startseite wird automatisch weniger gut bewertet, als wenn der Suchbegriff direkt auf deiner Startseite stehen würde. Du verschenkst also durch das für Google sonst nichtssagende Fameset als Startseite ein wenig vom möglichen Ranking. Das gilt entsprechend für jede weitere Unterebene, die der Google-Bot durchforstet.

        Gruß, Don P

        1. Hellihello DonP

          Google hat nicht wirklich ein Problem mit Frames, aber eine Unterseite deiner angemeldeten Startseite wird automatisch weniger gut bewertet, als wenn der Suchbegriff direkt auf deiner Startseite stehen würde. Du verschenkst also durch das für Google sonst nichtssagende Fameset als Startseite ein wenig vom möglichen Ranking. Das gilt entsprechend für jede weitere Unterebene, die der Google-Bot durchforstet.

          Du bist Dir sicher, dass Du weißt, wie Google sein Ranking wirklich macht? Und Google kann kein Javascript und weiß im Grunde auch nicht was ein Frameset ist und geht deshalb unbeirrt seit Jahr und Tag mit einem irgendwann mal entwickelten Standardalgrohythmus durch?

          Dank und Gruß,

          frankx

          1. Hallo,

            Du bist Dir sicher, dass Du weißt, wie Google sein Ranking wirklich macht?

            Natürlich nicht, aber diese Info habe ich im Vertrauen von professionellen Suchmaschinenoptimierern erfahren, die durch viel Experimentieren über Jahre so in etwa eine gute Ahnung haben, wie Google sein Ranking zur Zeit macht.

            Und Google kann kein Javascript und weiß im Grunde auch nicht was ein Frameset ist und geht deshalb unbeirrt seit Jahr und Tag mit einem irgendwann mal entwickelten Standardalgrohythmus durch?

            Reiner Blödsinn. Habe ich das denn behauptet?

            Gruß, Don P

            1. Hi,

              Natürlich nicht, aber diese Info habe ich im Vertrauen von professionellen Suchmaschinenoptimierern erfahren,

              Wow.

              Ich würde mich als professionellen SEO bezeichnen (ist halt ein Teil des Webdesigns - jedenfalls wenn man es IMHO "richtig" machen will) und bin von daher nicht auf Infos und Erfahrungen aus dritter Hand angewiesen. ;->

              Gruß, Cybaer

              --
              Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
              1. Hallo,

                Ich würde mich als professionellen SEO bezeichnen

                Ach so, da habe ich dich vielleicht aus Versehen in deiner Ehre gekränkt, wenn ich dir sage, dass du evtl. etwas vom Ranking verschenkst. Das war natürlich nicht meine Absicht. Und wie ich sehe, hast du ja auch ein paar Gegenmaßnahmen auf der Startseite unternommen. Recht so, großer SuMa-Guru.

                Gruß, Don P

                1. Hi,

                  Ach so, da habe ich dich vielleicht aus Versehen in deiner Ehre gekränkt, wenn ich dir sage, dass du evtl. etwas vom Ranking verschenkst.

                  Wie kommst Du auf die haarsträubende Idee, daß Du mich in meiner Ehre kränken könntest? =:-)

                  Ich möchte nur darauf hinweisen, daß hier mal wieder ein Nonsens-Argument gegen Frames herhalten muß ...

                  Gruß, Cybaer

                  --
                  Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                  1. Hallo,

                    Wie kommst Du auf die haarsträubende Idee, daß Du mich in meiner Ehre kränken könntest? =:-)

                    Weil du mit

                    das deutet (zumindest bislang) eher darauf hin, daß irgendwas sagst, ohne zu wissen, worüber Du redest. (Sorry, klingt jetzt härter, als es persönlich gemeint ist. ;-) Inhaltlich aber noch viel zu sanft. >;->)

                    ziemlich schroff reagiert und mir nahelegelegt hast, gefälligst keine Spekulationen über "insbesondere" deine Startseite anzustellen. "Härter als persönlich gemeint" ist immerhin noch persönlich gemeint. Daraus kann man doch schließen, dass du dich persönlich angegriffen fühlst, z.B. als Optimierer in der Ehre gekränkt oder sonstwie...

                    Nonsens-Argument gegen Frames

                    Deine Meinung sei dir unbenommen. Ich bleibe bei meiner.

                    Gruß, Don P

                    1. Hi,

                      Daraus kann man doch schließen, dass du dich persönlich angegriffen fühlst,

                      Ähm, daraus kann man schließen, daß Du persönlich AFAIK Nonsens verbreitest, der einer Korrektur bedarf, damit er nicht unwidersprochen stehenbleibt.

                      z.B. als Optimierer in der Ehre gekränkt oder sonstwie...

                      Ach, das weiß hier ja eh kaum einer. :-) Zumal ich mich zum Thema SEO hier auch kaum äußere.

                      Nonsens-Argument gegen Frames
                      Deine Meinung sei dir unbenommen. Ich bleibe bei meiner.

                      Immer wieder erstaunlich, wie gerne Menschen bei unfundierten Meinungen bleiben ... >:->

                      Gruß, Cybaer

                      --
                      Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                      1. Hallo,

                        Immer wieder erstaunlich, wie gerne Menschen bei unfundierten Meinungen bleiben ... >:->

                        Ja, und auch wie gerne Menschen andere Meinungen einfach als unfundiert abkanzeln, die ihnen nicht zusagen.

                        Zum Thema unfuniert fällt mir gerade folgendes Experiment ein:

                        Fünf Affen leben in einem Käfig, in dessen Mitte sich eine Leiter befindet, über der eine Banane aufgehängt ist.

                        Sobald ein Affe anfängt, die Leiter zu erklimmen, um an die Banane zu kommen, spritzt ihn der aufmerksame Tierpfleger mit kaltem Wasser ab, was dem Affen sehr missfällt, so dass er sein Vorhaben aufgibt. Nach ein paar Versuchen der Affen ist jedem klar, dass es keine gute Idee ist, diese Banane holen zu wollen.

                        Nun tauscht man einen Affen aus, gegen einen neuen. Der hat natürlich keine Ahnung von der besonderen Bedeutung der Banane und will zunächst auf die Leiter klettern. Der Tierpfleger hat jetzt aber nichts mehr zu tun, denn die anderen vier Affen halten den Neuen stets vehement davon ab, bis auch der begriffen hat, dass es keine gute Idee ist, diese Banane zu holen.

                        Tauscht man einen weiteren Affen aus, passiert dasselbe usw. bis alle fünf Affen ausgetauscht sind. Von der fünf neuen Affen weiß schließlich keiner mehr, warum die Banane ursprünglich nicht geholt werden sollte, trotzdem wird kein Versuch mehr unternommen.

                        Bin mir nicht sicher, ob das Experiment wirklich so durchgeführt wurde bzw. überhaupt funktionieren würde, aber es hat was. Z.B. vertößt es noch heute für manche Menschen gegen die guten Tischsitten, Kartoffeln mit dem Messer zu schneiden. Der Grund ist meines Wissens, dass man früher in wohlhabender Gesellschaft Siberbesteck benutzte, das bei gewissen Nahrungsmitteln zu einer  wenig schmackhaften chemischen Reaktion führte. Aber kaum jemand benutzt heute noch Silberbesteck, wo es doch schon lange rostfreien Stahl gibt. Wozu also diese überholte Tischsitte? Ist doch irgendwie unfundiert bzw. sinnlos geworden.

                        Zurück zur SEO: Vielleicht ist ja hier deine Meinung die unfundierte, weil du neuere Erkenntnise einfach nicht akzeptieren willst?

                        Gruß, Don P

                        1. Hi,

                          Zurück zur SEO: Vielleicht ist ja hier deine Meinung die unfundierte, weil du neuere Erkenntnise einfach nicht akzeptieren willst?

                          Da habe ich so meine Zweifel. :-)

                          Ich habe SEO betrieben, als es Google (und Frames) noch gar nicht gab, und habe mich seitdem nicht abgekapselt, sondern das Verhalten div. SE (und die Meinungen div. SEOs - sofern öffentlich verfügbar) ständig im Auge. Das ist nicht nur Beruf, sondern auch Hobby. :-)) (vom ständigen Austausch mit den Kollegen und Experimenten mal ganz zu schweigen.)

                          Ich vermute eher, daß dein SEO-Kumpel wenig Erfahrung mit Frame-Umsetzungen hat - zumal mit SE-optimierten ...

                          ... ist ja nicht so, daß man mit einer "schlechten" Frame-Umsetzung (wie auch generell "schlechtem" HTML, etc.) im Ergebnis eine, auch im Sinne der SEs, weniger optimale Website hinbasteln kann. Und mir scheint das allg. Wissen um (auch in diesem Sinne) "guten" Frame-Umsetzung nicht sonderlich ausgeprägt.

                          Dazu (und zu der "Schroffheit") noch die Bemerkung: Wenn Du davon ausgehst, und dabei  mich direkt ansprichst ("deine Startseite"), daß bei Frames irgendwas verschenkt wird, dann kann ich nur feststellen, daß Du a) standardmäßig wohl von einer "schlechten" Frame-Umsetzung ausgehst und b) einfach ins Blaue hineinredest, ohne vorher mal nachzuschauen, ob das denn auch konkret zutrifft. Das ist ein Niveau, wie ich es hier nicht erwarte. Wenn ich eine Meinung habe, und jemand anderes hier sagt, sieh doch, Du irrst, dann *überprüfe* ich das *bevor* ich mich weiter dazu auslasse. :-o

                          Nach der Zurechtweisung lapidar von "Gegenmaßnahmen" die ich getroffen hätte zu reden, verwundert mich dann auch. Ist für mich so, als wenn jemand gewohnt wäre, seine Überschriften mit <div style="font-size:120%; font-weight:bold;"> auszuzeichnen, und dann "überrascht" von "Gegenmaßnahmen" spricht, nur weil man ihn drauf hinweist, daß Suchmaschinen doch eher <h1> mögen (was man auch *selbstverständlich* verwendet). =:->

                          Gruß, Cybaer

                          --
                          Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
            2. Hellihello DonP

              Hallo,

              Du bist Dir sicher, dass Du weißt, wie Google sein Ranking wirklich macht?

              Natürlich nicht, aber diese Info habe ich im Vertrauen von professionellen Suchmaschinenoptimierern erfahren, die durch viel Experimentieren über Jahre so in etwa eine gute Ahnung haben, wie Google sein Ranking zur Zeit macht.

              Hättest Du nun geschrieben, Dir sei ein Mitarbeiter von Google bekannt, wäre ich beeindruckt. Dass ein Frameset vielleicht solche zu beobachtenden Ergebnisse erzielt hat, habe ich auch schon gehört. Ich höre und lese aber auch, dass Google hier ständig entwickelt. Würde ich an deren Stelle auch machen, deshalb vermute ich, dass es so ist.

              Und Google kann kein Javascript und weiß im Grunde auch nicht was ein Frameset ist und geht deshalb unbeirrt seit Jahr und Tag mit einem irgendwann mal entwickelten Standardalgrohythmus durch?

              Reiner Blödsinn. Habe ich das denn behauptet?

              Nö, hab ich das behauptet (;-)?

              Dank und Gruß,

              frankx

              1. Hallo,

                Hättest Du nun geschrieben, Dir sei ein Mitarbeiter von Google bekannt, wäre ich beeindruckt.

                So ist es nicht gerade, und wenn dem so wäre, würde ich das natürlich nicht an die große Glocke hängen, sondern lieber selber ein bisschen optimieren und dabei steinreich werden :-))

                Ich kenne aber die Seiten mancher Optimierer, die sehr erfolgreich sind, und zwar nicht nur mit ein, zwei Stichworten, sondern mit Tausenden. Daher nehme ich es denen ab, wenn sie sagen, mit Framesets verhält es sich so und so, jedenfalls zu Zeit.

                Ich höre und lese aber auch, dass Google hier ständig entwickelt. Würde ich an deren Stelle auch machen, deshalb vermute ich, dass es so ist.

                Ja sicher, sie sind immer am Weiterentwickeln, und die Optimierer am Hinterherlaufen.

                Nö, hab ich das behauptet (;-)?

                Beinahe unterstellt, aber ist schon ok :-)

                Gruß, Don P

                1. Hellihello DonP

                  Ich kenne aber die Seiten mancher Optimierer, die sehr erfolgreich sind, und zwar nicht nur mit ein, zwei Stichworten, sondern mit Tausenden. Daher nehme ich es denen ab, wenn sie sagen, mit Framesets verhält es sich so und so, jedenfalls zu Zeit.

                  Nun ja, bei Optimierern wie bei anderen Experten würde ich immer theoretisch erstmal auch (nicht nur und auch theoretisch) unterstellen, dass sie ihre Kompetenz in ein gutes Licht rücken wollen. Gefühlte Werte sind da so eine Sache. Im Zweifel wäre man als Entwickler ohne Frameset zumindest sicher davor, sich solch einem Argument ausgesetzt zu sehen.

                  Abgesehen davon gehört in ein Frameset aus meiner Sicht die Navigation komplett (mit allem drum und dran) in den Noframebereich, wenn man SEO berücksichtigen möchte. Und dann ist aus meiner gefühlten Wirklichkeit bei Google-Suchen mit an oberster Stelle wie folgt: Example.de/Kategorie/Name/Untername
                  also: Internetshop.tld/Comedys/LabelXYZ/Hans_Mueller/Songs_von_der_Strasse hilft enorm, wenn einer nach Teilen davon explizit sucht.

                  Ja sicher, sie sind immer am Weiterentwickeln, und die Optimierer am Hinterherlaufen.

                  Genau, hechel hechel, jetzt weiß ich, wie sies machen, also gestern zumindest (;-).

                  Nö, hab ich das behauptet (;-)?

                  Beinahe unterstellt, aber ist schon ok :-)

                  Nun gut, Du hast mich ertappt. Bitte ganz höflich um Verzeihung, um hier mal ein Exempel zu statuieren.

                  Dank und Gruß,

                  frankx

                  1. Hallo,

                    Nun ja, bei Optimierern wie bei anderen Experten würde ich immer theoretisch erstmal auch (nicht nur und auch theoretisch) unterstellen, dass sie ihre Kompetenz in ein gutes Licht rücken wollen.

                    Schon, aber ich erfahre solche Dinge ja nicht in Verkaufsgesprächen. Ein Optimierer würde sich wohl ins eigene Bein schießen, wenn er seine Erkenntnisse einem potentiellen Kunden oder Konkurrenten erzählt.

                    Gefühlte Werte sind da so eine Sache.

                    Man kann es ja leicht überprüfen: Suchworte bei Google absetzen und Ergebnisse bestaunen.

                    Im Zweifel wäre man als Entwickler ohne Frameset zumindest sicher davor, sich solch einem Argument ausgesetzt zu sehen.

                    Mit solchem Wissen kann man dann trotz Frameset gleich gute Rankings erzielen, ohne solches Wissen allerdings eher weniger, weil man ja nicht weiß, wo man ansetzen soll.

                    Abgesehen davon gehört in ein Frameset aus meiner Sicht die Navigation komplett (mit allem drum und dran) in den Noframebereich, wenn man SEO berücksichtigen möchte.

                    Auf jeden Fall, aber es geht noch besser. Google liest zwar den Noframe-Bereich, aber wegen des vielen Missbrauchs, der inzwischen zwecks Optimierung damit getrieben wurde, ist sehr zweifelhaft, ob sich das im Ranking überhaupt noch niederschlägt.

                    Und dann ist aus meiner gefühlten Wirklichkeit bei Google-Suchen mit an oberster Stelle wie folgt: Example.de/Kategorie/Name/Untername

                    Ja, das ist sicher auch ganz gut.

                    Letzlich kann man aber zum Glück doch sagen, dass die beste Optimierung wenig nützt, wenn man keinen brauchbaren Inhalt hat. Das ist es ja gerade, was Google so erfolgreich gemacht hat: Es werden gute Ergebnisse geliefert, nicht nur optimierter Stuss.

                    Und dabei darf man nicht vergessen, dass es abgesehen vom Inhalt und von der Optimierung der Seiten noch bedeutende andere Kriterien gibt, nach denen Google rankt. Die liegen i.d.R. nicht in der Hand des Webdesigners. Und das ist auch gut so.

                    Beinahe unterstellt, aber ist schon ok :-)

                    Nun gut, Du hast mich ertappt. Bitte ganz höflich um Verzeihung, um hier mal ein Exempel zu statuieren.

                    Schon ok, wie gesagt :-)

                    Gruß, Don P

                    1. Hellihello DonP,

                      Gefühlte Werte sind da so eine Sache.

                      Man kann es ja leicht überprüfen: Suchworte bei Google absetzen und Ergebnisse bestaunen.

                      Eben, ich war mal früher mit Sozialwissenschaftlicher Forschung beschäftigt. "Konfundierung" wäre vermutlich ein Stichwort bei der Analyse solcher Statistiken. Oder: korreliert/gehteinher die mit Frames erstellte Webseite vielleicht noch mit anderen für Suchmaschinen "negativen" Werten. Das ist nicht leicht herauszubekommen in der Regel, meiner Erfahrung nach reicht da die individuelle Beobachtung nur dann aus, wenn ein Effekt wirklich sehr offensichtlich sind.

                      Dank und Gruß,

                      frankx

                      1. Hallo,

                        Oder: korreliert/gehteinher die mit Frames erstellte Webseite vielleicht noch mit anderen für Suchmaschinen "negativen" Werten.

                        Kannst du das präzisieren? Ich meine, wenn z.B. meine Seiten relativ konstant ein gewisses Ranking haben – nicht der sog. Page-Rank in der Google-Toolbar, sondern einfach mit den meisten Stichworten z.B. auf Seite 2 der Ergebnisliste – und ich ändere dann nur eine bestimmte Sache, z.B. die Art der Verlinkung meiner Seiten untereinander, woraufhin mit denselben Stichworten meine Seiten bald sämtlich auf Seite 1 der Ergebnisliste stehen, dann ist doch recht eindeutig, das Google eben genau diese neue Linkstruktur besser bewertet. Andere, für Suchmaschinen "negative" Werte können ja nach wie vor bestehen, haben aber wohl bzgl. dieses neuen Rankings keinen großen Einfluss, weil ich ja daran nichts geändert habe.

                        Oder kann man das so nicht ohne weiteres behaupten?

                        Gruß, Don P

                        1. Hellihello DonP

                          Oder: korreliert/gehteinher die mit Frames erstellte Webseite vielleicht noch mit anderen für Suchmaschinen "negativen" Werten.

                          Kannst du das präzisieren?

                          Folgendes Beispiel: Zwei Therapieformen werden verglichen. Eine schneidet besser ab als die andere. Nicht untersucht wurden die Aufnahmkriterien der unterschiedlichen Einrichtungen. Du hast also einen Effekt der aber von zwei Faktoren herrührt, von denen Du aber nur einen kontrolliert hast. Das trifft für u.g. aber eher weniger zu.

                          Ich meine, wenn z.B. meine Seiten relativ konstant ein gewisses Ranking haben – nicht der sog. Page-Rank in der Google-Toolbar, sondern einfach mit den meisten Stichworten z.B. auf Seite 2 der Ergebnisliste – und ich ändere dann nur eine bestimmte Sache, z.B. die Art der Verlinkung meiner Seiten untereinander, woraufhin mit denselben Stichworten meine Seiten bald sämtlich auf Seite 1 der Ergebnisliste stehen, dann ist doch recht eindeutig, das Google eben genau diese neue Linkstruktur besser bewertet. Andere, für Suchmaschinen "negative" Werte können ja nach wie vor bestehen, haben aber wohl bzgl. dieses neuen Rankings keinen großen Einfluss, weil ich ja daran nichts geändert habe.

                          Oder kann man das so nicht ohne weiteres behaupten?

                          Ja, klingt plausibel. Es _könnte_ aber auch sein, dass a) die Seite, die auf Platz zwei gerutscht ist, aus anderen Gründen dort hingelangt ist b) auch andere Faktoren mitgespielt haben, die außerhalb der Kontrolle lagen. Es wäre also u.a. rein theoretisch zu testen, ob sich der "Befund" auch rückgängig machen ließe. Denn das eine Seite aufsteigt ist vielleicht ein gängiger Trend. Reine Theorie jetzt bitte. Es spricht ja bei chronologischer Nähe viel dafür.

                          Statistisch würdest Du a) zusehen, eine aussagekräftige Anzahl von Ergebnissen zu produzieren (unter 10 ist gefühlt nischt zu holen) und b) eine Kontrollgruppe zu haben, die über die Zeit mitläuft, aber nicht entsprechend beeinflusst wird. Dann kannst du die statistische Wahrscheinlichkeit ausrechnen, dass dieser Befund nicht zufällig ist.

                          Dank und Gruß,

                          frankx

                        2. Hi,

                          woraufhin mit denselben Stichworten meine Seiten bald sämtlich auf Seite 1 der Ergebnisliste stehen, dann ist doch recht eindeutig, das Google eben genau diese neue Linkstruktur besser bewertet.

                          Nicht eindeutig (da Google ständig in Bewegung ist), aber der Verdacht liegt nahe. Man kann so etwas ja mehrmals machen, um es empirisch zu bestätigen. :-)

                          Allerdings: Wenn man z.B. die Technik wechselt, muß die neue Technik nicht besser sein. Vielleicht hat man die alte Technik nur nicht richtig beherrscht! 8-)

                          Gruß, Cybaer

                          --
                          Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                2. Hi,

                  Daher nehme ich es denen ab, wenn sie sagen, mit Framesets verhält es sich so und so, jedenfalls zu Zeit.

                  Es gibt nicht "*die* Frameset-Technik". Und wer meint, diese Technik müsse genannte Nachteile haben, der mag sich in SEO auskennen, aber bestimmt nicht mit Frames.

                  Gruß, Cybaer

                  --
                  Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
        2. Hi,

          Google hat nicht wirklich ein Problem mit Frames, aber eine Unterseite deiner angemeldeten Startseite wird automatisch weniger gut bewertet, als wenn der Suchbegriff direkt auf deiner Startseite stehen würde.

          ?

          1. Es ist Sinn einer Website, unterschiedliche Themen auf unterschiedlichen (Unter-)Seiten zu haben, und nicht alles auf einer (Start-)Seite. Oder was möchtet Du mir sagen?
          2. Unterlasse besser Spekulationen, was bei mir von Google warum gewertet wird - insbesondere mit Bezug auf meine Startseite. Denn das deutet (zumindest bislang) eher darauf hin, daß irgendwas sagst, ohne zu wissen, worüber Du redest. (Sorry, klingt jetzt härter, als es persönlich gemeint ist. ;-) Inhaltlich aber noch viel zu sanft. >;->)

          Gruß, Cybaer

          --
          Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
          1. Hallo,

            Unterlasse besser Spekulationen, was bei mir von Google warum gewertet wird - insbesondere mit Bezug auf meine Startseite.

            Sorry, wollte keine Perlen vor die Säue* werfen, soll nicht wieder vorkommen.

            *Das klingt jetzt vielleicht härter, als persönlich gemeint, aber das Sprichwort lautet nunmal so.

            Gruß, Don P

            1. Hi,

              Sorry, wollte keine Perlen vor die Säue* werfen, soll nicht wieder vorkommen.

              *Das klingt jetzt vielleicht härter, als persönlich gemeint, aber das Sprichwort lautet nunmal so.

              :) Was stört's die deutsche Eiche ... ;->

              Gruß, Cybaer

              --
              Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
      2. Hello out there!

        PS: Die von Gunnar (dem No-Frames-Taliban) standardmäßig verlinkte Subotnik-Seite, ist inhaltlich ohnehin ziemlicher Stuß ...

        Wenn du das nicht mit Argumenten untermauern kannst, ist dein Posting ziemlicher Stuss.

        See ya up the road,
        Gunnar

        --
        „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
        1. Hi,

          Wenn du das nicht mit Argumenten untermauern kannst, ist dein Posting ziemlicher Stuss.

          Als wenn das nicht hinreichend in langatmigen Diskussionen hier im Archiv nachzulesen wäre ...

          ... was Du ja auch weißt.

          Kurz gesagt: Wenn man Frames einsetzt, dann sollte man die Besonderheiten und Anforderungen der Technik auch berücksichtigen. Wenn man dies nicht tut, und stattdessen lieber solche dümmlichen Stuß-Listen pflegt, muß man sich auch nicht wundern dafür ausgelacht zu werden.

          Wer mit CSS anfängt und nicht mehr lernen will als Klassenselektoren, kann damit ja auch arbeiten. Aber er sollte dann auch keine Webseite in die Welt setzen, wie beschränkt CSS doch sei ...

          Gruß, Cy-"der, wie bekannt, diese Frames-'Probleme' nicht nachvollziehen kann, weil er sich damit beschäftigt hat"-baer

          --
          Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
      3. Hellihello Cybärli,

        Komisch. Meine Coding-Site ist ja eine Frames-Site und die Seiten sind bei relevanten Suchbegriffen (mitunter auch weniger relevanten) typischerweise auf der 1. Ergebnisseite von Google (mitunter auf Platz 1, oder auch einfach nur vor SELFHTML). Also das anbiedern klappt dann wohl auch ganz gut mit Frames ... :))

        Ja, das denke ich übrigens auch. Im Zweifel, wenn es darauf ankäme, sieht man sich als Entwickler aber vielleicht merkwürdigen Behauptungen (selbsternannter) Experten gegenüber. Würd ich eine Seite für viel Geld bauen, wär ich vermutlich vorsichtig, auch wenn ichs sonst nicht einsehe (;-).

        ... dem No-Frames-Taliban

        (;-)

        standardmäßig verlinkte Subotnik-Seite, ist inhaltlich ohnehin ziemlicher Stuß ...

        Meine Alternative gefällt Dir wohl nicht? Besser im rechten Frame in Weiß die Contras und im linken Frame in Schwarz die Pros?

        Dank und Gruß,

        frankx

        1. Hi,

          Im Zweifel, wenn es darauf ankäme, sieht man sich als Entwickler aber vielleicht merkwürdigen Behauptungen (selbsternannter) Experten gegenüber. Würd ich eine Seite für viel Geld bauen, wär ich vermutlich vorsichtig, auch wenn ichs sonst nicht einsehe (;-).

          Wer für Seiten viel Geld bekommt, der sollte dafür IMHO auch mal sein Gehirn einschalten. >;->

          Meine Alternative gefällt Dir wohl nicht?

          Ich schaffe es noch gerade, über die Ironie zu schmunzeln ... :)

          ... na ja, die Seite ist eigentlich schon fast Sarkasmus, oder? :)

          Gruß, Cybaer

          --
          Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
          1. Hellihello Cybaer,

            Meine Alternative gefällt Dir wohl nicht?

            Ich schaffe es noch gerade, über die Ironie zu schmunzeln ... :)

            ... na ja, die Seite ist eigentlich schon fast Sarkasmus, oder? :)

            Nun komm; definier Sarkasmus (;-)

            Dank und Gruß,

            frankx

            1. Hi,

              ... na ja, die Seite ist eigentlich schon fast Sarkasmus, oder? :)
              Nun komm; definier Sarkasmus (;-)

              Eine besonders beißende Form der Ironie. :)

              Gruß, Cybaer

              --
              Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
              1. Hellihello Cybaer,

                ... na ja, die Seite ist eigentlich schon fast Sarkasmus, oder? :)
                Nun komm; definier Sarkasmus (;-)

                Eine besonders beißende Form der Ironie. :)

                Aha, Du willst mir also Bissigkeit unterstellen. Sollte ich Dich oder sonst jemanden damit eine symbolisch oder seelische Bisswunde zugefügt haben, bitte um Verzeihung. Hoffentlich ruf ich jetzt damit nicht wieder die "ist mir zu langweilig hier - dürfen wir fernsehen"-Front auf den Plan. Sind die eigentlich mit der Anti-Frames-Mafia verbündet?

                Dank und Gruß,

                frankx

      4. Hi Leute,

        PS: Die von Gunnar (dem No-Frames-Taliban) standardmäßig verlinkte Subotnik-Seite...

        Hehehe, No-Frames-Taliban... ;)

        Ein kleiner Zweizeiler:

        Wer Frames nicht genügend respektiert,
        Wir schnell zum Terroristen degradiert.

        [latex]
        gary_\mathrm {max}
        [/latex]

        PS.: Wo bleibt den nur endlich die wirklich _neutrale_ Gegenüberstellung zwischen Frames (zwei oder mehr)und NoFrames (Auslagern usw.), die Anfänger, Hilfsprogrammnutzer (z. B. Frontpage), Selbstprogrammierer und den Fortgeschrittenen Experten berücksichtigen. Vielleicht mit Spiegelstrich rechts / links, dann kann man Direkt vergleichen.

        1. Hallo,

          PS.: Wo bleibt den nur endlich die wirklich _neutrale_ Gegenüberstellung zwischen Frames (zwei oder mehr)und NoFrames (Auslagern usw.), die Anfänger, Hilfsprogrammnutzer (z. B. Frontpage), Selbstprogrammierer und den Fortgeschrittenen Experten berücksichtigen. Vielleicht mit Spiegelstrich rechts / links, dann kann man Direkt vergleichen.

          DAS wäre mal ein innovativer Ansatz, würde mich auch interessieren :-).

          Es lassen sich mit Sicherheit mehr oder weniger allgemeine Szenarien finden, wo Frames eher zu empfehlen oder eher nicht zu empfehlen sind – je nach Art, Anwendungsbereich und Zielgruppe von HTML-Dokumenten (man beachte die vorsichtige Formulierung).

          Vielleicht sollte man mal einen Thread dazu eröffnen, wo einfach sämtliche denkbaren Vor- und Nachteile zusammengetragen werden. Daraus ließe sich dann vielleicht eine neutrale Gegenüberstellung machen. Aber vermutlich ist es unmöglich, hier irgend einen Konsens wenigstens für bestimmte Anwendungfälle zu finden :-(

          Gruß, Don P

          1. Hellihello Don P,

            PS.: Wo bleibt den nur endlich die wirklich _neutrale_ Gegenüberstellung zwischen Frames (zwei oder mehr)und NoFrames (Auslagern usw.), die Anfänger, Hilfsprogrammnutzer (z. B. Frontpage), Selbstprogrammierer und den Fortgeschrittenen Experten berücksichtigen. Vielleicht mit Spiegelstrich rechts / links, dann kann man Direkt vergleichen.

            DAS wäre mal ein innovativer Ansatz, würde mich auch interessieren :-).

            Es lassen sich mit Sicherheit mehr oder weniger allgemeine Szenarien finden, wo Frames eher zu empfehlen oder eher nicht zu empfehlen sind – je nach Art, Anwendungsbereich und Zielgruppe von HTML-Dokumenten (man beachte die vorsichtige Formulierung).

            Vielleicht sollte man mal einen Thread dazu eröffnen, wo einfach sämtliche denkbaren Vor- und Nachteile zusammengetragen werden. Daraus ließe sich dann vielleicht eine neutrale Gegenüberstellung machen. Aber vermutlich ist es unmöglich, hier irgend einen Konsens wenigstens für bestimmte Anwendungfälle zu finden :-(

            Nun, nehmen wir doch diesen hier. Ein Ticket ist ja bereits erstellt, meine ich.

            Ein Konsens muss doch nicht sein. Entscheiden mag doch jeder selbst, aber eine umfassende Auflistung der Argumente wäre ja ohne weiteres möglich.

            Dank und Gruß,

            frankx

          2. Hallo,

            PS.: Wo bleibt den nur endlich die wirklich _neutrale_ Gegenüberstellung zwischen Frames (zwei oder mehr)und NoFrames (Auslagern usw.), die Anfänger, Hilfsprogrammnutzer (z. B. Frontpage), Selbstprogrammierer und den Fortgeschrittenen Experten berücksichtigen. Vielleicht mit Spiegelstrich rechts / links, dann kann man Direkt vergleichen.

            DAS wäre mal ein innovativer Ansatz, würde mich auch interessieren :-).

            konstruktives Zusammentragen von Informationen zu diesem Thema in einem Thread
            könnte diesen für das Selfforumssieb interessant machen - und den dortigen Eintrag
            als _die_ Adresse für die immer wieder auftretenden Frame-Diskussionen. Eine
            normale Archivsuche zu Frames (ihren Nach- und Vorteilen) ist extrem unergiebig.
            Das habe ich irgendwann mal selbst ausprobiert - und fast nur stereotype
            Beiträge gefunden.

            Freundliche Grüße

            Vinzenz, kein <I> :-)

            1. Hellihello Vinzenz,

              PS.: Wo bleibt den nur endlich die wirklich _neutrale_ Gegenüberstellung zwischen Frames (zwei oder mehr)und NoFrames (Auslagern usw.), die Anfänger, Hilfsprogrammnutzer (z. B. Frontpage), Selbstprogrammierer und den Fortgeschrittenen Experten berücksichtigen. Vielleicht mit Spiegelstrich rechts / links, dann kann man Direkt vergleichen.

              DAS wäre mal ein innovativer Ansatz, würde mich auch interessieren :-).

              konstruktives Zusammentragen von Informationen zu diesem Thema in einem Thread
              könnte diesen für das Selfforumssieb interessant machen - und den dortigen Eintrag
              als _die_ Adresse für die immer wieder auftretenden Frame-Diskussionen. Eine
              normale Archivsuche zu Frames (ihren Nach- und Vorteilen) ist extrem unergiebig.
              Das habe ich irgendwann mal selbst ausprobiert - und fast nur stereotype
              Beiträge gefunden.

              Wie aber die Sachen zusammentragen? Dazu brauchts ja bestenfalls  eine Testseite.

              Dank und Gruß,

              frankx

              1. Hellihello

                http://vergessichnicht.de/Frames_Pro_und_Contra mal entsprechend vorbereitet um als Sammelstelle zu dienen. Einiges lässt sich ja hier im Forum schon finden dazu. Eigentlich ists doch ganz einfach: solange Pros und Contras sammeln, bis keiner mehr was dazu zu sagen hat, oder?

                Dank und Gruß,

                frankx

                1. Hi frankx,

                  Sehr schön! Gosses Lob :-)

                  Jetzt fehlt nur noch ein Formular, wo man auswählen kann, ob es sich um einen Pro oder Contra Beitrag handelt, und man dann seinen (hoffentlich Sinvollen) Senf dazu geben kann...

                  With best regards

                  gary

                  1. Hellihello gary,

                    Sehr schön! Gosses Lob :-)

                    Jetzt fehlt nur noch ein Formular, wo man auswählen kann, ob es sich um einen Pro oder Contra Beitrag handelt, und man dann seinen (hoffentlich Sinvollen) Senf dazu geben kann...

                    Merci. Das heut aber nicht mehr, morgen erst höchstens wieder abends. Aber wer einen Linktipp oder einen "Punkt machen" will, könnte ja vorerst auch hier Posten und ich baus dann ein. Soll ja wie gesagt nur eine Ideensammlug sein fürs Forumssieb.

                    Dank und Gruß und guts Nächtle,

                    frankx

                2. Hi,

                  http://vergessichnicht.de/Frames_Pro_und_Contra mal entsprechend vorbereitet

                  Sind deine Seite echt ernstgemeint? Also das mit der Ironie/Sarkasmus war von mir ernstgemeint.

                  Denn wer z.B. Frames verwendet, und den NOFRAMES-Bereich nicht nutzt, kann sich IMHO nicht sonderlich mit Frames beschäftigt haben.

                  Die Seite taugt wirklich als wunderbares Beispiel, wie man es *nicht* macht ...

                  ... und ich dachte (und denke noch), daß das in diesem Fall auch Absicht ist.

                  Irre ich mich?

                  Gruß, Cybaer

                  --
                  Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                  1. Hellihello cybaerli,

                    Denn wer z.B. Frames verwendet, und den NOFRAMES-Bereich nicht nutzt, kann sich IMHO nicht sonderlich mit Frames beschäftigt haben.

                    Nun, dass kommt darauf an, was der Autor erreichen will, oder? Weiter unten irgendwo schrub ich ja vom vollen austexten des Noframesbereiches. Aber für so eine temporärer Übersicht, wozu?

                    Die Seite taugt wirklich als wunderbares Beispiel, wie man es *nicht* macht ...

                    ... und ich dachte (und denke noch), daß das in diesem Fall auch Absicht ist.

                    Irre ich mich?

                    Die mit dem bösen Frameset natürlich. Das andere ist doch, wie es da auch steht, eher ein Skizzenblatt für das Forumssieb - wie Vinzenez es vorschlug. Meinst Du ernsthaft, ich soll da die Navigation und den Text der Eingangsseite in den Noframe-Bereich packen? Bisher sollten ja nur die Argumente aufgelistet werden inklusive einer Linkliste und das lediglich als Vorschlag. Der Anklang ist ja eher gering. Wenn dieses Framesset bestand haben sollte (und sei es als Frameset im Forumssieb - wo ich jetzt mal von ausging, dass es dort nicht als Frameset landen würde) dann kann ich gern bei Gelegenheit einen Noframebereich einsetzen und auch sonstige Änderungen für eine beispielhafte Seite einfügen.

                    Dank und Gruß,

                    frankx

                    1. Hi,

                      Meinst Du ernsthaft, ich soll da die Navigation und den Text der Eingangsseite in den Noframe-Bereich packen?

                      Ich meine ernsthaft, daß man da nicht auch nur eine Sekunde daran zweifeln kann. =:-)

                      Gruß, Cybaer

                      --
                      Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                      1. Hellihello Cybaer,

                        Ich meine ernsthaft, daß man da nicht auch nur eine Sekunde daran zweifeln kann. =:-)

                        here you are

                        Dank und Gruß,

                        frankx

                3. http://vergessichnicht.de/Frames_Pro_und_Contra mal entsprechend vorbereitet um als Sammelstelle zu dienen. Einiges lässt sich ja hier im Forum schon finden dazu. Eigentlich ists doch ganz einfach: solange Pros und Contras sammeln, bis keiner mehr was dazu zu sagen hat, oder?

                  Ich hab jetzt nicht eure komplette Diskussion mitbekommen, aber Argumente contra Frames hab ich z.b.:

                  * keine direkte Verlinkung möglich
                  * bookmarken geht nicht

                  Ich hatte mal eine schöne Diskussion mit Cybaer, wo die vielen Nachteile von Frames sehr deutlich wurden. Nur nennt er es nicht so, weil es für alle Nachteile Möglichkeiten gibt diese zu umgehen, sind es für ihn keine Nachteile.

                  Struppi.

                  1. Hellihello Struppi,

                    Ich hatte mal eine schöne Diskussion mit Cybaer, wo die vielen Nachteile von Frames sehr deutlich wurden. Nur nennt er es nicht so, weil es für alle Nachteile Möglichkeiten gibt diese zu umgehen, sind es für ihn keine Nachteile.

                    Haick schoma vamerkt

                    Dank und Gruß,

                    frankx

                  2. Hi,

                    Ich hatte mal eine schöne Diskussion mit Cybaer, wo die vielen Nachteile von Frames sehr deutlich wurden. Nur nennt er es nicht so, weil es für alle Nachteile Möglichkeiten gibt diese zu umgehen, sind es für ihn keine Nachteile.

                    Genau. Ich mache Frames z.B. *prinzipiell* so, daß ich pro Content-Frame ein eigenes Frameset habe. *Das* ist für mich schlicht der Normalfall (Hinweis: i.d.R. sind meine Sites framelos - Framesites sind schon die Ausnahme, die ich aber eben auch nicht scheue), und schon die erste Umsetzung war mit einem CMS (und damit logischerweise auch der Content nochmal im NOFRAMES-Bereich keinerlei Zusatzaufwand). Und bei der "Privatanwendung" ohne CMS ist der Aufwand für einen HTML-Laien (nach der Einrichtung) auch in jeder Beziehung problemlos (ebenfalls mit Offline-Fähigkeit bzw. online auf Server mit minimaler Ausstattung lauffähig). Dann der Einfachheit halber allerdings ohne "Content in NOFRAMES", sondern nur mit "NOFRAMES-Menü/Links", wo es dann in der Tat zu einer "schlechteren Bewertung" kommen müßte, wie von Don P. beschrieben (zumindest theoretisch - praktisch nicht, weil schlicht ohne Relevanz).

                    Meine Coding-Website ist da schon die einzige (und begründete) Ausnahme von dieser Regel.

                    Allerdings muß man natürlich auch sehen, daß historisch Frames und JS gleichzeitig gekommen sind, und sicherlich von Vorneherein vorgesehen war, daß man das auch zusammen einsetzen soll. Aber OK, JavaScript auszuschalten ist ja mittlerweile, dank "Web 2.0", auch eher rückläufig ... (nein, das soll jetzt kein Plädoyer für Frames sein! ;-))

                    Gruß, Cybaer

                    --
                    Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                    1. Hellihello Cybaer,

                      Genau. Ich mache Frames z.B. *prinzipiell* so, daß ich pro Content-Frame ein eigenes Frameset habe. *Das* ist für mich schlicht der Normalfall (Hinweis: i.d.R. sind meine Sites framelos - Framesites sind schon die Ausnahme, die ich aber eben auch nicht scheue), und schon die erste Umsetzung war mit einem CMS (und damit logischerweise auch der Content nochmal im NOFRAMES-Bereich keinerlei Zusatzaufwand). Und bei der "Privatanwendung" ohne CMS ist der Aufwand für einen HTML-Laien (nach der Einrichtung) auch in jeder Beziehung problemlos (ebenfalls mit Offline-Fähigkeit bzw. online auf Server mit minimaler Ausstattung lauffähig). Dann der Einfachheit halber allerdings ohne "Content in NOFRAMES", sondern nur mit "NOFRAMES-Menü/Links", wo es dann in der Tat zu einer "schlechteren Bewertung" kommen müßte, wie von Don P. beschrieben (zumindest theoretisch - praktisch nicht, weil schlicht ohne Relevanz).

                      Das hieße im gg. Beispielfall???

                      Allerdings muß man natürlich auch sehen, daß historisch Frames und JS gleichzeitig gekommen sind, und sicherlich von Vorneherein vorgesehen war, daß man das auch zusammen einsetzen soll. Aber OK, JavaScript auszuschalten ist ja mittlerweile, dank "Web 2.0", auch eher rückläufig ... (nein, das soll jetzt kein Plädoyer für Frames sein! ;-))

                      Das JS wollte ich noch einbauen. Frage ist, ob die aufgerufene Seite über den QueryString der Navigation bzw. dem Mainframe mitgeteilt werden sollte, oder ob es da andere Möglichkeiten gibt, zB. via window.name?

                      Dank und Gruß,

                      frankx

                      1. Hi,

                        wo es dann in der Tat zu einer "schlechteren Bewertung" kommen müßte, wie von Don P. beschrieben (zumindest theoretisch - praktisch nicht, weil schlicht ohne Relevanz).
                        Das hieße im gg. Beispielfall???

                        Die Seiten wurden so (ob des Contents) ohnehin gut bewertet, daß es schlicht keine Rolle gespielt hat, ob Google hier einen Bruchteil weniger PR vererbt oder nicht.

                        Das JS wollte ich noch einbauen. Frage ist, ob die aufgerufene Seite über den QueryString der Navigation bzw. dem Mainframe mitgeteilt werden sollte, oder ob es da andere Möglichkeiten gibt, zB. via window.name?

                        Mit Ajax ist ja aufgekommen, den Status mittels Hash anzuzeigen. Das kann man auch für Frames verwenden. Also z.B.

                        http://www.example.org/frameset.html#content_url

                        Gruß, Cybaer

                        --
                        Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                        1. Hallo,

                          [...] daß es schlicht keine Rolle gespielt hat, ob Google hier einen Bruchteil weniger PR vererbt oder nicht.

                          Na also, es geht doch :-)), jetzt räumst du es also ein. Vorher war es schlicht unfundiert, Unsinn usw.
                          Ob Relevanter Bruchteil oder nicht ist Nebensache, es ging ja allein um die Tatsache, ob oder ob nicht.

                          Gruß, Don P

                          1. Hi,

                            [...] daß es schlicht keine Rolle gespielt hat, ob Google hier einen Bruchteil weniger PR vererbt oder nicht.
                            Na also, es geht doch :-)), jetzt räumst du es also ein.

                            ? Nein! :-o

                            Meine Aussage ist: Man kann mit einem "schlechten" Frames-Code "Schaden" anrichten. Man kann auch mit einem "schlechten" generellen HTML-Code "Schaden" anrichten. Mit so ziemlich allem kann man "Schaden" anrichten (JS, Flash, ...). Die Frage ist aber: Was, wenn ich den Code so abfasse, daß er *keinen* Schaden anrichtet? *Das* ist der Punkt! Wenn das geht, dann ist dein Argument obsolet, ...

                            ... und es geht eben. :-)

                            Gruß, Cybaer

                            --
                            Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                        2. Hellihello Cybaer,

                          Das JS wollte ich noch einbauen. Frage ist, ob die aufgerufene Seite über den QueryString der Navigation bzw. dem Mainframe mitgeteilt werden sollte, oder ob es da andere Möglichkeiten gibt, zB. via window.name?

                          Mit Ajax ist ja aufgekommen, den Status mittels Hash anzuzeigen. Das kann man auch für Frames verwenden. Also z.B.

                          http://www.example.org/frameset.html#content_url

                          Status mittels Hash? Was könnte mir das sagen? Dass sich bei Ajax die URL ja auch nicht ändert, also das wie ein interner Ankersprung verbucht wird? Warum heißt das "Hash" (=assoziatives Array?) und warum Status (=readystate?) ? Der ist doch im Erfolgsfalle 200, oder?

                          Dank und Gruß,

                          frankx

                          1. Hi,

                            Status mittels Hash? Was könnte mir das sagen? Dass sich bei Ajax die URL ja auch nicht ändert, also das wie ein interner Ankersprung verbucht wird?

                            In Ajax wird für die (im URL ja ansonsten nicht nachvollziehbaren) Änderung ggf. der Hash im URL geändert (s. JavaScript: location.hash). Der Vorteil dieser Variante ist es, daß man den URL eines einzigen Framesets zur Laufzeit so anpassen kann, daß man erkennen kann, welcher Contentframe gerade aktiv ist (für Bookmarking z.B.).

                            Aber dies nur als Möglichkeit mittels JS das zu machen. Prinzipiell finde ich das nicht gut, denn a) kann JS ausgeschaltet sein und b) bevorzuge ich eben *deutlichst* die "1 Frameset pro Contentframe"-Variante, wo dies ohnehin nicht notwendig ist (es gibt ja eh einen sichtbaren URL pro Contentframe).

                            Bei der Coding-Website verwende ich das "klassische" "Content-URL als Parameter"-Prinzip (also z.B. index.htm?/dhtml/index.htm). Das hat den Vorteil, daß auch bei deaktiviertem JS der korrekte Contentframe geladen wird (via PHP, das Zugriff auf URL-Parameter hat, nicht aber auf den clientseitigen Hash). Der Nachteil ist halt, daß sich der URL inkl. Parameter während des Surfens durch meine Site nicht ändert (das wäre beim Hash mit JS kein Problem). Hier muß der Surfer das Frameset auflösen, um die richtige Seite zu bookmarken (via "Exit"-Papierkorb oder der auf jeden Seite genannten Kurz-URL zum Bookmarken).

                            Dies wird von den Framegegnern als Nachteil genannt - und auch von mir(!) als Nachteil gesehen! Wie gesagt: Usablity und SEO standen bei mir *vor* dem Umgang mit Frames auf der Tagesordnung, und dem hat sich jede Technik, auch Frames, unterzuordnen.

                            Aber bei der Coding-Site ist es a) Absicht und b) hat sie als Zielgruppe User, die selbst Coden (und von daher ein wenig mehr Verständnis aufbringen sollten, als Oma Krawupke von nebenan ;-)). Da fand ich den Nachteil in Abwägung mit der Absicht als nachrangig.

                            Bei einer normalen "Wald und Wiesen"-Site käme so eine Umsetzung für mich aber niemals nicht (;-)) in Frage ...

                            Gruß, Cybaer

                            --
                            Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                    2. Hallo,

                      Dann der Einfachheit halber allerdings ohne "Content in NOFRAMES", sondern nur mit "NOFRAMES-Menü/Links", wo es dann in der Tat zu einer "schlechteren Bewertung" kommen müßte, wie von Don P. beschrieben (zumindest theoretisch - praktisch nicht, weil schlicht ohne Relevanz).

                      "Schlicht ohne Relevanz", da hast du's: Ob im NOFRAMES-Bereich nun viel drinsteht oder nicht, der SuMa ist das gleichgültig, weil der dieser Bereich gar nicht bewertet wird. Das liegt daran, dass viele versuchen die SuMa-Spider zu täuschen, indem Sie durch halbe Romane den NOFRAMES-Bereich mit Stichworten überfrachten. De facto bekommt diesen ja kein Mensch zu Gesicht, weil alle modernen Browser Frames unterstützen. Jedenfalls kenne ich keinen, der das nicht tut.

                      Wenn die Startseite ein Frameset ist, ist sie also bewertungsmäßig leer und wird lediglich vom Spider zum Verfolgen der Links benutzt. Und ich behaupte, dass das Ranking für die Stichworte der verfolgten Seiten abnimmt, je weiter der Google-Spider sich in die Tiefen der Linkstruktur hangeln muss. Das ist empirisch bewiesen (bzw. hoch wahrscheinlich gemacht), ob du's nun glaubst oder nicht. Und es macht auch Sinn: Von einer umfangreichen Domain-Startseite zu einem bestimmten Thema ist mehr zu erwarten, als wenn das Thema irgendwo auf fünfter Ebene der Verlinkung behandelt wird, völlig logisch, oder? Google kocht auch nur mit Wasser, was nicht heißt, dass es nicht auch besonders auf die weiteren Zutaten ankommt.

                      Dass du übrigens für diese temporäre Gegenüberstellung von Vor- und Nachteilen der Frames partout einen ausgefüllten NOFRAMES-Bereich verlangst, ist mir absolut unverständlich. Wozu sollte das gut sein, wo es doch praktisch keine frames-verschmähenden Browser mehr gibt? Für die Suchmaschinen etwa? Muss denn unbedingt jeder noch so temporäre und experimentelle Versuch gleich in aller Welt bekannt gemacht werden? Als ob es nicht schon genügend Webseiten gäbe. *kopfschüttel*

                      Ich würde statt dessen sogar die Spider erst mal mit "noindex, nofollow" wieder wegschicken.

                      Gruß, Don P

                      1. Hellihello DonP

                        Wenn die Startseite ein Frameset ist, ist sie also bewertungsmäßig leer und wird lediglich vom Spider zum Verfolgen der Links benutzt.

                        Genau. Du meinst, die Suchmaschin hälte "href" und "src" für das gleiche? Und Du meinst auch, sie verschmäht die internen Links im Noframebereich? Und Du meinst auch, dass sie ein Ankerelement nicht von einem Frame-Element unterscheidet?

                        Das ist empirisch bewiesen (bzw. hoch wahrscheinlich gemacht)

                        Na was denn nun, bewiesen oder hoch wahrscheinlich? Und dann auch nocht "gemacht"? Da wird der gelernte Statistiker doch gleich hellhörig. Ich konstatiere: "Gemäß mündlicher Überlieferung wirkt sich ein Frameset höchstwahrscheinlich auf das Google-Ranking negativ aus, wobei dieser negative Effekt vermutlich als eher gering einzustufen ist". Irgendwelche Einwände?

                        , ob du's nun glaubst oder nicht.

                        Ich - war jetzt nicht gemeint, ich weiß - habe in dieser Sache keinen Glauben. Ich suche nach hard-facts.

                        Und es macht auch Sinn: Von einer umfangreichen Domain-Startseite zu einem bestimmten Thema ist mehr zu erwarten, als wenn das Thema irgendwo auf fünfter Ebene der Verlinkung behandelt wird, völlig logisch, oder?

                        Nun ja, wir reden nur dann von einer(!) "Ebene" mehr, wenn die Suchamschine wirklich nicht liest, ob es ein Frameset ist. Zudem würde ich "meine" Suchmaschine auch immer mal wenigsten prüfen lassen, ob eins der Fenster "Navi*" und eins vielleicht "Content*"  heißt. Ob das manche Suchis machen, entzieht sich meiner Kenntnis.

                        Google kocht auch nur mit Wasser, was nicht heißt, dass es nicht auch besonders auf die weiteren Zutaten ankommt.

                        Ja, insofern sind o.g. Überlegungen vielleicht nicht ganz unplausibel?

                        Dass du übrigens für diese temporäre Gegenüberstellung von Vor- und Nachteilen der Frames partout einen ausgefüllten NOFRAMES-Bereich verlangst, ist mir absolut unverständlich. Wozu sollte das gut sein, wo es doch praktisch keine frames-verschmähenden Browser mehr gibt? Für die Suchmaschinen etwa? Muss denn unbedingt jeder noch so temporäre und experimentelle Versuch gleich in aller Welt bekannt gemacht werden? Als ob es nicht schon genügend Webseiten gäbe. *kopfschüttel*

                        Ich würde statt dessen sogar die Spider erst mal mit "noindex, nofollow" wieder wegschicken.

                        Habischemacht.

                        Dank und Gruß,

                        frankx

                        1. Hallo,

                          Du meinst, die Suchmaschine hälte "href" und "src" für das gleiche?

                          Ja.

                          Und Du meinst auch, sie verschmäht die internen Links im Noframebereich?

                          Sie werden nicht verschmäht, sondern natürlich gelesen zwecks Auffinden des nächsten zu durchsuchenden Dokuments, aber sie gehen nicht in die Bewertung ein, d.h. es ist völlig gleichtgültig, ob ein Link im NOFRAMES-Bereich "Megawichtiges Thema" heißt oder einfach "y-xörmmhh!". Die Stichworte "Megawichtiges Thema" zählen einfach nicht als Vorkommen, als ob sie gar nicht dastünden, und die nächste durchsuchte Seite bekommt automatisch einen kl. Abzug, weil sie eine Ebene tiefer liegt als die Startseite.

                          Und Du meinst auch, dass sie ein Ankerelement nicht von einem Frame-Element unterscheidet?

                          Ja.

                          Das ist empirisch bewiesen (bzw. hoch wahrscheinlich gemacht)

                          Na was denn nun, bewiesen oder hoch wahrscheinlich? Und dann auch nocht "gemacht"?

                          Das ist vorsichtshalber so formuliert, damit keiner mit dem philosophischen Einwand kommt, dass man ja gar nichts verifiziern, sondern nur falsifizieren kann. In den Geisteswissenschaften spricht man von deshalb "wahrscheinlich machen" (mit guten Indizien und Argumenten).

                          Da wird der gelernte Statistiker doch gleich hellhörig. Ich konstatiere: "Gemäß mündlicher Überlieferung wirkt sich ein Frameset höchstwahrscheinlich auf das Google-Ranking negativ aus, wobei dieser negative Effekt vermutlich als eher gering einzustufen ist". Irgendwelche Einwände?

                          Eigentlich keine Einwände. Wobei das "eher gering" natürlich schwammig ist: Es ist anscheinend so, dass der Effekt für die zweite Ebene (die erste ist das Frameset) "eher gering" wirkt, der Unterschied zwischen der dritten und vierten Ebene aber bereits deutlich ist, denn die Kurve der Abwertung ist nicht linear. Ohne das Frameset wären die Stichworte der vierten Ebene ja auf der dritten, dann bereits mit deutlich besserem Ranking.

                          Nun ja, wir reden nur dann von einer(!) "Ebene" mehr, wenn die Suchmaschine wirklich nicht liest, ob es ein Frameset ist. Zudem würde ich "meine" Suchmaschine auch immer mal wenigsten prüfen lassen, ob eins der Fenster "Navi*" und eins vielleicht "Content*"  heißt. Ob das manche Suchis machen, entzieht sich meiner Kenntnis.

                          "Suchis" mögen nunmal keine Framesets, weil sie zu recht befürchten, dass die gelisteten Seiten dann möglicherweise aus dem Zusammenhang gerissen daher kommen.

                          Ja, insofern sind o.g. Überlegungen vielleicht nicht ganz unplausibel?

                          Meine jetzt? Sicher nicht unplausibel.

                          Ich würde statt dessen sogar die Spider erst mal mit "noindex, nofollow" wieder wegschicken.

                          Habischemacht.

                          Freutmisch.

                          Don P

                          1. Hellihello DonP

                            Und Du meinst auch, dass sie ein Ankerelement nicht von einem Frame-Element unterscheidet?

                            Ja.

                            Das widerspräche aber dem zu unterstellenden Informationsdurst. Zumal die Information ja bereits erarbeitet wurde, denn die Suchmaschine muss ja die Attribute "src" und "href" ebenfalls unterscheiden und weiß auch bereits, dass es sich nicht um das "src"-Attribut eines "script" oder "img" Elementes handelt.

                            Googles bestreben ist es, so unterstelle ich, die qualitativ=inhaltlich besten und relevantesten Ergebnisse zu präsentieren. Dabei will sich die Krake nicht von Betrug irritieren lassen, aber in beiderlei Hinsicht: 1. nicht falsche bzw. gefälschte Inhalte hoch Ranken und 2. nicht echte Inhalte beim Betrugsfilter verlieren. Wäre ich der Google, täte ich am 2. permanent arbeiten, wie gesagt - nur so ein Gedanke dazu. Abgesehen davon dass sich darum vermutlich täglich einige Dutzend der sicher nicht unkreativen Mitarbeiter dort und hier und irgendwo auf diesem Planeten Gedanken machen, vor einem Erfahrungshintergrund von zig Menschenarbeitsjahren - unterstelle ich mal ebenfalls.

                            Dank und Gruß,

                            frankx

                          2. Hellihello DonP

                            Eigentlich keine Einwände. Wobei das "eher gering" natürlich schwammig ist: Es ist anscheinend so, dass der Effekt für die zweite Ebene (die erste ist das Frameset) "eher gering" wirkt, der Unterschied zwischen der dritten und vierten Ebene aber bereits deutlich ist, denn die Kurve der Abwertung ist nicht linear. Ohne das Frameset wären die Stichworte der vierten Ebene ja auf der dritten, dann bereits mit deutlich besserem Ranking.

                            Nun ja, das klang erstmal plausibel. Aber wenn in der Navi und/oder dem Noframebereich die komplette Linktafel/Pagemap abgebildet ist, wie es sich bei Frames ja anbietet, dann trifft dies wohl nicht mehr zu. Mir fiele dafür auch kein Szenario ein

                            Verein/Sporart/Jugendmannschaft/Feier/Bericht. Nun ist dem Verein der PR dieser Seite bestimmt wurscht. Zudem ist es vermutlich schlicht garnicht zu unschlau anzunehmen, dass Seiten, die nicht auf der ersten oder zweiten Ebene verlinkt sind, dort nämlich absichtlich ihrer Relevanz wegen vom Autor nicht verlinkt wurden.

                            Dank und Gruß,

                            frankx

                      2. Hi,

                        "Schlicht ohne Relevanz", da hast du's: Ob im NOFRAMES-Bereich nun viel drinsteht oder nicht, der SuMa ist das gleichgültig, weil der dieser Bereich gar nicht bewertet wird. Das liegt daran, dass viele versuchen die SuMa-Spider zu täuschen, indem Sie durch halbe Romane den NOFRAMES-Bereich mit Stichworten überfrachten.

                        Blödsinn, Unfug, ... - Du bist soeben über meine Schwelle der "kann man in keinster Weise ernst nehmen" gerutscht! Weitere "Diskussionen" mit Dir über dieses Thema haben sich damit erledigt. :-/

                        Konkret:

                        Das "schlicht ohne Relevanz" bezog sich (IMHO erkennbarerweise) darauf, daß die (Frame-)Seiten ob des Contents (und der sonstigen allg. SEO-Maßnahmen) *so* gut bewertet wurden, daß der minimale PR-Verlust (sofern überhaupt von Relevanz - der "nackte" PR wird ohnehin allg. etwas überbewertet, Content & Co. sind das *deutlich* wichtigere Kriterium), der bei dieser(!) Art der Framenutzung auftritt, schlicht nicht messbar war bzw. für die Platzierung überhaupt keine Bedeutung hatte (mehr als Top geht halt nicht).

                        *Natürlich* wird der NOFRAMES-Bereich von dem SuMas bewertet (genauer: sogar *nur* er wird beim Frameset bewertet). )=:-o

                        Das kannst Du mal eben(!) feststellen, indem Du eine Textstelle meines Start-Content-Frames start.htm (z.B. "Listings habe ich jetzt für den Download") in Google (oder anderen SuMas) suchst. Du bekommst als (einzigen) Treffer die (Frameset-)Startseite index.htm und nicht die (Frame-)Seite start.htm, wo die Phrase drin steht.

                        Grund: die start.htm wird überhaupt nicht indiziert (noindex), während die index.htm ein PHP-Script ist, das den Frameset-Code ausgibt und dort den BODY von start.htm in den NOFRAMES-Bereich setzt (und selbstredend ist das Frameset index.htm im Gegensatz zur start.htm indizierbar: index,follow).

                        Wenn die Startseite ein Frameset ist, ist sie also bewertungsmäßig leer und wird lediglich vom Spider zum Verfolgen der Links benutzt.

                        So ein unqalifizierter Unsinn (s.o.).

                        Es mag sein, daß "böse Buben" den NOFRAMES-Bereich mißbrauchen (wie sie auch andere Dinge wie FONT oder CSS für ihre Zwecke mißbrauchen. Und bei Mißbräuchen mag Google in der automatischen Erkennung so seine Schwierigkeiten haben (deswegen ja auch die "Meldestelle", weil man der autom. Mißbrauchserkennung dort *nicht* traut), aber die autom. Erkennung, ob der NOFRAMES-Bereich zum Content-Frame paßt, ist ja nun wirklich Pille-Palle, wenn NOFRAMES-Bereich und Inhalt des Content-Frames ohnehin identisch sind, nicht wahr? 8-)

                        Dass du übrigens für diese temporäre Gegenüberstellung von Vor- und Nachteilen der Frames partout einen ausgefüllten NOFRAMES-Bereich verlangst, ist mir absolut unverständlich.

                        Wenn man eine (wieso temporäre?) Seite über Vor-/Nachteile von Frames machen will, sollte sie die angeblichen Nachteile von Frames halt vermeiden. Diese Maßnahme ist die wichtigste.

                        Ansonsten das alte Problem: Du hast deine Meinung, ich widerspreche, Du prüfst nicht nach (obwohl dies einfachst möglich wäre: s.o.), und behauptest den Unsinn lieber weiter. :-(

                        Der Vorteil ist (s.o.): Die SuMa indiziert das Frameset, und der Surfer findet auch nur das Frameset - und nicht die (wenn man es schlecht(!) macht: ein wenig PR-reduzierte) Frameseite. Das ist aus Sicht der SuMa optimal, aus Sicht des Surfers auch (kann sofort die komplette Seite mit allen Frames bookmarken), und aus Sicht des Seitenautoren auch (jegliche Form des "Framesets nachträglich nachladen" entfällt dadurch).

                        Aber da Du wiederholt diesen "Diskussionstil" (eher: Monologstil) an den Tag legst: EOT (möge dein aktuelles SEO-Wissen auf alle Zeiten unbefleckt von Erkenntnis vor sich hingammeln ... >:->)

                        Gruß, Cybaer

                        --
                        Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                    3. Hello out there!

                      Genau. Ich mache Frames z.B. *prinzipiell* so, daß ich pro Content-Frame ein eigenes Frameset habe.

                      OK, damit hat jede Webseite ihren URI; dieser Nachteil beim "üblichen" Einsatz von Frames fällt weg.

                      Welchen Vorteil sollte aber das Frameset gegenüber einer Ein-Dokument-Webseite haben?

                      Beim Frameset mit n Frames sind es n + 1 Dokumente, die 1. der Client vom Server anfordern muss und 2. vom Server zum Client geschickt werden müssen; bspw. Frameset, Inhaltsframe, Menüframe. Lass es durch Caching weniger sein; es sind mindestens zwei.

                      Der dadurch erzeugte Traffic (HTTP-Request und -Response) dürfte die paar Bytes, die man durch das gecachte Menü spart, bei weitem übersteigen.

                      Also dann doch besser eine serverseitig zusammengesetzte Ein-Dokument-Webseite.

                      See ya up the road,
                      Gunnar

                      --
                      „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
                      1. Hi,

                        Der dadurch erzeugte Traffic (HTTP-Request und -Response) dürfte die paar Bytes, die man durch das gecachte Menü spart, bei weitem übersteigen.

                        Der Traffic ist mir ehrlich gesagt egal (merkt man daran, daß ich den Content i.d.R. ja sogar doppelt übertrage: Content-Frame und Frameset). =;-> Das war beim ersten Einsatz so, und ist in der heutigen YouTibe-Ära erst recht so. ;)

                        (Damals hatte meine Zielgruppe allerdings schon recht viel Bandbreite unterm Arsch, und es gab sowieso von jeder Seite eine no-frames & text-only Version für langsame Verbindungen.)

                        Also dann doch besser eine serverseitig zusammengesetzte Ein-Dokument-Webseite.

                        Kommt halt drauf an.

                        1. Frames funktionieren ohne Server (und seinen Techniken)
                        2. Frames bieten ein statisches Layout auf allen Browsern (na ja, zumindet den heutzutage üblichen, also framefähigen).
                        3. Der Anwender kann selbst einfach Content und Rest voneinander trennen, indem er nur den (ggf. für ihn einzig wesentlichen) Content-Frame aufruft.
                        4. Frames sind absolut sinnvoll für "Spezialseiten" - z.B. wenn man verschiedene Contents zusammen auf einen Blick braucht, usw. usf.

                        Bei 2. Punkt kann man durchaus mit CSS & ggf. auch JS was hinbiegen, so daß es irgendwie auch auf dem IE klappt (mehr oder weniger). Aber da sind dann wiederum so viele Dinge zu beachten, daß Frames dann doch einfacher sind.

                        Ich will ja keineswegs darauf aus, daß man bitteschön nur Frames verwenden soll. =;-> Aber wie gesagt: SEO/Usability stand bei mir *vor* dem Einsatz von Frames an, in diesem sine qua non hatte und hat sich jede Web-Technik, auch die Frame-Technik, unterzuordnen. Das hat gut geklappt, deswegen habe ich damit angefangen, und deswegen sehe ich auch die (zumindest Vielzahl) der "Probleme" nicht als solche. Ich rate also nicht prinzpiell von Frames ab, sondern sorge eher dafür, daß, im Fall des Falles, das Ganze reibungslos läuft.

                        Daß es insbes. bei HTML-Hobby-Anfängern (und oft auch bei HTML-Profis) alles andere als "reibungslos" läuft, egal worum es geht, das will ich gerne konstatieren. Daß man sich unbedachterweise auch und gerade mit Frames Probleme einfangen kann, die gerade der Einsteiger nicht überblickt, übrigens auch. ;)

                        Gruß, Cybaer

                        --
                        Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                  3. Hellihello Struppi,

                    * keine direkte Verlinkung möglich
                    * bookmarken geht nicht

                    naja, ist das nicht etwas zu rigide?

                    Bookmarken kann ich im Firefox mit "rechteMaus/diesenLinkBookmarken", also wäre es wohl richtiger zu sagen, dass man in Framesets nicht Seiten Bookmarken kann sondern nur Links, oder?

                    Dank und Gruß,

                    frankx

                  4. Hi,

                    Ich hatte mal eine schöne Diskussion mit Cybaer, wo die vielen Nachteile von Frames sehr deutlich wurden. Nur nennt er es nicht so, weil es für alle Nachteile Möglichkeiten gibt diese zu umgehen, sind es für ihn keine Nachteile.

                    Ausgrab : FRAMES Pro & Contra
                    Außerdem: Frameset nachladen
                              Frames: Pfui oder akzeptabel

                    Gruß, Cybaer

                    --
                    Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                    1. Hellihello,

                      Ausgrab : FRAMES Pro & Contra
                      Außerdem: Frameset nachladen
                                Frames: Pfui oder akzeptabel

                      Hab ich mal in die Linkliste mit aufgenommen, den letzten hatte ich da ja schon.

                      Beim Nachladen mit Hash oder Search bin ich noch nicht weiter. Was ich kapier: JS kennt entweder .hash oder .search, trennen bei #abc?def kann es wohl nicht.

                      Ich denke ja, eine vollständiger Prototyp für ein Frameset sollte auch in der Lage sein, einen mitübergebenen Searchstring zu verarbeiten.

                      unterseite.htm?ichbin=oskar sollt dann die unterseite mit diesem querystring ins contentframe packen. oder tut es das, frag ich mich grad - mit der hier in self demonstrierten methode? nochmal schaun später heut vielleicht.

                      Dank und Gruß,

                      frankx

                      1. Hi,

                        Beim Nachladen mit Hash oder Search bin ich noch nicht weiter. Was ich kapier: JS kennt entweder .hash oder .search, trennen bei #abc?def kann es wohl nicht.

                        Ein URL kann "search" und "hash" *gleichzeitig* haben. Trennen mußt Du nichts, dafür hat location ja die unterschiedlichen Eigenschaften.

                        unterseite.htm?ichbin=oskar sollt dann die unterseite mit diesem querystring ins contentframe packen. oder tut es das, frag ich mich grad - mit der hier in self demonstrierten methode? nochmal schaun später heut vielleicht.

                        ?

                        Gruß, Cybaer

                        --
                        Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                        1. Hellihello Cybaer,

                          Ein URL kann "search" und "hash" *gleichzeitig* haben. Trennen mußt Du nichts, dafür hat location ja die unterschiedlichen Eigenschaften.

                          Ja, das dachtich auch. In meinem Test aber zeigt mir JS _entweder_ den location.hash an (wenn eine Raute vorhanden war, egal ob mit oder ohne Fragezeichen) _oder_ location.search, nur dann wenn keine Raute da war (natürlich aber ein Fragezeichen).

                          Mussisch nochmal testen...;

                          unterseite.htm?ichbin=oskar sollt dann die unterseite mit diesem querystring ins contentframe packen. oder tut es das, frag ich mich grad - mit der hier in self demonstrierten methode? nochmal schaun später heut vielleicht.

                          ?

                          Damit meine ich;

                          www.example.com/dir/unterseite.htm?query=string

                          wird zu

                          www.example.com/index.htm?/dir/unterseite.htm

                          wech ist der schöne query-string des ersten aufrufes, wenn nicht zusätzliches Javascript hilft. So meine Erinnerung, als ich an dem Nachlader mal bastelte.

                          Dank und Gruß,

                          frankx

                        2. Hellihello Cybaer,

                          Ein URL kann "search" und "hash" *gleichzeitig* haben. Trennen mußt Du nichts, dafür hat location ja die unterschiedlichen Eigenschaften.

                            
                            
                          <script type="text/javascript">  
                          //<![CDATA[  
                            
                          alert("hash: "+location.hash);  
                          alert("search: "+location.search);  
                            
                            
                          //]]>  
                          </script>  
                            
                          
                          

                          im FF: "file:///Z:/javascript/location_hash_search.js.htm#myhash?mysearch"

                          bringt 2 alertboxen:

                          1. hash: #myhash?mysearch
                          2. search:

                          wieso ist search leer?

                          file:///Z:/javascript/location_hash_search.js.htm?mysearch

                          bringt 2 alertboxen:

                          1. hash:
                          2. search: ?mysearch

                          ist logisch, hash gibts ja nicht.

                          Dank und Gruß,

                          frankx

                          1. Hallo frankx,

                            <script type="text/javascript">
                            //<![CDATA[
                            alert("hash: "+location.hash);
                            alert("search: "+location.search);
                            //]]>
                            </script>

                            
                            >   
                            > im FF: "file:///Z:/javascript/location\_hash\_search.js.htm#myhash?mysearch"  
                            > bringt 2 alertboxen:  
                            > 1. hash: #myhash?mysearch  
                            > 2. search:  
                            > wieso ist search leer?  
                              
                            und "file:///Z:/javascript/location\_hash\_search.js.htm?mysearch#myhash" sollte im FF (und anderen Browsern) das gewünschte Resultat bringen:  
                            1\. hash: #myhash  
                            2\. search: ?mysearch  
                              
                            Auf die Reihenfolge kommt es an! (siehe auch [RFC 1630, Appendix BNF](http://tools.ietf.org/html/rfc1630#appendix-BNF))  
                              
                            Grüsse  
                            Siramon,  
                                 ja der Penner aus Nr. 14
                            
            2. Hallo,

              Das

              [konstruktive] Zusammentragen von Informationen zu diesem Thema

              wäre ungefähr so relevant wie eine brandaktuelle Dokumentation von JSSS.

              (»Was ist denn JSSS?« - Genau!)

              Eine normale Archivsuche zu Frames (ihren Nach- und Vorteilen) ist extrem unergiebig. Das habe ich irgendwann mal selbst ausprobiert - und fast nur stereotype Beiträge gefunden.

              Ja, weil seit Jahren (circa 5-6 meinem Eindruck nach) niemand mehr Bock darauf hat, das Thema durchzudiskutieren. Ich kann das verstehen, nachdem ich mich 2002 und 2003 ins Thema vertieft hatte, war es irgendwann genug. Soweit müsste man natürlich mindestens zurückgehen, um Diskussionen im Forum zu finden, die nicht ausschließlich auf frühere verweisen.

              Aber will man das? Ich hatte lange eine Seite gepflegt mit dem Titel »Verantwortungsbewusster Einsatz und provisorische Lösungen für einige Probleme von Frames«. Ich habe sie kürzlich gelöscht. Die wenigen Fälle, in denen man die Eigenheiten von Frames benötigte, haben sich m.E. in Luft aufgelöst. (Auch aus SELFHTML werden die Quickbar usw. in der jetzigen Frames-Umsetzung herausfliegen.)

              Mathias

              1. Hallo Mathias,

                [konstruktive] Zusammentragen von Informationen zu diesem Thema
                wäre ungefähr so relevant wie eine brandaktuelle Dokumentation von JSSS.
                (»Was ist denn JSSS?« - Genau!)

                kannte ich noch - nein, nicht die Doku - aber Netscape-4-Stylesheets :-)

                Eine normale Archivsuche zu Frames (ihren Nach- und Vorteilen) ist extrem unergiebig. Das habe ich irgendwann mal selbst ausprobiert - und fast nur stereotype Beiträge gefunden.

                Ja, weil seit Jahren (circa 5-6 meinem Eindruck nach) niemand mehr Bock darauf hat, das Thema durchzudiskutieren. Ich kann das verstehen, nachdem ich mich 2002 und 2003 ins Thema vertieft hatte, war es irgendwann genug.

                meine Suche dürfte ich etwa 2003 oder 2004 vorgenommen haben.

                Aber will man das?

                Ich nicht, das hatte ich gleich

                Vinzenz, kein <I> :-)

                zu verstehen gegeben. Mir fällt im wesentlichen ein Einsatzzweck für Frames ein, siehe Archivthread [Musik über mehrere HTML Seiten laufen lassen]. Dieser Fall ist aber sehr selten - da Musik nur sehr selten wirklich zur Website gehört - und könnte genauso gut (oder schlecht) durch ein Popup gelöst werden.

                Da aber die Framesfrage auch jetzt noch immer wieder im Forum diskutiert wird, wäre es meiner Meinung nach dennoch interessant, die wirklich relevanten (Archiv-)Beiträge zu diesem Thema aufzuarbeiten, damit man es beim nächsten Auftreten dieser Frage leichter hat. Ein paar wirklich gute Diskussionen, entsprechend kommentiert, wären überzeugender als der Standardlink zu Subotnik, der inzwischen die "suche im Archiv!"-Antwort abgelöst hat.

                Freundliche Grüße

                Vinzenz

                1. Hellihello Vinzenz,

                  zu verstehen gegeben. Mir fällt im wesentlichen ein Einsatzzweck für Frames ein, siehe Archivthread [Musik über mehrere HTML Seiten laufen lassen]. Dieser Fall ist aber sehr selten - da Musik nur sehr selten wirklich zur Website gehört - und könnte genauso gut (oder schlecht) durch ein Popup gelöst werden.

                  Da aber die Framesfrage auch jetzt noch immer wieder im Forum diskutiert wird, wäre es meiner Meinung nach dennoch interessant, die wirklich relevanten (Archiv-)Beiträge zu diesem Thema aufzuarbeiten, damit man es beim nächsten Auftreten dieser Frage leichter hat. Ein paar wirklich gute Diskussionen, entsprechend kommentiert, wären überzeugender als der Standardlink zu Subotnik, der inzwischen die "suche im Archiv!"-Antwort abgelöst hat.

                  Meine Rede (;-).

                  Dank und Gruß,

                  frankx

              2. Hallo,

                Eine normale Archivsuche zu Frames (ihren Nach- und Vorteilen) ist extrem unergiebig. [...]

                Ja, weil seit Jahren (circa 5-6 meinem Eindruck nach) niemand mehr Bock darauf hat, das Thema durchzudiskutieren.

                Man hat sich anscheinend einfach drauf geeinigt, dass Frames in aller Regel unrauchbar sind, basta.

                Ich hatte lange eine Seite gepflegt mit dem Titel »Verantwortungsbewusster Einsatz und provisorische Lösungen für einige Probleme von Frames«. Ich habe sie kürzlich gelöscht.

                Schade. Hatte keine Gelegenheit das zu lesen. Ein Wunder, dass Frames in SelfHTML wenigstens noch erwähnt werden.

                Die wenigen Fälle, in denen man die Eigenheiten von Frames benötigte, haben sich m.E. in Luft aufgelöst.

                Wie meinst du das? Dass die Eigenheiten von Frames keine Probleme mehr schaffen oder dass Frames allgemein praktisch keine Bedeutung mehr haben?

                Zuerst habe ich gedacht, der Name "SELFHTML" beute soviel wie "HTML selbst gemacht", ohne Vorurteile und ohne bestimmten Fokus. Aber dann habe ich bald gemerkt, dass es eigentlich nur ums WWW geht, d.h. man sollte es vielleicht besser in "WWWHTML" umbenennen und dann erst recht besonders auf Vor- und Nachteile von Frames eingehen.

                Frames werden ja hauptsächlich deswegen verworfen, weil man im WWW damit auf Probleme gestoßen ist. Es wird argumentiert, dass z.B. manche Benutzer (DAU und Co.) damit nicht klar kommen, die Suchmaschinen es schwer haben, die Bildschirmaufteilung besser dem Browser überlassen werden sollte usw.

                Wenn man ein Webangebot bereistellt für möglichst viele Benutzer mit unterschiedlichsten Endgeräten, dann mag das vielleicht stimmen, aber das ist doch nicht das einzige vorstellbare Szenario, wenn auch vielleicht das häufigste.

                HTML kann auch für ganz andere Anwendungen eingesetzt werden, z.B. rein privat oder intern in einem Unternehmen, wo die Benutzer nicht von Frames irritiert werden, weil sie keine Anfänger sind, wo auch keine Suchmaschinen ausgesperrt werden, weil die Dokumente gar nicht bei solchen indiziert sind, wo javascript immer aktiviert ist usw.

                Dass Browser ohnehin eigenmächtig den Zeilenumbruch dynamisch an die Fenstergröße bzw. den Viewport anpassen, ist IMO kein Vorteil und kein brauchbares Argument gegen Frames, denn Browser haben anscheinend nicht die geringste Ahnung von Typografie. Jeder Typograf lernt im ersten Lehrjahr, dass die Zeilenlänge zwischen 50 und 60 Zeichen betragen sollte, damit ein Text noch gut lesbar ist. In den Printmedien wird das berücksicht, aber am Bildschirm? Fehanzeige! 100 und mehr Zeichen pro Zeile sind bei den heute gebräuchlichen Auflösungen die Regel. Mit größenveränderlichen Frames kann sich aber jeder seine Lieblingsansicht einstellen für eine bestimmte Anwendung.

                Z.B. könnte ein DJ seine eigene Musikdatenbank einrichten, wo er bequem im Browser Titel usw. aussuchen u. anhören kann. Je nach Ort und Bildschirm (z.B. Laptop), kann er dann die Schrift- und Framegrössen ganz einfach anpassen, damit alles schön übersichtlich bleibt. Das ist nur ein Beispiel. Es sind noch zahlreiche andere Anwendungen denkbar.

                Gruß, Don P

                --
                sh:( fo:) ch:? rl:( br:] n4:~ ie:% mo:? va:{ js:) de:/ zu:] fl:( ss:| ls:&
                1. Hellihello DonP,

                  HTML kann auch für ganz andere Anwendungen eingesetzt werden, z.B. rein privat oder intern in einem Unternehmen, wo die Benutzer nicht von Frames irritiert werden, weil sie keine Anfänger sind, wo auch keine Suchmaschinen ausgesperrt werden, weil die Dokumente gar nicht bei solchen indiziert sind, wo javascript immer aktiviert ist usw.

                  Dass Browser ohnehin eigenmächtig den Zeilenumbruch dynamisch an die Fenstergröße bzw. den Viewport anpassen, ist IMO kein Vorteil und kein brauchbares Argument gegen Frames, denn Browser haben anscheinend nicht die geringste Ahnung von Typografie. Jeder Typograf lernt im ersten Lehrjahr, dass die Zeilenlänge zwischen 50 und 60 Zeichen betragen sollte, damit ein Text noch gut lesbar ist. In den Printmedien wird das berücksicht, aber am Bildschirm? Fehanzeige! 100 und mehr Zeichen pro Zeile sind bei den heute gebräuchlichen Auflösungen die Regel. Mit größenveränderlichen Frames kann sich aber jeder seine Lieblingsansicht einstellen für eine bestimmte Anwendung.

                  Z.B. könnte ein DJ seine eigene Musikdatenbank einrichten, wo er bequem im Browser Titel usw. aussuchen u. anhören kann. Je nach Ort und Bildschirm (z.B. Laptop), kann er dann die Schrift- und Framegrössen ganz einfach anpassen, damit alles schön übersichtlich bleibt. Das ist nur ein Beispiel. Es sind noch zahlreiche andere Anwendungen denkbar.

                  Oder eine Übersicht über die Bestellungen, oder die Produkte, oder die eigenen Seiten oder...; Mir fiel übrigens auf, dass es auch Sinn macht, wenn das Menü nicht so lang, dafür abe die Inhalte um so länger sind. Das unabhängige Scrollen bringen die Frames ja einfach so mit. Mal schauen, wie ich Deinen Beitrag in meine kleine Zusammenstellung basteln kann.

                  Dank und Gruß,

                  frankx

                  1. Hallo,

                    Z.B. könnte ein DJ seine eigene Musikdatenbank einrichten
                    Oder eine Übersicht über die Bestellungen, oder die Produkte, oder die eigenen Seiten oder...;

                    Redest du jetzt noch vom Intranet wie Don P?

                    Als Beispiele fallen immer lange Listen von Links ein und eben die verlinkten Dokumente, die dann genauere Infos enthalten. Und zwischen denen will man, so die Annahme, so schnell wie möglich springen, sodass man Liste und Information, so die Annahme, bestenfalls gleichzeitig sehen und bedienen will.

                    Sozusagen das Modell »Datenbank«. Das ist erstmal naheliegend, man denke an die Aufteilung von iTunes, welches einem über verschiedene Kriterien, die in Spalten neben stehen, eine sukzessive Auswahl erlaubt. So eine Auswahl ist praktisch, ob Frames die notwendige Lösung ist, wäre eine andere Frage.

                    Schwieriger sind die weiteren Beispiele: Solch geartete Listen habe ich eigentlich überall, sowohl im öffentlichen Web wie im beschränkten Bereich. Ich glaube, dann würde mir keine Site bzw. Anwendung einfallen, wo man Frames oder verwandte Lösungen für Paralleldarstellung (iframe/object, Popups) nicht in dieser Weise inflationär einsetzen könnte. Produktlisten? Zack, Frames. Nachrichtenlisten? Zack, Frames. Bestellungslisten? Zack, Frames. Sonstige Linklisten? Zack, Frames.

                    Man macht es aber nicht. Warum nicht?

                    Das soll jetzt kein Argument bzw. Fehlschluss vom Sein aufs Sollen sein. Ich weiß nur einfach nicht, wie das zusammenpassen soll. Was denkt ihr? Wenn die Vorteile von Frames doch so auf der Hand zu liegen scheinen und es überall Anwendungsmöglichkeiten gibt, dann fallen die paar Nachteile offenbar nicht ins Gewicht, oder? Oder fallen sie nur im öffentlichen Web dermaßen ins Gewicht? (Warum?)

                    Ich könnte mich bloß fragen, ob nicht schon die Prämissen (»Benutzer will ungern ständig zwischen Dokumenten springen, indem er den Back-Button nutzt«) vielleicht schon fehlerhaft sind. Aber diese Prämisse zum Beispiel klingt doch ganz plausibel...

                    Mathias

                    1. Hellihello

                      Hallo,

                      Z.B. könnte ein DJ seine eigene Musikdatenbank einrichten
                      Oder eine Übersicht über die Bestellungen, oder die Produkte, oder die eigenen Seiten oder...;

                      Redest du jetzt noch vom Intranet wie Don P?

                      Natürllich. Da mache ich es ja in einem Anwendungsfalle genau so. Nur für mich, kann ich machen was ich will (;-).

                      Als Beispiele fallen immer lange Listen von Links ein und eben die verlinkten Dokumente, die dann genauere Infos enthalten. Und zwischen denen will man, so die Annahme, so schnell wie möglich springen, sodass man Liste und Information, so die Annahme, bestenfalls gleichzeitig sehen und bedienen will.

                      Siehe das Beispiel vom Eric Myer.

                      Sozusagen das Modell »Datenbank«. Das ist erstmal naheliegend, man denke an die Aufteilung von iTunes, welches einem über verschiedene Kriterien, die in Spalten neben stehen, eine sukzessive Auswahl erlaubt. So eine Auswahl ist praktisch, ob Frames die notwendige Lösung ist, wäre eine andere Frage.

                      Nein, aus meiner Sicht geht es nicht um Notwendigkeit sondern um Möglichkeit. Ist es eine mögliche Lösung, und, wenn sie nicht im Intranet stattfindet, verletzt sie Regelen des W3C (deprecated) oder des WAI (Punkteverlust durch Barrieren)? - was Frames beides nicht tun.

                      Schwieriger sind die weiteren Beispiele: Solch geartete Listen habe ich eigentlich überall, sowohl im öffentlichen Web wie im beschränkten Bereich. Ich glaube, dann würde mir keine Site bzw. Anwendung einfallen, wo man Frames oder verwandte Lösungen für Paralleldarstellung (iframe/object, Popups) nicht in dieser Weise inflationär einsetzen könnte. Produktlisten? Zack, Frames. Nachrichtenlisten? Zack, Frames. Bestellungslisten? Zack, Frames. Sonstige Linklisten? Zack, Frames.

                      Nun ja, wieso denn so absolutistisch? Mir fehlt hier so ein bisschen die "Freiheit des Autors".

                      Man macht es aber nicht. Warum nicht?

                      Es geht nicht darum, dass alles das selbe machen, denke ich. "<font>" "macht" man nicht, weils deprecated ist.

                      Das soll jetzt kein Argument bzw. Fehlschluss vom Sein aufs Sollen sein. Ich weiß nur einfach nicht, wie das zusammenpassen soll. Was denkt ihr? Wenn die Vorteile von Frames doch so auf der Hand zu liegen scheinen und es überall Anwendungsmöglichkeiten gibt, dann fallen die paar Nachteile offenbar nicht ins Gewicht, oder? Oder fallen sie nur im öffentlichen Web dermaßen ins Gewicht? (Warum?)

                      Weil das Web in großen Teilen kommerzialisiert ist und sein Götze Google heißt. Das ist einer der Gründe wovor selbst ich jetzt als Entwickler noch angst hätte und einem "echten" Kunden nie ein Frameset unterjubeln würde - weil es haufenweise von halbwissen strotzenden Glauben um die Punkteverluste gibt. Schlechter GoogleRank = SchlechteSeite.

                      [Abgesehen davon sah ich mir gestern mit einem Schüler mal den Quelltext von Wikiepedia/Akronym an. Da kam eine <h3> direkt nach einem <h1> und vor einem <h2> und ich sah den Text vor lauter Javascript nicht.]

                      Ich könnte mich bloß fragen, ob nicht schon die Prämissen (»Benutzer will ungern ständig zwischen Dokumenten springen, indem er den Back-Button nutzt«) vielleicht schon fehlerhaft sind. Aber diese Prämisse zum Beispiel klingt doch ganz plausibel...

                      Ach weißt Du, bei mir gibts nicht "den Nutzer". Ich habe die Vorliebe, dass ich es mag, wenn es "stabile" Elemente auf der Seite gibt. In Jugendsprache: ich "hasse" es, wenn die Navi scrollt, obwohl ich den Inhalt scrollen will und umgekehrt. Dass ich das mit gehörigen CSS-Verrenkungen (wie imitiere ich ein Frameset mit CSS, am besten noch inklusive Javascript, um die Framebreiten einstellen zu können(;-)) nachbauen könnte, weiß ich.

                      Dank und Gruß,

                      frankx

                2. Hello out there!

                  Man hat sich anscheinend einfach drauf geeinigt, dass Frames in aller Regel unrauchbar sind, basta.

                  Nein, Frames sind durchaus rauchbar. Frames kannst du in der Pfeife rauchen! ;-)

                  Frames werden ja hauptsächlich deswegen verworfen, weil man im WWW damit auf Probleme gestoßen ist. Es wird argumentiert, dass z.B. manche Benutzer (DAU und Co.) damit nicht klar kommen,

                  Eher erfahrene Nutzer. Diese sind es, die anderen sagen "sieh dir http://example.net/foo/bar/baz an" anstatt "gehe auf www.example.net, clicke im Menü auf 'Foo', auf der nächsten Seite clicke im Menü auf 'Bar', auf der nächsten Seite clicke im Menü auf 'Baz'".

                  die Suchmaschinen es schwer haben

                  In der Tat heutzutage wohl kein Argument gegen Frames (mehr).

                  HTML kann auch für ganz andere Anwendungen eingesetzt werden, z.B. rein privat oder intern in einem Unternehmen,

                  Dort könnten Framesets gewiss mitunter sinnvoll eingesetzt werden. Wenn es um Spezialanwendungen geht, sollte das im OP erwähnt sein.

                  Bei einem N00bie, der hier im Forum eine Frage zu Frames stellt, ist nicht von einer solchen Spezialanwendung auszugehen. Dann ist der Verweis auf die Probleme mit Frames angebracht.

                  Dass Browser ohnehin eigenmächtig den Zeilenumbruch dynamisch an die Fenstergröße bzw. den Viewport anpassen, ist IMO kein Vorteil und kein brauchbares Argument gegen Frames,

                  Nein, das hat mit Frames nichts zu tun. Das ist auch bei framelosen Webseiten so; und das ist auch gut so[tm].

                  Jeder Typograf lernt im ersten Lehrjahr, dass die Zeilenlänge zwischen 50 und 60 Zeichen betragen sollte, damit ein Text noch gut lesbar ist.

                  Die CSS-Eigenschaft 'max-width' existiert. Die Einheit 'em' auch. Man muss es nur sinnvoll einsetzen.

                  In den Printmedien wird das berücksicht, aber am Bildschirm? Fehanzeige! 100 und mehr Zeichen pro Zeile sind bei den heute gebräuchlichen Auflösungen die Regel.

                  Schuld des Webseitenautors.

                  Und dass nicht die Auflösung relevant ist, sondern die Viewportgröße, sollte sich doch nun langsam herumgesprochen haben.

                  See ya up the road,
                  Gunnar

                  --
                  „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
                3. Hallo,

                  Generell sollte man sich vor Augen führen: »the web has grown from a document retrieval system into an application delivery system« (Crockford). Die Entwicklung verlief halt in Bahnen und Frames waren so eine Übergangserscheinung dieser Entwicklung. Das betraf m.M.n. nicht bloß die spezifische Situation des öffentlichen Webs.

                  Ich habe einst viel zu Thema Popups gearbeitet. Da war die Argumentation ähnlich, wie du sie für Frames beschreibst: Im offenen Web in freier Wildbahn sei das etwas ganz anderes als im Intranet oder bei geschlossenen Sites.

                  Konkret sah das dann so aus, dass es Webanwendungen gab (mit Web meine ich jetzt nicht nur das öffentliche, sondern halt jegliche Anwendungen auf Basis von HTTP, HTML / CSS / JavaScript, Browser und Co.), die wie die üblichen Desktop-Programme mehrere verschachtelte Dialoge in Form von Popup-Fenstern öffneten. Das war damals - neben Frames - DIE zeitgemäße Übertragung von bekannten UI-Konzepten auf Webanwendungen. Das war nicht ganz dumm, aber das Fensterchaos und die übrigen Nachteile blieben. (Die ähneln denen von Frames, weil eine Site plötzlich auch in mehrere autonome Browsing-Kontexte gespalten wird, über die der Anwender trotzdem nicht die volle Kontrolle hat).

                  Und dann kam Ajax mit voller Wucht und die ganzen integrativen Lösungen wie Lightbox und Konsorten sprachen sich herum. Heute ordnet man Webanwendungen zum Glück ganz anders an und nutzt das klassische Dokumentmodell durchaus.

                  Natürlich könnte man all die tollen neuen Web-2.0-artigen Anwendungen auch mit Frames und Popups umsetzen. Aber es hat seinen Grund, dass man trotz der Ajax-Revolution bei vielen Webanwendungen zum klassischen Dokumentenmodell zurückkehrt, um sich bei ihm soweit zu bedienen, wie es einem nützlich erscheint. Da wird immer nur ein Dokument im Browser angezeigt, das die gesamte UI bereitstellt, oft eine definierte URI hat und eine konventionelle »Navigation« bietet. Dabei haben wir es mit einer hochinteraktiven Webanwendung zu tun, auch das Dokument selbst ist durch Ajax hochinteraktiv.

                  Das alles ginge natürlich auch anders, unter anderem mit Frames, Popups usw., aber man entscheidet sich bewusst dazu, sich an die Konventionen des »alten« Webs anzupassen. Man mischt das eine mit dem anderen, tut so, als wäre die UI, die man da vor sich hat, auch irgendwie wie ein Dokument aufgebaut. Meiner Interpretation nach ist das Ziel dieser Mischung die optimale, intuitive Bedienbarkeit.

                  Das heißt natürlich nicht, dass diese Webanwendungen wirklich nach dem alten Modell des »document retrieval system« funktionieren, im Gegenteil. Da kann man keinen Crawler oder Screenreader durchschicken, nur rudimentär Informationen adressieren und mit Hypertext-Netzwerken hat das wenig zu tun.

                  Diese Trends sagen natürlich wenig über die tatsächlichen Vor- und Nachteile der einen oder der anderen Umsetzung aus. Es geht zwar auch um handfeste Vorteile, aber nicht weniger um bekannte, vertraute Bedienkonzepte, Gewohnheiten und Erwartungen.

                  Mathias

                  1. Hallo Mathias,

                    Wow, das ist jetzt eine interessante Abhandlung zur Geschichte des Webdesigns, bin beeindruckt. Dafür bekommst du von mir ein fachlich-hilfreich-Voting, und es wird gebookmarked und ausgedruckt, zur weiteren Meditation...

                    Fazit: Man ist also tendenziell in der Web-Gestaltung zu den Wurzeln zurückgekehrt, aber mit zusätzlicher Interaktivität, die man früher nur über PopUps und/oder Frames lösen konnte.

                    Man kann also sagen, dass Frames oder PopUps heutzutage immer weniger verwendet werden. Und weil dem so ist, ist es auch gut (Esst Kot! Millionen Fliegen können nicht irren!), oder auch umgekehrt (Und Er sah, dass es sehr gut war).

                    Leider hat das auch dazu geführt, dass alle Seiten mehr oder weniger gleich aussehen. Vielleicht ist das sogar ein Vorteil. Irgendwann hat man sich ja auch darauf geeinigt, Anwendungsfenster so zu gestalten, dass u.A. oben horizontal ein Menü zu finden ist (Datei – Bearbeiten - Ansicht usw). Es gibt meines Wissens dafür einen Standard, habe aber vergessen, wie der heißt. So muss man sich nicht für jedes Programm umgewöhnen.

                    Die Sache mit den PopUps ist klar: Die werden einfach zu sehr für Werbezwecke missbraucht. Wer will schon den Bildschirm mit 20 Fensterchen zugepflastert sehen, die von selber erscheinen und wie bei der Hydra durch Schließen eines PopUps gleich zwei weitere sich öffnen...

                    Diese Trends sagen natürlich wenig über die tatsächlichen Vor- und Nachteile der einen oder der anderen Umsetzung aus. Es geht zwar auch um handfeste Vorteile, aber nicht weniger um bekannte, vertraute Bedienkonzepte, Gewohnheiten und Erwartungen.

                    Nun, gerade "bekannte, vertraute Bedienkonzepte, Gewohnheiten und Erwartungen" werden doch von Frames nicht grundsätzlich über den Haufen geworfen. Viele erfolgreiche Anwendungsprogramme arbeiten mit verschiedenen kleineren Fenstern für Einstellungen usw. Das ist einem Computer-Anwender doch eigentlich sehr vertraut.

                    Web-Anwendung dürfen, wenn der von dir gezeichnete Trend sich endgültig durchsetzt, also keine "Anwendungen" mehr sein, sondern müssen, selbst wenn sie Andungen sind, in der Verkleidung eines flachen Dokuments daherkommen. Naja, ich bin noch immer nicht restlos davon überzeugt, dass das der Weisheit letzter Schluss ist.

                    Gruß, Don P

                    1. Hellihello DonP,

                      Web-Anwendung dürfen, wenn der von dir gezeichnete Trend sich endgültig durchsetzt, also keine "Anwendungen" mehr sein, sondern müssen, selbst wenn sie Andungen sind, in der Verkleidung eines flachen Dokuments daherkommen. Naja, ich bin noch immer nicht restlos davon überzeugt, dass das der Weisheit letzter Schluss ist.

                      Das hast Du aber schön formuliert. Trifft auch meine Ansicht. Nur frag ich mich, was "Andungen" sind, das Pendant zu "Alpungen" oder "Pyrenäungen"?

                      Dank und Gruß,

                      frankx

                      1. Hallo,

                        Das hast Du aber schön formuliert. Trifft auch meine Ansicht. Nur frag ich mich, was "Andungen" sind, das Pendant zu "Alpungen" oder "Pyrenäungen"?

                        Nein, eher sowas wie Himalajungen, oder auch hünenhafte Pygmäungen ;-)

                        Sollte vielleicht mal eine dt. Rechtschreibprüfung im FF installieren...

                        Gruß, Don P

                        --
                4. Man hat sich anscheinend einfach drauf geeinigt, dass Frames in aller Regel unrauchbar sind, basta.

                  Naja, Frames machen im Rahmen einer üblichen Website Probleme, die gelöst werden müssen und zu denen Erfahrung gehört. Aber es gibt durchaus Rahmenbedingungen unter denen sie Sinn machen.

                  Zuerst habe ich gedacht, der Name "SELFHTML" beute soviel wie "HTML selbst gemacht", ohne Vorurteile und ohne bestimmten Fokus. Aber dann habe ich bald gemerkt, dass es eigentlich nur ums WWW geht, d.h. man sollte es vielleicht besser in "WWWHTML" umbenennen und dann erst recht besonders auf Vor- und Nachteile von Frames eingehen.

                  Ich les' das so, dass du das polemisch meinst. Aber eine Doku sollte vollständig sein und die hat auch nichts mit der Meinung die hier im Forum vertreten wird zu tun. Man kann natürlich bei dem einen oder anderen Punkt auf Nachteile oder Schwierigkeiten hinweisen, aber im grossen und ganzen ist selfhtml neutral. Wo du aus der Doku, deinen oben genannten Standpunkt herrausliest, ist mir nicht so klar. Das Forum und die Doku sind zwei völlig unterschiedliche Sachen und das ist ja genau das was du erwartest.

                  Dass Browser ohnehin eigenmächtig den Zeilenumbruch dynamisch an die Fenstergröße bzw. den Viewport anpassen, ist IMO kein Vorteil und kein brauchbares Argument gegen Frames, denn Browser haben anscheinend nicht die geringste Ahnung von Typografie. Jeder Typograf lernt im ersten Lehrjahr, dass die Zeilenlänge zwischen 50 und 60 Zeichen betragen sollte, damit ein Text noch gut lesbar ist.

                  Das was du ansprichst ist ein ganz normales Verhalten von Fließtext, in allen Anwendungen - überall!
                  Um die von dir gewünschte Zeilenbreite anzuzeigen musst du überall das Seitenformat entsprechend formatieren. Auch in einer textverarbeitung wird bei einer grossen Auflösung im Vollbild mit der enstprechenden Schriftgröße 100 und mehr Zeichen pro Zeile angezeigt. Das ist also Aufgabe des Gestalters und nicht des Programmes das zu verhindern, z.b. indem du die Seitengröße und/oder die Rändern entsprechend setzt.

                  In den Printmedien wird das berücksicht, aber am Bildschirm?

                  Wenn du mir zeigst wie du mit ein und der gleichen Druckvorlage im Printbereich auf verschiedenen Formaten druckst, dann stimmt die Aussage, ansonsten kannst du das eine nicht mit dem anderen Vergleichen

                  Z.B. könnte ein DJ seine eigene Musikdatenbank einrichten, [...]. Es sind noch zahlreiche andere Anwendungen denkbar.

                  Genau - Frames können durchaus Sinn machen, nicht umsonst bemüht man sich für das Problem an sich, auch einen Nachfolger zu finden (xframes oder teilweise iframes). Ich denke das Problem ist, das HTML relativ viel können muss und gleichzeitig nicht zuviel können darf, es gibt ja ein paar Ansätze Frames ersetzbar zu machen, z.b. die CSS Eigenschaften position:fixed oder overflow:scroll, wie schwierig aber die Umsetzung ist zeigt sich dann aber in den Darstellungsfehler die auftreten können.

                  Ich denke auch dass es keine Diskussion an sich ist, sondern eben - wie auch schon erwähnt - in erster Linie darum geht, dass HTML Anfänger die hier Fragen zu Frames stellen oft die anderen Möglichkeiten oder die Schwierigkeiten mit frames bei Internetseiten nicht kennen und hier deshalb gerne erstmal etwas pauschal die Technik verteufelt wird, um den Fragesteller die Möglichkeiten zu geben darüber sich Gedasnken zu machen.

                  Struppi.

                  1. Hello out there!

                    Aber eine Doku sollte vollständig sein […] Man kann natürlich bei dem einen oder anderen Punkt auf Nachteile oder Schwierigkeiten hinweisen, aber im grossen und ganzen ist selfhtml neutral.

                    Nicht „kann“, sondern „sollte“! Der Sinn von SELFHTML ist es nicht, stur alle HTML-Elemente und ihre Attribute und CSS-Eigenschaften aufzulisten, das tun schon die HTML-/CSS-Spezifikationen.

                    SELFHTML ist keine Spezifikation, sondern ein Tutorial (und muss als solches nicht einmal notwendigerweise vollständig sein).

                    Wenn also in SELFHTML Framesets erwähnt werden (Sollten sie das überhaupt? Ich denke, ja.), dann sollte auch auf die dadurch entstehenden Probleme für die Nutzer hingewiesen werden.

                    Ich denke auch dass es […] in erster Linie darum geht, dass HTML Anfänger die hier Fragen zu Frames stellen oft die anderen Möglichkeiten oder die Schwierigkeiten mit frames bei Internetseiten nicht kennen und hier deshalb gerne erstmal etwas pauschal die Technik verteufelt wird, um den Fragesteller die Möglichkeiten zu geben darüber sich Gedasnken zu machen.

                    ACK.

                    Ein Tutorial wie SELFHTML sollte die Dinge auch nicht aus der Sicht des Systems (der Sprachen HTML, CSS, …) beschreiben, sondern aus der Sicht des Webseitenautors, der nicht fragt „Was kann HTML/CSS so alles?“, sondern „Wie erreiche ich …?“

                    An der Stelle wäre eine Gegenüberstellung von Framesets und serverseitigen Include-Techniken gut – selbstverständlich neutral, d.h. nicht voreingenommen. Neutral heißt ja nicht, dass aus der Gegenüberstellung keine Technik als Sieger hervorgehen darf; es kann anhand der zusammengetragenen Vor- und Nachteile durchaus eine Empfehlung gegeben werden.

                    Die Befürworter von „Enduring Framedom“ haben mir noch kein schlüssiges Argument geliefert, was mit Frames möglich sein soll, was mit serverseitigen Include-Techniken nicht möglich wäre.

                    See ya up the road,
                    Gunnar

                    --
                    „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
                    1. Hellihello Gunnar,

                      Aber eine Doku sollte vollständig sein […] Man kann natürlich bei dem einen oder anderen Punkt auf Nachteile oder Schwierigkeiten hinweisen, aber im grossen und ganzen ist selfhtml neutral.

                      Nicht „kann“, sondern „sollte“! Der Sinn von SELFHTML ist es nicht, stur alle HTML-Elemente und ihre Attribute und CSS-Eigenschaften aufzulisten, das tun schon die HTML-/CSS-Spezifikationen.

                      SELFHTML ist keine Spezifikation, sondern ein Tutorial (und muss als solches nicht einmal notwendigerweise vollständig sein).

                      Aber über Frames steht ja nun mal was drin.

                      Wenn also in SELFHTML Framesets erwähnt werden (Sollten sie das überhaupt? Ich denke, ja.), dann sollte auch auf die dadurch entstehenden Probleme für die Nutzer hingewiesen werden.

                      Natürlich.

                      Ich denke auch dass es […] in erster Linie darum geht, dass HTML Anfänger die hier Fragen zu Frames stellen oft die anderen Möglichkeiten oder die Schwierigkeiten mit frames bei Internetseiten nicht kennen und hier deshalb gerne erstmal etwas pauschal die Technik verteufelt wird, um den Fragesteller die Möglichkeiten zu geben darüber sich Gedasnken zu machen.

                      ACK.

                      Das wäre doch fein.

                      Ein Tutorial wie SELFHTML sollte die Dinge auch nicht aus der Sicht des Systems (der Sprachen HTML, CSS, …) beschreiben, sondern aus der Sicht des Webseitenautors, der nicht fragt „Was kann HTML/CSS so alles?“, sondern „Wie erreiche ich …?“

                      An der Stelle wäre eine Gegenüberstellung von Framesets und serverseitigen Include-Techniken gut – selbstverständlich neutral, d.h. nicht voreingenommen. Neutral heißt ja nicht, dass aus der Gegenüberstellung keine Technik als Sieger hervorgehen darf; es kann anhand der zusammengetragenen Vor- und Nachteile durchaus eine Empfehlung gegeben werden.

                      Die Befürworter von „Enduring Framedom“ haben mir noch kein schlüssiges Argument geliefert, was mit Frames möglich sein soll, was mit serverseitigen Include-Techniken nicht möglich wäre.

                      Nun, um zu sagen, was mit Frames möglich ist, was mit anderen Techniken nicht möglich ist, braucht es keine schlüssigen Argumente.

                      Frames bieten die Möglichkeit:
                      1. verschieden Fenster zu öffnen bzw. u.U. sogar logisch voneinander unabhängige Inhalte zu präsentieren.
                      2. dem User die Möglichkeit zu geben, diese in der größe anzupassen
                      3. sind die ursprüngliche Lösung für das "Problem" mehrere unabhängig voneinanders scrollbaren Bereiche.
                      4. erlauben includen von HTML mit HTML - keine weitere "serverseitige" Technik nötig. Alles was ich brauch, ist ein Texteditor und ein Browser.
                      5. Navigation und Inhalt logisch-semantisch stringent in zwei Dokumenten darzustellen. Navi ist Kapitelliste <h1>Inhalt</h1><ul class="navigation"><li>...</li></ul>, Inhalt ist wirklich nur Inhalt, ohne Kapitelliste o.ä..

                      Was hat denn Dein drüber Schlafen zu letztem Punkt gebracht?

                      Dank und Gruß,

                      frankx

                      1. Hello out there!

                        Nun, um zu sagen, was mit Frames möglich ist, was mit anderen Techniken nicht möglich ist, braucht es keine schlüssigen Argumente.

                        Äh, doch. Womit willst du sonst überzeugen, wenn nicht mit Argumenten?

                        Frames bieten die Möglichkeit:

                        1. verschieden Fenster zu öffnen bzw. u.U. sogar logisch voneinander unabhängige Inhalte zu präsentieren.

                        Richtig, genau das ist eine sinvolle Anwendung von Framesets (wenn man es dem Benutzer nicht selbst überlassen möchte, die verschiedenen Dokumente in verschiedenen Fenstern/Tabs darzustellen).

                        Was ein N00bie aber mit Frames vorhat zu tun, ist die Aufsplittung _eines_ Dokuments. Dafür sind Frames denkbar schlecht.

                        1. dem User die Möglichkeit zu geben, diese in der größe anzupassen

                        Ist das sinnvoll? Ja, durchaus. Wenn ein Nutzer gerade nicht navigieren will, sondern den Seiteninhalt lesen, könnte er aus Platzgründen die (seitliche) Navigation ausblenden wollen. Diese Funktionalität ist aber durchaus auch mit JavaScript zu realisieren, dafür braucht es keine Frames.

                        1. sind die ursprüngliche Lösung für das "Problem" mehrere unabhängig voneinanders scrollbaren Bereiche.

                        Auch das geht ohne Frames mit CSS.

                        1. erlauben includen von HTML mit HTML - keine weitere "serverseitige" Technik nötig. Alles was ich brauch, ist ein Texteditor und ein Browser.

                        Wo ist das Problem, sich Webspace mit SSI/PHP/… zu besorgen? Wo ist das Problem, einen Editor zu benutzen, der Inhalte aus anderen Dateien dynamisch ins zu bearbeitende Dokument einfügt?

                        Ein Webseitenautor sollte die richtigen Werkzeuge wählen und nutzen, nicht sich hinter seinen ungeeigneten Werkzeugen verstecken und deren Mängel auf die Nutzer abwälzen.

                        1. Navigation und Inhalt logisch-semantisch stringent in zwei Dokumenten darzustellen. Navi ist Kapitelliste <h1>Inhalt</h1><ul class="navigation"><li>...</li></ul>, Inhalt ist wirklich nur Inhalt, ohne Kapitelliste o.ä..

                        Was hat denn Dein drüber Schlafen zu letztem Punkt gebracht?

                        (Gähn) Oh, schon so spät? |-)

                        Deine Bedenken, dass die Navigation nicht zum Hauptinhalt gehört und gleichberechtigt neben (im Sinne des Elementbaums) dessen Überschrift und Textabsätzen stehen sollte, kann ich nachvollziehen.

                        Andererseits beschreibt HTML nicht nur den Hauptinhalt, sondern eine gesamte Webseite, und da gehört die Navigation zu anderen Seiten mit dazu (sonst würde das H im HTML seinen Sinn verlieren). Und die Links zu anderen Seiten finden sich sinnvollerweise nicht nur im Fließtext, sondern auch in einem Navigationsmenü.

                        Eine Webseite umfasst also neben ihrem Hauptinhalt auch ein Navigationsmenü; beides gehört zusammen in _ein_ Dokument, das die gesamte Webseite beschreibt.

                        Du willst nun Navigation und Hauptinhalt trennen? Dazu müssen sie nicht in zwei Dokumente getrennt werden; sie können zwei Knoten im selben Dokument sein (was oft sowieso gemacht wird; es ist für die Formatierung mit CSS nützlich):

                        <body>  
                          <ul id="Navigation">  
                            <li><a href="foo">Foo</a></li>  
                            <li><a href="bar">Bar</a></li>  
                          </ul>  
                          <div id="Inhalt">  
                            <h1>Lorem ipsum</h1>  
                            <p>Lorem ipsum dolor sit amet.</p>  
                          </div>  
                        </body>
                        

                        Und schon steht die Navigation nicht gleichberechtigt neben Überschrift und Textabsätzen des Hauptinhalts, sondern ist fein säuberlich von diesem getrennt.

                        See ya up the road,
                        Gunnar

                        --
                        „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
                        1. Hellihello Gunnar,

                          Nun, um zu sagen, was mit Frames möglich ist, was mit anderen Techniken nicht möglich ist, braucht es keine schlüssigen Argumente.

                          Äh, doch. Womit willst du sonst überzeugen, wenn nicht mit Argumenten?

                          Na Fakten, dachte ich (;-).

                          Frames bieten die Möglichkeit:

                          1. verschieden Fenster zu öffnen bzw. u.U. sogar logisch voneinander unabhängige Inhalte zu präsentieren.

                          Richtig, genau das ist eine sinvolle Anwendung von Framesets (wenn man es dem Benutzer nicht selbst überlassen möchte, die verschiedenen Dokumente in verschiedenen Fenstern/Tabs darzustellen).

                          Gut, also 1 Argument. BTW: kannst Du in Deinem Browser zwei Tabs nebeneinander darstellen? Ich wünschte mir Deine Gewissenhaftigkeit auch für die Argumente der "Gegenseite".

                          Was ein N00bie aber mit Frames vorhat zu tun, ist die Aufsplittung _eines_ Dokuments. Dafür sind Frames denkbar schlecht.

                          Unterstellung 1., 2. egal, denn es geht aktuell hier darum, was Frames können was anderes nicht kann. Und vergiss bitte nicht auch, dass der Autor auch einen berechtigten Willen hat. Er ist nicht Sklave eines imaginären MonsterUsers.

                          1. dem User die Möglichkeit zu geben, diese in der größe anzupassen

                          Ist das sinnvoll? Ja, durchaus.

                          Es ist egal, ob das sinnvoll ist. Die Frage war: was können Frames, was zB SSI nicht kann.

                          Wenn ein Nutzer gerade nicht navigieren will, sondern den Seiteninhalt lesen, könnte er aus Platzgründen die (seitliche) Navigation ausblenden wollen. Diese Funktionalität ist aber durchaus auch mit JavaScript zu realisieren, dafür braucht es keine Frames.

                          Wieder bitte die enstprechende Sorgfalt: Javascript baut auf HTML auf. Was ist, wenn JS deaktivert ist (lol)?

                          1. sind die ursprüngliche Lösung für das "Problem" mehrere unabhängig voneinanders scrollbaren Bereiche.

                          Auch das geht ohne Frames mit CSS.

                          Nein, zumindest nicht die Aufteilung Header fixe Höhe, Footer fixe Breite, Navi-links und News-rechts fixe Breite, Content den Rest in der Mitte, Scrollbar für den Content im Content-Fenster und sonst nirgends. (Ich habe nur abgespeichert, dass nicht jede erdenkliche Framelösung 1:1 mit CSS umsetzbar ist, bitte korrigiere mich, am besten mit Link wenn möglich).

                          1. erlauben includen von HTML mit HTML - keine weitere "serverseitige" Technik nötig. Alles was ich brauch, ist ein Texteditor und ein Browser.

                          Wo ist das Problem, sich Webspace mit SSI/PHP/… zu besorgen?

                          Ich glaube nicht, dass wir hier pauschal finanzielle und technische Überlegungen diskutieren, am besten für die zig Millionen Webseitenersteller gleich mit. Bleibe doch bitte bei Deiner Frage und weiche nicht aus, indem du sagst, dass es mit eine bisschen Geld/Technik auch anders geht. Auf den Schulrechnern ist kein PHP installiert. Es ist kein öffentlicher Webspace. Da kann ich das mit den Gegebenheiten (erstmal) nur mit Frames. Das war ja auch Deine Frage.

                          Wo ist das Problem, einen Editor zu benutzen, der Inhalte aus anderen Dateien dynamisch ins zu bearbeitende Dokument einfügt?

                          Willst Du mir oder anderen vorschreiben, welchen Editor sie benutzen sollen? Notepad ist cool.

                          Ein Webseitenautor sollte die richtigen Werkzeuge wählen und nutzen, nicht sich hinter seinen ungeeigneten Werkzeugen verstecken und deren Mängel auf die Nutzer abwälzen.

                          Diesen Punkt hatten wir beide schon öfter. Dirk Schürjohann hat auch einen schönen Artikel geschrieben dazu im Weblog. Es gibt nicht "den Webseitenautor", gar einen Stand, der sich gewissen Prämissen zu beugen hat. Alles mündige Bürger im Wesentlichen meine ich.

                          1. Navigation und Inhalt logisch-semantisch stringent in zwei Dokumenten darzustellen. Navi ist Kapitelliste <h1>Inhalt</h1><ul class="navigation"><li>...</li></ul>, Inhalt ist wirklich nur Inhalt, ohne Kapitelliste o.ä..

                          Was hat denn Dein drüber Schlafen zu letztem Punkt gebracht?

                          (Gähn) Oh, schon so spät? |-)

                          Deine Bedenken, dass die Navigation nicht zum Hauptinhalt gehört und gleichberechtigt neben (im Sinne des Elementbaums) dessen Überschrift und Textabsätzen stehen sollte, kann ich nachvollziehen.

                          Andererseits beschreibt HTML nicht nur den Hauptinhalt, sondern eine gesamte Webseite, und da gehört die Navigation zu anderen Seiten mit dazu (sonst würde das H im HTML seinen Sinn verlieren). Und die Links zu anderen Seiten finden sich sinnvollerweise nicht nur im Fließtext, sondern auch in einem Navigationsmenü.

                          Eine Webseite umfasst also neben ihrem Hauptinhalt auch ein Navigationsmenü; beides gehört zusammen in _ein_ Dokument, das die gesamte Webseite beschreibt.

                          Du willst nun Navigation und Hauptinhalt trennen? Dazu müssen sie nicht in zwei Dokumente getrennt werden; sie können zwei Knoten im selben Dokument sein (was oft sowieso gemacht wird; es ist für die Formatierung mit CSS nützlich):

                          <body>

                          <ul id="Navigation">
                              <li><a href="foo">Foo</a></li>
                              <li><a href="bar">Bar</a></li>
                            </ul>
                            <div id="Inhalt">
                              <h1>Lorem ipsum</h1>
                              <p>Lorem ipsum dolor sit amet.</p>
                            </div>
                          </body>

                            
                          Nope. Dieses div ist für den hier viel erwähnten Client so nichtssagend wie ein frameset, noch nichtssagender eigentlich. <section> gibts ja noch nicht. Das o.g. ist in meinen Augen ein Workarround für ein Frameset.  
                          
                          >   
                          > Und schon steht die Navigation nicht gleichberechtigt neben Überschrift und Textabsätzen des Hauptinhalts, sondern ist fein säuberlich von diesem getrennt.  
                            
                          Wie gesagt, beim nächsten Roman lass ich auf jede Seite oben links das Inhaltsverzeichnis drucken (;-).  
                          
                          >   
                          > See ya up the road,  
                            
                          Yup, seeya;  
                            
                          frankx
                          
                          1. Hallo,

                            BTW: kannst Du in Deinem Browser zwei Tabs nebeneinander darstellen?

                            Bei einem Browser, der nicht nur Tabs, sondern integrierte Fenster unterstützt, ja.

                            Aber jetzt wirfst du Schreiben und Lesen des Webs durcheinander.

                            Frames nehmen an, dass Tabs und Zurück-Navigation beim Wechseln zwischen Dokumenten einen signifikanteren Mehraufwand mit sich bringen. Nun sind diese Methoden viel flexibler, weil die »Parallelisierung« vom Nutzer vorgenommen wird. Wie gesagt, man arbeitet ständig mit mehreren Tabs und wechselt zwischen ihnen - selbstständig als Anwender. Ein Frameset muss ein Webautor erstellen, die Zusammenstellung macht ein Autor einmal. Dass dabei gerade »logisch voneinander unabhängige Inhalte« vereinigt werden, ist eher die absolute Ausnahme. (Und, wenn es verschiedene Sites sind, als »Framing« sogar verpönt und unterbunden.)

                            Während vor ein paar Jahren noch die autorenseitige Parallelisierung dominierte (target="_blank" für jeden »externen« Link, Popups allerorten, Frames sowieso), stelle ich eine radikale Verlagerung fest, die den Anwender ermächtigt. Dafür, dass diese Konzepte vor ein paar Jahren dermaßen hartnäckig vertreten wurden (»kein externer Link ohne target="_blank"!«, alle möglichen Unterinformationen wurden in Popups untergebracht), sind sie absurd sang- und klanglos abgetreten. Früher sah man das offenbar alles paternalistischer. Diese historische Perspektive relativiert für mich vieles.

                            Nein, zumindest nicht die Aufteilung Header fixe Höhe, Footer fixe Breite, Navi-links und News-rechts fixe Breite, Content den Rest in der Mitte, Scrollbar für den Content im Content-Fenster und sonst nirgends.

                            Das müsste gehen, die Frage ist, welchen Sinn so ein Layout hat...

                            Dieses div ist für den hier viel erwähnten Client so nichtssagend wie ein frameset

                            Der Vorwurf müsste eher heißen, die ul-Navigation ist nichtssagend, deshalb arbeitet man auch am nl-Element und nicht an derWirklicheDokumentinhaltOhneNavigation.

                            Mathias

                            1. Hellihello Mathias,

                              BTW: kannst Du in Deinem Browser zwei Tabs nebeneinander darstellen?

                              Bei einem Browser, der nicht nur Tabs, sondern integrierte Fenster unterstützt, ja.

                              Aber jetzt wirfst du Schreiben und Lesen des Webs durcheinander.

                              Ich wollte darauf hinaus, dass Tabs und Windows was anderes sind. Gunnars Frage war ja klar umgrenzt: was können Frames, was nicht anders geht.

                              Frames nehmen an, dass Tabs und Zurück-Navigation beim Wechseln zwischen Dokumenten einen signifikanteren Mehraufwand mit sich bringen. Nun sind diese Methoden viel flexibler, weil die »Parallelisierung« vom Nutzer vorgenommen wird.

                              Wenn Ersteller und Nutzer aber in einer Feedbackschleife hängen (Intranet, Eigennutz)?

                              Wie gesagt, man arbeitet ständig mit mehreren Tabs und wechselt zwischen ihnen - selbstständig als Anwender.

                              Du unterstellst hier ein StandardUserVerhalten.

                              Ein Frameset muss ein Webautor erstellen, die Zusammenstellung macht ein Autor einmal. Dass dabei gerade »logisch voneinander unabhängige Inhalte« vereinigt werden, ist eher die absolute Ausnahme.

                              Es geht nicht darum, wie oft das geschieht, sondern wie und ob es möglich ist und wenn ja, ob nur mit Frames. Dies war eine Antwort auf Gunnars konkrete Frage.

                              Während vor ein paar Jahren noch die autorenseitige Parallelisierung dominierte (target="_blank" für jeden »externen« Link, Popups allerorten, Frames sowieso), stelle ich eine radikale Verlagerung fest, die den Anwender ermächtigt.

                              Nun, externe Links sollen ausgezeichnet sein. Aber anders als mit target.

                              Dafür, dass diese Konzepte vor ein paar Jahren dermaßen hartnäckig vertreten wurden (»kein externer Link ohne target="_blank"!«

                              ... externe Links als solche kennzeichnen...

                              , alle möglichen Unterinformationen wurden in Popups untergebracht), sind sie absurd sang- und klanglos abgetreten.

                              Doch aber nur, weil Popups geblockt werden, vom FF, von der GoogleToolbar etc. - wegen Werbungsmissbrauch.

                              Früher sah man das offenbar alles paternalistischer. Diese historische Perspektive relativiert für mich vieles.

                              Infos werden nach wie vor vor Ort in kleinen Fenstern angeboten. Mittlerweile als eingebautes absolut positioniertes Div per Javascript. Solche Vor-Ort-Deklarationen oder "steht-auf-einem-anderen-Blatt" machen ja oft auch viel Sinn.

                              Nein, zumindest nicht die Aufteilung Header fixe Höhe, Footer fixe Breite, Navi-links und News-rechts fixe Breite, Content den Rest in der Mitte, Scrollbar für den Content im Content-Fenster und sonst nirgends.

                              Das müsste gehen, die Frage ist, welchen Sinn so ein Layout hat...

                              Die Frage war, was geht mit Frames, was ohne nicht geht. Das o.g. Layout erklärt sich in seinem Sinn doch fast von selbst: Header (statische oder dynamische Kopfzeile) und Footer (s. Header) sind doch bekannt bei Dokumenten. Die Aufteilung einer Seite in drei Spalten wird oft betrieben. O.g. geht nicht, weil der Content seine Größe nicht kennt, und die müsste er kennen, um scrollbar zu werden (zumindest seine Höhe müsste er wissen).

                              Dieses div ist für den hier viel erwähnten Client so nichtssagend wie ein frameset

                              Der Vorwurf müsste eher heißen, die ul-Navigation ist nichtssagend, deshalb arbeitet man auch am nl-Element und nicht an derWirklicheDokumentinhaltOhneNavigation.

                              Nun, wieder auf Gunnars Frage zurückführen bitte. Wenn wir perspektivisch diskutieren, könnte man auch vorschlagen, für Frames reservierte Attributwerte vorzuschlagen:
                              title="header|footer|navi1-navi3|content|news|advertisement".

                              Ansonsten erwähnte ich ja auch, analog zum <nl>, dass ich mal las, dass <section> als umgegendes Element für <h?> und seine Absätze kommen soll.

                              Dank und Gruß,

                              frankx

                              1. Hallo,

                                Wie gesagt, man arbeitet ständig mit mehreren Tabs und wechselt zwischen ihnen - selbstständig als Anwender.

                                Du unterstellst hier ein StandardUserVerhalten.

                                Eigentlich zeichne ich nur die Paradigmen nach, wie ich sie historisch erlebt habe. Heute geht man bei der Konzeption von Seiten davon aus, dass die aktive Benutzung von Back-Button und Tabs Standard sind. Ja, das kann man feststellen - vor allem in Abgrenzung zur Vergangenheit, in der diese Annahme nicht existierte. Ob das so richtig ist, muss man natürlich hinterfragen. Auf die Popup-Euphorie habe ich damals auch nur geantwortet: Die behauptete Unmündigkeit (»aber der User kann ja nicht den Browser bedienen, ich muss ihm assistieren«) ist keine überhistorische Tatsache mit ewiger Geltung, sondern man KANN den Benutzer auch anders behandeln.

                                Nun, externe Links sollen ausgezeichnet sein.

                                Auch so ein Dogma. ;)
                                Überall, wo ich tätig bin, schert man sich darum mittlerweile gar nicht mehr.

                                , alle möglichen Unterinformationen wurden in Popups untergebracht), sind sie absurd sang- und klanglos abgetreten.

                                Doch aber nur, weil Popups geblockt werden, vom FF, von der GoogleToolbar etc. - wegen Werbungsmissbrauch.

                                Übrigens:
                                Wenn ich hier von Popups rede und sie mit Frames vergleiche, dann blende ich deren Missbrauch aus und denke nur an die normale Anwendung. Werbe-Popups sind kein Thema für mich, darüber wird auch nicht inhaltlich gestritten. Interessiert habe ich mich für Popup-Fenster, die mit dem Argument eingesetzt wurden, dass man dem Benutzer ja beide Dokument nebeneinander anzeigen will, auf dass er sie aufeinander beziehen kann und ein Wechsel zwischen ihnen einfach möglich ist. Also ein Argument, das auch oft zur Legitimation von Frames herhalten muss.

                                Die Frage war, was geht mit Frames, was ohne nicht geht.

                                Ok.
                                (Für mich eine eher uninteressante Herangehensweise, ich seh solche Techniken vor allem im Vergleich eher funktional...)

                                Das o.g. Layout erklärt sich in seinem Sinn doch fast von selbst

                                Die Struktur ist auch weniger der springende Punkt, sondern das »ständig im Blick haben«.
                                Lustigerweise, und das ist ein Umstand, den man vor ein paar Jahren auch nie erwartet hätte, wird position:fixed gar nicht so oft verwendet. Früher galt das als megadolle Sache und Frameskiller, nur IE 6 stand im Weg, aber Workarounds gabs en masse. Mittlerweile kann der IE position:fixed, aber eine breite Anwendung gibts trotzdem nicht... Alles sehr absurd. ;)

                                Nun, wieder auf Gunnars Frage zurückführen bitte. Wenn wir perspektivisch diskutieren, könnte man auch vorschlagen, für Frames reservierte Attributwerte vorzuschlagen:
                                title="header|footer|navi1-navi3|content|news|advertisement".

                                Lies dir vielleicht mal die verlinkte Diskussion mit emu durch, damals wurden logische Beziehungen viel diskutiert. In HTML gibts dazu bereits Mechanismen wie das link-Element und das rel-Attribut.

                                Mathias

                                1. Hellihello Mathias,

                                  Hallo,

                                  Wie gesagt, man arbeitet ständig mit mehreren Tabs und wechselt zwischen ihnen - selbstständig als Anwender.

                                  Du unterstellst hier ein StandardUserVerhalten.

                                  Eigentlich zeichne ich nur die Paradigmen nach, wie ich sie historisch erlebt habe.

                                  Genau. Versuchen wir es doch mal damit, dass wir schauen, ob Frames für Spezialanwendung ein geeignetes Werkzeug sein könnten.

                                  Heute geht man bei der Konzeption von Seiten davon aus, dass die aktive Benutzung von Back-Button und Tabs Standard sind. Ja, das kann man feststellen - vor allem in Abgrenzung zur Vergangenheit, in der diese Annahme nicht existierte.

                                  Ich habe für den Freundeskreis der Schule eine kleine Seite gebaut. Als Frameset, links Navi, rechts Content. Ca. 8 Menüpunkte. Da kommt mir kein Back-Button in die Quere (also keine Mausgeste bei mir jetzt), denn die funktionieren einwandfrei.

                                  Ich überlege auch nicnt, ob ich mit PHP oder einem entsprechenden Editor die Seite frameless machen sollte. Sie funktioniert doch prima und hat bezogen auf ihre Zwecke keinen Nachteil und es war/ist (für mich, den Autoren) die einfachste und zwweckmäßigste Lösung gewesen.

                                  Ob das so richtig ist, muss man natürlich hinterfragen. Auf die Popup-Euphorie habe ich damals auch nur geantwortet: Die behauptete Unmündigkeit (»aber der User kann ja nicht den Browser bedienen, ich muss ihm assistieren«) ist keine überhistorische Tatsache mit ewiger Geltung, sondern man KANN den Benutzer auch anders behandeln.

                                  Hier vermischen sich meiner Ansicht nach drei Dinge und es wird mit undiskutieren Prämissen gehandelt. Mein praktisches Beispiel habe ich ja schon genannt. Generelle Tendenzen im Nutzerverhalten und Moden in der Webseitenerstellung wollte ich garnicht diskutieren, eher die Nützlichkeit einer Technik in bestimmten Zusammenhängen sowie derer Alleinstellungesmerkmale. Zumindest vorerst einmal. Zuletzt dann eben die von Dir angerissene Freiheit des Autors, der sehr wohl entscheiden kann, darf und soll, wie sie/er irgenwelchen Nutzern (das sind ja u.U. auch nur abgegrenzte Gruppen) etwas präsentieren will.

                                  Nun, externe Links sollen ausgezeichnet sein.

                                  Auch so ein Dogma. ;)
                                  Überall, wo ich tätig bin, schert man sich darum mittlerweile gar nicht mehr.

                                  Nun ja, ich persönliche sehe da grundsätzlich erstmal einen Vorteil, zwischen externem und internem Link zu unterscheiden. Verweise nach aussen bekommen im Frameset einen target="_blank". Die will ich als Autor in einem anderen Fenster erscheinen lassen. Ja, ich als Autor bestimme, was der User auf meiner Webseite zu sehen bekommt. Sorry, ich nix Sklave von MonsterUser.

                                  , alle möglichen Unterinformationen wurden in Popups untergebracht), sind sie absurd sang- und klanglos abgetreten.

                                  Doch aber nur, weil Popups geblockt werden, vom FF, von der GoogleToolbar etc. - wegen Werbungsmissbrauch.

                                  Übrigens:
                                  Wenn ich hier von Popups rede und sie mit Frames vergleiche, dann blende ich deren Missbrauch aus und denke nur an die normale Anwendung. Werbe-Popups sind kein Thema für mich, darüber wird auch nicht inhaltlich gestritten.

                                  Aber machen es mittlerweile unmöglich, Popups normal zu nutzen, weil die GoogleToolbar und andere Browser sie erstmal hopp wegblenden und ein schlichter Nutzer das u.U. garnicht checkt (zB. Eltern einer Schule).

                                  Interessiert habe ich mich für Popup-Fenster, die mit dem Argument eingesetzt wurden, dass man dem Benutzer ja beide Dokument nebeneinander anzeigen will, auf dass er sie aufeinander beziehen kann und ein Wechsel zwischen ihnen einfach möglich ist. Also ein Argument, das auch oft zur Legitimation von Frames herhalten muss.

                                  Wie gesagt, ich sehe auch die Freiheit der Autoren.

                                  Die Frage war, was geht mit Frames, was ohne nicht geht.

                                  Ok.
                                  (Für mich eine eher uninteressante Herangehensweise, ich seh solche Techniken vor allem im Vergleich eher funktional...)

                                  Nun, Gunnar wollte das explizit wissen, und wenn man das Thema mal komplett durchknautschen will, dann gehörts dazu. Die von mir genannte Seitenaufteilung, header, scrollbarer Rest, ist nur mit Frames realisierbar (wenn der header eine Fixe und keine prozentuale Größe haben soll).

                                  Das o.g. Layout erklärt sich in seinem Sinn doch fast von selbst

                                  Die Struktur ist auch weniger der springende Punkt, sondern das »ständig im Blick haben«.

                                  Freiheit des Autors? (;-). Unterschiedliche User-Vorlieben? Ich mache ja Seiten auch so, weil ich mir sie als User dann praktikabel vorstelle. Ich will es auch garnicht "allen" Recht machen, das geht nämlich nicht.

                                  Lustigerweise, und das ist ein Umstand, den man vor ein paar Jahren auch nie erwartet hätte, wird position:fixed gar nicht so oft verwendet. Früher galt das als megadolle Sache und Frameskiller, nur IE 6 stand im Weg, aber Workarounds gabs en masse. Mittlerweile kann der IE position:fixed, aber eine breite Anwendung gibts trotzdem nicht... Alles sehr absurd. ;)

                                  Wieder eine andere Baustelle, weil wir hier über allgemeine Trends sprechen und nicht über die Nützlichkeit eines Werkzeuges, aber ich führe das darauf zurück, dass sich die Seiten eben einer allgemeinen gepflogenheit anpassen, die zZ. lautet: alles scrollt immer mit.

                                  Nun, wieder auf Gunnars Frage zurückführen bitte. Wenn wir perspektivisch diskutieren, könnte man auch vorschlagen, für Frames reservierte Attributwerte vorzuschlagen:
                                  title="header|footer|navi1-navi3|content|news|advertisement".

                                  Lies dir vielleicht mal die verlinkte Diskussion mit emu durch, damals wurden logische Beziehungen viel diskutiert.

                                  Ah, ich hatte jetzt erstmal nur den Anfang gelesen, wo emu ja sagt, wie ich auch, eine Navi hat in einem Inhaltsdokument eigentlich nichts verloren.

                                  In HTML gibts dazu bereits Mechanismen wie das link-Element und das rel-Attribut.

                                  Lechtz. Kenn ich vom Hörensagen und klingt vielversprechend. Schaff ich es doch, den Frames eine weitere logische Beziehung zueinander zu verpassen - die im Freundeskreis der Schule _niemals_ jemand erfassen wird?

                                  Dank und Gruß,

                                  frankx

                                  1. Hallo frankx

                                    … header, scrollbarer Rest, ist nur mit Frames realisierbar (wenn der header eine Fixe und keine prozentuale Größe haben soll).

                                    Wirklich?

                                    Auf Wiederlesen
                                    Detlef

                                    --
                                    - Wissen ist gut
                                    - Können ist besser
                                    - aber das Beste und Interessanteste ist der Weg dahin!
                                    1. Hellihello Detlef,

                                      Hallo frankx

                                      … header, scrollbarer Rest, ist nur mit Frames realisierbar (wenn der header eine Fixe und keine prozentuale Größe haben soll).

                                      Wirklich?

                                      cool, mit

                                      * html #inhalt {
                                       position:static;
                                       height:100%;
                                       border-top:130px solid green;
                                       border-bottom:110px solid green;
                                      }

                                      Star html hack und einer Border von Kopfzeilenhöhe und Fusszeilenhöhe.

                                      Also, es geht auch anders, aber das wissen nichtmal die cracks hier (abgesehen von den SuperCracks).

                                      Bitte dann noch das Javascript für die Größenänderung per MouseClickAndMove. Für Anfänger sicherlich ein einsichtiger Weg (;-).

                                      Aber bezogen auf die konkrete Frage geht der Punkt natürlich an Dich.

                                      #inhalt {
                                       position:absolute;
                                       top:120px;
                                       right:0;
                                       bottom:100px;
                                       left:0;
                                       border:10px solid green;
                                       overflow:auto;
                                      }

                                      bewirkt dann, bei "normalen" Browsern, dass das auch scrollbar wird ohne eine Höhenangabe. Das war die Krücke, bei der ich bei meinen Recherchen seinerzeit hängengeblieben war.

                                      Ich vermute, dass sich das mit einem Div rechts und einem Links mit entsprchendem margin-left/right für das Contentdiv auch lösen ließe, die rechts und links dann ebenfalls mit Scrollbar. Dann per Ajax nur das inhalt-Div auswechseln, und ein Frameset ist nachgebaut. Bitte gebt wenigstens zu, dass es zwar möglich ist, aber doch an Know-How nicht mehr zu toppen. Ich schätz mich nicht als allzu hirnträge ein, aber diese alternativen per CSS fand ich dann inklusive der hacks für den IE doch recht anspruchsvoll im Ganzen und keinesfalls anfängertaubglich.

                                      Dank und Gruß,

                                      frankx

                                      1. Hallo frankx

                                        Also, es geht auch anders, aber das wissen nichtmal die cracks hier (abgesehen von den SuperCracks).

                                        Bei dem Beispiel bestand die Anforderung darin, dass nur der Inhalt innerhalb der Border scrollt. Das währe wohl eine wüste Framekonsruktion geworden.

                                        bewirkt dann, bei "normalen" Browsern, dass das auch scrollbar wird ohne eine Höhenangabe. Das war die Krücke, bei der ich bei meinen Recherchen seinerzeit hängengeblieben war.

                                        Und die Krücke ist die mangelnde Unterstützung von prosition:absolute durch den IE, der dann extra im Quirksmodus überredet werden muss.

                                        Ich vermute, dass sich das mit einem Div rechts und einem Links mit entsprchendem margin-left/right für das Contentdiv auch lösen ließe, die rechts und links dann ebenfalls mit Scrollbar.

                                        Nicht gleich übertreiben.

                                        Dann per Ajax nur das inhalt-Div auswechseln, und ein Frameset ist nachgebaut.

                                        Also abhängig von Javascript und ansonsten eine perfekte Verknüpfung der jeweiligen Nachteile. ;)

                                        Bitte gebt wenigstens zu, dass es zwar möglich ist, aber doch an Know-How nicht mehr zu toppen.

                                        Nö, für mich wären jegliche serverseitigen Spielereien wesentich komplizierter als so ein bisschen CSS.

                                        Ich schätz mich nicht als allzu hirnträge ein, aber diese alternativen per CSS fand ich dann inklusive der hacks für den IE doch recht anspruchsvoll im Ganzen und keinesfalls anfängertaubglich.

                                        Als wirklich anfängertauglich empfinde ich Framesets auch nicht. Sie scheinen erst so schön einfach und erst später fallen dann diverse Probleme auf.

                                        Was mich auch an Framesets stört ist, dass es ohne Javascript keine Möglichkeit gibt, die Breite der Fenster von der Schriftgröße abhängig zu machen.

                                        Auf Wiederlesen
                                        Detlef

                                        --
                                        - Wissen ist gut
                                        - Können ist besser
                                        - aber das Beste und Interessanteste ist der Weg dahin!
                                        1. Hellihello Detlef,

                                          Also, es geht auch anders, aber das wissen nichtmal die cracks hier (abgesehen von den SuperCracks).

                                          Bei dem Beispiel bestand die Anforderung darin, dass nur der Inhalt innerhalb der Border scrollt. Das währe wohl eine wüste Framekonsruktion geworden.

                                          Jap. btw: wer stellt denn solche "Anforderungen" (eine Ausbildung?)?

                                          bewirkt dann, bei "normalen" Browsern, dass das auch scrollbar wird ohne eine Höhenangabe. Das war die Krücke, bei der ich bei meinen Recherchen seinerzeit hängengeblieben war.

                                          Und die Krücke ist die mangelnde Unterstützung von prosition:absolute durch den IE, der dann extra im Quirksmodus überredet werden muss.

                                          also Quirks und * html - hack? Wer soll denn sowas wissen.

                                          übrigens, äh - btw, wird man von "prosition:absolute" betrunken?

                                          Ich vermute, dass sich das mit einem Div rechts und einem Links mit entsprchendem margin-left/right für das Contentdiv auch lösen ließe, die rechts und links dann ebenfalls mit Scrollbar.

                                          Nicht gleich übertreiben.

                                          cool. scrollt ja auch, im FF getestet.

                                          Dann per Ajax nur das inhalt-Div auswechseln, und ein Frameset ist nachgebaut.

                                          Also abhängig von Javascript und ansonsten eine perfekte Verknüpfung der jeweiligen Nachteile. ;)

                                          Klar, ich wollte ja auch daruf hinaus, dass man sich mit dem Frame-Ersatz "auch" "Probleme" einhandelt, abgesehen vom nötigen Knoff-Hoff.

                                          Bitte gebt wenigstens zu, dass es zwar möglich ist, aber doch an Know-How nicht mehr zu toppen.

                                          Nö, für mich wären jegliche serverseitigen Spielereien wesentich komplizierter als so ein bisschen CSS.

                                          Also für Anfänger ist das nicht "ein bisschen". Außerdem brauchst Du doch dennoch serverseitige Techniken, um die 50 Navigationsspunkte in den 50 Dokumenten aktuell zu halten.

                                          Ich schätz mich nicht als allzu hirnträge ein, aber diese alternativen per CSS fand ich dann inklusive der hacks für den IE doch recht anspruchsvoll im Ganzen und keinesfalls anfängertaubglich.

                                          Als wirklich anfängertauglich empfinde ich Framesets auch nicht. Sie scheinen erst so schön einfach und erst später fallen dann diverse Probleme auf.

                                          Naja, das wäre ja der schlichte Punkt: Die gehen, man kapiert auch was, sie sind u.U. begrenzt tauglich. Nicht jeder, der was mit Web zu tun hat, möchte ein Web-Profi sein und werden. Und dem einen liegt mehr PHP, dem anderen CSS. Was mich bei Gunnars Anti-Frame-Feldzug stört ist die grundsätzliche "vermeide Frames"  Aussage. Ich finde, das passt auch nicht wirklich zum Geist der Forums. Natürlich kann er seine Meinung haben, und er kann sie auch schreiben, und ich kanns und wills ihm auch garnicht verbieten, um das mal vorwegzunehmen.

                                          Was mich auch an Framesets stört ist, dass es ohne Javascript keine Möglichkeit gibt, die Breite der Fenster von der Schriftgröße abhängig zu machen.

                                          Jap, der Vorlieben und Geschmäcker gibt es viele. Nimm doch Tabellen *lol* - kleiner Scherz.

                                          Dank und Gruß,

                                          frankx

                                          1. Hallo frankx

                                            Jap. btw: wer stellt denn solche "Anforderungen" (eine Ausbildung?)?

                                            Fragesteller in diesem Forum (allerdings existiert wohl das Bild nicht mehr).

                                            also Quirks und * html - hack? Wer soll denn sowas wissen.

                                            Der, der in den Quelltext schaut. ;)

                                            übrigens, äh - btw, wird man von "prosition:absolute" betrunken?

                                            Selbstverständlich, und wenn man IE heißt, dann sogar ohne „r”.

                                            cool. scrollt ja auch, im FF getestet.

                                            Auch zumindest im 6er IE (mangels IE7 konnte ich es dort noch nicht testen).

                                            Klar, ich wollte ja auch daruf hinaus, dass man sich mit dem Frame-Ersatz "auch" "Probleme" einhandelt, abgesehen vom nötigen Knoff-Hoff.

                                            Wenn man übertreibt, dann ja.
                                            Welche Technologie für das Einbinden der Inhalte verwendet wird, sollte genau überlegt werden. Meiner Meinung nach sind Frames, wie auch Ajax für „Standardwebseiten” nicht wirklich geeignet. Für spezielle Anforderungen können (I)Frames oder auch Ajax geeignet sein, je nachdem, ob und welche browserseitigen Funktionen erforderlich sind.

                                            Also für Anfänger ist das nicht "ein bisschen". Außerdem brauchst Du doch dennoch serverseitige Techniken, um die 50 Navigationsspunkte in den 50 Dokumenten aktuell zu halten.

                                            Welcher Anfänger verwaltet Seiten mit 50 oder mehr Navigationspunkten, die sich so häufig ändern, dass es mittels dateiübergreifendem Suchen & Ersetzen oder editorseitiger Includetechnik nicht beherrschbar wäre.
                                            Außerdem finde ich das serverseitige Einbinden der Navigation in komplette Einzelseiten trivial im Vergleich zu den von Cybaer erwähnten Möglichkeiten die Probleme mit Frames zu umschiffen.

                                            Naja, das wäre ja der schlichte Punkt: Die gehen, man kapiert auch was, sie sind u.U. begrenzt tauglich.

                                            Und dann, nachdem es erst so einfach schien, wird viel Energie darauf verwendet, Hintergrundbilder zu teilen und anzupassen, Nachladescripte zu basteln, zu versuchen, Ausklappmenüs frameübergreifend zu bekommen, statt sich gleich ein wenig intensiver mit CSS und Includetechniken zu beschäftigen. (Interessant finde ich hier immer wieder die Fragen, wie man das Frameset dazu bewegen kann, sich im Browser wie eine Einzelseite zu verhalten.)

                                            Nicht jeder, der was mit Web zu tun hat, möchte ein Web-Profi sein und werden. Und dem einen liegt mehr PHP, dem anderen CSS.

                                            Nur an CSS kommt man früher oder später sowieso nicht vorbei, die umfangreiche Beschäftigung mit Framesets könnte man durchaus vermeiden.

                                            Was mich bei Gunnars Anti-Frame-Feldzug stört ist die grundsätzliche "vermeide Frames"  Aussage. Ich finde, das passt auch nicht wirklich zum Geist der Forums.

                                            Uns gibt es nur mit Meinung und ungebetener Beratung.

                                            Diese ganzen Framediskussionen finde ich nervig, meist läuft es doch so ab:

                                            • Ein Anfänger stellt eine Frage zu Problemen mit seinem Frameset, die er ohne dieses übehaupt nicht hätte.
                                            • jemand weist darauf hin oder/und verlinkt auf den Subotnik Artikel
                                              Und schon haben wir eine wilde Diskussion, bei der eine Seite ausführt, dass Frames Probleme bereiten (können), die der Anfänger (noch) nicht überblickt, worauf die andere kontert, dass es ja gar nicht wirklich Probleme sind, weil sich diese für einen Fortgeschrittenen mit entsprechenden Erfahrungen vermeiden lassen.

                                            Wer unbedingt Frames verwenden will, soll es tun, aber bitte nicht, weil es so schön einfach scheint, oder er noch nichts anderes kennt, sondern nach Abwägung der möglichen Vor- und Nachteile.

                                            Jap, der Vorlieben und Geschmäcker gibt es viele. Nimm doch Tabellen *lol* - kleiner Scherz.

                                            Scherz? Eher Horror!
                                            Vor Jahren habe ich eine Frameseite mit Tabellenlayout übernommen und erweitert.
                                            Jedes Mal, wenn ich jetzt wieder etwas ändern oder erweitern muss, könnte ich mich irgendwo hin beißen, dass ich das ganze Ding nicht in die Tonne getreten und komplett neu geschrieben habe. Jedes Mal ärgere ich mich aufs neue, finde aber auch nicht den nötigen Elan, es komplett zu erneuern, wo über die Jahre doch schon Einiges an Arbeit drin steckt.

                                            Auf Wiederlesen
                                            Detlef

                                            --
                                            - Wissen ist gut
                                            - Können ist besser
                                            - aber das Beste und Interessanteste ist der Weg dahin!
                                            1. Hellihello Detlef,

                                              Jap. btw: wer stellt denn solche "Anforderungen" (eine Ausbildung?)?

                                              Fragesteller in diesem Forum (allerdings existiert wohl das Bild nicht mehr).

                                              wölsches Büld?

                                              also Quirks und * html - hack? Wer soll denn sowas wissen.

                                              Der, der in den Quelltext schaut. ;)

                                              Den Quirks hatte ich erstmal übersehen.

                                              übrigens, äh - btw, wird man von "prosition:absolute" betrunken?

                                              Selbstverständlich, und wenn man IE heißt, dann sogar ohne „r”.

                                              Du meinst den Intenet Exploe?

                                              Klar, ich wollte ja auch daruf hinaus, dass man sich mit dem Frame-Ersatz "auch" "Probleme" einhandelt, abgesehen vom nötigen Knoff-Hoff.

                                              Wenn man übertreibt, dann ja.
                                              Welche Technologie für das Einbinden der Inhalte verwendet wird, sollte genau überlegt werden.

                                              Ach, Schüler dürfen auch mal spielen. Tut ja nicht weh.

                                              Meiner Meinung nach sind Frames, wie auch Ajax für „Standardwebseiten” nicht wirklich geeignet. Für spezielle Anforderungen können (I)Frames oder auch Ajax geeignet sein, je nachdem, ob und welche browserseitigen Funktionen erforderlich sind.

                                              Also: früh übt sich, wer will?

                                              Also für Anfänger ist das nicht "ein bisschen". Außerdem brauchst Du doch dennoch serverseitige Techniken, um die 50 Navigationsspunkte in den 50 Dokumenten aktuell zu halten.

                                              Welcher Anfänger verwaltet Seiten mit 50 oder mehr Navigationspunkten, die sich so häufig ändern, dass es mittels dateiübergreifendem Suchen & Ersetzen oder editorseitiger Includetechnik nicht beherrschbar wäre.

                                              Nö, das war ein weiteres Beispiel. Aber ich bleibe dabei, dass jeder sich fragen darf, auch ein Anfänger, ob er wider besseren Rat sich das Suchen/Ersetzen schenken möchte oder nicht.

                                              Außerdem finde ich das serverseitige Einbinden der Navigation in komplette Einzelseiten trivial im Vergleich zu den von Cybaer erwähnten Möglichkeiten die Probleme mit Frames zu umschiffen.

                                              Luschtig. Für jede Seite ein neues Frameset find ich wieder merkwürdig. Am meisten behagt mir die Idee, nur die Info nachzuladen, die sich ändert (js-httprequest).

                                              Naja, das wäre ja der schlichte Punkt: Die gehen, man kapiert auch was, sie sind u.U. begrenzt tauglich.

                                              Und dann, nachdem es erst so einfach schien, wird viel Energie darauf verwendet, Hintergrundbilder zu teilen und anzupassen, Nachladescripte zu basteln, zu versuchen, Ausklappmenüs frameübergreifend zu bekommen, statt sich gleich ein wenig intensiver mit CSS und Includetechniken zu beschäftigen.

                                              Du sprichst von professionellen Webseitenbauern.

                                              (Interessant finde ich hier immer wieder die Fragen, wie man das Frameset dazu bewegen kann, sich im Browser wie eine Einzelseite zu verhalten.)

                                              Nicht jeder, der was mit Web zu tun hat, möchte ein Web-Profi sein und werden. Und dem einen liegt mehr PHP, dem anderen CSS.

                                              Nur an CSS kommt man früher oder später sowieso nicht vorbei, die umfangreiche Beschäftigung mit Framesets könnte man durchaus vermeiden.

                                              Kommt auf den Stand an. An CSS-Basics komme ich schon von Anfang an nicht vorbei. Postition und Float sowie die zugehörigen margins sind für mich aber schon wirklich fortgeschritten.

                                              Was mich bei Gunnars Anti-Frame-Feldzug stört ist die grundsätzliche "vermeide Frames"  Aussage. Ich finde, das passt auch nicht wirklich zum Geist der Forums.

                                              Uns gibt es nur mit Meinung und ungebetener Beratung.

                                              Diese ganzen Framediskussionen finde ich nervig, meist läuft es doch so ab:

                                              • Ein Anfänger stellt eine Frage zu Problemen mit seinem Frameset, die er ohne dieses übehaupt nicht hätte.
                                              • jemand weist darauf hin oder/und verlinkt auf den Subotnik Artikel
                                                Und schon haben wir eine wilde Diskussion, bei der eine Seite ausführt, dass Frames Probleme bereiten (können), die der Anfänger (noch) nicht überblickt, worauf die andere kontert, dass es ja gar nicht wirklich Probleme sind, weil sich diese für einen Fortgeschrittenen mit entsprechenden Erfahrungen vermeiden lassen.

                                              Wer unbedingt Frames verwenden will, soll es tun, aber bitte nicht, weil es so schön einfach scheint, oder er noch nichts anderes kennt, sondern nach Abwägung der möglichen Vor- und Nachteile.

                                              Deshalb ja die Idee, die Kernpunkte in einem Pro und Contra festzuhalten. Im Grunde ist ja mit diesem Thread auch fast alles schon irgendwo gesagt.

                                              Jap, der Vorlieben und Geschmäcker gibt es viele. Nimm doch Tabellen *lol* - kleiner Scherz.

                                              Scherz? Eher Horror!
                                              Vor Jahren habe ich eine Frameseite mit Tabellenlayout übernommen und erweitert.
                                              Jedes Mal, wenn ich jetzt wieder etwas ändern oder erweitern muss, könnte ich mich irgendwo hin beißen, dass ich das ganze Ding nicht in die Tonne getreten und komplett neu geschrieben habe. Jedes Mal ärgere ich mich aufs neue, finde aber auch nicht den nötigen Elan, es komplett zu erneuern, wo über die Jahre doch schon Einiges an Arbeit drin steckt.

                                              Genau, wärste mal bei Frameset geblieben (;-).

                                              Nimm doch SSI, oder PHP oder gleich ROR - genug der Häme. Sorry.

                                              Dank und Gruß und schönes Wochenende, bis Montag

                                              frankx

                                              1. Hallo frankx

                                                wölsches Büld?

                                                Die Seite mit dem Bild, wie es aussehen soll.

                                                … Aber ich bleibe dabei, dass jeder sich fragen darf, auch ein Anfänger, ob er wider besseren Rat sich das Suchen/Ersetzen schenken möchte oder nicht.

                                                Ja, dass soll er. Er soll es aber tun, nachdem er den Rat bekommen und sich bewusst dagegen entschieden hat.
                                                Dann soll er bitte auch nicht mit den Problemen nerven, die er sich durch seine Entscheidung aufgehalst hat.

                                                Luschtig. Für jede Seite ein neues Frameset find ich wieder merkwürdig. …

                                                Das ist aber leider die zuverlässigste Möglichkeit eine Reihe der Probleme zu vermeiden.

                                                … Am meisten behagt mir die Idee, nur die Info nachzuladen, die sich ändert (js-httprequest).

                                                Dann werde zumindest ich diese Infos nie zu Gesicht bekommen.

                                                …, statt sich gleich ein wenig intensiver mit CSS und Includetechniken zu beschäftigen.

                                                Du sprichst von professionellen Webseitenbauern.

                                                Nein, das bin ich selbst auch nicht. Ich schreibe von denen, die nicht nur schnell mal eine Site hinrotzen sondern sich etwas länger damit beschäftigen.

                                                Kommt auf den Stand an. An CSS-Basics komme ich schon von Anfang an nicht vorbei. Postition und Float sowie die zugehörigen margins sind für mich aber schon wirklich fortgeschritten.

                                                An margin, float und position (man beachte die geänderte Reihenfolge) komme ich dann nicht mehr vorbei, wenn ich mehr als bunte Plaintextseiten vielleicht noch mit Bildern will, ohne dafür wilde Tabellen- oder Schachtelframekonstruktionen zu verwenden.

                                                Genau, wärste mal bei Frameset geblieben (;-).

                                                Leider bin ich beim Frameset mit Tabellenlayout geblieben.

                                                Nimm doch SSI, oder PHP oder gleich ROR - genug der Häme. Sorry.

                                                Nö, wozu?
                                                Es ist editorseitig noch gut beherrschbar.

                                                Auf Wiederlesen
                                                Detlef

                                                --
                                                - Wissen ist gut
                                                - Können ist besser
                                                - aber das Beste und Interessanteste ist der Weg dahin!
                          2. Hello out there!

                            Äh, doch. Womit willst du sonst überzeugen, wenn nicht mit Argumenten?

                            Na Fakten, dachte ich (;-).

                            Gut, dass du den Helm schon aufgesetzt hast ... ;-)

                            Frames bieten die Möglichkeit:

                            1. verschieden Fenster zu öffnen bzw. u.U. sogar logisch voneinander unabhängige Inhalte zu präsentieren.

                            Richtig, genau das ist eine sinvolle Anwendung von Framesets

                            Gut, also 1 Argument.

                            Für _diese_ Anwendung, ja.

                            BTW: kannst Du in Deinem Browser zwei Tabs nebeneinander darstellen?

                            Nein, leider nicht. In der Tat eine Funktionalität, die ich des öfteren vermisse.

                            (IE 7 bietet zumindest eine Miniaturübersicht über alle Tabs an. Tun das andere Browser auch?)

                            Ich wünschte mir Deine Gewissenhaftigkeit auch für die Argumente der "Gegenseite".

                            Die sei dir gewiss.

                            Was ein N00bie aber mit Frames vorhat zu tun, ist die Aufsplittung _eines_ Dokuments. Dafür sind Frames denkbar schlecht.

                            Unterstellung 1.

                            Was jetzt? Dass N00bies Frames zur Aufsplittung _eines_ Dokuments einsetzen oder dass Frames _dafür_ schlecht sind?

                            Egal, ich halte beides für gegeben.

                            1. egal, denn es geht aktuell hier darum, was Frames können was anderes nicht kann.

                            Es geht hier darum, ob/wann es sinnvoll ist, Frames einzusetzen.

                            Wenn es dir allein um eine Technik geht ohne Hinblick auf den Kontext ihrer Anwendung, können wir die Diskussion hier abbrechen, weil ich sie dann für völlig wertlos erachte.

                            Und vergiss bitte nicht auch, dass der Autor auch einen berechtigten Willen hat. Er ist nicht Sklave eines imaginären MonsterUsers.

                            Ich beschäftige mich schon zu lange mit Mensch-Computer-Interaktion und Usability, als dass ich den Willen eines Autors über Benutzerfreundlichkeit stellen würde.

                            Außerdem ist es nicht Willen eines Autors, Frames einzusetzen, sondern Inhalte im Web zu publizieren. Und dabei auf mehreren Seiten Vorkommendes auszulagern. Frames sind lediglich ein Werkzeug zum Erreichen dieses Zieles, und zwar ein schlechtes.

                            Es gibt zum Erreichen dieses Zieles bessere Mittel. Wenn man diese dem Webseitenautor aufzeigt, tut man doch damit nichts gegen seinen Willen.

                            1. dem User die Möglichkeit zu geben, diese in der größe anzupassen

                            Ist das sinnvoll? Ja, durchaus.

                            Es ist egal, ob das sinnvoll ist.

                            Nein!! Der Zweck bestimmt die Mittel, nicht andersrum.

                            Die Frage war: was können Frames, was zB SSI nicht kann.

                            Nein, eher: Sollten zum Erreichen eines bestimmten Zieles Framesets eingesetzt werden oder lässt sich dieses Ziel auch anders erreichen, evtl. ja sogar besser?

                            Wieder bitte die enstprechende Sorgfalt: Javascript baut auf HTML auf. Was ist, wenn JS deaktivert ist (lol)?

                            Dann kann der Nutzer diese zusätzliche Funktionalität der Webseite nicht nutzen, wie auch andere Gimmicks nicht, die JavaScript dort bereithalten mag (Mouseover-Effekte, clientseitige Prüfung von Formulareingaben zur Vermeidung unnötigen Traffics, …).

                            Den Inhalt der Webseite kann er dennoch lesen und auf der Website navigieren.

                            Nein, zumindest nicht die Aufteilung Header fixe Höhe, Footer fixe Breite, Navi-links und News-rechts fixe Breite, Content den Rest in der Mitte, Scrollbar für den Content im Content-Fenster und sonst nirgends.

                            Schon die Vorgabe ist recht sinnlos. Was, wenn der Inhalt eines Frames bei einem kleineren Viewport nicht vollständig zu sehen ist; scrollen aber vom Webseitenautor unterbunden wurde? Die Webseite ist (teiilweise) unbenutzbar.

                            Auf den Schulrechnern ist kein PHP installiert. Es ist kein öffentlicher Webspace. Da kann ich das mit den Gegebenheiten (erstmal) nur mit Frames.

                            Nein. Wenn es darum geht, eine Website mit einer Handvoll Seiten zu erstellen, dann kann man auch die Navigation in jedes HTML-Dokument einbauen und bei Bedarf in jedem ändern.

                            Willst Du mir oder anderen vorschreiben, welchen Editor sie benutzen sollen?

                            Keinesfalls. Ich sage ja nur: nimm ein Werkzeug, das deinen Anforderungen genügt.

                            Notepad ist cool.

                            Aber kein Editor. ;-b

                            Ein Webseitenautor sollte die richtigen Werkzeuge wählen und nutzen, nicht sich hinter seinen ungeeigneten Werkzeugen verstecken und deren Mängel auf die Nutzer abwälzen.

                            Diesen Punkt hatten wir beide schon öfter. Dirk Schürjohann hat auch einen schönen Artikel geschrieben dazu im Weblog. Es gibt nicht "den Webseitenautor"

                            Den Einwand verstehe ich an dieser Stelle nicht. Nun gut, ich formuliere meine Aussage neu (und so war sie auch gemeint): Jeder Webseitenautor sollte die für sich richtigen Werkzeuge wählen und nutzen …

                            Nope. Dieses div ist für den hier viel erwähnten Client so nichtssagend wie ein frameset, noch nichtssagender eigentlich. <section> gibts ja noch nicht.

                            Es ging hier um den Elementbaum. Ob ein Knoten darin nun vom Elementtyp 'div' oder 'section' ist, ist dabei irrelevant.

                            'div' hat für die Dokumentstruktur die Semantik, irgendwas zu sein und anderes zu gruppieren. Genauso habe ich es verwendet.

                            Das o.g. ist in meinen Augen ein Workarround für ein Frameset.

                            ?? Nein, ein Frameset besteht aus mehreren Dokumenten. Das o.g. ist ein Dokument, bestehend aus mehreren Teilen.

                            Wie gesagt, beim nächsten Roman lass ich auf jede Seite oben links das Inhaltsverzeichnis drucken (;-).

                            Schon gut, du kannst den Helm jetzt wieder abnehmen.

                            Wo wir beim Drucken sind: Das Navigationmenü einer Webseite muss beim Ausdruck ja nicht mit aufs Papier. CSS macht’s möglich.

                            See ya up the road,
                            Gunnar

                            --
                            „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
                            1. Hellihello Gunnar,

                              Hello out there!

                              Äh, doch. Womit willst du sonst überzeugen, wenn nicht mit Argumenten?

                              Na Fakten, dachte ich (;-).

                              Gut, dass du den Helm schon aufgesetzt hast ... ;-)

                              "Gewähren und gewähren lassen", hörte ich vorhin vor dem Randori in der Halle.

                              Frames bieten die Möglichkeit:

                              1. verschieden Fenster zu öffnen bzw. u.U. sogar logisch voneinander unabhängige Inhalte zu präsentieren.

                              Richtig, genau das ist eine sinvolle Anwendung von Framesets

                              Gut, also 1 Argument.

                              Für _diese_ Anwendung, ja.

                              Es ging mir konkret um die Beantwortung Deiner Frage: "Die Befürworter von „Enduring Framedom“ haben mir noch kein schlüssiges Argument geliefert, was mit Frames möglich sein soll, was mit serverseitigen Include-Techniken nicht möglich wäre."

                              BTW: kannst Du in Deinem Browser zwei Tabs nebeneinander darstellen?

                              Nein, leider nicht. In der Tat eine Funktionalität, die ich des öfteren vermisse.

                              (IE 7 bietet zumindest eine Miniaturübersicht über alle Tabs an. Tun das andere Browser auch?)

                              Schau, und wenn Du das zur Sortierung auf Deinem Rechner mit einem Frameset löst. Du vermischtest "Window/Tab" - das meinte ich mit "Gewissenhaftigkeit".

                              Ich wünschte mir Deine Gewissenhaftigkeit auch für die Argumente der "Gegenseite".

                              Die sei dir gewiss.

                              Gewiss doch.

                              Was ein N00bie aber mit Frames vorhat zu tun, ist die Aufsplittung _eines_ Dokuments. Dafür sind Frames denkbar schlecht.

                              Unterstellung 1.

                              Was jetzt? Dass N00bies Frames zur Aufsplittung _eines_ Dokuments einsetzen oder dass Frames _dafür_ schlecht sind?

                              Egal, ich halte beides für gegeben.

                              Och, ich sehe in der HTML-AG hin und wieder Newbies, und auch grundsätlzlich: der Vorlieben gibt es viele. Die anderen kriegst Du ja hier im Forum zumindest nicht mit, weil sie keine Fragen zu Frames stellen.

                              1. egal, denn es geht aktuell hier darum, was Frames können was anderes nicht kann.

                              Es geht hier darum, ob/wann es sinnvoll ist, Frames einzusetzen.

                              Nun, ich meine mittlerweile, das der Konfliktpunkt hier liegen könnte. Ich vertrete die Ansicht, dass Webautorchen selbst (ob Hobbyautor, Profi, Actionartist oder sonstwas) selbst entscheidet, was für ihn sinnvoll ist. "Vermeide" wäre da nicht die passende Aussage. Eher "bedenke".

                              Wenn es dir allein um eine Technik geht ohne Hinblick auf den Kontext ihrer Anwendung, können wir die Diskussion hier abbrechen, weil ich sie dann für völlig wertlos erachte.

                              Nein, es ging nur zugespitzt um die Antwort Deiner oben zitierten Frage. Ansonsten natürlich "ack" oder wie man sagt.

                              Und vergiss bitte nicht auch, dass der Autor auch einen berechtigten Willen hat. Er ist nicht Sklave eines imaginären MonsterUsers.

                              Ich beschäftige mich schon zu lange mit Mensch-Computer-Interaktion und Usability, als dass ich den Willen eines Autors über Benutzerfreundlichkeit stellen würde.

                              Da scheiden sich wirklich unsere Geister. Kinder malen Bilder, um zu malen, nicht damit sie irgendwem gefallen.

                              Außerdem ist es nicht Willen eines Autors, Frames einzusetzen, sondern Inhalte im Web zu publizieren. Und dabei auf mehreren Seiten Vorkommendes auszulagern. Frames sind lediglich ein Werkzeug zum Erreichen dieses Zieles, und zwar ein schlechtes.

                              Naja, wie geschruben: das entscheidet Auto selbst.

                              Es gibt zum Erreichen dieses Zieles bessere Mittel. Wenn man diese dem Webseitenautor aufzeigt, tut man doch damit nichts gegen seinen Willen.

                              Welche Technik zu welchem Temperament passt, möge jeder selbst am besten wissen.

                              1. dem User die Möglichkeit zu geben, diese in der größe anzupassen

                              Ist das sinnvoll? Ja, durchaus.

                              Es ist egal, ob das sinnvoll ist.

                              Nein!! Der Zweck bestimmt die Mittel, nicht andersrum.

                              Die Frage war: was können Frames, was zB SSI nicht kann.

                              Nein, eher: Sollten zum Erreichen eines bestimmten Zieles Framesets eingesetzt werden oder lässt sich dieses Ziel auch anders erreichen, evtl. ja sogar besser?

                              Bei Ghostbusters gibts sone Textzeile a la: "Ich kenn mich mit diesen Dingen wie gut und schlecht nicht so gut aus" - "Wenn alles Leben auf der Erde mit einem Schlag erlöschen würde, das wäre 'schlecht'".

                              Wieder bitte die enstprechende Sorgfalt: Javascript baut auf HTML auf. Was ist, wenn JS deaktivert ist (lol)?

                              Dann kann der Nutzer diese zusätzliche Funktionalität der Webseite nicht nutzen, wie auch andere Gimmicks nicht, die JavaScript dort bereithalten mag (Mouseover-Effekte, clientseitige Prüfung von Formulareingaben zur Vermeidung unnötigen Traffics, …).

                              Naja, bezogen auf die zitierte Frage: mit Frames könnte er das auch JS-unabhängig.

                              Den Inhalt der Webseite kann er dennoch lesen und auf der Website navigieren.

                              Ich als Autor habe die Macht. Ich präsentiere nach meinen Vorstellungen. Kannst ja wegklicken, wenns Dir nicht passt (;-). Du spielst als Musiker ja auch weiter, wenns irgendwem im Publikum nicht gefällt.

                              Nein, zumindest nicht die Aufteilung Header fixe Höhe, Footer fixe Breite, Navi-links und News-rechts fixe Breite, Content den Rest in der Mitte, Scrollbar für den Content im Content-Fenster und sonst nirgends.

                              Schon die Vorgabe ist recht sinnlos. Was, wenn der Inhalt eines Frames bei einem kleineren Viewport nicht vollständig zu sehen ist; scrollen aber vom Webseitenautor unterbunden wurde? Die Webseite ist (teiilweise) unbenutzbar.

                              Vielleicht entscheide ich mich ja mal, dass mir kleine Viewports schnuppe sind?

                              Auf den Schulrechnern ist kein PHP installiert. Es ist kein öffentlicher Webspace. Da kann ich das mit den Gegebenheiten (erstmal) nur mit Frames.

                              Nein. Wenn es darum geht, eine Website mit einer Handvoll Seiten zu erstellen, dann kann man auch die Navigation in jedes HTML-Dokument einbauen und bei Bedarf in jedem ändern.

                              Das entscheidet bitte der Webautor selbst, ob er sich diese zusätzliche Mühe machen will. Für mich ist es logisch eine Vorübung fürs includen.

                              Willst Du mir oder anderen vorschreiben, welchen Editor sie benutzen sollen?

                              Keinesfalls. Ich sage ja nur: nimm ein Werkzeug, das deinen Anforderungen genügt.

                              Sag ich auch: manchmal Frames.

                              Notepad ist cool.

                              Aber kein Editor. ;-b

                              Ich fang damit an.

                              Ein Webseitenautor sollte die richtigen Werkzeuge wählen und nutzen, nicht sich hinter seinen ungeeigneten Werkzeugen verstecken und deren Mängel auf die Nutzer abwälzen.

                              Diesen Punkt hatten wir beide schon öfter. Dirk Schürjohann hat auch einen schönen Artikel geschrieben dazu im Weblog. Es gibt nicht "den Webseitenautor"

                              Den Einwand verstehe ich an dieser Stelle nicht. Nun gut, ich formuliere meine Aussage neu (und so war sie auch gemeint): Jeder Webseitenautor sollte die für sich richtigen Werkzeuge wählen und nutzen …

                              Full ACK.

                              Nope. Dieses div ist für den hier viel erwähnten Client so nichtssagend wie ein frameset, noch nichtssagender eigentlich. <section> gibts ja noch nicht.

                              Es ging hier um den Elementbaum. Ob ein Knoten darin nun vom Elementtyp 'div' oder 'section' ist, ist dabei irrelevant.

                              'div' hat für die Dokumentstruktur die Semantik, irgendwas zu sein und anderes zu gruppieren. Genauso habe ich es verwendet.

                              Das o.g. ist in meinen Augen ein Workarround für ein Frameset.

                              ?? Nein, ein Frameset besteht aus mehreren Dokumenten. Das o.g. ist ein Dokument, bestehend aus mehreren Teilen.

                              Es muss doch nicht immer _ein_ Dokument sein. Wozu blos?

                              Wie gesagt, beim nächsten Roman lass ich auf jede Seite oben links das Inhaltsverzeichnis drucken (;-).

                              Schon gut, du kannst den Helm jetzt wieder abnehmen.

                              Wo wir beim Drucken sind: Das Navigationmenü einer Webseite muss beim Ausdruck ja nicht mit aufs Papier. CSS macht’s möglich.

                              Auch _eine_ Möglichkeit.

                              Dank und Gruß,

                              frankx

                        2. Hallo,

                          verschieden Fenster zu öffnen bzw. u.U. sogar logisch voneinander unabhängige Inhalte zu präsentieren.

                          ... wenn man es dem Benutzer nicht selbst überlassen möchte, die verschiedenen Dokumente in verschiedenen Fenstern/Tabs darzustellen

                          Genau!

                          http://molily.de/javascript-popups#loesung2fehler
                          http://molily.de/javascript-popups#alternativen

                          (Vieles davon trifft auch auf Frames zu.)

                          Wenn ein Nutzer gerade nicht navigieren will, sondern den Seiteninhalt lesen, könnte er aus Platzgründen die (seitliche) Navigation ausblenden wollen. Diese Funktionalität ist aber durchaus auch mit JavaScript zu realisieren, dafür braucht es keine Frames.

                          Das führt uns eher zu anpassungsfähigen Layouts, die bereits eine gute Lesbarkeit vorgeben und selbst auf Umgebungsänderungen flexibel reagieren. Ein Interface mit »... ausblenden« ist auch viel verständlicher als ein bloßes Frameset. (Man erinnert sich an Framesets, die mit Pfeilen auf den verschiebbaren Rahmen hingewiesen haben ... sehr unbeholfen, zumal die verschiedenen Browser das gar nicht konsistent implementiert hatten.)

                          Mathias

                5. Hi,

                  Man hat sich anscheinend einfach drauf geeinigt, dass Frames in aller Regel unrauchbar sind, basta.

                  Anscheinend hat man sich nicht darauf geeinigt, weswegen Frames in HTML auch *nicht* deprecated sind, und in XHTML erneut dabei sein werden (XFrames).

                  Gruß, Cybaer

                  --
                  Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                  1. Hellihello

                    Anscheinend hat man sich nicht darauf geeinigt, weswegen Frames in HTML auch *nicht* deprecated sind, und in XHTML erneut dabei sein werden (XFrames).

                    Coole Beschreibung:
                    "Frames were introduced into HTML at version 4.0 [HTML4]. They introduced a manner of composing several HTML documents into a single view to create an application-like interface.

                    However, Frames introduced several usability problem that caused several commentators to advise Web site builders to avoid them at all costs. Examples of such usability problems are:

                    * The [back] button works unintuitively in many cases.
                        * You cannot bookmark a collection of documents in a frameset, or send someone a reference to the collection.
                        * If you do a [reload], the result may be different to what you had.
                        * [page up] and [page down] are often hard to do.
                        * You can get trapped in a frameset.
                        * Searching finds HTML pages, not Framed pages, so search results usually give you pages without the navigation context that they were intended to be in.
                        * Since you can't content negotiate, noframes markup is necessary for user agents that don't support frames. However, almost no one produces noframes content, and so it ruins Web searches, since search engines are examples of user agents that do not support frames.
                        * There are security problems caused by the fact that it is not visible to the user when different frames come from different sources.

                    This document defines a separate XML application, not a part of XHTML per se, that allows similar functionality to HTML Frames, with fewer usability problems, principally by making the content of the frameset visible in its URI."

                    Dank und Gruß,

                    frankx

                    1. Hi,

                      Coole Beschreibung:

                      Man (auch Du) beachte vor allen Dingen:

                      * Since you can't content negotiate, noframes markup is necessary for user agents that don't support frames. However, almost no one produces noframes content, and so it ruins Web searches, since search engines are examples of user agents that do not support frames.

                      Und auch für den Rest gilt: Wenn man Frames für eine Standardseite verwendet, dann sollte man möglichst jeder Content-Seite sein eigenes Frameset gönnen.

                      Das viele Webautoren den NOFRAMES-Bereich nur nutzen für "Ihr Browsr unterstützt keine Frames!", sagt etwas über diese Webautoren aus, nicht über die Technik als solche.

                      Gruß, Cybaer

                      --
                      Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                      1. Hellihello bärchen,

                        Hi,

                        Coole Beschreibung:

                        Man (auch Du) beachte vor allen Dingen:

                        * Since you can't content negotiate, noframes markup is necessary for user agents that don't support frames. However, almost no one produces noframes content, and so it ruins Web searches, since search engines are examples of user agents that do not support frames.

                        Das glaube ich nicht, dass Google nicht in der Lage ist, die src eines frame-Elementes auszulesen. Aber dennoch würde und habe ich denn Noframesbereich korrekt ausgetextet.

                        Und auch für den Rest gilt: Wenn man Frames für eine Standardseite verwendet, dann sollte man möglichst jeder Content-Seite sein eigenes Frameset gönnen.

                        Naja, ich erwähnte schon das Beispiel vom Freundeskreis unserer Schule. Ich könnte auch sagen: "definiere Standardseite" (;-).

                        Im Grunde finde ich den Ansatz ja interessant, nur das nötige nachzuladen, also mit JS-httprequest.

                        Das viele Webautoren den NOFRAMES-Bereich nur nutzen für "Ihr Browsr unterstützt keine Frames!", sagt etwas über diese Webautoren aus, nicht über die Technik als solche.

                        Naja, da sind wir ja einer Meinung.

                        Dank und Gruß,

                        frankx

                        1. Hi,

                          Das glaube ich nicht, dass Google nicht in der Lage ist, die src eines frame-Elementes auszulesen.

                          Korrekt. Google macht das.

                          Naja, ich erwähnte schon das Beispiel vom Freundeskreis unserer Schule. Ich könnte auch sagen: "definiere Standardseite" (;-).

                          Jede Webseite, für die nicht ganz konkret ein abweichendes Verhalten explizit begründet werden kann. ;-)

                          Im Grunde finde ich den Ansatz ja interessant, nur das nötige nachzuladen, also mit JS-httprequest.

                          Wenn man nicht auf Besucher via Suchmaschinen oder auf Besucher ohne JS angewiesen ist, dann kann man das natürlich machen.

                          Gruß, Cybaer

                          --
                          Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                  2. Hallo,

                    weswegen Frames in HTML auch *nicht* deprecated sind

                    Deprecated ist ein Terminus, der zur Unterscheidung von Transitional und Strict eingeführt wurde. Er macht auch nur in dem Rahmen Sinn: Für Deprecated erklären heißt, alte Elemente aus Strict auszuschließen und sie in Transitional zu belassen.

                    Frames laufen außer Konkurrenz, weil sie mit »normalen« HTML-Dokumenten (Strict/Transitional) so gesehen nix zu tun haben. Sie sind inhärent »presentational« und es gibt auch logischerweise kein stattdessen empfohlenes Strict-Äquivalent.

                    Siehe auch </archiv/2005/4/t104779/#m646484>.

                    und in XHTML erneut dabei sein werden (XFrames).

                    XHTML 2 ist faktisch tot und XFrames hat keine Zukunft, diese Standards werden nicht ernsthaft weiter entwickelt.

                    Mathias

                    1. Hi,

                      Deprecated ist ein Terminus, der zur Unterscheidung von Transitional und Strict eingeführt wurde. Er macht auch nur in dem Rahmen Sinn: Für Deprecated erklären heißt, alte Elemente aus Strict auszuschließen und sie in Transitional zu belassen.

                      Schon klar.

                      XHTML 2 ist faktisch tot und XFrames hat keine Zukunft, diese Standards werden nicht ernsthaft weiter entwickelt.

                      Faktisch sehe ich das auch so (praktisch sowieso), aber gibt es dazu was offizielles?

                      Gruß, Cybaer

                      --
                      Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                      1. Hallo,

                        XHTML 2 ist faktisch tot und XFrames hat keine Zukunft, diese Standards werden nicht ernsthaft weiter entwickelt.

                        Faktisch sehe ich das auch so (praktisch sowieso), aber gibt es dazu was offizielles?

                        Die Entwicklungen wurden nicht offiziell eingestellt, falls du das meinst.
                        Offiziell hat das W3C meiner Erinnerung nach verlauten lassen, dass XHTML 2 weiterentwickelt werden soll, parallel zu HTML 5. Was jedenfalls klar ist, dass die Öffentlichkeit daran extrem wenig Interesse hat und die Aussicht auf Implementierung in den großen Browsern äußerst schlecht ist (bevor das passiert, wird XHTML 2 ohnehin keine Recommendation).
                        Ob intern momentan Arbeiten an XFrames laufen, weiß ich nicht, ich bezweifle es aber, da seit zwei Jahren kein Ton mehr zu hören ist und die Chose schon seit 2002 läuft.

                        Mathias

                        1. Hi,

                          Offiziell hat das W3C meiner Erinnerung nach verlauten lassen, dass XHTML 2 weiterentwickelt werden soll, parallel zu HTML 5. Was jedenfalls klar ist, dass die Öffentlichkeit daran extrem wenig Interesse hat und die Aussicht auf Implementierung in den großen Browsern äußerst schlecht ist (bevor das passiert, wird XHTML 2 ohnehin keine Recommendation).

                          Soweit auch mein Kenntnisstand. Meine Meinung zu den "Theoretikern im Elfenbeinturm" ist ja sowieso hinlänglich bekannt ...

                          Gruß, Cybaer

                          --
                          Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
        2. Hello out there!

          Wo bleibt den nur endlich die wirklich _neutrale_ Gegenüberstellung zwischen Frames (zwei oder mehr)und NoFrames (Auslagern usw.)

          Ich wüsste nicht, was an Subotniks Artikel nicht neutral sein sollte. Es werden objektiv vorhandene Nachteile einer Technik aufgelistet und deshalb abgeraten, diese Technik einzusetzen. Eben weil es gute Alternativen dazu gibt, die bessere Ergebnisse erzielen.

          Die von den Operation-Enduring-Framedom-Bushmännern hin und wieder angebrachten „Vorteile“ sind keine, da diese Argumente für serverseitige Includes (ob SSI oder PHP ist hier völlig egal) genauso zutreffen.

          Der einzige Vorteil von Frames gegenüber serverseitigen Include-Techniken ist, dass letztere eben Webspace verlangen, der diese unterstützt. Wer an dieser Stelle sparen möchte, weil er denkt, Geiz sei geil, der möchte wohl auch eine billig aussehende Webseite.

          See ya up the road,
          Gunnar

          --
          „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
        3. Hi,

          Wer Frames nicht genügend respektiert,
          Wir schnell zum Terroristen degradiert.

          Ne ne, kein Terrorist. =:-) Ich meine: Fundamentalist. Und dann noch einer, der mit seinem Glauben immer und immer wieder andere bekehren möchte. Sowas mag ich halt prinzipiell nicht. Egal ob es um Islamisten, Evangelikale oder Vanillepudding geht ... ;-)

          Wirkt auf mich selbst dann unsympathisch, wenn das Anliegen eien gewissen Berechtigung zu haben scheint (ich möchte da nur an die hiesigen Tiraden von F. einem gewissen v.G. gegenüber als Beispiel nennen).

          PS.: Wo bleibt den nur endlich die wirklich _neutrale_ Gegenüberstellung zwischen Frames (zwei oder mehr)und NoFrames (Auslagern usw.), die Anfänger, Hilfsprogrammnutzer (z. B. Frontpage), Selbstprogrammierer und den Fortgeschrittenen Experten berücksichtigen.

          Ach, Frames sind nur eine Technik, und das Web ist voll von Techniken. Jede Technik will IMHO erlernt sein, sonst ist das Ergebnis nicht unbedingt optimal. Ein z.B. FP-Nutzer wird wohl nie ein optimales Ergebnis erzielen wollen, egal was er macht ...

          Gruß, Cybaer

          --
          Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
          1. Hello out there!

            Fundamentalist. Und dann noch einer, der mit seinem Glauben immer und immer wieder andere bekehren möchte.

            Du hättest einen Punkt, wenn immer wieder derselbe bekehrt werden sollte, bis er schließlich selbst dran glaubt.

            Ist aber nicht so; es sind ja wieder immer neue Leute, die Frames einsetzen, weil sie sich ihrer Nachteile noch nicht bewusst sind. Also muss es denen einmalig(!) immer wieder(!) gesagt werden. (Du erkennst, dass das kein Widerspruch ist?)

            Wirkt auf mich selbst dann unsympathisch, wenn das Anliegen eien gewissen Berechtigung zu haben scheint

            Das Stammpublikum hier, denen Frames schon auf die Nerven gehen, ist ja nicht das Zielpublikum der Predigten.

            Das ist nichts anderes als immer wieder jemandem anderen zu sagen, wie er seine Inhalte zentriert auf die Seite bekommt.

            See ya up the road,
            Gunnar

            --
            „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
            1. Hi,

              Du hättest einen Punkt, wenn immer wieder derselbe bekehrt werden sollte, bis er schließlich selbst dran glaubt.

              Also mich nerven die Zeugen Jehovas auch, wenn sie nur einmal vor meiner Tür stehen, und mir die Backe vollquatschen wollen (oder die Mormonen, oder eben Du - ich will dich ja nicht blacklisten und muß daß auch ständig mitlesen :->).

              Ist aber nicht so; es sind ja wieder immer neue Leute, die Frames einsetzen, weil sie sich ihrer Nachteile noch nicht bewusst sind. Also muss es denen einmalig(!) immer wieder(!) gesagt werden. (Du erkennst, dass das kein Widerspruch ist?)

              Jep. Typisch deutsche Nervensäge halt. >;->

              Und das anhand deiner Vorurteile und einer IMHO mehr als zweifelhaften Liste angeblicher Nachteile.

              Das Stammpublikum hier, denen Frames schon auf die Nerven gehen, ist ja nicht das Zielpublikum der Predigten.

              Ich bin auch Stammpublikum, und mir gehen die Predigten auf den Senkel (und damit bin ich bekanntermaßen nicht allein).

              Das ist nichts anderes als immer wieder jemandem anderen zu sagen, wie er seine Inhalte zentriert auf die Seite bekommt.

              Das sehe ich anders. Du verwechselst Positiv-Hilfe mit Allgemeinplätzen.

              Gruß, Cybaer

              --
              Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
              1. Hello out there!

                Also mich nerven […] die Mormonen

                Was hast du gegen mehrere Frauen? >;->

                ich will dich ja nicht blacklisten und muß daß auch ständig mitlesen :->).

                Nö, keiner zwingt dich. Wenn im Titel „Frame“ steht und als Autor „Gunnar“, solltest du es auch ohne technische Hilfe einer Blacklist schaffen, das Posting zu ignorieren.

                Und das anhand deiner Vorurteile und einer IMHO mehr als zweifelhaften Liste angeblicher Nachteile.

                Ich habe keine Vorurteile; ich habe Argumente. Wenn du Zweifel an den Argumenten hast, darfst du sie gerne vorbringen. „Siehe Archiv“ zählt nicht.

                Das sehe ich anders. Du verwechselst Positiv-Hilfe mit Allgemeinplätzen.

                Von Framesets abzuraten IST Positiv-Hilfe. Das kannst du gerne anders sehen.

                See ya up the road,
                Gunnar

                --
                „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
                1. Hi,

                  Also mich nerven […] die Mormonen
                  Was hast du gegen mehrere Frauen? >;->

                  Dann nerven mich die Hormonen! >;->

                  Nö, keiner zwingt dich. Wenn im Titel „Frame“ steht und als Autor „Gunnar“, solltest du es auch ohne technische Hilfe einer Blacklist schaffen, das Posting zu ignorieren.

                  Das ist doch wie mit dem Pickel: Man weiß, daß man ihn in Ruhe lassen soll, aber dann kratzt man sich doch ... ;->

                  ... human nature! ;)

                  Gruß, Cybaer

                  --
                  Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                  1. Also mich nerven […] die Mormonen
                    Was hast du gegen mehrere Frauen? >;->
                    Dann nerven mich die Hormonen! >;->

                    Angst vorm Vollzeit-PMS?

                    [Frameset-Belehrungen]
                    Das ist doch wie mit dem Pickel: Man weiß, daß man ihn in Ruhe lassen soll, aber dann kratzt man sich doch ... ;->

                    Multimedia-Preuße! >;)

                    Roland

                    --
                    Aquahu akbar!
                    1. Hi,

                      Also mich nerven […] die Mormonen
                      Was hast du gegen mehrere Frauen? >;->
                      Dann nerven mich die Hormonen! >;->

                      Angst vorm Vollzeit-PMS?

                      (grusel) Eigentlich meinte ich *meine* "Hormonen"! O;-> Aber deine Vorstellung ist ja noch viel schlimmer! =:->

                      [Frameset-Belehrungen]
                      Das ist doch wie mit dem Pickel: Man weiß, daß man ihn in Ruhe lassen soll, aber dann kratzt man sich doch ... ;->
                      Multimedia-Preuße! >;)

                      Jawoll! Hamm'se etwa nich' jedient? Immer vorneweg an der Web-Front! Damals '96/'97 als die Frames auf dem Vormarsch waren ... ;->

                      ... Aug in Aug mit dem BVB-Feind ("Best viewed by")! :) Da sah so manche Website aus, wie ein Schlachtfeld - die Grauen vorwegnehmend, die heutzutage manches BeepWorld-Massaker an Augen- und Hirnschäden hinterläßt. >%->

                      Gruß, Cybaer

                      --
                      Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
                      1. Damals '96/'97 als die Frames auf dem Vormarsch waren ...

                        Damals auf dem vorm, heute ziemlich im.

                        Roland

                        --
                        Aquahu akbar!
                2. Hello out there!

                  Ich habe keine Vorurteile; ich habe Argumente.

                  Ich unterstütze Suboniks. Bis auf das mit den Suchmaschinen; das hat wohl kaum Relevanz (mehr).

                  Aber da gilt die Salvatorische Klausel: Durch die Ungültigkeit eines Arguments wird die Gültigkeit der anderen nicht eingeschränkt.

                  Und hier will doch niemand die Optimierung von Webseiten für Maschinen über die Optimierung für Menschen stellen?

                  (Das Achten auf valides HTML ist auch eine Optimierung für Maschinen; das kommt aber den Nutzern zugute: Je nach Schwere von Fehlern gibt es keine Auswirkungen, Darstellungsfehler, Darstellungswunder. SEO kommt den Nutzern nicht zugute.)

                  BTW, Subotniks Artikel ist beim Googlen nach "Frames" auf Platz 3 – gleich hinter Wikipedia und SELFHTML.

                  See ya up the road,
                  Gunnar

                  --
                  „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
                  1. Hellihello Gunnar,

                    BTW, Subotniks Artikel ist beim Googlen nach "Frames" auf Platz 3 – gleich hinter Wikipedia und SELFHTML.

                    Das kommt nur, weil ich "meinen Versuch einer tabellarischen Zusammenstellung mit Linkliste" auf noindex gesetzt hab (;-).

                    Abgesehen davon finde ich den Subotnik-Artikel wirklich mäßig sachbezogen und auch mäßig korrekt.

                    "Mit HTML 4.0 wurde wieder mehr Wert auf die Trennung von Inhalt und Präsentation eines HTML-formatierten Textes gelegt. Im HTML-Code sollten nur Elemente verwendet werden, die etwas über die Bedeutung und die Struktur des Textes aussagen."

                    Das ist keinesfalls komplett korrekt, da sowohl <img> wie auch <script>, <style> und <object> genauso informationsgebende Elemente sind. Information beschränkt sich bei HTML keinsfalls auf Text.

                    "Eine FRAMESET-Datei hat dagegen überhaupt keinen Inhalt (der NOFRAMES-Bereich wird von einem FRAMEs-fähigen Browser völlig ignoriert)!"

                    Es hat genausoviel Inhalt wie o.g. Elemente. Es hat zudem den Inhalt: ich bin zwei oder mehrer Inhalte.

                    "Sie macht ausschliesslich Angaben über die grafische Präsentation anderer Dokumente. Für andere Ausgabemedien als für die hochauflösende Bildschirmdarstellung hat das Frameset keine Bedeutung."
                    Das ist schlicht unfug. Wie Eric Myer u.a. zeigt, macht es insbesondere dann Sinn, ein Frameset einzusetzten, wenn das Menü sehr viele Einträge hat (ein Übersicht zB. s.a. die Sidebar von Selfhtml u.a.). Ein Frameset lässt sich zudem in der Größe verändern und macht im korrekten Falle genau eine inhaltliche Aussage: zwei Inhalte, die sich in einer 1:n Relation befinden.

                    "Auf den ersten Blick erscheint das als philosophisches Problem von Struktur-Dogmatikern..."

                    Um mal auf dieser Ebene zu argumentieren: genau das tut der Artikel, weshalb ich ihn als unvollständig und einseitig ansehe.

                    ", wir werden aber sehen, dass dies die Ursache aller weiteren Probleme ist."

                    Meiner bescheidenen Meinung nach leider nicht.

                    "Das FRAMESET ist ein toter Container, der nichts von seinen Inhalten weiß."

                    Genau wie ein <img> oder <objekt>. Es gibt eben auch nichtschriftliche Inforamtion.

                    Diese Aussage findet sich auch nirgends beim W3C.

                    Auf das weitere gehe ich jetzt erstmal nicht ein. Mir ist ja nach einer sachlichen Auflistung der Pros und Kontras.

                    Nebenbei will mir garnicht in den Kopf, warum ein Frameset für einen kleinen Viewport ungeeignet wäre. Ich kann doch gerade und nur beim Frameset das selbst sofort anpassen, sogar das Menü wegschieben um mehr Platz für den Inhalt zu haben bzw. es aufziehen, wenn ich zu einem weiteren Thema den Menüpunkt suche.

                    Dank und Gruß,

                    frankx

                    1. Hallo,

                      "Mit HTML 4.0 wurde wieder mehr Wert auf die Trennung von Inhalt und Präsentation eines HTML-formatierten Textes gelegt. Im HTML-Code sollten nur Elemente verwendet werden, die etwas über die Bedeutung und die Struktur des Textes aussagen."

                      Das ist keinesfalls komplett korrekt, da sowohl <img> wie auch <script>, <style> und <object> genauso informationsgebende Elemente sind. Information beschränkt sich bei HTML keinsfalls auf Text.

                      Du musst schon berücksichtigen, was der Autor damit sagen will. Natürlich grenzt sich HTML 4 nicht von object usw. ab, aber doch von denjenigen HTML-Elementen, die als HTML-Elemente die Präsentation beeinflussen.

                      style tut dies nicht direkt, genausowenig wie script es direkt tut, genausowenig wie object andere Inhalte mit dem HTML verschweißt - all diese binden fremde Medientypen ein. Das Ideal von HTML 4 ist tatsächlich die Trennung der Sprachen bzw. Logiken. Grafiken, JavaScript und CSS sind nunmal nicht HTML - aber frameset, frames, target usw. sind HTML. Das ist der Punkt.

                      "Eine FRAMESET-Datei hat dagegen überhaupt keinen Inhalt (der NOFRAMES-Bereich wird von einem FRAMEs-fähigen Browser völlig ignoriert)!"

                      Es hat genausoviel Inhalt wie o.g. Elemente. Es hat zudem den Inhalt: ich bin zwei oder mehrer Inhalte.

                      Ja und?

                      Es ist doch egal, dass style und script keinen menschenlesbaren Inhalt im Sinne von natürlichsprachigem Text, Ton oder Bild haben. Sie sind ja auch selbst keine HTML-Dokumente! Das aber sind Framesets, und überhaupt deshalb ist die Inhaltslosigkeit von Relevanz.

                      Der Text will sagen: Ein »Frameset« bricht mit der klassischen Dokumentvorstellung. Das hat verschiedene Auswirkungen.
                      Das Einbinden von CSS oder JavaScript *in* ein klassisches Dokument konterkariert nicht dessen Konzept.

                      "Sie macht ausschliesslich Angaben über die grafische Präsentation anderer Dokumente. Für andere Ausgabemedien als für die hochauflösende Bildschirmdarstellung hat das Frameset keine Bedeutung."
                      Das ist schlicht unfug. Wie Eric Myer u.a. zeigt, macht es insbesondere dann Sinn, ein Frameset einzusetzten, wenn das Menü sehr viele Einträge hat (ein Übersicht zB. s.a. die Sidebar von Selfhtml u.a.). Ein Frameset lässt sich zudem in der Größe verändern und macht im korrekten Falle genau eine inhaltliche Aussage: zwei Inhalte, die sich in einer 1:n Relation befinden.

                      Du widersprichst dem Text damit überhaupt nicht, der macht trotzdem seinen Punkt.

                      Es ist eigentlich egal, was für eine Beziehung zwischen den Inhalten besteht. Natürlich besteht oft eine inhaltliche Relation, dazu setzt man Frames schließlich ein. Die Aussage des Textes ist aber, dass diese Relation nicht im Frameset ausgedrückt ist. Darin stehen nur Elemente, die eine grafische Anordnung definieren. Sie können prinzipiell keine inhaltlich-semantische Relation ausdrücken. DESHALB gilt eben, dass Framesets für andere Ausgabemedien, die der Darstellung nicht fähig sind, nichts sagen (und eine Navigation deshalb schwierig ist, weil der Benutzer erstmal die Relation selbst herausfinden muss, was je nach Zugangstechnik ziemlich schwierig ist). Denn mehr als die bloße Darstellung drücken sie nicht aus.

                      "Das FRAMESET ist ein toter Container, der nichts von seinen Inhalten weiß."

                      Genau wie ein <img> oder <objekt>. Es gibt eben auch nichtschriftliche Inforamtion.

                      Du widersprichst wieder einer Aussage, die gar nicht gemacht wurde.

                      object ist Bestandteil eines klassischen HTML-Dokuments und das ist in diesem Kontext völlig konsistent: Ein Dokument verweist auf andere Medien in einem bestimmten inhaltlichen Kontext. Ein Frameset ist aber ein eigenständiges HTML-Dokument. (Jetzt könnte man natürlich drüber diskutieren, ob ein Dokument nur mit ein paar objects, die mit CSS über den Bildschirm geklebt werden, noch ein klassisches Dokument ist und was den Unterschied zum »toten Container« macht.)

                      Diese Aussage findet sich auch nirgends beim W3C.

                      Was für ein Argument... ;)

                      Ich kann doch gerade und nur beim Frameset das selbst sofort anpassen, sogar das Menü wegschieben um mehr Platz für den Inhalt zu haben bzw. es aufziehen, wenn ich zu einem weiteren Thema den Menüpunkt suche.

                      Bei integrierten Navigationen kann man auch durch Scrollen das Menü wegschieben bzw. in den Fokus holen... Ist nix spezifisches.

                      Mathias

                      1. Hellihello Mathias,

                        "Mit HTML 4.0 wurde wieder mehr Wert auf die Trennung von Inhalt und Präsentation eines HTML-formatierten Textes gelegt. Im HTML-Code sollten nur Elemente verwendet werden, die etwas über die Bedeutung und die Struktur des Textes aussagen."

                        Das ist keinesfalls komplett korrekt, da sowohl <img> wie auch <script>, <style> und <object> genauso informationsgebende Elemente sind. Information beschränkt sich bei HTML keinsfalls auf Text.

                        Du musst schon berücksichtigen, was der Autor damit sagen will. Natürlich grenzt sich HTML 4 nicht von object usw. ab, aber doch von denjenigen HTML-Elementen, die als HTML-Elemente die Präsentation beeinflussen.

                        Naja, mit dieser Aussage hätte ich jetzt, um genau zu sein, zwei "Probleme" - ich habe gelesen, dass die Diskussion für Dich 5-6 Jahre alt, Du Deine Seite dazu gelöscht hast und im Grunde das Thema als abgeschlossen ansiehst. Meine "Probleme" dennoch:

                        1. Es geht mir ja eigentlich darum, nicht zu berücksichtigen, was der Autor sagen will, sondern zuzusehen, dass das, was "der Autor" sagen will, auch so gesagt wird, wies gemeint ist. Das die Idee hinter dem Pro und Contra. Das auch meine Kritik im Ganzen an dem Artikel: zu weltanschaulich, zu wenig präzise im Detail.
                        2. Ein img/src ist zwar oft (bei Links) Layout relativ pur. Aber grafische Information (ein Bild von einer Person, eine grafische Darstellung von Verläufen o.ä.) sind ja kein Layout. Das ist Information, wie sie u.U. in Worten nur schwer zu beschreiben ist. "Layout" (s. u.a. auch UML) kann auch Informationsträger sein.

                        style tut dies nicht direkt, genausowenig wie script es direkt tut, genausowenig wie object andere Inhalte mit dem HTML verschweißt - all diese binden fremde Medientypen ein.

                        Ja, und Information ist ein Bündel aus Schrift, Audio, Bilder (bewegt und unbewegt).

                        Das Ideal von HTML 4 ist tatsächlich die Trennung der Sprachen bzw. Logiken. Grafiken, JavaScript und CSS sind nunmal nicht HTML - aber frameset, frames, target usw. sind HTML. Das ist der Punkt.

                        Mh, irgendwie krieg ich diesen Punkt nicht. Das Element, ob object, img oder iframe oder frame verweist auf eine Quelle. Einmal ein Flashfilm, einmal ein Bild, einmal ein animiertes GiF, einmal ein weiterer HTML-Quelltext. Ich finde das logisch einwandfrei. Das w3c schreibt auch bei den Problemen nur von der "usability" (also den Browserschwächen sag ich mal ein wenig pointiert, die mit History und Links nicht zurechtkommen). Es rät sogar zur Alternative Nutzung von <object>.

                        "Eine FRAMESET-Datei hat dagegen überhaupt keinen Inhalt (der NOFRAMES-Bereich wird von einem FRAMEs-fähigen Browser völlig ignoriert)!"

                        Es hat genausoviel Inhalt wie o.g. Elemente. Es hat zudem den Inhalt: ich bin zwei oder mehrer Inhalte.

                        Ja und?

                        Mh, vielleicht ist dies zurückzuführen auf einen eingeschränkteren oder erweiterten Informationsbegriff. Eine logische Strukturbeziehung zwischen Elementen zB. eines Buches (Umschlag, Klappentext, Titel, sonstige Infos, Inhaltsangabe, Inhalt einzelner Kapitel) ist auch Teil der gesamten Information, würde ich sagen. Die Inhaltsangabe (Menü) hilft zB. ein einzelnes Kapitel (einzelne html-Seiten i.d.Regel) in einen übergeordneten Zusammenhang zu bringen.

                        Es ist doch egal, dass style und script keinen menschenlesbaren Inhalt im Sinne von natürlichsprachigem Text, Ton oder Bild haben. Sie sind ja auch selbst keine HTML-Dokumente! Das aber sind Framesets, und überhaupt deshalb ist die Inhaltslosigkeit von Relevanz.

                        Eine HTML-Seite kann ja auch nur ein Bild enthalten. Vergiss bitte auch nicht den Noframes-Bereich. Die Trennung von überwiegend informationsfreiem Layout und Text bezieht sich doch eben auf Text. Aber HTML bleibt HTML, wenn es überwiegend oder nur fremde Quellen einbindet.

                        Der Text will sagen: Ein »Frameset« bricht mit der klassischen Dokumentvorstellung. Das hat verschiedene Auswirkungen.

                        Definiere bitte "klassische Dokumentenvorstellung". Beim W3C kann ich das nicht finden. Ich bleibe auch dabei, dass ein Frameset zwischen veschiedenen Elementen auf einer logischen Ebene eine Relation herstellt (Titel, Inhaltsangabe, Kapitel).

                        Das Einbinden von CSS oder JavaScript *in* ein klassisches Dokument konterkariert nicht dessen Konzept.

                        "Sie macht ausschliesslich Angaben über die grafische Präsentation anderer Dokumente. Für andere Ausgabemedien als für die hochauflösende Bildschirmdarstellung hat das Frameset keine Bedeutung."
                        Das ist schlicht unfug. Wie Eric Myer u.a. zeigt, macht es insbesondere dann Sinn, ein Frameset einzusetzten, wenn das Menü sehr viele Einträge hat (ein Übersicht zB. s.a. die Sidebar von Selfhtml u.a.). Ein Frameset lässt sich zudem in der Größe verändern und macht im korrekten Falle genau eine inhaltliche Aussage: zwei Inhalte, die sich in einer 1:n Relation befinden.

                        Du widersprichst dem Text damit überhaupt nicht, der macht trotzdem seinen Punkt.

                        Verstehe ich nicht. Ich versuche doch klar zu machen, dass es um einen logischen Zusammenhang geht. Zwei Dinge nebeneinander zu stellen, die sich aufeinander beziehen ist etwas andere als "ausschließlich Angaben über die grafische Präsentation" zu machen. Auch der zweite Satz zum Viewport passt doch irgendwie nicht zum Myer-Beispiel. Die Bedeutung hat doch nichts mit einem großen Viewport zu tun.

                        Es ist eigentlich egal, was für eine Beziehung zwischen den Inhalten besteht.

                        Das hätte ich gerne erläutert. Das scheint mir so gesagt eher in Richtung sinnfrei.

                        Natürlich besteht oft eine inhaltliche Relation, dazu setzt man Frames schließlich ein.

                        Naja, das meine ich ja, als einen Punkt unter einigen.

                        Die Aussage des Textes ist aber, dass diese Relation nicht im Frameset ausgedrückt ist. Darin stehen nur Elemente, die eine grafische Anordnung definieren.

                        Da sage ich mal, das ist schlicht falsch. Wenn ich title="Logo", title="Menue" title="Content" angebe, ist das ein logischer Zusammenhang. Genau dafür ist HTML da. Eine Ebene über dem Verhältnis <h1> zu <h2> zu <p>. Abgesehen davon, dass ohne jegliches Layout, wenn ich den Quelltext nicht lesen würde (s.a. titles der Frames), auch h1, h2 und p keinen Sinn machen würden. Layout ist einfach auch informationsgebend.

                        Sie können prinzipiell keine inhaltlich-semantische Relation ausdrücken.

                        Naja, wie gesagt, das wäre genau aus meiner Sicht der interssante  Punkt.

                        DESHALB gilt eben, dass Framesets für andere Ausgabemedien, die der Darstellung nicht fähig sind, nichts sagen (und eine Navigation deshalb schwierig ist, weil der Benutzer erstmal die Relation selbst herausfinden muss, was je nach Zugangstechnik ziemlich schwierig ist).

                        Verstehe ich nicht, was Du meinst. Mit Vorlesegeräten kommst Du bei korrekter semantischer Zuordnung sehr gut damit zurecht, so meine Info. Zudem ist das "Layout" noch für den User (also an den Viewport) anpassbar. Was denn zB mit einer Tabelle, die Bilder (vorher - nachher) gegenüberstellt. Auch so eine logische Relation.

                        Denn mehr als die bloße Darstellung drücken sie nicht aus.

                        Naja, jetzt kreist es.

                        "Das FRAMESET ist ein toter Container, der nichts von seinen Inhalten weiß."

                        Genau wie ein <img> oder <objekt>. Es gibt eben auch nichtschriftliche Inforamtion.

                        Du widersprichst wieder einer Aussage, die gar nicht gemacht wurde.

                        Das kapier ich nicht. Das Auslesen des Inhaltes des src-Attributes eines img bringt mir erstmal genausoviel "meta" Info wie das Auslesen des src-Attributes eines frames. title und alt Tags helfen dann schon weiter. Komisch, dass manche Menschen Dinge nichtssagend finden, die mir erstmal was sagen. Vielleicht hör ich ja Stimmen?

                        object ist Bestandteil eines klassischen HTML-Dokuments und das ist in diesem Kontext völlig konsistent: Ein Dokument verweist auf andere Medien in einem bestimmten inhaltlichen Kontext.

                        Und ein HTML-Dokument ist kein Medium? Das klingt für mich so, als wenn die Elemente eines Hashes keine Hashes selbst ein dürften.

                        Ein Frameset ist aber ein eigenständiges HTML-Dokument. (Jetzt könnte man natürlich drüber diskutieren, ob ein Dokument nur mit ein paar objects, die mit CSS über den Bildschirm geklebt werden, noch ein klassisches Dokument ist und was den Unterschied zum »toten Container« macht.)

                        Jap, fände ich gut, wenn das mal ausdiskutiert wird, SELFHTML hier eine Position bezieht und sich nicht "versteckt" (ich weiß, das klingt gemein, soll pointiert gemeint sein) hinter einer vorgeblich ewig veralteten Dokumentation. Ich fände, es wäre für diese Neverending Story ein Ending, wenn es hier einen aktuellen Artikel dazu gäbe.

                        Diese Aussage findet sich auch nirgends beim W3C.

                        Was für ein Argument... ;)

                        Nun, über den Tellerrand zu schaun, oder was? (;-). Bei einem Pro und Contra gehört für mich mindestens dazu, dass framesets weder "deprecated" sind noch "accessibility"-probleme haben. Zwei wichtige Gründe für mich zumindest.

                        Ich kann doch gerade und nur beim Frameset das selbst sofort anpassen, sogar das Menü wegschieben um mehr Platz für den Inhalt zu haben bzw. es aufziehen, wenn ich zu einem weiteren Thema den Menüpunkt suche.

                        Bei integrierten Navigationen kann man auch durch Scrollen das Menü wegschieben bzw. in den Fokus holen... Ist nix spezifisches.

                        Naja, ich muss den Inhalt scrollen, um das Menü zu sehen. Für mich spitzt sich das in der Frage zu, wo denn die <ul class="menu"> denn im semantisch wohlsortierten HTML-Dokument seien Platz hat. Vor dem <h1>? Wohl kaum, denn vor dem <h1> kann nichts stehen, sonst wäre es ja nicht die <h1>. Dannach? Auch nicht, denn die Inhaltsübersicht ist ja kein inhaltlicher Teil von <h1>Nahrung<h1> auf meiner Unter(!)- Seite in meinem HTML-Seite über "Meerschweinchen".

                        Dank und Gruß,

                        frankx

                        1. Hello out there!

                          Das w3c schreibt auch bei den Problemen nur von der "usability" […] Es rät sogar zur Alternative Nutzung von <object>.

                          An welcher Stelle?

                          Für mich ist die Einbindung eines HTML-Dokuments in 'iframe' oder 'object' psinzipiell dasselbe. (Die kleinen Unterschiede sind marginal: das eine ist Strict, das andere wird von Browsern besser unterstützt.) [</archiv/2006/3/t126257/#m814260>]

                          Bei einem Pro und Contra gehört für mich mindestens dazu, dass framesets weder "deprecated" sind

                          Deprecated genug, dass es sie in HTML 4.01 Strict, XHTML 1.0 Strict und XHTML 1.1 nicht gibt.

                          noch "accessibility"-probleme haben.

                          Hm, haben sie wirklich keine?

                          „Nicht alle Benutzer können von visuellen Hilfen wie Imagemaps, proportionalen Scrollbars, nebeneinander angeordneten Frames oder Grafiken Gebrauch machen, die sehenden Benutzern von grafischen Desktop-Browsern den Weg weisen.“ [WCAG §2.2]

                          Für mich spitzt sich das in der Frage zu, wo denn die <ul class="menu"> denn im semantisch wohlsortierten HTML-Dokument seien Platz hat. Vor dem <h1>? Wohl kaum, denn vor dem <h1> kann nichts stehen, sonst wäre es ja nicht die <h1>. Dannach? Auch nicht, denn die Inhaltsübersicht ist ja kein inhaltlicher Teil von <h1>Nahrung<h1> auf meiner Unter(!)- Seite in meinem HTML-Seite über "Meerschweinchen".

                          Da führst du einen interessanten Punkt an; da muss ich mal drüber schlafen.

                          See ya up the road,
                          Gunnar

                          --
                          „Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (Kirsten Evers)
                          1. Hellihello Guunar,

                            hoffentlich gut geschlafen.

                            Das w3c schreibt auch bei den Problemen nur von der "usability" […] Es rät sogar zur Alternative Nutzung von <object>.

                            An welcher Stelle?

                            http://www.w3.org/TR/WCAG10-HTML-TECHS/#alt-frames, oder verstehe ich da was miss?

                            Für mich ist die Einbindung eines HTML-Dokuments in 'iframe' oder 'object' psinzipiell dasselbe. (Die kleinen Unterschiede sind marginal: das eine ist Strict, das andere wird von Browsern besser unterstützt.) [/archiv/2006/3/t126257/#m814260]

                            Bei einem Pro und Contra gehört für mich mindestens dazu, dass framesets weder "deprecated" sind

                            Deprecated genug, dass es sie in HTML 4.01 Strict, XHTML 1.0 Strict und XHTML 1.1 nicht gibt.

                            Nun, lieber Gunnar, Du nimmst es doch sonst so genau (;-). Einigen wir uns darauf, dass "deprecated" ein reservierter Begriff ist beim W3C, der vom W3C auf Frames nicht angewandt wird?

                            noch "accessibility"-probleme haben.

                            Hm, haben sie wirklich keine?

                            „Nicht alle Benutzer können von visuellen Hilfen wie Imagemaps, proportionalen Scrollbars, nebeneinander angeordneten Frames oder Grafiken Gebrauch machen, die sehenden Benutzern von grafischen Desktop-Browsern den Weg weisen.“ [WCAG §2.2]

                            Also ich habe es so verstanden: "Und wenn Sie Frames verwenden (Priorität 2)  12.2 Beschreiben Sie den Zweck von Frames und ihre Beziehung untereinander, wenn dies aus den Titeln allein nicht ersichtlich wird."
                            http://www.w3c.de/Trans/WAI/webinhalt.html#tech-frame-longdesc.

                            Du kriegst beim WAI doch "Abzüge" für fehlende Infos zB. kein lang-Attribut im html-Element, kein alt-Attribut und kein title-Attribut bei <img>. Nicht aber für Frames grundsätzlich.

                            Für mich spitzt sich das in der Frage zu, wo denn die <ul class="menu"> denn im semantisch wohlsortierten HTML-Dokument seien Platz hat. Vor dem <h1>? Wohl kaum, denn vor dem <h1> kann nichts stehen, sonst wäre es ja nicht die <h1>. Dannach? Auch nicht, denn die Inhaltsübersicht ist ja kein inhaltlicher Teil von <h1>Nahrung<h1> auf meiner Unter(!)- Seite in meinem HTML-Seite über "Meerschweinchen".

                            Da führst du einen interessanten Punkt an; da muss ich mal drüber schlafen.

                            Der könnte meiner bescheidenen Meinung nach auch in einem überarbeiteten Artikel in SELFHTML zumindest erwähnt werdn.

                            In einem einzigen Dokument,das  <h1>Meerschweinchen</h1>, dann <h2>Inhaltsangabe</h2> und später dann <h2>Lebensraum</h2>... <h2>Nahrung</h2> hat, alles auf einer Seite, wäre das semantisch alles korrekt. Und es zeigt sich, dass die Inhaltsangabe auf einer logischen Ebene (h2) mit den Inhaltkapitelm steht, wobei doch die Kapitel "Lebensraum" und "Nahrung" in einer anderen logischen Beziehung zueinander stehen als zu der "Inhaltsangabe". Diese hat zu beiden einen übergeordneten Bezug bzw. stellt auch immer deren Bezug untereinander da, während sich die Kapitel nur bei Bedarf untereinander referenzieren.

                            Dank und Gruß,

                            frankx

                        2. Hallo,

                          Das Element, ob object, img oder iframe oder frame verweist auf eine Quelle. Einmal ein Flashfilm, einmal ein Bild, einmal ein animiertes GiF, einmal ein weiterer HTML-Quelltext. Ich finde das logisch einwandfrei.

                          Das Problem ist weniger, Daten in ein Dokument einzubinden. (Bzw. das wird durchaus ein Problem, wenn HTML-Dokumente in HTML-Dokumente eingebunden werden - weil diese schwer adressierbar sind usw.) Das ist wie gesagt das klassische Modell. Ein Frameset hingegen ist nur ein Meta-Dokument, das bloß auf Inhalte verweist - und zwar nicht, um diese inhaltlich, sondern hinsichtlich der Präsentation aufeinander zu beziehen.

                          Definiere bitte "klassische Dokumentenvorstellung". Beim W3C kann ich das nicht finden.

                          Es ist all das, was du beim W3C findest (Strict, Transitional), ausgenommen Frameset.

                          Ich bleibe auch dabei, dass ein Frameset zwischen veschiedenen Elementen auf einer logischen Ebene eine Relation herstellt (Titel, Inhaltsangabe, Kapitel).

                          Um mich zu wiederholen: Die Relation stellst du als Autor *mit* dem Frameset her. Sie steht aber nicht im Frameset drin - damit meine ich: nicht maschinenlesbar. HTML kann solche Beziehungen nicht ausdrücken. Wenn das angelegt wäre (nunja, es gibt link-Relations, sagen wir einmal: von Browsern sinnvoll implementiert), gäbe es viele Probleme von Frames nicht. (XFrames hatte den Anspruch, einiges davon umzusetzen.)

                          Die Aussage des Textes ist aber, dass diese Relation nicht im Frameset ausgedrückt ist. Darin stehen nur Elemente, die eine grafische Anordnung definieren.

                          Da sage ich mal, das ist schlicht falsch. Wenn ich title="Logo", title="Menue" title="Content" angebe, ist das ein logischer Zusammenhang.

                          Nochmal: Ein HTML-Client kann sich nicht dafür interessieren, was für eine Logik du dir »dabei gedacht hast« oder auch mit natürlicher Sprache in Form von title im Frameset untergebracht hast. Er kann letzteres dem Benutzer kommunizieren und der muss sehen, was er damit anfängt. Das ist ganz ok, aber schon alles. Der Client selbst *versteht* sie nicht und kann deshalb ggf. auch keine automatische sinnvolle Linearisierung der Frameset-Struktur bieten.

                          Mit Vorlesegeräten kommst Du bei korrekter semantischer Zuordnung sehr gut damit zurecht, so meine Info.

                          Genau, ich als User, der die Verbindung nachvollziehen muss.

                          "Das FRAMESET ist ein toter Container, der nichts von seinen Inhalten weiß."

                          ...

                          Das Auslesen des Inhaltes des src-Attributes eines img bringt mir erstmal genausoviel "meta" Info wie das Auslesen des src-Attributes eines frames. title und alt Tags helfen dann schon weiter.

                          Was ich die ganze Zeit sagen will: Wenn ich in einem Dokument, sagen wir mal, so in textlastiges aus SELFHTML, eine Grafik einbinde, dann ist die natürlich ein eigenständiger Informationsträger. Aber das einbindende Dokument ist (i.d.R.) keine bloße Liste, die Grafiken visuell anordnet und gruppiert. Schon gar nicht ist es ein eigener Dokumenttyp, der nichts anderes als diese Anordnung leisten soll. Das ist mit »toter Container« gemeint.

                          Wenn ich eine Grafik einbinde, so weiß ich zudem um deren Inhalt, bei HTML-Dokumenten ist das etwas anderes, weil ich damit ein neues Universum aufmache, nämlich eine eigene Browsing-Instanz einbaue. In dem Unterfenster kann alles mögliche passieren, die einbindende Browsing-Instanz weiß davon nix. So verstehe ich »nichts von seinen Inhalten wissen«.

                          object ist Bestandteil eines klassischen HTML-Dokuments und das ist in diesem Kontext völlig konsistent: Ein Dokument verweist auf andere Medien in einem bestimmten inhaltlichen Kontext.

                          Und ein HTML-Dokument ist kein Medium?

                          Habe ich doch überhaupt nicht ausgeschlossen. Aber in dem speziellen Fall treten halt die Probleme von Frames auf, insbesondere wenn der »bestimmte inhaltliche Kontext« einfach nicht existiert, weil da bloß eine Art Verweis steht.

                          (Jetzt könnte man natürlich drüber diskutieren, ob ein Dokument nur mit ein paar objects, die mit CSS über den Bildschirm geklebt werden, noch ein klassisches Dokument ist und was den Unterschied zum »toten Container« macht.)

                          Jap, fände ich gut, wenn das mal ausdiskutiert wird, SELFHTML hier eine Position bezieht

                          Es ist ja nicht so, als würde es hier nur um Frames gehen. Tote Container, die nur einbinden und verweisen, während das Eingebundene und Verwiesene dem üblichen Zugriff entzogen wird, haben wir allerorten im Web.

                          Frames machen Navigation im Web schwer, weil sie das Konzept aufweichen, dass definierte Informationen als Hypertext-Knoten adressierbar sind (Subotnik: »Normalerweise zeigt ein Browserfenster ein HTML-Dokument an.«). Das wird eigentlich massiv und auf breiter Ebene immer wieder aufgeweicht, insbesondere durch clientseitig aktive Logik wie JavaScript / AJAX / Rich Internet Application / Single Page Application etc. pp. Das Web ist heutzutage eine Plattform und nicht bloß ein Netzwerk von atomaren, verknüpften Hypertext-Einheiten (Dokumenten bzw. deren adressierbaren Teilen).

                          Nach wie vor gilt, dass das Web - egal, was man daraus macht - immer AUCH als Hypertext-Netzwerk verarbeitet wird, wo nur einzelne, lose Dokumente und Hyperlinks dazwischen eine Rolle spielen. Damit sollte man rechnen. Trotzdem gab es und gibt es allerorten Tendenzen, die dem entgegenlaufen. Das verbessert die Usability mal, mal schmälert sie sie gleichzeitig, jedenfalls macht dies der Zugänglichkeit oft den Garaus - beziehungsweise das Feld ist einfach noch nicht erforscht.

                          Ich weiß wirklich nicht, wie man dazu etwas Normatives schreiben soll. Mir scheint, dass dieser Widerstreit bei allem technischen Wandel über Jahre hinweg bestehen bleibt. Er ist auch nicht einseitig aufzulösen und es gibt auch keine allgemeine Synthese. Ich denke nicht, dass diese Story in Kürze ein Ende finden wird. Ein Artikel könnte höchstens den Widerstreit beschreiben, den man schon seit Anbeginn des Webs beobachten kann, aber doch keinen Schlussstrich ziehen.

                          Bei einem Pro und Contra gehört für mich mindestens dazu, dass framesets weder "deprecated" sind noch "accessibility"-probleme haben. Zwei wichtige Gründe für mich zumindest.

                          Frames sind nicht einfach neutral in Bezug auf Accessibility.

                          Für mich spitzt sich das in der Frage zu, wo denn die <ul class="menu"> denn im semantisch wohlsortierten HTML-Dokument seien Platz hat.

                          Auf die Frage hat sich die Frames-Debatte schon früher zugespitzt...

                          Die klassische »Menüleiste« hat im HTML-Dokument gar keinen Platz, <http://forum.de.selfhtml.org/archiv/2003/12/t67816/@tite=sagte emu mal>.

                          Deshalb kommt man überhaupt auf die naheliegendere und gleichzeitig widersinnige und praktisch verhängnisvolle Idee, so etwas wie »Navigationen« in eigene Dokumente auszulagern, die dann aber wiederum durch Framesets lose an das Dokument zu koppeln oder mit object einzubinden... Dass das Ergebnis unbefriedigend ist, kommt nicht von ungefähr. Das ist so falsch bzw. inkonsistent, dass nicht einmal das Gegenteil (wiederholte »Navigationsleisten« in jedem Dokument) richtig ist.

                          Mathias

                          1. Hellihello Mathias,

                            Das Element, ob object, img oder iframe oder frame verweist auf eine Quelle. Einmal ein Flashfilm, einmal ein Bild, einmal ein animiertes GiF, einmal ein weiterer HTML-Quelltext. Ich finde das logisch einwandfrei.

                            Das Problem ist weniger, Daten in ein Dokument einzubinden. (Bzw. das wird durchaus ein Problem, wenn HTML-Dokumente in HTML-Dokumente eingebunden werden - weil diese schwer adressierbar sind usw.) Das ist wie gesagt das klassische Modell. Ein Frameset hingegen ist nur ein Meta-Dokument, das bloß auf Inhalte verweist - und zwar nicht, um diese inhaltlich, sondern hinsichtlich der Präsentation aufeinander zu beziehen.

                            Nun schon das Wort "Meta" ließe ja zumindest den Gedanken nach inhaltlicher Aussage mal kurz aufkeimen. Ich male ein Haus, nur den "body". Ich male ein Dach, darüber. Das ist keine Frage des Layouts, sondern des logischen Bezuges. Eine Tabelle setzt Dinge in einen logischen Bezug, weil es sie übereinander und nebeneinander stehen. Das ist ein Teil der Information, meiner bescheidenen Meinung nach. Ein Frameset, mal so angerissen, dann etwas wie eine "Meta"-Tabelle.

                            Definiere bitte "klassische Dokumentenvorstellung". Beim W3C kann ich das nicht finden.

                            Es ist all das, was du beim W3C findest (Strict, Transitional), ausgenommen Frameset.

                            Ums jetzt mal genau zu nehmen: definiert das W3C das so oder ist das Deine "willkürliche" (;-) Definition?

                            Ich bleibe auch dabei, dass ein Frameset zwischen veschiedenen Elementen auf einer logischen Ebene eine Relation herstellt (Titel, Inhaltsangabe, Kapitel).

                            Um mich zu wiederholen: Die Relation stellst du als Autor *mit* dem Frameset her. Sie steht aber nicht im Frameset drin - damit meine ich: nicht maschinenlesbar. HTML kann solche Beziehungen nicht ausdrücken. Wenn das angelegt wäre (nunja, es gibt link-Relations, sagen wir einmal: von Browsern sinnvoll implementiert), gäbe es viele Probleme von Frames nicht. (XFrames hatte den Anspruch, einiges davon umzusetzen.)

                            Mh, haben nur die Menschen oder die Browser die Probleme. Die Relationen innerhalb einer Tabelle stelle auch ich als Autor her. Der Browser weiß nur, dass er <th> mal dick schreiben soll, thats all, wenns <th> überhaupt gibt.

                            Die Aussage des Textes ist aber, dass diese Relation nicht im Frameset ausgedrückt ist. Darin stehen nur Elemente, die eine grafische Anordnung definieren.

                            s.o. Grafische Anordnung (mbMn) = Information

                              
                            <table>  
                            <tr>  
                            <td>  
                            <img title="Auto vor dem Unfall" src="auto_vor_unfall.jpg">  
                            </td>  
                            <td>  
                            <img title="Auto nach dem Unfall" src="auto_nach_unfall.jpg">  
                            </td>  
                            </tr>  
                            </table>  
                            
                            

                            Der Browser (Maschinenlesbarkeit) weiß nur, ob er irgendwo Linien malen darf und was rechts, links, oben, unten hinkommt. Browser können auch xml anzeigen, und verstehen ohne Stylessheet nur, dass es xml ist.

                            Da sage ich mal, das ist schlicht falsch. Wenn ich title="Logo", title="Menue" title="Content" angebe, ist das ein logischer Zusammenhang.

                            Nochmal: Ein HTML-Client kann sich nicht dafür interessieren, was für eine Logik du dir »dabei gedacht hast« oder auch mit natürlicher Sprache in Form von title im Frameset untergebracht hast.

                            Nee, aber alle anderen, zb http://www.w3c.de/Trans/WAI/webinhalt.html#tech-frame-longdesc:  "Beschreiben Sie den Zweck von Frames und ihre Beziehung untereinander" . Ein HTML-Client weiß nicht, was ein <h1> bedeutet. Er weiß auch nicht, was <autor> bedeutet.

                            Er kann letzteres dem Benutzer kommunizieren

                            Das halte ich für gewagt. Der Client kommuniziert (s.o.) garnicht, er kann "nur" Layouten.

                            und der muss sehen, was er damit anfängt.

                            Hups, da steht ja was nebeneinander, und was darüber, das bedeutet: oben der Titel, links die Navi (;-).

                            Das ist ganz ok, aber schon alles. Der Client selbst *versteht* sie nicht und kann deshalb ggf. auch keine automatische sinnvolle Linearisierung der Frameset-Struktur bieten.

                            Die kann er auch sonst nicht anbieten. Er verfügt über eine internes Default-Stylesheet bezogen auf HTML-Syntax, das wars.

                            Mit Vorlesegeräten kommst Du bei korrekter semantischer Zuordnung sehr gut damit zurecht, so meine Info.

                            Genau, ich als User, der die Verbindung nachvollziehen muss.

                            Und nur der User zählt, oder?

                            "Das FRAMESET ist ein toter Container, der nichts von seinen Inhalten weiß."
                            ...
                            Das Auslesen des Inhaltes des src-Attributes eines img bringt mir erstmal genausoviel "meta" Info wie das Auslesen des src-Attributes eines frames. title und alt Tags helfen dann schon weiter.

                            Was ich die ganze Zeit sagen will: Wenn ich in einem Dokument, sagen wir mal, so in textlastiges aus SELFHTML, eine Grafik einbinde, dann ist die natürlich ein eigenständiger Informationsträger. Aber das einbindende Dokument ist (i.d.R.) keine bloße Liste, die Grafiken visuell anordnet und gruppiert. Schon gar nicht ist es ein eigener Dokumenttyp, der nichts anderes als diese Anordnung leisten soll. Das ist mit »toter Container« gemeint.

                            "Hypertext bedeutet nicht nur, dem Anwender per Mausklick weitere Informationen zur Verfügung zu stellen, sondern auch, dem Anwender die Möglichkeit zu bieten, sich selbst Informationen so zusammenzustellen, dass er sie optimal miteinander vergleichen und daraus Schlüsse oder Entscheidungen ableiten kann. Zu diesem Zweck eignet sich die Frame-Technik hervorragend, da sie es erlaubt, verschiedene, getrennt voneinander gespeicherte Informationen auf Anwenderwunsch gleichzeitig anzuzeigen."

                            http://de.selfhtml.org/html/frames/layouts.htm ???

                            Wenn ich eine Grafik einbinde, so weiß ich zudem um deren Inhalt, bei HTML-Dokumenten ist das etwas anderes, weil ich damit ein neues Universum aufmache, nämlich eine eigene Browsing-Instanz einbaue. In dem Unterfenster kann alles mögliche passieren, die einbindende Browsing-Instanz weiß davon nix. So verstehe ich »nichts von seinen Inhalten wissen«.

                            Nun, in der Regel weiß die Navi, was im Content steht, oder?

                            object ist Bestandteil eines klassischen HTML-Dokuments und das ist in diesem Kontext völlig konsistent: Ein Dokument verweist auf andere Medien in einem bestimmten inhaltlichen Kontext.

                            Und ein HTML-Dokument ist kein Medium?

                            Habe ich doch überhaupt nicht ausgeschlossen. Aber in dem speziellen Fall treten halt die Probleme von Frames auf, insbesondere wenn der »bestimmte inhaltliche Kontext« einfach nicht existiert, weil da bloß eine Art Verweis steht.

                            Das hab ich jetzt nicht ganz kapiert.

                            (Jetzt könnte man natürlich drüber diskutieren, ob ein Dokument nur mit ein paar objects, die mit CSS über den Bildschirm geklebt werden, noch ein klassisches Dokument ist und was den Unterschied zum »toten Container« macht.)

                            Na, es wird natürlihc etwas haarspalterisch, aber ich meine, das ist der oder ein "Kern" der Diskussion.

                            Jap, fände ich gut, wenn das mal ausdiskutiert wird, SELFHTML hier eine Position bezieht

                            Es ist ja nicht so, als würde es hier nur um Frames gehen. Tote Container, die nur einbinden und verweisen, während das Eingebundene und Verwiesene dem üblichen Zugriff entzogen wird, haben wir allerorten im Web.

                            Frames machen Navigation im Web schwer, weil sie das Konzept aufweichen, dass definierte Informationen als Hypertext-Knoten adressierbar sind (Subotnik: »Normalerweise zeigt ein Browserfenster ein HTML-Dokument an.«). Das wird eigentlich massiv und auf breiter Ebene immer wieder aufgeweicht, insbesondere durch clientseitig aktive Logik wie JavaScript / AJAX / Rich Internet Application / Single Page Application etc. pp. Das Web ist heutzutage eine Plattform und nicht bloß ein Netzwerk von atomaren, verknüpften Hypertext-Einheiten (Dokumenten bzw. deren adressierbaren Teilen).

                            Nach wie vor gilt, dass das Web - egal, was man daraus macht - immer AUCH als Hypertext-Netzwerk verarbeitet wird, wo nur einzelne, lose Dokumente und Hyperlinks dazwischen eine Rolle spielen. Damit sollte man rechnen. Trotzdem gab es und gibt es allerorten Tendenzen, die dem entgegenlaufen. Das verbessert die Usability mal, mal schmälert sie sie gleichzeitig, jedenfalls macht dies der Zugänglichkeit oft den Garaus - beziehungsweise das Feld ist einfach noch nicht erforscht.

                            Ich weiß wirklich nicht, wie man dazu etwas Normatives schreiben soll.

                            Nicht normativ. Informativ wie immer. Bisher konnte ich immer noch SELFHTML zitieren mit "Durch den Einsatz von Frames wachsen die Gestaltungsmöglichkeiten außerordentlich. Frames stellen an das Design von HTML-Seiten aber auch besonders hohe Ansprüche." Aber das finde ich grad nicht mehr. Da hieß es immer, das sei "uralt".

                            Mir scheint, dass dieser Widerstreit bei allem technischen Wandel über Jahre hinweg bestehen bleibt. Er ist auch nicht einseitig aufzulösen und es gibt auch keine allgemeine Synthese.

                            Deshalb ja mein Vorschlag, das irgendwie so mal mit "Pro" und "Contra" zu notieren. http://vergessichnicht.de/Frames_Pro_und_Contra als Ideen- und Linksammlung ist mitgewachsen ein bisschen.

                            Ich denke nicht, dass diese Story in Kürze ein Ende finden wird. Ein Artikel könnte höchstens den Widerstreit beschreiben, den man schon seit Anbeginn des Webs beobachten kann, aber doch keinen Schlussstrich ziehen.

                            Jenau.

                            Bei einem Pro und Contra gehört für mich mindestens dazu, dass framesets weder "deprecated" sind noch "accessibility"-probleme haben. Zwei wichtige Gründe für mich zumindest.

                            Frames sind nicht einfach neutral in Bezug auf Accessibility.

                            Dazu führe bitte die entsprechende Richtlinie des WAI an. Ich kann das meiner bisherigen Recherche nach nicht bestätigen.

                            Für mich spitzt sich das in der Frage zu, wo denn die <ul class="menu"> denn im semantisch wohlsortierten HTML-Dokument seien Platz hat.

                            Auf die Frage hat sich die Frames-Debatte schon früher zugespitzt...

                            Die klassische »Menüleiste« hat im HTML-Dokument gar keinen Platz, <http://forum.de.selfhtml.org/archiv/2003/12/t67816/@tite=sagte emu mal>.

                            Deshalb kommt man überhaupt auf die naheliegendere und gleichzeitig widersinnige und praktisch verhängnisvolle Idee, so etwas wie »Navigationen« in eigene Dokumente auszulagern, die dann aber wiederum durch Framesets lose an das Dokument zu koppeln oder mit object einzubinden... Dass das Ergebnis unbefriedigend ist, kommt nicht von ungefähr. Das ist so falsch bzw. inkonsistent, dass nicht einmal das Gegenteil (wiederholte »Navigationsleisten« in jedem Dokument) richtig ist.

                            Genau. Bei meinem nächsten Roman - würde ich je einen schreiben - lass ich dann die Inhaltsangabe auf jede Seite mitdrucken anstelle einer praktischen ausklappbaren Inhaltsangabe (;-).

                            Dank und Gruß,

                            frankx

                            1. Hallo,

                              Ich male ein Haus, nur den "body". Ich male ein Dach, darüber. Das ist keine Frage des Layouts, sondern des logischen Bezuges. Eine Tabelle setzt Dinge in einen logischen Bezug, weil es sie übereinander und nebeneinander stehen. Das ist ein Teil der Information, meiner bescheidenen Meinung nach. Ein Frameset, mal so angerissen, dann etwas wie eine "Meta"-Tabelle.

                              Jetzt mischt du Frames, Tabellen usw. ineinander. Die Diskussion der logischen Implikationen von Frames und Tabellen haben wir hier auch schon bis zum Abwinken vor fünf Jahren gehabt.

                              Dazu kann ich leider auch nur wiederholen, was ich jetzt glaube ich schon zweimal gesagt habe: Man kann HTML verwenden und mit irgendwelchen HTML-Strukturen alles mögliche »ausdrücken« und »meinen«. Das hat auch niemand bezweifelt. Aber mit der Diskussion um »Semantik«, Semantic Web, aussagekräftiger, maschinenlesbarer Auszeichnung usw. hat das alles nichts zu tun.

                              Dein Tabellenbeispiel mit den beiden Bildern, die sich aufeinander beziehen, ist nicht einmal ein gutes. Was soll das für eine spezifische Beziehung sein, die durch das »Nebeneinanderstellen« ausgesagt wird? Ein Text ist immer eine lineare, sequentielle Ordnung:

                              <p>Vorher</p>
                              <p>Nachher</p>

                              Was drückt dein Beispiel mehr aus, was nicht hier schon implizit durch die textuelle Aufeinanderfolge ausgedrückt wird? Texte laufen von oben nach unten, von rechts nach links. Ein Satz bezieht sich auf den vorigen und steht zu ihm in einem Folgeverhältnis.

                              Wenn man mit einer bloßen Layouttabelle bereits eine inhaltliche Beziehung ausdrücken kann, wieso kann man es dann z.B. mit CSS nicht, indem man Elemente mit float nebeneinanderstellt?

                              Zurück zu deinem Beispiel. Aussagekräftiger wäre vielleicht noch:

                              <tr><th>Vorher<td><img>
                              <tr><th>Nachher<td><img>

                              Hier wäre die Sequenz durch die Zeilen herausgearbeitet und zudem hätte jede Zeile eine Beschriftung.

                              Aber wenn man penibel ist, ist die Beschriftung bereits im alt-Attribut und die Sequenz muss nicht »vertikal«, sondern kann auch »horizontal« gelegen sein. Somit wären wir wieder bei deinem Beispiel <td><img><td><img>. Wollen wir nur die Sequenz ausdrücken, so wäre doch dies die passendere Auszeichnungsmöglichkeit:

                              <ol>
                              <li><img alt"Auto vorher">
                              <li><img alt="Autor nachher">
                              </ol>

                              Definiere bitte "klassische Dokumentenvorstellung". Beim W3C kann ich das nicht finden.
                              definiert das W3C das so oder ist das Deine "willkürliche" (;-) Definition?

                              Natürlich gibt es dort den Begriff nicht. Aber all die Beschreibungen, was ein HTML-Dokument ist, transportieren ein bestimmtes Dokumentmodell. Und das Frameset ist im Vergleich dazu eben ein anderes, zweites Modell.

                              Die Relationen innerhalb einer Tabelle stelle auch ich als Autor her. Der Browser weiß nur, dass er <th> mal dick schreiben soll, thats all, wenns <th> überhaupt gibt.

                              Ich finde es wenig hilfreich, alles mögliche in einen Topf zu werfen und woanders nach Beispielen zu suchen.

                              Framesets sagen - mit dem Auge der Maschinenlesbarkeit gesehen - neben der Präsentationsanweisung nichts anderes aus, als dass die Dokumente irgendwie zusammengehören und sich auf irgendeine Weise aufeinander beziehen. In welcher Weise, das kann man in menschenlesbaren Attributen unterbringen.

                              th ist damit nicht vergleichbar. th gibt eine Bezeichnung für eine Spalte oder Zeile vor. Diese Beziehung ist maschinenlesbar, wenn man z.B. mit dem scope-Attribut arbeitet und auch sonst die Tabelle entsprechend strukturiert. Dann weiß der Browser genau, in welcher strukturellen Beziehung die Inhaltsteile zueinander stehen. Zumindest insofern, dass man die Tabelle z.B. in einem Screenreader mit der Tastatur durchlaufen kann und der Browser zu jeder Zelle die verknüpften Kontext-Infos geben kann.

                              Letzteres habe ich das auch immer für Frames propagiert: Wenn man Frames einsetzt, dann doch bitte diese Beziehungen explizieren. Das wird mitunter ziemlich aufwändig und unelegant.

                              Das ist ganz ok, aber schon alles. Der Client selbst *versteht* sie nicht und kann deshalb ggf. auch keine automatische sinnvolle Linearisierung der Frameset-Struktur bieten.

                              Die kann er auch sonst nicht anbieten. Er verfügt über eine internes Default-Stylesheet bezogen auf HTML-Syntax, das wars.

                              Nein, er kann die Dokumentteile gemäß ihrer Auszeichnung wiedergeben bzw. diese verarbeiten, z.B. ein Zitat als solches kennzeichnen oder eine Liste der Überschriften anbieten.

                              "Hypertext bedeutet nicht nur, dem Anwender per Mausklick weitere Informationen zur Verfügung zu stellen, sondern auch, dem Anwender die Möglichkeit zu bieten, sich selbst Informationen so zusammenzustellen, dass er sie optimal miteinander vergleichen und daraus Schlüsse oder Entscheidungen ableiten kann. Zu diesem Zweck eignet sich die Frame-Technik hervorragend, da sie es erlaubt, verschiedene, getrennt voneinander gespeicherte Informationen auf Anwenderwunsch gleichzeitig anzuzeigen."

                              http://de.selfhtml.org/html/frames/layouts.htm ???

                              Ja, schön. Das ist ein Loblied auf das revolutionäre Interface-Konzept namens ... »Fenster«! In der Konsequenz haben wir heute Browser, die mehrere Dokumente in einem Fenster anzeigen können.

                              Fensterbasierte grafische Oberflächen sind toll und ultrawichtig, und dieser Umgang mit Informationen im Web gehört zum Alltag. Das hat aber (zumindest historisch-faktisch) mit Frames und deren Anwendung nichts zu tun. Wir machen das alles heute ganz wunderbar ohne Frames und niemand empfindet Frames dazu als sonderlich große Hilfe: Wenn ich auf einer Site Informationen vergleichen will, dann kann ich dies sehr prägnant in *einem* »klassischen« Dokument tun. (Das Dokument kann natürlich dynamisch generiert sein.) Wenn ich Dokumente gänzlich fremder Sites vergleichen will, nutze ich die Möglichkeiten meines UI. Mir fällt beim besten Willen kein Beispiel zu diesem Anwendungsbereich von Frames ein. (Mashups mit Frames - das wäre ja richtig Webzwonull!)

                              (Ich glaube, ich habe die Stelle schon ungefähr fünfmal kommentiert...)

                              ... bei HTML-Dokumenten ist das etwas anderes, weil ich damit ein neues Universum aufmache, nämlich eine eigene Browsing-Instanz einbaue. In dem Unterfenster kann alles mögliche passieren, die einbindende Browsing-Instanz weiß davon nix. So verstehe ich »nichts von seinen Inhalten wissen«.

                              Nun, in der Regel weiß die Navi, was im Content steht, oder?

                              Nein, im Content-Fenster kann ein Dokument angezeigt werden, zu dem die Navigation überhaupt keine Verbindung hat.

                              Bisher konnte ich immer noch SELFHTML zitieren mit "Durch den Einsatz von Frames wachsen die Gestaltungsmöglichkeiten außerordentlich. Frames stellen an das Design von HTML-Seiten aber auch besonders hohe Ansprüche." Aber das finde ich grad nicht mehr. Da hieß es immer, das sei "uralt".

                              Das ist natürlich eine Aussage mit Bezug auf die damaligen anderweitigen Gestaltungsmöglichkeiten.

                              Bei einem Pro und Contra gehört für mich mindestens dazu, dass framesets weder "deprecated" sind noch "accessibility"-probleme haben. Zwei wichtige Gründe für mich zumindest.

                              Frames sind nicht einfach neutral in Bezug auf Accessibility.

                              Dazu führe bitte die entsprechende Richtlinie des WAI an.

                              Ich weiß nicht, was du da verlangst. Nicht bei allen Richtlinien der WCAG 1 ist ein konkreter Bezug zu Frames hergestellt (diese Bezüge sind im Übrigen in den »Techniques« untergebracht), trotzdem betreffen viele Richtlinien auch implizit Frames. Soll ich die aufzählen? (Und warum gerade die uralten WCAG 1?)

                              Mathias

                              1. Hellihello Mathias,

                                also in der Regel lasse ich mich in Fragen der Programmierung (-stechnik / Vinzenz) und auch der Verwendung von MVC, der weitesgehenden Trennung von Layout, Content, Datenmodell und Verarbeitung ja immer wieder überzeugen. Auch Semantik finde ich wie auch Accessibility einen wichtigen Aspekt.

                                Dennoch fehlt mir hier scheinbar ein Gen, der u.a. von Dir angeführten Argumentation zu folgen. Es kommen ja auch von Dir Sätze a la: hab ich schon zweimal gesagt, haben wir schon mehrfach gesagt.

                                Mein Fazit: es gibt unterschiedliche Ansichten, Frames sind nicht wirklich suchmaschinenunfreundlich, es gibt eine (überwiegende) Menge von Personen (zumindest hier im Forum), die sie im Grunde als "deprecated" ansehen, obwohl sie das laut W3C nicht sind und auch mit dem WAI konform gehen.

                                Die Tatsache, dass eine Navigation im Grunde aus semantischer Sicht keinen sinnvollen Platz in einem HTML-Dokument hat, wollte Gunnar immerhin mal überschlafen.

                                Ich empfinde diese _sorry_ etwas stupide oder monotone Verweiserei auf einen zugegebener Weise meiner bescheidenen Meinung nach eher unausgewogenen Artikel bei subotnik, der Zumal im Widerspruch zu den Publikationen hier bei SELF steht, als irgendwie der Sache und auch dem Geist von SELFHTML nicht angemessen, merke aber auch, dass viele hier entweder abgegessen von diesem Thema sind und/oder eben ihr Fazit gezogen haben.

                                Eine Gegenüberstellung der Punkte, so dachte ich, könnte es dem mündigen Newbie vielleicht ermöglichen, sich hier selbst ein Bild zu machen. Vinzenz hat ja sogar auch in die Richtung argumentiert.

                                Im Grunde meine ich, sei alles gesagt, auch wenn ichs irgendwie in der Birne scheints nicht ganz zusammnen kriege.

                                Dank und Gruß und guts Nächtle,

                                frankx

                                Ps. Ich kann ja diesen Thread noch als Verweis mit aufnehmen und die Pro und Contra-Liste selbst im Netz stehen lassen, und dann bei Gunnars ostinativen Subotniklinks einen ostinativen Contrapunkte setzen (;-) oder es auch bleiben lassen. Gehört ja auch zum SELF dazu, herauszufinden, was von den hier gegebenen Antworten wie und wo seine Richtigkeit hat.

                              2. Texte laufen von oben nach unten, von rechts nach links.

                                !ralk si, een aJ