nicht angemeldet dieselross
Der Martin
dieselross
Der Martin
Gunnar Bittersmann
dieselross
Matti Mäkitalo
molily
Matti Mäkitalo
molily
Hallo Gemeinde,
ich muss einen Anmeldeblock innerhalb eines absolut positionierten DIV ein- und ausblenden, was ja an sich kein Problem ist.
Das funktioniert auch ganz gut in einigermaßen modernen Browsern, aber ab IE8 abwärts geht's – na ja, eben abwärts.
So wird beispielsweise der Hintergrund meiner DIV-Box transparent, was gar nicht geht. Was mache ich falsch bzw., wie kann ich den IE überreden, es richtig zu machen?
der Code:~~~html
<div id="anmeldung" style="display: none" >
<form id="anmeldeformular" action="">
<h3 id="anmeldungshead">
Anmeldung
</h3>
<div class="schliessbutton">
<a href="index.html">
X
</a>
</div>
<table id="anmeldetabelle">
<tr>
<td class="label">
Benutzername
</td>
</tr>
<tr>
<td class="eingabefeld">
<input type="text" size="10" maxlength="10" name="benutzereingabe"/>
</td>
</tr>
<tr>
<td class="label">
Passwort
</td>
</tr>
<tr>
<td class="eingabefeld">
<input type="text" size="10" maxlength="10" name="passworteingabe"/>
</td>
</tr>
<tr>
<td class="leerzeile">
</td>
</tr>
<tr class="buttonzeile">
<td class="tabellenbutton">
Anmelden
</td>
</tr>
<tr>
<tr class="leerzeile">
</tr>
</tr>
<tr>
<td class="vergessenlink">
<a href="#">Ich habe mein Passwort vergessen</a>
</td>
</tr>
</table>
</form>
<a href="#" class="registerbutton gelb">
<img src="images/Registrieren_Icon.png" alt="Registrieren_Icon" width="30" height="30">
<h3>Als Neukunde registrieren</h3>
</a>
<a href class="registerbutton gruen">
<img src="images/Zugangsdaten_Icon.png" alt="Zugangsdaten_Icon" width="30" height="30">
<h3>Zugangsdaten anfordern</h3>
</a>
</div>
Matthias Apselund das css dazu:~~~css
#anmeldung {
position: absolute;
display: block;
right: 0px;
top: 80px;
background-color: rgba(163,71,156,1);
width: 300px;
min-height: 100px;
-moz-border-radius: 20px;
-webkit-border-radius: 20px;
border-radius: 20px;
z-index: 300;
}
#anmeldungshead {
margin: 10px;
margin-bottom: -10px;
font-size: 18px;
color: white;
}
.schliessbutton {
position: absolute;
right: 10px;
top: 10px;
width: 25px;
height: 25px;
z-index: 350;
}
.schliessbutton a {
display: table-cell;
text-align: center;
vertical-align: middle;
width: 25px;
height: 25px;
-moz-border-radius: 8px;
-webkit-border-radius: 8px;
border-radius: 8px;
background-color: red;
color: white;
}
#anmeldetabelle {
width: 280px;
margin: 0px auto 10px auto;
}
#anmeldetabelle thead {
padding: 10px 0px 5px 10px;
}
#anmeldetabelle .label {
color: white;
font-size: 12px;
height: 20px;
vertical-align: bottom;
}
#anmeldetabelle .eingabefeld {
width: 280px;
background-color: white;
height: 20px;
border: 1px solid #ddd;
}
.leerzeile {
line-height: 10px;
padding: 0px;
}
.tabellenbutton {
width: 280px;
height: 20px;
-moz-border-radius: 8px;
-webkit-border-radius: 8px;
border-radius: 8px;
color: white;
background-color: #53a890;
border: 2px solid #ddd;
display: table-cell;
text-align: center;
vertical-align: middle;
margin-top: 10px;
cursor: pointer;
}
.tabellenbutton:hover {
font-weight: bold;
}
.vergessenlink {
text-align: center;
}
.vergessenlink a {
text-decoration: underline;
color: white;
}
.vergessenlink a:hover {
color: red;
}
.registerbutton {
position: relative;
width: 115px;
height: 70px;
-moz-border-radius: 8px;
-webkit-border-radius: 8px;
border-radius: 8px;
padding: 10px;
text-align: center;
margin-left: 10px;
margin-bottom: 10px;
float: left;
}
.registerbutton img {
position: absolute;
left: 10px;
top: 10px;
margin-bottom: -100%;
margin-right: -100%;
}
.registerbutton:hover img {
width: 40px;
height: 40px;
}
.registerbutton h3 {
display: table-cell;
height: 70px;
vertical-align: bottom;
text-align: right;
font-size: 11px;
color: white;
}
Davon, dass der IE ab 7 abwärts auch noch das ganze Menü zerschießt will ich gar nicht erst anfangen, da werde ich wohl noch einiges an zusätzlichem CSS schreiben müssen.
Gruß
dieselross
Meine Herren,
erfahrungsgemäß werden Fragen, die mit so viel Quelltext hier auflaufen, erst sehr spät bis gar nicht beantwortet.
Erschwerend kommt für die Helfer hinzu, dass dein Quelltext durchweg unkommentiert ist.
Mein Tipp: Reduziere den Code auf das wesentliche und reichere kritische Stellen mit erläuternden Kommentaren an. Im besten Fall lieferst du auch gleich ein Online-Beispiel mit. Sollte es dir nicht möglich sein, das Wesentliche herauszufiltern, dann führe deine Helfer sukzessive in den Quelltext ein, also erläutere kleinschrittig wieso etwas da steht, wo es steht.
Hallo,
Mein Tipp: Reduziere den Code auf das wesentliche und reichere kritische Stellen mit erläuternden Kommentaren an. Im besten Fall lieferst du auch gleich ein Online-Beispiel mit. Sollte es dir nicht möglich sein, das Wesentliche herauszufiltern, dann führe deine Helfer sukzessive in den Quelltext ein, also erläutere kleinschrittig wieso etwas da steht, wo es steht.
dem schließe ich mich prinzipiell an. Allerdings habe ich die Angewohnheit, erstmal den Code zu überspringen und nur den Prosa-Text zu lesen, um überhaupt mal zu verstehen, was der Fragesteller will. Und Prosa-Text war wirklich nicht viel drin, auf die damit angesprochenen Aspekte konnte ich dann gezielt eingehen.
Ciao,
Martin
Hallo,
So wird beispielsweise der Hintergrund meiner DIV-Box transparent, was gar nicht geht.
kein Wunder, denn das ist der Defaultwert für die Hintergrundfarbe. Und da alte IEs keine rgba-Angaben kennen, ignorieren sie sie un bleiben beim Defaultwert. Ergänze für die Veteranen also eine Hintergrundfarbe ohne Alphatransparenz:
#anmeldung {
position: absolute;
display: block;
right: 0px;
top: 80px;
background-color: rgb(163,71,156);
background-color: rgba(163,71,156,1);
width: 300px;
min-height: 100px;
-moz-border-radius: 20px;
-webkit-border-radius: 20px;
border-radius: 20px;
z-index: 300;
}
Für die Browser, die's verstehen, überschreibt die zweite background-color-Definition die erste. Wobei ... bedeutet der Wert 1 für den Alphakanal nicht sowieso "voll deckend"? Dann ist rgba an der Stelle gar nicht nötig.
> Davon, dass der IE ab 7 abwärts auch noch das ganze Menü zerschießt will ich gar nicht erst anfangen, da werde ich wohl noch einiges an zusätzlichem CSS schreiben müssen.
Willst du IE7 wirklich extra unterstützen? Halte ich nicht für nötig oder sinnvoll. Denn wer IE7 benutzt, hat mindestens Windows XP. Und wer XP hat, kann auch problemlos auf IE8 upgraden.
So long,
Martin
--
Die letzten Worte der Challenger-Crew:
Lasst doch mal die Frau ans Steuer!
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
Willst du IE7 wirklich extra unterstützen? Halte ich nicht für nötig oder sinnvoll. Denn wer IE7 benutzt, hat mindestens Windows XP. Und wer XP hat, kann auch problemlos auf IE8 upgraden.
Genau genommen muss ich sogar noch den IE6 unterstützen :-(
Gruß
dieselross
Hallo,
Willst du IE7 wirklich extra unterstützen? Halte ich nicht für nötig oder sinnvoll. Denn wer IE7 benutzt, hat mindestens Windows XP. Und wer XP hat, kann auch problemlos auf IE8 upgraden.
Genau genommen muss ich sogar noch den IE6 unterstützen :-(
*seufz*
Du hast mein tief empfundenes Mitgefühl. Hilft dir aber auch nicht, oder? ;-)
Oder wie weit "muss" die Unterstützung gehen? Normalerweise macht man ja bei den älteren Browsern Zugeständnisse insofern, dass die Seiten zwar bedienbar und alle Inhalte zugänglich sein müssen, aber auf "schick aussehen" verzichtet man dann teilweise.
Unter der Prämisse ist auch "IE6 unterstützen" noch zumutbar.
Ciao,
Martin
*seufz*
Du hast mein tief empfundenes Mitgefühl. Hilft dir aber auch nicht, oder? ;-)
Stimmt. Hilft nicht im technischen Sinne. Aber moralisch. Danke dafür.
Normalerweise macht man ja bei den älteren Browsern Zugeständnisse insofern, dass die Seiten zwar bedienbar und alle Inhalte zugänglich sein müssen, aber auf "schick aussehen" verzichtet man dann teilweise.
Unter der Prämisse ist auch "IE6 unterstützen" noch zumutbar.
Darauf wird es wohl hinauslaufen. Danke für die Hilfe. Die Transparenz war noch aus der ersten Testphase und da ich sie - testweise - auf 100% gesetzt hatte, hab' ich das wohl übersehen.
Gruß
dieselross
Und das nächste Problem:
Kann der IE7 auch nicht mit z-index umgehen?
Gruß
dieselross
Om nah hoo pez nyeetz, dieselross!
Kann der IE7 auch nicht mit z-index umgehen?
eigentlich schon. iirc nicht mit negativen. Beachte, z-index gilt nur für Elemente mit position ≠ static. Zudem hilft unter Umständen haslayout.
Matthias
Om nah hoo pez nyeetz, dieselross!
Danke für die guten Wünsche!
eigentlich schon. iirc nicht mit negativen. Beachte, z-index gilt nur für Elemente mit position ≠ static. Zudem hilft unter Umständen haslayout.
Hmm hasLayout sollte durch position: absolute eigentlich gegeben sein. Aber trotzdem legen sich nachfolgende Elemente ab IE7 abwärts darüber.
Ich sehe schon. Das wird noch ein Kampf.
dieselross
@@dieselross:
nuqneH
<div id="anmeldung" style="display: none">
Das Element wird mit JavaScript sichtbar gemacht? Dann sollte es auch nur versteckt werden, wenn JavaScript ausgeführt wird, da andernfalls das Formular unbedienbar ist.
Also weg mit 'style="display: none"', stattdessen mit JavaScript dem html-Element eine Klasse "js" gehen (Modernizr tut das) und im Stylesheet nnottieren
`.js #anmeldung {display: none}`{:.language-css}
> ~~~html
<table id="anmeldetabelle">
> <tr>
> <td class="label">
> Benutzername
> </td>
Label solltest du unbedingt als label auszeichnen, um die Zuordnung du den Eingabefeldern anzugeben. Das ermöglicht die Fokussierung des Eingabefeldes durch Anclicken des Labels, besonders wichtig bei Radiobuttons und Checkboxen. Für Nutzer assistiver Techniken wie Screenreader wäre ohne diese Auszeichnung im Markup kein Bezug zwischen Label und Eingabefeld vorhanden, das Formular wäre unbedienbar.
</tr>
<tr> <td class="eingabefeld"> <input type="text" size="10" maxlength="10" name="benutzereingabe"/> </td>
Eine Spalte macht noch keine Tabelle. Du missbrauchst hier table, tr, td – warum eigentlich?
Wenn du Label und Eingabefeld nebeneinander haben willst, könnte eine
Tabelle angebracht sein; dann aber zusammengehörige Labels und Eingabefelder in einer Tabellenzeile, d.h. im selben tr-Element. Die Labels wären dann Kopfzellen: th, nicht td.
Aber vielleicht willst du zusammengehörige Label und Eingabefelder einfach mit div oder span gruppieren.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
<div id="anmeldung" style="display: none">
> Das Element wird mit JavaScript sichtbar gemacht? Dann sollte es auch nur versteckt werden, wenn JavaScript ausgeführt wird, da andernfalls das Formular unbedienbar ist.
Eigentlich erst 'mal nicht. Ich spreche (noch) kein JavaScript.
> Label solltest du unbedingt als [label](http://de.selfhtml.org/html/formulare/strukturieren.htm#label) auszeichnen, um die Zuordnung du den Eingabefeldern anzugeben. Das ermöglicht die Fokussierung des Eingabefeldes durch Anclicken des Labels, besonders wichtig bei Radiobuttons und Checkboxen. Für Nutzer assistiver Techniken wie Screenreader wäre ohne diese Auszeichnung im Markup kein Bezug zwischen Label und Eingabefeld vorhanden, das Formular wäre unbedienbar.
Da hast Du selbstverständlich Recht.
> Eine Spalte macht noch keine Tabelle. Du missbrauchst hier table, tr, td – warum eigentlich?
Gute und berechtigte Frage.
> Wenn du Label und Eingabefeld nebeneinander haben willst, könnte eine Tabelle angebracht sein; dann aber zusammengehörige Labels und Eingabefelder in einer Tabellenzeile, d.h. im selben tr-Element. Die Labels wären dann Kopfzellen: th, nicht td.
> Aber vielleicht willst du zusammengehörige Label und Eingabefelder einfach mit div oder span gruppieren.
Wohl eher so.
> Qapla'
Danke für die guten Wünsche (auch wenn mein klingonisch etwas holperig ist) und danke vor allem für die hilfreichen Anmerkungen.
Gruß
dieselross
--
- life's for learning -
Ceterum censeo IE esse delendam
besucht mich auf www.re-ality.de
Hi,
<table id="anmeldetabelle">
<tr> <td class="label"> Benutzername </td>
>
> Label solltest du unbedingt als [label](http://de.selfhtml.org/html/formulare/strukturieren.htm#label) auszeichnen, um die Zuordnung du den Eingabefeldern anzugeben. Das ermöglicht die Fokussierung des Eingabefeldes durch Anclicken des Labels, besonders wichtig bei Radiobuttons und Checkboxen. Für Nutzer assistiver Techniken wie Screenreader wäre ohne diese Auszeichnung im Markup kein Bezug zwischen Label und Eingabefeld vorhanden, das Formular wäre unbedienbar.
Das gilt übrigens auch für diverse GUI-Test-Tools. Ich nutze momentan Behat/Mink, und dort kann ich Formularfelder über deren Label adressieren. Mein Test-Schritt sieht also z.B. so aus:
When I fill in "Benutzername" with "Matti"
Ist doch deutlich schöner zu lesen als
When I fill in "#anmeldetabelle input[name='nutzername']" with "Matti"
(und ich bin mir nichtmal sicher, ob es mit einem Selektor überhaupt sicher funktionieren würde).
Aus dem gleichen Grund nutze ich auch intensiv das output-Element von HTML5. Dafür ist die Kopplung mit dem Label-Element auch erlaubt, und ich habe einen Satz für Mink geschrieben, mit dem ich Output-Texte anhand ihres Labels testen kann.
Bis die Tage,
Matti
Hallo,
When I fill in "Benutzername" with "Matti"
Der Test schlägt fehl, sobald jemand das Label in der Locale ändert, oder die Seite an den Testclient nicht mehr in der entsprechenden Sprache ausgeliefert wird.
When I fill in "#anmeldetabelle input[name='nutzername']" with "Matti"
Der Test schlägt fehl, sobald jemand die Bezeichner im Code ändert.
Was passiert wohl häufiger?
(und ich bin mir nichtmal sicher, ob es mit einem Selektor überhaupt sicher funktionieren würde).
Das geht sicherlich.
Bei den Testframeworks, die ich kenne, wird i.d.R. mit dem name-Attribut, mit Klassen oder IDs gearbeitet – den diese sind für die client- bzw. serverseitige Weiterverarbeitung interessant.
Grüße,
Mathias
Hi,
When I fill in "Benutzername" with "Matti"
Der Test schlägt fehl, sobald jemand das Label in der Locale ändert, oder die Seite an den Testclient nicht mehr in der entsprechenden Sprache ausgeliefert wird.
Ich habe das Thema intern länger diskutiert. Ich bin der Meinung, dass die korrekte Auswahl des Locales und die Label-Bezeichner Bestandteile des Tests sind. Meine Idee dahinter ist es, dass ich meine Tests so schreibe, dass ich alleine mit auf dem Screen sichtbaren Begriffen hantieren muss. Und dazu nehme ich dann eben den Text auf dem Label.
Andersherum: wenn ich meine GUI-Tests als eine Teilform der Akzeptanztests verstehe, dann ist das Innenleben der Software irrelevant. Zum Innenleben gehören die technischen Bezeichner der Felder.
Elementar dagegen sind die Labeltexte, weil diese die Eingabefelder benennen. Wenn da auf einmal etwas anderes steht als erwartet (sei es, weil irgendwie im Test die Locale verrutscht ist oder jemand den Labelinhalt umbenannt hat), ist das m.E. ein Fehler (aus Sicht des Tests kann ich ja nicht beurteilen, ob der neue Labelinhalt ein Synonym für den alten ist oder ob da kompletter Quatsch steht). Und daher teste ich mit den Sätzen nicht nur das Befüllen der Eingabefelder, sondern eben auch die Korrektheit der Label.
Zu guter Letzt: Die Tests mit fachlichen Bezeichnern sind besser lesbar. Ich kann sie ausdrucken, jemandem ohne technischen Hintergrund hinlegen und von ihm erwarten, dass er in der Lage ist, die Tests manuell durchzuarbeiten. Mit den technischen Bezeichnern geht das nicht.
When I fill in "#anmeldetabelle input[name='nutzername']" with "Matti"
Der Test schlägt fehl, sobald jemand die Bezeichner im Code ändert.
Was passiert wohl häufiger?
Ich stimme deiner impliziten Antwort zu: i.d.R. wird der Labelbezeichner geändert. Meine technischen Bezeichner sind meist automatisch generiert, da ändert sich nicht viel daran.
Bei den Testframeworks, die ich kenne, wird i.d.R. mit dem name-Attribut, mit Klassen oder IDs gearbeitet – den diese sind für die client- bzw. serverseitige Weiterverarbeitung interessant.
Ich arbeite mit Behat, Mink und der MinkExtension. Die Arbeit mit technischen Bezeichnern ist möglich. Ich habe mich aus oben genannten Gründen dazu entschlossen, die fachlichen Bezeichner (Labeltexte) zu nutzen.
Bis die Tage,
Matti
Hallo,
Meine Idee dahinter ist es, dass ich meine Tests so schreibe, dass ich alleine mit auf dem Screen sichtbaren Begriffen hantieren muss. … wenn ich meine GUI-Tests als eine Teilform der Akzeptanztests verstehe, dann ist das Innenleben der Software irrelevant.
Ja, das kann ich nachvollziehen. Wenn man es streng als Akzeptanztest sieht und nicht als Integrationstest auf hoher Ebene, dann ist es gleichsam zwingend, mit den tatsächlichen Labels zu arbeiten.
Bei mehrsprachigen Sites, bei denen Testcode und Verwaltung der Übersetzung unterschiedliche Systeme sind, die von unterschiedlichen Personen gewartet werden, läuft man schnell Gefahr, dass Tests fehlschlagen, nur weil jemand irgendein Wording minimal geändert hat. Aber vielleicht ist es gut, wenn diese Änderung auffällt. Es besteht natürlich die Möglichkeit, Übersetzungs-Keys anstatt -Values zu verwenden, aber das verschlechtert wieder die Lesbarkeit des Tests.
Grüße,
Mathias