Quentin: Anpassung Homepage an neue Medien

Hi,
ich habe in CSS definiert

  
body {font-size: 100.01%;}  
h1 {font-size: 1.5em;}  

Müsste da nicht mit Verkleinerung des Fensters auch die Schrift (inerhalb <h1>  </h1>) kleiner werden?
Danke für Eure Hilfe
Quentin

  1. Hi,

    body {font-size: 100.01%;}
    h1 {font-size: 1.5em;}

    
    >   
    > Müsste da nicht mit Verkleinerung des Fensters auch die Schrift (inerhalb <h1>  </h1>) kleiner werden?  
      
    Nö - die Schriftgröße wurde ja nicht in Abhängigkeit der Fenstergröße definiert.  
      
    Die Schrift in h1 wird bei Deinem CSS kleiner, wenn Du die Default-Schriftgröße des Browsers verringerst, oder für eines der Vorfahrenelemente des h1 eine kleinere Schrift definierst.  
      
    cu,  
    Andreas
    
    -- 
    [Warum nennt sich Andreas hier MudGuard?](http://MudGuard.de/)  
    [O o ostern ...](http://ostereier.andreas-waechter.de/)  
      
    Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.  
    
    
  2. Hi!

    ich habe in CSS definiert

    body {font-size: 100.01%;}
    h1 {font-size: 1.5em;}

      
    Die Angabe für das Body-Element ist überflüssig.  
    Die '100.01%' sind ein Überbleibsel aus Zeiten, wo man auf inzwischen veraltete IE Versionen Rücksicht nehmen musste.  
    Und '100%' ist ebenfalls nicht erforderlich, da es in jedem Browser einen Default-Wert für die (vom User einstellbare) Basis-Schriftgröße gibt und die Angabe '100%' genau diesem Wert entspricht.  
      
    
    > Müsste da nicht mit Verkleinerung des Fensters auch die Schrift (inerhalb <h1>  </h1>) kleiner werden?  
      
    Wieso sollte sie?  
    Solange du an der Basis-Schriftgröße und/ oder der Schriftgröße der Elternelemente des H1-Elements nichts änderst, bleibt die effektive Schriftgröße gleich, da es keinen Zusammenhang zwischen deiner Schriftgrößenangabe und der Viewportgröße gibt.  
      
    Wenn du dich über "Responsive Webdesign" (kurz RWD) schlau machen willst, gibt es u.a. hier im Forum bereits zahlreiche Threads zum Thema.  
      
    Das "Mittel der Wahl" für solche Fälle sind [Media Queries](http://lmgtfy.com/?q=css+media+queries).  
      
      
    Gruß Gunther
    
    1. @@Gunther:

      nuqneH

      Das "Mittel der Wahl" für solche Fälle sind Media Queries.

      Sind sie das?

      calc(a vw + b em) mit geeigneten Werten für a und b. Dann hat man den Effekt auch quasi-stufenlos.

      Qapla'

      --
      „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
      1. @@Gunnar:

        nuqneH

        Das "Mittel der Wahl" für solche Fälle sind Media Queries.

        Sind sie das?

        Ja, sind sie! :-P

        calc(a vw + b em) mit geeigneten Werten für a und b. Dann hat man den Effekt auch quasi-stufenlos.

        Wenn man es "sich leisten kann", Millionen von Android Nutzern u.U. auszuschließen ...!
        Im Übrigen "funktioniert" nur das solange wie beabsichtigt, solange die Elemente 100% der Viewportbreite einnehmen. Sobald auf größeren Viewports die Breite per 'max-width' begrenzt wird, stößt diese Variante an ihre Grenzen.

        Von daher sind MQs aufgrund ihrer "besseren Browserunterstützung" und vielseitigeren Anwendbarkeit das "bevorzugte" Mittel, was ja die (zusätzliche) Verwendung der von dir erwähnten Methode nicht ausschließt.

        Gruß Gunther

        1. @@Gunther:

          nuqneH

          Wenn man es "sich leisten kann", Millionen von Android Nutzern u.U. auszuschließen ...!

          Im Gegenteil. Bei progressive enhancement wird niemand ausgeschlossen.

          Im Übrigen "funktioniert" nur das solange wie beabsichtigt, solange die Elemente 100% der Viewportbreite einnehmen. Sobald auf größeren Viewports die Breite per 'max-width' begrenzt wird, stößt diese Variante an ihre Grenzen.

          Da kann ich dir nicht folgen. MQs beziehen sich auf den Viewport, vw bezieht sich auf den Viewport.

          Qapla'

          --
          „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
          1. @@Gunnar:

            nuqneH

            Wenn man es "sich leisten kann", Millionen von Android Nutzern u.U. auszuschließen ...!

            Im Gegenteil. Bei progressive enhancement wird niemand ausgeschlossen.

            Da kann ich dir nicht folgen.
            Was meinst du denn in diesem Fall mit "progressive enhancement" und wie sieht das konkret aus?

            Im Übrigen "funktioniert" nur das solange wie beabsichtigt, solange die Elemente 100% der Viewportbreite einnehmen. Sobald auf größeren Viewports die Breite per 'max-width' begrenzt wird, stößt diese Variante an ihre Grenzen.

            Da kann ich dir nicht folgen. MQs beziehen sich auf den Viewport, vw bezieht sich auf den Viewport.

            Ja, du hast Recht. Sobald eine "Breitenbegrenzung" von Elementen per 'max-width' greift, braucht es die "Rechnerei" ja gar nicht mehr. Also nehme ich alles zurück und behaupte das Gegenteil! ;-)

            Gruß Gunther

            1. @@Gunther:

              nuqneH

              Was meinst du denn in diesem Fall mit "progressive enhancement" und wie sieht das konkret aus?

              Die Überschrift ist auf allen Geräten als solche erkennbar. Auf Geräten, die dies unterstützen, passt sich die Schriftgröße dem Viewport an. Wobei es, wie molily richtig anmerkte, fraglich ist, ob man dies wirklich möchte.

              und wie sieht das konkret aus?

              h1  
              {  
              	font-size: 1.2em;  
              	font-size: calc(1em + 1vw);  
              }
              

              Qapla'

              --
              „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
      2. @@Gunnar:

        nuqneH

        calc(a vw + b em) mit geeigneten Werten für a und b. Dann hat man den Effekt auch quasi-stufenlos.

        Die Methode ist zwar generell "nicht schlecht", hat aber so ihre Tücken.
        Eine ist, dass man im Prinzip auch noch "sicherstellen" muss, welche Schriftart tatsächlich zur Anzeige kommt.

        Es wäre sicherlich "wünschens-/ begrüßenswert", wenn man für 'font-size' vergleichbare Möglichkeiten wie bspw. für 'background-size' zur Verfügung hätte.

        Weißt du, ob

        • so etwas zumindest in Planung ist?
        • es grundsätzliche "Probleme" dabei gibt, die entsprechendes generell ausschließen würden?

        Gruß Gunther

        1. @@Gunther:

          nuqneH

          Eine ist, dass man im Prinzip auch noch "sicherstellen" muss, welche Schriftart tatsächlich zur Anzeige kommt.

          Kann man nicht. Es ist sicher sinnvoll, nicht völlig verschienenartige, sondern ähnliche Schriften bei font-family anzugeben. „family“ legt das nahe.

          Es wäre sicherlich "wünschens-/ begrüßenswert", wenn man für 'font-size' vergleichbare Möglichkeiten wie bspw. für 'background-size' zur Verfügung hätte.

          Mir ist nicht klar, worauf du hinauswillst.

          Qapla'

          --
          „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
          1. @@Gunnar:

            nuqneH

            Eine ist, dass man im Prinzip auch noch "sicherstellen" muss, welche Schriftart tatsächlich zur Anzeige kommt.

            Kann man nicht.

            @font-face

            Es ist sicher sinnvoll, nicht völlig verschienenartige, sondern ähnliche Schriften bei font-family anzugeben. „family“ legt das nahe.

            Tahoma, Arial und Verdana gehören alle zur Font-Family "sans-serif", trotzdem ist ihre jeweilige Zeichenbreite sehr unterschiedlich und somit ihr "Platzbedarf" bei gleicher Größe.

            Es wäre sicherlich "wünschens-/ begrüßenswert", wenn man für 'font-size' vergleichbare Möglichkeiten wie bspw. für 'background-size' zur Verfügung hätte.

            Mir ist nicht klar, worauf du hinauswillst.

            Auf eine CSS-Angabe für 'font-size', die die Schriftgröße automatisch an die Größe des jeweiligen Elternelements anpasst, und zwar so, dass diese bspw. jeweils den maximalen Wert hat (für Einzeiler).

            Im Prinzip eben ähnlich wie bei 'background-size' (contain|cover).

            Gruß Gunther

            1. @@Gunther:

              nuqneH

              Eine ist, dass man im Prinzip auch noch "sicherstellen" muss, welche Schriftart tatsächlich zur Anzeige kommt.

              Kann man nicht.

              @font-face

              Damit kannst du Wünsche äußern, aber nicht sicherstellen.

              Es ist sicher sinnvoll, nicht völlig verschienenartige, sondern ähnliche Schriften bei font-family anzugeben. „family“ legt das nahe.

              Tahoma, Arial und Verdana gehören alle zur Font-Family "sans-serif", trotzdem ist ihre jeweilige Zeichenbreite sehr unterschiedlich und somit ihr "Platzbedarf" bei gleicher Größe.

              So war das nicht gemeint. font-family ist die Angabe des Stylesheet-Entwicklers; der kann dessen Wert auf ähnliche Schriften einschränken:
              {font-family: "Helvetica Neue", Helvetica, Arial, sans-serif}.

              (Ja, das wird nicht für alle Schriften gehen.)

              Auf eine CSS-Angabe für 'font-size', die die Schriftgröße automatisch an die Größe des jeweiligen Elternelements anpasst, und zwar so, dass diese bspw. jeweils den maximalen Wert hat (für Einzeiler).

              Ah. SVG ist dein Freund.

              Qapla'

              --
              „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
              1. @@Gunnar:

                nuqneH

                Eine ist, dass man im Prinzip auch noch "sicherstellen" muss, welche Schriftart tatsächlich zur Anzeige kommt.

                Kann man nicht.

                @font-face

                Damit kannst du Wünsche äußern, aber nicht sicherstellen.

                Och!? Ich habe bis jetzt zumindest immer angenommen, dass eine solche Angabe "verbindlich" sei. Vorausgesetzt natürlich, der jeweilige Browser unterstützt das und die entsprechende Schriftartendatei ist auch tatsächlich verfügbar.
                Von daher die ernst gemeinte Frage: In welchen Fällen ist das denn dann nicht "sichergestellt"?

                Auf eine CSS-Angabe für 'font-size', die die Schriftgröße automatisch an die Größe des jeweiligen Elternelements anpasst, und zwar so, dass diese bspw. jeweils den maximalen Wert hat (für Einzeiler).

                Ah. SVG ist dein Freund.

                Du meinst also, den Text als SVG Image einzubetten, richtig?

                  
                <svg xmlns="http://www.w3.org/2000/svg" version="1.1">  
                  <text x="0" y="15" fill="red">I love SVG</text>  
                </svg> 
                

                Ist das semantisch gesehen nicht "voll daneben"?
                Und dann bräuchte es auch noch einen Fallback für Browser ohne Inline-SVG Support (aktuell eigentlich nur noch der IE 8, aber immerhin).

                Gruß Gunther

                1. @@Gunther:

                  nuqneH

                  Och!? Ich habe bis jetzt zumindest immer angenommen, dass eine solche Angabe "verbindlich" sei. Vorausgesetzt natürlich, der jeweilige Browser unterstützt das und die entsprechende Schriftartendatei ist auch tatsächlich verfügbar.

                  Ein UA mag dem Nutzer auch anbieten, Webfonts grundsätzlich nicht zu verwenden.

                  Du meinst also, den Text als SVG Image einzubetten, richtig? […]
                  Ist das semantisch gesehen nicht "voll daneben"?

                  Hm …

                  Man könnte auch dem Text-Element per image replacement ein SVG-Hintergrund verpassen.

                  Dann muss man den Text allerdings doppelt pflegen. Auch irgendiwe daneben.

                  Qapla'

                  --
                  „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
                  1. @@Gunnar:

                    nuqneH

                    Och!? Ich habe bis jetzt zumindest immer angenommen, dass eine solche Angabe "verbindlich" sei. Vorausgesetzt natürlich, der jeweilige Browser unterstützt das und die entsprechende Schriftartendatei ist auch tatsächlich verfügbar.

                    Ein UA mag dem Nutzer auch anbieten, Webfonts grundsätzlich nicht zu verwenden.

                    Ja OK, den Fall hatte ich jetzt nicht in Erwägung gezogen. Der trifft im Übrigen ja auch auf deine vorgeschlagene "Font-Family Strategie" zu. :-P

                    Aber abgesehen von der Festlegung einer (Basis-)Schriftgröße, sehe ich da die Grenze dessen, was man als Autor tun kann/ soll/ muss. Wenn ein User, aus welchen Gründen auch immer meint, die Vorgaben des Autors "übersteuern" zu müssen, dann muss er das eben tun und mit "den Folgen" leben. Irgendwo ist halt die Grenze (auch des Machbaren).

                    Du meinst also, den Text als SVG Image einzubetten, richtig? […]
                    Ist das semantisch gesehen nicht "voll daneben"?

                    Hm …

                    Man könnte auch dem Text-Element per image replacement ein SVG-Hintergrund verpassen.

                    Dann muss man den Text allerdings doppelt pflegen. Auch irgendiwe daneben.

                    Ja, das scheint alles nicht "das Gelbe vom Ei" zu sein ... ;-)

                    Ich meine, wenn die Browser das bei Backgrounds hinkriegen, müsste es doch eigentlich auch bei der Font-Size machbar sein!? Denn der Browser "kennt" die tatsächlichen Gegebenheiten (Größen) ja am besten.

                    Gruß Gunther

            2. @@Gunther:

              nuqneH

              Auf eine CSS-Angabe für 'font-size', die die Schriftgröße automatisch an die Größe des jeweiligen Elternelements anpasst, und zwar so, dass diese bspw. jeweils den maximalen Wert hat (für Einzeiler).

              Schreib einen Request. Oh, zu spät. Hat der Anselm ja schon. Häng dich rein!

              Qapla'

              --
              „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
              1. @@Gunnar:

                nuqneH

                Schreib einen Request. Oh, zu spät. Hat der Anselm ja schon. Häng dich rein!

                Danke für die Info! :-)
                Das war ja wirklich Zufall, aber immerhin sind unsere Postings knapp älter als Anselms Request ... ;-)

                Ich habe darüber zwischenzeitlich auch noch weiter nachgedacht.
                Erstmal vom Grundsatz her hat Anselm die "Grundfunktion" ja schon zeimlich gut beschrieben, auch eine min + max Angabe.

                Was aber imho noch fehlt, ist eine Möglichkeit (Geschwister-)Elemente zu "gruppieren" und ihnen auf dieser Basis eine "gemeinsame" Schriftgröße zuzuordnen (bspw. bei Listeneinträgen oder Linksammlungen).

                Gruß Gunther

                1. @@Gunther:

                  nuqneH

                  Das war ja wirklich Zufall, aber

                  so was von.

                  Ich habe darüber zwischenzeitlich auch noch weiter nachgedacht.

                  Tu’s doch öffentlich.

                  Qapla'

                  --
                  „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
    2. Hallo,

      Das "Mittel der Wahl" für solche Fälle sind Media Queries.

      Nach einem ersten Überblick über Media Queries sehe ich, dass immer für bestimmte Screen-/Mediagrößen (bzw. Größenbereiche) Werte angegeben werden.
      Ist es demnach richtig, dass die Schrift nicht kontinuierlich verkleinert werden kann, wenn ich meine Screengröße verkleinere (es sei denn, man hätte unendlich viele media-queries?

      1. Hallo,

        Das "Mittel der Wahl" für solche Fälle sind Media Queries.

        Nach einem ersten Überblick über Media Queries sehe ich, dass immer für bestimmte Screen-/Mediagrößen (bzw. Größenbereiche) Werte angegeben werden.
        Ist es demnach richtig, dass die Schrift nicht kontinuierlich verkleinert werden kann, wenn ich meine Screengröße verkleinere (es sei denn, man hätte unendlich viele media-queries?

        Das siehst du prinzipiell richtig.
        Eine Variante, wie man quasi eine "stufenlose" Anpassung der Schriftgröße erreichen kann, hat Gunnar in diesem Beitrag gepostet.

        Ansonsten kann man auch per Javascript "nachhelfen". Es gibt diverse Skripte zur Anpassung der Schriftgröße. Ob sich der zusätzliche Aufwand lohnt, kann man im Einzelfall entscheiden.

        Gruß Gunther

        1. Hallo,

          Ist es demnach richtig, dass die Schrift nicht kontinuierlich verkleinert werden kann, wenn ich meine Screengröße verkleinere (es sei denn, man hätte unendlich viele media-queries?

          Das siehst du prinzipiell richtig.

          Ist dann z.B. das Beispiel (von 2010!) eine sinnvolle Variante von media-Definitionen?
          Grüße
          Quentin

          1. Hallo!

            Ist es demnach richtig, dass die Schrift nicht kontinuierlich verkleinert werden kann, wenn ich meine Screengröße verkleinere (es sei denn, man hätte unendlich viele media-queries?

            Das siehst du prinzipiell richtig.
            Ist dann z.B. das Beispiel (von 2010!) eine sinnvolle Variante von media-Definitionen?

            IMHO Nein!
            Und zwar aufgrund dessen, dass hier 'px' als Einheit verwendet werden. Gerade bei responsivem Webdesign ist es aber "äußerst empfehlenswert" (ansonsten auch), auf relative Einheiten wie 'em' zu setzen.

            Und bei der Definition von MQs gibt es noch weitere "Fallstricke" zu beachten:
            Jenachdem wie du die "Grenzen" der MQs festlegst (z.B. nur per min- oder max-width), kann es sein, dass mehrere MQs gleichzeitig "matchen" und somit die jeweils letzteren Angaben, bzw. die mit einer höheren Spezifität zur Anwendung kommen.

            Hier im Forum gibt es auch schon etliche Threads zum Thema.
            Suchbegriffe wie "Responsive Design", "Media Queries" und "Flexbox" sollten dir eine fülle an "Lesestoff" liefern. Der Vorteil dabei ist, dass viele Beiträge meist auch teils kontroverse Meinungen beinhalten, welche dir die Für und Wider der jeweiligen Methoden aufzeigen.

            Gruß Gunther

            1. Hallo!

              IMHO Nein!
              Und zwar aufgrund dessen, dass hier 'px' als Einheit verwendet werden. Gerade bei responsivem Webdesign ist es aber "äußerst empfehlenswert" (ansonsten auch), auf relative Einheiten wie 'em' zu setzen.

              Wenn in @media ... die Größe eines Gerätes (seines Bildschirms) angegeben wird, wie kann dies dann eine relative Größe sein? Relativ zu was?

              Hier im Forum gibt es auch schon etliche Threads zum Thema.
              Suchbegriffe wie "Responsive Design", "Media Queries" und "Flexbox" sollten dir eine fülle an "Lesestoff" liefern. Der Vorteil dabei ist, dass viele Beiträge meist auch teils kontroverse Meinungen beinhalten, welche dir die Für und Wider der jeweiligen Methoden aufzeigen.

              Habe jetzt schon mindestens 10 Treffer "Media Queries" angeschaut und immer wurde die Angabe px verwendet, ja selbst in Selfhtml-Wiki.
              Ich bin ratlos.

              Gruß
              Quentin

              1. Hallo!

                Habe jetzt schon mindestens 10 Treffer "Media Queries" angeschaut und immer wurde die Angabe px verwendet, ja selbst in Selfhtml-Wiki.

                Stimmt doch gar nicht: http://wiki.selfhtml.org/wiki/CSS/Media_Queries#width

                Aber ich kann dir wirklich nur raten, arbeite von Anfang an mit 'EMs', denn nur so macht imho "responsives Design" auch wirklich Sinn.

                Der tatsächliche Platzbedarf der Elemente auf einer Website hängt ja von der Schriftgröße ab. Und diese kann jeder User ganz nach belieben in seinem Browser einstellen. Bei einer vom Standard abweichenden Schriftgröße, "passen" Media Queries mit Pixelwerten nicht mehr.

                Gruß Gunther

                1. Hallo!

                  Stimmt doch gar nicht: http://wiki.selfhtml.org/wiki/CSS/Media_Queries#width

                  Stimmt doch! Genau auf der Seite, auf die Du verweist, steht
                  @media (width: 800px) { /* Breite entspricht genau 800 Pixel */ }
                  Danach zwei Zeilen mit em-Angaben.
                  Und danach steht:
                  Beachten Sie: Der Opera Browser akzeptiert in Version 9.5 nur Pixelwerte für dieses Merkmal. Nachfolgende Versionen unterstützen auch andere Werte.
                  Kein Wort von wegen "Pixel vermeiden"!

                  Und wenn man in dem Dokument in Richtung Anfang blättert, so überwiegen die px-Angaben bei weitem!
                  Gute Nacht!

      2. Hallo,

        Ist es demnach richtig, dass die Schrift nicht kontinuierlich verkleinert werden kann, wenn ich meine Screengröße verkleinere?

        Ja. Das kann man mit einigem Aufwand umsetzen, aber will man das? Auf einem großen Display will ich eher mit mehreren Spalten arbeiten, als dasselbe Ein-Spalten-Layout zu verwenden und nur die Schriftgröße aufzublasen. Umgekehrt, auf einem kleinen Display will ich nicht dasselbe Mehrspalten-Layout haben, in dem die Schrift bis zur Unkenntlichkeit verkleinert wurde.

        Wenn ich auf einem Smartphone mit 640-Pixel-Viewport angemessene 16-Pixel-Schrift habe, so will ich auf einem 1680-Pixel-Viewport keine 42-Pixel-Schriftgröße haben. Umgekehrt, wenn ich auf einem 1680-Pixel-Viewport angemessene 20-Pixel-Schrift habe, so will ich auf einem 640-Pixel-Viewport keine 7,6-Pixel-Schrift haben.

        (Natürlich spielen unterschiedliche PPI-Werte,  Bildschirm-Augen-Abstand und Device-Pixel-Verhältnis eine Rolle, aber es sollte klar sein, worauf ich hinaus will.)

        Grüße,
        Mathias

        1. @@molily:

          nuqneH

          Natürlich spielen unterschiedliche PPI-Werte,  Bildschirm-Augen-Abstand und Device-Pixel-Verhältnis eine Rolle […]

          Tun sie das? Das ist doch im Konzept „Pixel“ schon mit drin. Wir reden ja hier nicht über Device-Pixel, sondern über CSS-Pixel, die eher eine Winkeleinheit darstellen (Winkel, unter dem eine Länge auf dem Bildschirm einem Betrachter in dem für das jeweilige Gerät üblichen Augenabstand erscheint).

          Qapla'

          --
          „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
          1. Hallo,

            Wir reden ja hier nicht über Device-Pixel

            Doch, meine beispielhafte Skalierungsberechnung basierte auf Device-Pixel; daher die Anmerkung.

            Mathias