nicht angemeldet
CSS: Text an Bildschirm anpassen?
Matthias Scharwies
Gunnar Bittersmann
Rolf B
MudGuardHallo liebe SelfHTML-Community! Ich bin gerade dabei, die Registrierungsseite meiner Homepage anzufertigen. Nun stehe ich vor einem Problem beim Mobil-Verfügbar-machen. Und zwar soll sich die <h1>-Überschrift an den Bildschirm anpassen, da die Überschrift derzeit ohne zu zoomen kaum leserlich ist. Hier mein Code:
HTML:
<!DOCTYPE html>
<?php
?>
<html>
<head>
<title>Registrieren!</title>
<link rel="stylesheet" href="../css/main.css"/>
<meta name="viewport" >
</head>
<body>
<div id="outer-wrapper">
<div id="reg-wrapper">
<div id="headtext">
<h1>Register..</h1>
</div>
</div>
</div>
</body>
</html>
CSS:
body {
background-image: url('../res/images/regbg.jpg');
background-size: cover;
}
#outer-wrapper {
background-color: rgba(255, 255, 255, 0.76);
position: absolute;
width: 50%;
height: 100%;
margin: 0;
left: 25%;
top: 0px;
}
#headtext {
width: 100%;
background-color: green;
border-top: 1px solid black;
border-bottom: 1px solid black;
}
@media only screen
and (min-device-width : 320px)
and (max-device-width : 568px) {
body {
background-size: auto;
}
#outer-wrapper {
left: 0px;
width: 100%;
margin: 0;
padding: 0;
}
-
Servus!
Hallo liebe SelfHTML-Community!
Herzlich Willkommen!
Und zwar soll sich die <h1>-Überschrift an den Bildschirm anpassen, da die Überschrift derzeit ohne zu zoomen kaum leserlich ist.
Deine Metaangabe ist falsch!
So wär's richtig:
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">Dann würde ich für die media queries Werte in der relativen Schriftgröße em angeben. Als Größe verwende bitte min-width der Seite und nicht min-device-width des Geräts:
@media only screen and (min-width: 20em) { h1 { font-size: 3em; } } @media only screen and (min-width: 35em) { h1 { font-size: 2.5em; } }PS: Im von dir gezeigten Code fehlt eine schließende geschweifte Klammer.
Herzliche Grüße
Matthias Scharwies
--
Es gibt viel zu tun: ToDo-Liste-
Hat mein Problem schon gelöst! Vielen, vielen Dank!
MfG
Daniel
-
-
Lieber Daniel,
<body> <div id="outer-wrapper"> <div id="reg-wrapper"> <div id="headtext"> <h1>Register..</h1> </div> </div> </div> </body>im Ernst jetzt?
Schau mal in das Kapitel Warum Layouts mit CSS?, speziell den Teil Trennung von Inhalt und Design! Dein HTML-Code, also das Markup, stinkt geradezu nach Layout-driven Design. Und das ist nicht gut!
Besser so:
<body> <main> <section id="register"> <h1>Register</h1> <form method="post"> <ul> <li> <label for="mail">E-Mail</label> <input id="mail" name="mail"> </li> <li> <label for="user">gewünschter Benutzername</label> <input id="user" name="user"> </li> <li> <label for="pw">Passwort</label> <input id="pw" name="pw"> </li> <li> <label for="pw2">Passwortbestätigung</label> <input id="pw2" name="pw2"> </li> </ul> </form> </section> </main> <header>...</header> <footer>...</footer> </body>Mein Beispiel verwendet jede Menge an verschachtelten HTML-Elementen, die alle jeweils einem ganz speziellen Zweck folgen (
mainist der eigentliche Inhaltsbereich,sectionbildet einen Abschnitt,formist ein Formular usw.), sodass Deine Divitis ganz und gar unnötig ist.Du darfst Dir gerne Anregungen aus dem Kapitel Formulare erstellen und gestalten holen, um auch den Rest Deiner Seite mit sinnvollem Markup auszurüsten, welches Du dann mittels CSS gekonnt in Szene setzt.
Liebe Grüße,
Felix Riesterer.
-
Hallo Felix,
danke für deine Kritik. Ich werde mich bemühen, diese auch umzusetzen.
Die Seite wird dennoch nicht direkt online gehen, sondern soll jetzt im Moment hauptsächlich als Versuchskaninchen dienen, da ich vor allem beim mobile-responsive-design sehr unerfahren bin.
Mit freundlichen Grüßen, Daniel 😀
-
Servus!
Hallo Felix,
danke für deine Kritik. Ich werde mich bemühen, diese auch umzusetzen.
... sondern soll jetzt im Moment hauptsächlich als Versuchskaninchen dienen, da ich vor allem beim mobile-responsive-design sehr unerfahren bin.
Genau da kannst du jetzt wirkungsvoll an einer klaren HTML-Struktur arbeiten, die nur so viele Elemente wie nötig verwendet und deshalb sehr übersichtlich ist.
Auch beim CSS gilt „Weniger ist oft mehr!“, wenn du gezielt Festlegungen triffst.
So sind die meisten Breiten und anderen Größenfestlegungen im repsonsiven Webdesign gar nicht nötig, ab und zu mal eine
max-widthist oft schon genug.position: absolute, wie in deinemouter-wrapperist meist eher schädlich.Ein Hintergrundbild sieht oft auf dem Desktop sehr gut aus, bei mobilen Geräten wirkt es oft anders. Wenn Du es eh durch den
outer-wrapperwieder fast verdeckst, könntest Du überlegen, ob ein attraktiver header reicht.Auf jeden Fall könntest du es auch zusammenfassen:
body { background-image: url('../res/images/regbg.jpg'); background-size: cover; background-color: rgba(255, 255, 255, 0.76); }Herzliche Grüße
Matthias Scharwies
--
Es gibt viel zu tun: ToDo-Liste
-
-
@@Felix Riesterer
<body> <main> <section id="register"> <h1>Register</h1> <form method="post"> <ul> <li> <label for="mail">E-Mail</label> <input id="mail" name="mail"> </li> <li> <label for="user">gewünschter Benutzername</label> <input id="user" name="user"> </li> <li> <label for="pw">Passwort</label> <input id="pw" name="pw"> </li> <li> <label for="pw2">Passwortbestätigung</label> <input id="pw2" name="pw2"> </li> </ul> </form> </section> </main> <header>...</header> <footer>...</footer> </body>sectionbildet einen AbschnittEine
sectionmacht noch keinen Sommer. Wennsectionallein auftritt, dann handelt es sich nicht um einen Abschnitt;sectionwäre damit falsch.Eine ungeordnete Liste ist vermutlich auch nicht das geeignete HTML-Element für Eingabefelder. Wenn die schrittweise Abarbeitung der Eingaben verdeutlich werden soll, könnte ich mir noch eher eine geordnete Liste vorstellen. Ansonsten
poderdiv, umlabelundinputzu gruppieren.„Passwortbestätigung“ ist Unfug. Wenn etwas doppelt eingegeben werden müsste, dann die E-Mail-Adresse.
Bei den meisten Eingabefeldern fehlt der entsprechende
type.LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
Lieber Gunnar,
Eine
sectionmacht noch keinen Sommer. Wennsectionallein auftritt, dann handelt es sich nicht um einen Abschnitt;sectionwäre damit falsch.aha... soso. Du überzeugst mich damit nicht. Wäre ein Textabsatz, der aus nur einer nicht über die volle Breite gehenden Zeile Text besteht, deshalb auch kein Textabsatz, sondern eine verkappte Überschrift?
Deinen Einwand halte ich für Unsinn. Ein Abschnitt ist ein Abschnitt, und wenn es nur einen davon gibt, so gibt es eben nur einen davon. Das heißt aber nicht, dass man seinen Inhalt nicht in ein
section-Element gruppieren dürfte.Eine ungeordnete Liste ist vermutlich auch nicht das geeignete HTML-Element für Eingabefelder. Wenn die schrittweise Abarbeitung der Eingaben verdeutlich werden soll, könnte ich mir noch eher eine geordnete Liste vorstellen.
Was ein Quatsch! Die Reihenfolge der Abarbeitung ist völlig dem User überlassen. Er darf gerne mit dem Passwort anfangen. Insofern ist die Liste eher das Modell Einkaufsliste (ul) als Bedienungsanleitung (ol).
Ansonsten
poderdiv, umlabelundinputzu gruppieren.Das halte ich auch für Unsinn. Die Angaben sind Pflichtangaben, da man keine auslassen kann. Sie werden wie Punkte auf der Einkaufsliste ausgewiesen, da sie wie die einzukaufenden Dinge abgearbeitet werden müssen. Also ist es eine Auflistung an Daten. Also Liste. Also ist
ulundlidas Markup der Wahl.Du hast mich in Sachen Semantik früher mehr überzeugt. Heute war es nix.
„Passwortbestätigung“ ist Unfug. Wenn etwas doppelt eingegeben werden müsste, dann die E-Mail-Adresse.
Welches Naturgesetz erzwingt diese von Dir so absolut formulierte Aussage?
Die Mailadresse kann ich im Klartext sehen und gegebenenfalls korrigieren. Das Passwort wird mit Sternchen oder Punkten vom Browser unleserlich gemacht. Da kann ich nicht sehen, ob ich mich vertippt habe. Daher braucht es eine Bestätigung. Warum man die Mailadresse zweimal eintragen soll, habe ich noch nie verstanden und mich in diesen Fällen immer nur kopfschüttelnd gewundert.
Auch diesen Deinen Einwand halte ich für Unsinn.
Bei den meisten Eingabefeldern fehlt der entsprechende
type.Ja, das stimmt, da war ich in der Eile zu nachlässig. Wenn kein
type-Attribut notiert ist, greift der Default-Type, welcher "text" ist. Das wäre beim Benutzernamen sogar richtig, bei der Angabe der Mailadresse zwar nicht gänzlich falsch, aber ungünstig, weil der Browser die vorläufige Richtigkeit zumindest auf Syntaxebene nicht überprüfen kann und beim Passwort wirklich falsch, da man die Eingabe dann ja sehen kann, was man aber nicht sollte.In diesem letzten Punkt gebe ich Dir recht und korrigiere:
<ul> <li> <label for="mail">E-Mail</label> <input id="mail" name="mail" type="email"> </li> <li> <label for="user">gewünschter Benutzername</label> <input id="user" name="user"> </li> <li> <label for="pw">Passwort</label> <input id="pw" name="pw" type="password"> </li> <li> <label for="pw2">Passwortbestätigung</label> <input id="pw2" name="pw2" type="password"> </li> </ul>Liebe Grüße,
Felix Riesterer.
-
Servus!
Bei den meisten Eingabefeldern fehlt der entsprechende
type.Ja, das stimmt, da war ich in der Eile zu nachlässig. Wenn kein
type-Attribut notiert ist, greift der Default-Type, welcher "text" ist. Das wäre beim ... Passwort wirklich falsch, da man die Eingabe dann ja sehen kann, was man aber nicht sollte.Da gab's aber auch schon mal die Debatte, wie oft man jemanden hat, der einem über die Schulter schaut, und wie oft man im stillen Kämmerlein sein Passwort eingibt. Manche plädieren dann für ein normales Textfeld ohne autocomplete. (Bei mir schauen die Schüler über die Doku-Kamera auf die Tastatur.)
Herzliche Grüße
Matthias Scharwies
--
Es gibt viel zu tun: ToDo-Liste -
Hallo Felix,
ich habe auch erstmal gestutzt, als ich eine Liste als Basis eines Formulars sah. Nach etwas Googeln finde ich durchaus Advokaten für diese Methode, sogar mit einer guten Begründung: Ein Screenreader sagt an, wieviele Elemente eine Liste hat. Ich erfahre also zu Beginn, wieviele Felder ich ausfüllen muss. Finde ich prima.
Die Wiederholung der Mailadresse, die man überall findet und auf die ich stets mit Ctrl+C und Ctrl+V reagiere, kapiere ich auch nicht.
Zu der "einsamen Section" habe ich eine Story. Mir hat mal jemand erzählt, dass man in einem Unternehmen durchaus einen Büroleiter, Abteilungsleiter, Bereichsleiter und Ressortchef bräuchte, auch wenn es nur ein Ressort gibt, das aus einem einzigen Bereich besteht, der eine einzige Abteilung hat, in der es genau ein Büro mit - sagenwirmal - 5 Leuten gibt. Das würde zwar nach dem Märchen von den Sieben Zwergen klingen, aber die rollenspezifischen Aufgaben dieser Führungsebenen sind da und müssen erledigt werden. Ich hab ihm das nicht ganz abgenommen, weil er der Bereichsleiter war und seinen Posten rechtfertigen musste. Die ROLLEN sind da, aber nicht unbedingt genug Arbeit, um mit jeder Rolle eine volle Stelle auszulasten.
Beim Seitenlayout sind die Rollen auch da - und hier haben wir den Vorteil, dass die Verteilung der Rollen auf einzelne Personen - äh, Elemente - kein Geld kostet. Und wie im richtigen Leben ist es so, dass die Vereinigung mehrerer Rollen auf einer Stelle gerne zu Konflikten und Durcheinander führt. Insofern halte ich die Trennung mal zumindest nicht für falsch, und das CSS dürfte sauberer werden.
Rolf
--
sumpsi - posui - clusi -
Hi,
Bei den meisten Eingabefeldern fehlt der entsprechende
type.Ja, das stimmt, da war ich in der Eile zu nachlässig. Wenn kein
type-Attribut notiert ist, greift der Default-Type, welcher "text" ist. Das wäre beim Benutzernamen sogar richtig, bei der Angabe der Mailadresse zwar nicht gänzlich falsch, aber ungünstig, weil der Browser die vorläufige Richtigkeit zumindest auf Syntaxebene nicht überprüfen kannnicht nur die Syntaxprüfung wird durch den type beeinflußt, sondern auch die auf touch-Geräten angebotene Tastatur - bei type="email" dann mit direkt erreichbarem @ (ohne erst auf die Spezialzeichen-Tastatur-Ebene wechseln zu müssen), bei type="number" direkt erreichbare Ziffern usw.
cu,
Andreas a/k/a MudGuard -
@@Felix Riesterer
„Passwortbestätigung“ ist Unfug. Wenn etwas doppelt eingegeben werden müsste, dann die E-Mail-Adresse.
Welches Naturgesetz erzwingt diese von Dir so absolut formulierte Aussage?
Why the Confirm Password Field Must Die via 1unitedpower
Die Mailadresse kann ich im Klartext sehen und gegebenenfalls korrigieren.
Das Passwort auch …
Das Passwort wird mit Sternchen oder Punkten vom Browser unleserlich gemacht. Da kann ich nicht sehen, ob ich mich vertippt habe.
… wenn Entwickler eine Unschaltmöglichkeit bereitstellen.
(Dass nicht Entwickler das tun müssen sollten, sondern Browser das nativ anbieten sollten – wie IE/Edge es ansatzweise tut –, ist eine andere Geschichte.)
Daher braucht es eine Bestätigung.
Nein, braucht es nicht. Wenn jemand versehentlich ein anderes Passwort eingetippt hat als beabsichtigt, vergibt er sich einfach ein neues per „Passwort vergessen“ …
Warum man die Mailadresse zweimal eintragen soll, habe ich noch nie verstanden und mich in diesen Fällen immer nur kopfschüttelnd gewundert.
… wofür freilich die E-Mail-Adresse korrekt sein muss. Die E-Mail-Adresse ist hier das kritische Datum, nicht das Passwort.
beim Passwort wirklich falsch, da man die Eingabe dann ja sehen kann, was man aber nicht sollte.
Natürlich sollte man die Eingabe des Passworts sehen können, wenn man das will. (Fortsetzung)
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
@@Gunnar Bittersmann
Daher braucht es eine Bestätigung.
Nein, braucht es nicht. Wenn jemand versehentlich ein anderes Passwort eingetippt hat als beabsichtigt, vergibt er sich einfach ein neues per „Passwort vergessen“ …
Oh, das sagte ich ja schon alles in dem bereits verlinkten Thread.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
-
-
@@Felix Riesterer
Eine
sectionmacht noch keinen Sommer. Wennsectionallein auftritt, dann handelt es sich nicht um einen Abschnitt;sectionwäre damit falsch.aha... soso. Du überzeugst mich damit nicht. Wäre ein Textabsatz, der aus nur einer nicht über die volle Breite gehenden Zeile Text besteht, deshalb auch kein Textabsatz, sondern eine verkappte Überschrift?
Nein.
Deinen Einwand halte ich für Unsinn. Ein Abschnitt ist ein Abschnitt, und wenn es nur einen davon gibt, so gibt es eben nur einen davon. Das heißt aber nicht, dass man seinen Inhalt nicht in ein
section-Element gruppieren dürfte.<main> <h1>1. Kapitel</h1> <section> <h2>1.1. Abschnitt</h2> <p>Bla fasel</p> </section> </main>Welchen Sinn macht die Überschrift 1.1., wenn es keine 1.2. gibt?
Wenn die Überschrift 1.1. keinen Sinn macht, macht das
section-Element auch keinen.Ansonsten
poderdiv, umlabelundinputzu gruppieren.Das halte ich auch für Unsinn. Die Angaben sind Pflichtangaben, da man keine auslassen kann. Sie werden wie Punkte auf der Einkaufsliste ausgewiesen, da sie wie die einzukaufenden Dinge abgearbeitet werden müssen. Also ist es eine Auflistung an Daten. Also Liste. Also ist
ulundlidas Markup der Wahl.Rolf B erwähnte, dass die Ansage der Gesamtzahl der Eingabefelder für Screenreadernutzer nützlich wäre. Müsste ich mal bei solchen nachfragen, ob dem wirklich so ist oder ob sie das eher als akustische Vollmüllung empfinden.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
Lieber Gunnar,
<main> <h1>1. Kapitel</h1> <section> <h2>1.1. Abschnitt</h2> <p>Bla fasel</p> </section> </main>Welchen Sinn macht die Überschrift 1.1., wenn es keine 1.2. gibt?
sie macht vielleicht keinen, aber sie hat einen. Es handelt sich um eine inhaltliche Bündelung des folgenden Inhalts, der in Bezug zum Thema "1. Kapitel" eher untergeordnete Bedeutung hat. Jedenfalls steht er im Verhältnis zu den Ausführungen, die vielleicht zwischen den beiden Überschriften noch stehen könnten, eine Stufe niedriger im Rang. Gerade die in Mode kommenden
TL;DR-Abschnitte gehörten meiner Meinung nach in eine Überschrift 1.n. - im Notfall eben 1.1.Liebe Grüße,
Felix Riesterer.
-
-
-
-