eeye: /(XHTML) + (CSS) history.back() ohne JS

Hey folks

Folgendes Problem:
Will man in der Navi einen echten "Schritt zurück" gehen (quasi Back-Buton des Browsers), also kein link auf die Seite, die in der Struktur logisch davor kommt, geht das ja mit Javascript und history.back().
In WML gab es auch die Möglichkeit, das direkt mittels des <prev /> Tags zu notieren:   <do label="Zurück" type="back"><prev/></do>

Geht sowas auch mit plain XHTML+CSS ohne JS?

Ansonsten fällt mir dazu nur ne serverseitige Lösung ein. Den client anhand der IP tracken und die zurück-links entsprechend generieren...

Grüsse, eeye

PS: XHTML gibts nicht als Themenbereich. Was nehemen? Eher HTML oder eher XML-Derivat?

--
[ ] <- Nail here for new Monitor.
  1. Hi,

    Will man in der Navi einen echten "Schritt zurück" gehen (quasi Back-Buton des Browsers), also kein link auf die Seite, die in der Struktur logisch davor kommt,

    nicht in der Struktur. Die History des Browsers hat _nichts_ mit Strukturen zu tun. (X)HTML schon (bzw. eigentlich nur), aber nicht die History.

    Geht sowas auch mit plain XHTML+CSS ohne JS?

    (X)HTML ist Struktur, CSS ist Darstellung, JavaScript ist Funktion. Was Du benötigst ist weder Struktur noch Darstellung, sondern Funktion.

    Ansonsten fällt mir dazu nur ne serverseitige Lösung ein. Den client anhand der IP tracken und die zurück-links entsprechend generieren...

    Ja, aber warum so kompliziert? Der Browser hat doch schon seinen Back-Button, der zudem unschätz- und unersetzbare Vorteile bietet, wie z.B. dass der User ihn bereits kennt.

    PS: XHTML gibts nicht als Themenbereich. Was nehemen? Eher HTML oder eher XML-Derivat?

    XHTML ist ein "modernes" HTML, daher würde ich es eher dort ansiedeln.

    Cheatah

    --
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. Hi,

      Will man in der Navi einen echten "Schritt zurück" gehen (quasi Back-Buton des Browsers), also kein link auf die Seite, die in der Struktur logisch davor kommt,

      nicht in der Struktur. Die History des Browsers hat _nichts_ mit Strukturen zu tun. (X)HTML schon (bzw. eigentlich nur), aber nicht die History.

      Nee, is klar. War Missverständlich ausgedrückt. Was ich meinte mit Struktur:
      Ich hab (nur Bsp.) folgende Seitenstruktur:
      seite1.html linkt auf seite2.html und die auf seite3.html. Von seite1 aus spring ich nun dirket auf Seite3 (url eingeben). DFann komm ich mit dem Back-Button wieder zuück auf seite1 und mit einem hardcoded zurück-link auf "die Seite, die in der (Site)Struktur logisch davor kommt" (was ich ja eben nicht will)
      Meinen also imho schon das gleiche... hoffentlich hat das jetzt jemand verstanden...

      Geht sowas auch mit plain XHTML+CSS ohne JS?

      (X)HTML ist Struktur, CSS ist Darstellung, JavaScript ist Funktion. Was Du benötigst ist weder Struktur noch Darstellung, sondern Funktion.

      ACK. Allerdings hat WML diese Funktionalität eben per <prev/> Tag bereitgestellt.

      Ansonsten fällt mir dazu nur ne serverseitige Lösung ein. Den client anhand der IP tracken und die zurück-links entsprechend generieren...

      Ja, aber warum so kompliziert? Der Browser hat doch schon seinen Back-Button, der zudem unschätz- und unersetzbare Vorteile bietet, wie z.B. dass der User ihn bereits kennt.

      Stimmt ;) Und wieder mein Fehler, da evtl unvollständige Aufgabenstellung (bzw wollen die Antworter hier immer gern wissen warum man etwas macht, die Fragesteller meistens wie *gg*)
      Also Ergänzung zur Fragestellung: Zielplattform sind Handys -> daher keine einheitlichen Browser, keine Back-Buttons (jedenfalls nich immer), kein JS....

      PS: XHTML gibts nicht als Themenbereich. Was nehemen? Eher HTML oder eher XML-Derivat?

      XHTML ist ein "modernes" HTML, daher würde ich es eher dort ansiedeln.

      Seh ich auch so, dann weiss auch jeder, was gemeint ist.
      XML-Derivat ist wohl eher für SVG, WSDL, etc gedacht...

      Grüsse, eeye

      --
      [ ] <- Nail here for new Monitor.
      1. Hi,

        Nee, is klar. War Missverständlich ausgedrückt. Was ich meinte mit Struktur:

        danke, aber das dachte ich mir schon :-)

        ACK. Allerdings hat WML diese Funktionalität eben per <prev/> Tag bereitgestellt.

        Jein, die Funktionalität steckt im Client. In WML ist lediglich ein Element speziell dafür vorgesehen. (X)HTML hat nichts dergleichen.

        Also Ergänzung zur Fragestellung: Zielplattform sind Handys -> daher keine einheitlichen Browser, keine Back-Buttons (jedenfalls nich immer), kein JS....

        Hm, dann verstehe ich nicht, warum Du XHTML verwenden willst ...?

        Cheatah

        --
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
        1. Hi

          ACK. Allerdings hat WML diese Funktionalität eben per <prev/> Tag bereitgestellt.
          Jein, die Funktionalität steckt im Client. In WML ist lediglich ein Element speziell dafür vorgesehen. (X)HTML hat nichts dergleichen.

          Klingt äusserst einleuchtend. Muss ja client-Funktionalität sein. Danke fürs draufstossen :)

          Also Ergänzung zur Fragestellung: Zielplattform sind Handys -> daher keine einheitlichen Browser, keine Back-Buttons (jedenfalls nich immer), kein JS....
          Hm, dann verstehe ich nicht, warum Du XHTML verwenden willst ...?

          Tja, wie das so oft ist: Chef kommt und sagt "Stell mal die alten WML-Seiten möglichst 1:1 auf XHTML+CSS um."
          Die XHTML+CSS unterstützung moderner Handys is gar nich mal sooo übel.  Natürlich kein Vergleich zu dem was "richtige" Browser können (sollten).

          Grüsse und Danke, eeye

          --
          [ ] <- Nail here for new Monitor.
          1. Hallo,

            Da Du offenbar einige Kenntnisse und Erfahrungen hast, erlaube ich mir
            ein paar Anschlussfragen, die mich schon lange interessieren:

            Tja, wie das so oft ist: Chef kommt und sagt "Stell mal die alten WML-Seiten möglichst 1:1 auf XHTML+CSS um."

            Verwendest Du XHTML Basic?
            http://www.w3.org/TR/xhtml-basic/

            Oder vollstaendiges XHTML 1.0?

            Die XHTML+CSS unterstützung moderner Handys is gar nich mal sooo übel.

            • Nehmen sie auch brav Stylesheets mit media="handheld"?
            • Ingorieren sie auch brav Stylesheets mit media="screen"?

            Gruesse,

            Thomas

            --
            Bitte keine Mails mit Fachfragen - dafuer gibt es das Forum!
            Ich mag es, wenn URLs verlinkt sind (</faq/#Q-19>).
            Oft gestellte PHP-Fragen beantwortet die dclp-FAQ bestens: http://www.dclp-faq.de/
            1. Hi

              Da Du offenbar einige Kenntnisse und Erfahrungen hast, erlaube ich mir
              ein paar Anschlussfragen, die mich schon lange interessieren:

              Ger. Allerdings überschätzt du mich. Bin auch noch recht neu im mobile-Bereich und erst seit ca. 1 Monat hier in der Firma. Kann dich also nicht mit umfassenden Fakten versorgen, aber mal kucken, was mein Halbwissen so hergibt ;)

              Verwendest Du XHTML Basic?
              http://www.w3.org/TR/xhtml-basic/

              Oder vollstaendiges XHTML 1.0?

              Vollständiges XHTML 1.0 kann meines erachtens nach kein Handy. Und neben XHTML Basic gibts ja auch noch XHTML MP (Mobile Profile). Ist glaub ich ursprünglich von Nokia kreiert worden und kein offizieller Standard (also nix w3c).
              Hm. Soweit ich das beurteilen kann, wird hier möglichst so gearbeitet, dass der Validator nich mekert und ansonsten so dass es halt tut. Hab bisher leider noch keine Übersicht gefunden, welche Handys was genau wie umsetzen. Hier intern gibts zwar so was ähnliches + die Erfahrungen der Kollegen, aber viel ist immer noch try&error :(
              zB weigern sich Nokia Handys generell links irgendwie umzuformatieren (immer blau, immer unterstrichen)...

              Die XHTML+CSS unterstützung moderner Handys is gar nich mal sooo übel.

              • Nehmen sie auch brav Stylesheets mit media="handheld"?
              • Ingorieren sie auch brav Stylesheets mit media="screen"?

              Das bzweifel ich ernsthaft! Kann aber dazu keinerlei Erfahrungswerte beisteuern. Ist aber ein interessante Frage...

              Liebe Grüsse, eeye

              --
              [ ] <- Nail here for new Monitor.
              1. Ger. Allerdings überschätzt du mich. [...]

                Pardon. Sollte selbstredend Ger_n_ heissen.

      2. Hallo,

        Ansonsten fällt mir dazu nur ne serverseitige Lösung ein. Den client anhand der IP tracken und die zurück-links entsprechend generieren...

        Waere wohl der stabilste Weg.
        Aber IMHO ueberfluessig.
        Ich bin mit Cheatah voellig einig:

        Ja, aber warum so kompliziert? Der Browser hat doch schon seinen Back-Button [...]

        Also Ergänzung zur Fragestellung: Zielplattform sind Handys -> daher keine einheitlichen Browser, keine Back-Buttons (jedenfalls nich immer),

        Das kann ich mir nicht vorstellen. Die Zurueck-Funktion ist eine der
        wichtigsten _jedes_ Browsers. Ob das nun ein Button oder ein Punkt
        im Kontext-Menue ist, ist sekundaer. Aber ich denke, jeder Handy-Browser
        hat diese Moeglichkeit, zurueck zu gehen, und der Benutzer wird
        diese Funktion auch kennen und oft benutzen.

        Schon mein Nokia 6210, das nur sehr rudimentaer WAP/WML "kann",
        hat eine Zurueck-Funktion im Menue.

        Gruesse,

        Thomas

        --
        Bitte keine Mails mit Fachfragen - dafuer gibt es das Forum!
        Ich mag es, wenn URLs verlinkt sind (</faq/#Q-19>).
        Oft gestellte PHP-Fragen beantwortet die dclp-FAQ bestens: http://www.dclp-faq.de/
        1. Hi

          Ansonsten fällt mir dazu nur ne serverseitige Lösung ein. Den client anhand der IP tracken und die zurück-links entsprechend generieren...

          Waere wohl der stabilste Weg.
          Aber IMHO ueberfluessig.

          Seh ich schon auch so. Wäre halt noch ne technisch mögliche, client-unabhängige Möglichkeit gewesen. Wäre aber auch von der Umsetzung her meines erachtens im gegebenen Fal _viel_ zu aufwändig.

          Das kann ich mir nicht vorstellen. Die Zurueck-Funktion ist eine der
          wichtigsten _jedes_ Browsers. Ob das nun ein Button oder ein Punkt
          im Kontext-Menue ist, ist sekundaer. Aber ich denke, jeder Handy-Browser
          hat diese Moeglichkeit, zurueck zu gehen, und der Benutzer wird
          diese Funktion auch kennen und oft benutzen.
          Schon mein Nokia 6210, das nur sehr rudimentaer WAP/WML "kann",
          hat eine zurueck-Funktion im Menue.

          Kann ich mir eigentlich auch nicht vorstellen, aber da das keine "gesicherte Erkenntnis für alle Handys" ist, wäre halt eine client-unabhängige Lösung ganz nett gewesen.
          Für alle Nokia-Handys, die mir bisher so untergekommen sind (7250i, 6220, 3100, 3200 fallen mir grad ein) kann ich übrigens bestätigen, dass eine zurueck-Funktion im Menü ist.

          Ansonsten leuchtet mit Cheatahs Aussage völlig ein. Das ist (_muss_ ja) client-Funktionalität. Also ganz allgemein: Wenn der client das nich kann, gehts halt net.

          Grüsse und danke für die Meinung, eeye

          --
          [ ] <- Nail here for new Monitor.
      3. Hi,

        seite1.html linkt auf seite2.html und die auf seite3.html. Von seite1 aus spring ich nun dirket auf Seite3 (url eingeben). DFann komm ich mit dem Back-Button wieder zuück auf seite1 und mit einem hardcoded zurück-link auf "die Seite, die in der (Site)Struktur logisch davor kommt" (was ich ja eben nicht will)
        Meinen also imho schon das gleiche... hoffentlich hat das jetzt jemand verstanden...

        nö... ein "hardcoded" 'zurück'-Link ist für mich ein link auf "seite2.html" - und damit hättest Du Dein Problem ja nicht.

        freundliche Grüße
        Ingo

        1. Tach

          nö... ein "hardcoded" 'zurück'-Link ist für mich ein link auf "seite2.html" - und damit hättest Du Dein Problem ja nicht.

          Genau. Damit hätte ich aber nur history.back()-Funktionalität, wenn ich eben von seite2 komme. In jedem anderen Fall lande ich mit dem link ja auf seite2 und nicht da wo ich herkomm. That's the problem.

          <thread_summary>
          history.back() lässt sich wohl nur per client-Funktionalität realisieren (klingt ja auch logisch), also nicht mit plain (X)HTML und wenns der client nicht kann, und man brauchts _unbedingt_ dann hilft nur eine serverseitige Lösung.
          </thread_summary>

          Grüsse, eeye

          --
          [ ] <- Nail here for new Monitor.
          1. Hi,

            nö... ein "hardcoded" 'zurück'-Link ist für mich ein link auf "seite2.html" - und damit hättest Du Dein Problem ja nicht.
            Genau. Damit hätte ich aber nur history.back()-Funktionalität, wenn ich eben von seite2 komme. In jedem anderen Fall lande ich mit dem link ja auf seite2 und nicht da wo ich herkomm. That's the problem.

            nein. damit hast du eben _keine_ history.back Funktion, sondern einen verweis auf die logisch vorhergehende Seite - den ich auch nicht unbedingt irreführend mit "zurück" bezeichnen würde.

            Und was hindert Dich daran, auf jeder Seite den Verweis auf den passenden Vorgänger zu setzen?

            freundliche Grüße
            Ingo

            1. Hallo

              nö... ein "hardcoded" 'zurück'-Link ist für mich ein link auf "seite2.html" - und damit hättest Du Dein Problem ja nicht.
              Genau. Damit hätte ich aber nur history.back()-Funktionalität, wenn ich eben von seite2 komme. In jedem anderen Fall lande ich mit dem link ja auf seite2 und nicht da wo ich herkomm. That's the problem.

              nein. damit hast du eben _keine_ history.back Funktion, sondern einen verweis auf die logisch vorhergehende Seite - den ich auch nicht unbedingt irreführend mit "zurück" bezeichnen würde.

              Sag ich doch. Mit hardcoded-links kann ich _keine_ history.back()-Funktioinalität umsetzten. Wie oben geschrieben deckt sich das eben nur in einem Fall (der Besucher kommt eben von der dirket vorhergehenden Seite). An der Beschriftung, sowie am gesamten Inhalt kann ich BTW nix ändern...

              Und was hindert Dich daran, auf jeder Seite den Verweis auf den passenden Vorgänger zu setzen?

              Da kann ich natürlich tun (und das is auch grad so). Funktioniert halt dann nicht mehr (im Sinne von history.back() ), sobald der Besucher _direkt_ (URL eingeben) auf eine meiner Unterseiten springt...

              Grüsse, eeye

              --
              [ ] <- Nail here for new Monitor.