Funwave: Eingabe Text-Block mittig in Bild (html/CSS)

problematische Seite

Hallo Team & Community,

nachdem ich nun fast 2 Tage Google zum glühen brachte, die Seiten hier und ähnliche durchsucht habe, mus ich mit meinen minimalen Kenntnissen aufgeben.

Die Aufgabenstellung ist:

  • beim anklicken eines html-links (http://meinehtml.html) soll direkt ein Popup aufgehen (evtl. mit Verzögerung wg. Blocker)

  • dieses Popup soll 650x580px groß sein und mittig auf dem Monitor aufploppen.

  • Hintergrundbild soll ein Eisbaerbild sein

  • in dieses Bild widerum soll ein Text-Eingabe-Block h/v-mittig rein

  • dieser Block muss verbreitert werden vom orginal Block/Maß

block2

  • beide Komponenten sollen am Ende bei klicken der html aufploppen und das Eingabefeld anzeigen, was so aussehen sollte:

so soll es aussehen

Hier mal mein Code: mein code

Ich hatte den Textblock mal kurzfristig sogar im Bild drinnen, allerdings oben links im Eck, aber nun ist das auch weg und liegt nun irgendwie daneben:

Derzeitige Ansicht

Ich hoffe, das die Profis mir hier kurzfristig helfen können, da wir das sehr gern bei unserem Jubiläum nutzen würden.

Danke im Voraus

  1. problematische Seite

    @@Funwave

    Die Aufgabenstellung ist:

    ziemlich unsinnig, denn

    • dieses Popup soll 650x580px groß sein und mittig auf dem Monitor aufploppen.

    Mein Viewport ist nur 320 × 372 Pixel groß. Durch Drehen des Gerätes komme ich auf 480 Pixel in der Breite, habe dann aber nur 320 Pixel in der Höhe.

    Das Ding sollte besser maximal 650 × 580 Pixel groß sein. (Wobei man die Beschränkung in der Höhe bei schmalen Viewports nochmal überdenken sollte.)

    • beim anklicken eines html-links (http://meinehtml.html) soll direkt ein Popup aufgehen

    Ein modales Fenster mit einer anderen Seite als Inhalt? Iframe, der per JavaScript generiert wird.

    BTW, für Beispieldomains verwende bitte eine der nach BCP 32 dafür vorgesehenen (wie bspw. example.net).

    Oder ist das Formular schon in der Seite und wird beim Click auf den Link Button angezeigt? Dann dialog-Element, dessen display-Eigenschaft geändert wird.

    (evtl. mit Verzögerung wg. Blocker)

    ??

    • Hintergrundbild soll ein Eisbaerbild sein

    … am kalten Polar.

    • in dieses Bild widerum soll ein Text-Eingabe-Block h/v-mittig rein

    Horizontales und vertikales Zentrieren mit Flexbox.

    • dieser Block muss verbreitert werden vom orginal Block/Maß

    Auf welche Breite denn?

    block2

    Die Schreibfehler müssen auch noch berichtigt werden: Plenk vorm ?, ß statt ss.

    Hier mal mein Code: mein code

    Oh je.

    Zuerst: <!DOCTYPE html> fehlt. (Muss ganz zu Anfang stehen, damit Browser nicht in den Quirksmodus fallen.)

    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
     
     
     
     
     		<meta charset="utf-8">
    

    Welche Zeichencodierung hätten S’ denn gern?

    Du darfst da nicht irgendwas hinschreiben, sondern musst die tatsächliche Zeichencodierung des Dokuments angeben. Und das nur einmal – mit meta charset.

    Und die Zeichencodierung sollte UTF-8 sein.

    <table class="_">
    

    Das Jahr 1999 ruft an. Es möchte seine Layouttabellen zurückhaben.

    Tabellen sind für tabellarische Daten da, nicht zum Layouten der Seite.

    <form method="post" action="../ticker/wunsch_gruss_frame.php?a=&amp;box_tabelle=_">
    

    Was soll das ?a=&amp;box_tabelle=_ da hinten dran? Wird das irgendwie ausgewertet?

    Deine Eingabefelder haben keine Beschriftung (label). Sollten sie aber unbedingt haben.

    Dein Formular könnte in etwa so aussehen: http://codepen.io/gunnarbittersmann/pen/wWZwmB

    LLAP 🖖

    --
    “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
    Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
    1. problematische Seite

      Hallo,

      … Dann dialog-Element, dessen display-Eigenschaft geändert wird.

      http://caniuse.com/#search=dialog: Ist es für das Dialog-Element nicht noch etwas zu früh?

      Gruß
      Jürgen

      1. problematische Seite

        @@JürgenB

        … Dann dialog-Element, dessen display-Eigenschaft geändert wird.

        http://caniuse.com/#search=dialog: Ist es für das Dialog-Element nicht noch etwas zu früh?

        Nein; es ist nie™ zu früh. Progressive enhancement. Man macht ja nichts kaputt, wenn man ein Element verwendet, das noch nicht alle Browser unterstützen.[1]

        In dem Fall sollte man aber die Unterstützung mit ARIA nachrüsten.

        LLAP 🖖

        --
        “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
        Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|

        1. Dass Uralt-IEs ihnen unbekannte Elemente nur stylen können, wenn sie mit document.createElement() (html5shiv) bekanntgemacht wurden, ist ja bekannt. ↩︎

        1. problematische Seite

          Hallo Gunnar,

          … Dann dialog-Element, dessen display-Eigenschaft geändert wird.

          http://caniuse.com/#search=dialog: Ist es für das Dialog-Element nicht noch etwas zu früh?

          Nein; es ist nie™ zu früh. Progressive enhancement. Man macht ja nichts kaputt, wenn man ein Element verwendet, das noch nicht alle Browser unterstützen.[^1]

          In dem Fall sollte man aber die Unterstützung mit ARIA nachrüsten.

          Und wie gehen dann Screenreader damit um, wenn normale Browser schon nichts damit anfangen können? Denn mit deinem Codepen-Beispeil konnte mein Safari nichts anfangen. Das war hier jetzt nicht schlimm, weil das Formular ja immer angezeigt wurde. Aber das Ziel war ja Einblinden nach Klick.

          Natürlich ist es OK, das man ältere oder wenig verbreitete Browser nicht mehr unterstützt, aber in diesem Fall bleiben fast alle auf der Strecke. Ein weiteres Problem sehe ich darin, das caniuse.com zwar „normale“ Browser testet, leider aber keine Screenreader. Den Tastatur-Test kann ich ja noch durchführen, den Vorlesetest aber nicht mehr so ohne Aufwand. Für jemand, der WWW-Seiten nur als Hobby erstellt, ist es schon schwer genug, mit den „verbreiteten“ Geräten zu testen.

          Gruß
          Jürgen

          1. problematische Seite

            Hallo,

            Nein; es ist nie™ zu früh. Progressive enhancement. Man macht ja nichts kaputt, wenn man ein Element verwendet, das noch nicht alle Browser unterstützen.[^1]

            In dem Fall sollte man aber die Unterstützung mit ARIA nachrüsten.

            Und wie gehen dann Screenreader damit um, wenn normale Browser schon nichts damit anfangen können?

            die werden's cermutlich genauso ignorieren (im Sinne von: nicht die gewünschte Funktion bieten) wie die Browser, die es nicht kennen.

            Denn mit deinem Codepen-Beispeil konnte mein Safari nichts anfangen. Das war hier jetzt nicht schlimm, weil das Formular ja immer angezeigt wurde.

            Also konnte er doch etwas damit anfangen: Die Seite mit dem Formular war prinzipiell benutzbar. Das ist ja gerade der Leitgedanke beim Progressive Enhancement: Man stellt zunächst mal eine einfache Basis-Funktionalität zur Verfügung, mit der sehr wahrscheinlich alle Clients zurechtkommen. Und darauf baut man dann die möglichen Verbesserungen (Enhancements) auf, die ein Client wahrnehmen und umsetzen kann, aber nicht unbedingt muss.

            Aber das Ziel war ja Einblinden nach Klick.

            Ja. Aber es bricht keinem ein Zacken aus der Krone, wenn dieses Feature nicht so funktioniert, ebenso wie bei einer Tab-Navigation oft alle Tabs einfach fortlaufend untereinander angezeigt werden, wenn Javascript deaktiviert ist: Sieht nicht ganz so aus, wie der Autor sich das gewünscht hat, ist aber im vollen Umfang benutzbar. Ziel erreicht. :-)

            Natürlich ist es OK, das man ältere oder wenig verbreitete Browser nicht mehr unterstützt

            Nein. Unterstützen sollte man sie dennoch in dem Sinn, dass man ihnen eben die Basisversion ohne Candy anbietet.

            So long,
             Martin

            --
            Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
            - Douglas Adams, The Hitchhiker's Guide To The Galaxy
            1. problematische Seite

              Hallo Martin,

              im Prinzip hast du (und auch Gunnar) Recht und ich stimme mit euch überein. Aber ich bleibe bei meiner Meinung, das es für den Einsatz des Dialog-Elements noch etwas zu früh ist.

              Gruß
              Jürgen

          2. problematische Seite

            @@JürgenB

            Denn mit deinem Codepen-Beispeil konnte mein Safari nichts anfangen.

            ? Was heißt „nichts anfangen“?

            Das war hier jetzt nicht schlimm, weil das Formular ja immer angezeigt wurde. Aber das Ziel war ja Einblinden nach Klick.

            Mein Fehler. Ich hatte

            #dialog-wunschtitel-senden[hidden]
            {
            	xxdisplay: none;
            }
            

            im Stylesheet, damit ich beim Basteln was sehe. Dann vergessen, xx rauszunehmen. Hab ich jetzt korrigiert.

            LLAP 🖖

            --
            “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
            Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
            1. problematische Seite

              Hallo Gunnar,

              ? Was heißt „nichts anfangen“?

              na ja, es hat eben nicht funktioniert, der dialog-Inhalt war immer sichtbar.

              Das war hier jetzt nicht schlimm, weil das Formular ja immer angezeigt wurde. Aber das Ziel war ja Einblinden nach Klick.

              Mein Fehler. Ich hatte

              ok, jetzt kann auch der Safari etwas damit „anfangen“.

              Ich habe jetzt mit deinem Code etwas gespielt und dialog durch x-x ersetzt. Das Einblenden nach Klick hat auch hier funktioniert. Heißt das, dass ich auch in Browsern, die Custom-Elements noch nicht unterstützen, eigene Tags verwenden kann? Denn aus Sicht des Safari ist das dialog-Element ja nichts anderes.

              Gruß
              Jürgen

              1. problematische Seite

                @@JürgenB

                Heißt das, dass ich auch in Browsern, die Custom-Elements noch nicht unterstützen, eigene Tags verwenden kann? Denn aus Sicht des Safari ist das dialog-Element ja nichts anderes

                Ja. Aus Sicht eines Uralt-IE sind main, section usw. auch nichts anderes. Nur dass die Besonderheit des JavaScript hinzukommt.

                LLAP 🖖

                --
                “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
                Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|