nicht angemeldet
Terminkalender
Hi Roland,
in vielen Punkten hast Du mich überzeugt, aber ein paar Anmerkungen hätte ich doch noch:
Bei ca. 10% Besuchern, die Javascript deaktiviert haben, ist Javascript vorauszusetzen schlicht nicht praktikabel. Hinzu kommen noch all jene, die nur teilweise diverse Funktionen blocken.
Weiß ich. Ich meinte, dass die Anpassung der Schriftgrößen ohne Javascript nicht geht, ganz in Deinem Sinne.
natürlich ist die Bildschirmauflösung, die eine entsprechende JS-Abfrage liefert, nur ein Anhaltspunkt,
Nein, sie ist nichtmal ein Anhaltspunkt, weil sie nichts über die Größe des Fensters aussagt. Meine bevorzugte Auflösung ist 1152*864, die Fenstergröße beträgt aber "nur" 868*616 Pixel. Ich behaupte sogar, dass kaum jemand mit Auflösungen von >= 1200 px Breite mit einer Vollbilddarstellung surft, weil dadurch die Zeilen zu lang werden, als dass man sie noch flüssig lesen könnte. Weiters fällt, wenn du das Stylesheet von der Fenstergröße abhängig machst, das Layout zusammen, wenn ich ebendiese während der Betrachtung ändere. Fixe Breiten sollten einfach nicht eingesetzt werden, man nimmt HTML damit die Möglichkeit, automatisch umzubrechen.
Richtig, aber von festen Breiten war nicht die Rede, sondern von PX-Angaben bei Schriftgrößen. Hier scheint mir die Bildschirmauflösung tatsächlich ein Indikator für lesbare Fontgrößen zu sein.
Es spricht nichts dagegen, Grafiken pixelgenau zu positionieren, das mache ich auch. Doch sollte man bedenken, dass rundherum genug Platz übrig bleibt, um alle Elemente darstellen zu können. Ich selbst verwende für die Navigation bevorzugt ein eigenes DIV, das fixiert positioniert ist und eine vorgegebene Breite hat. Doch ist diese so gewählt, dass sie bis zu einer Schriftgröße von 150% genug Platz für den Inhalt bereithält. Leider skaliert Mozilla nur den Test und nicht das DIV selbst hoch, Opera macht das IMHO besser.
Das ist wirklich eine Verbesserungsmöglichkeit für den Mozilla. Es ist tatsächlich oft überraschend, wieviel Reserve man braucht, um auf allen Systemen mit dem Platz auszukommen.
All diese überladenen Portale zeugen doch nur von der Angst, Besucher zu verlieren und aus diesem Grund alles auf eine Seite pappen zu müssen. Leider leidet darunter die Übersichtlichkeit (web.de). Die Startseite von SELFHTML dagegen wirkt recht übersichtlich. Über die einzementierte Schriftgröße wurde schon hitzig debattiert (</archiv/1999_2/t03933.htm>, </archiv/2002/3/7966/>). Ich finde sie überflüssig, Begründungen sind in den verlinkten Threads zu finden ;)
Stimmt, aber ich denke, Stefan hat wirklich daran gefeilt, das Portal für SelfHTML so luftig zu halten, obwohl soviel Inhalt dahinter steckt. Tatsächlich ist aber eine große Informationsdichte schwer handelbar, ohne bestimmte Topseiten vollzupflastern, denn die ALternative, eine allzu große Tiefe der Verzweigungen, ist auch unangenehm. Ich habe neulich was bei Adobe gesucht, von dessen Existenz ich sicher wusste, und habe gemerkt, wie schwer es war, sich auf den endlos verzweigten Seien zurechtzufinden. Da gibt es eine Menge Negativbeispiele.
Sollen sie nur, bei Heise habe ich ohne Javascript/ActiveX keine Probleme und nur darum geht es mir letztendlich.
korrekt, es funktioniert tatsächlich alles tadellos ohne
Zur Kontrolle von Formularen,
Das ist ein schönes Beispiel für den sinnvollen Einsatz von Javascript, jedoch kann es eine serverseitige Prüfung der Eingaben nicht gänzlich ersetzen.
Ja. Die gekonnte Kombination macht's.
zur Navigation in komplexen Inhalten,
Nein ;) Nichts ist lästiger, als sich durch ellenlange DHTML-Menüs hangeln zu müssen. Schließlich gibt es wunderbar schöne Listen in HTML. Ich behaupte, 90% der Bastler, die ein DHTML-Menü einsetzen, denken nicht an eine noscript-Variante und schließen damit gedankenlos Besucher aus. Da hilft nur der freundschaftliche Klaps auf den Hinterkopf ;)
Leider wahr, das mit den Seitenbastlern, aber Listen allein machen oft eine strukturierte Übersicht schwer, wenn man gleichzeitig die Verschachtelungsebenen begrenzen will. Hier steht man meines Erachtens vor einer schwierigen Wahl. Es erscheint mir oft so, als solle man bei der Entwicklung einer Anwendung ohne Kontextmenüs, Pulldowns usw. auskommen, was wirklich schwierig ist. Tatsächlich ist auch eine wirklich gute Planung und Strukturierung des Inhalts die eigentliche Schwierigkeit bei der Webentwicklung, weniger die technische Umsetzung. Ich gebe aber zu, dass mir DHTML-Menüs manchmal als die beste Lösung erscheinen. Dass man eine Alternatibe Navigation anbieten sollte, weiß wahrscheinlich jeder Entwickler, oft reicht aber gerade dazu die Kohle nicht mehr aus, was wirklich ärgerlich ist.
Kommerzielle Projekte sind heutzutage Fastfood, die Webdesigner[tm] nichts anderes als Hilfsarbeiter, die mit bunten Tools Seiten zusammenklicken. Leider. Das ist auch der Grund, warum ich in diesem Bereich niemals arbeiten würde.
Ja, angesichts der im Moment zu erzielenden Preise ist es wirklich nicht verlockend, sich in diesem Bereich beruflich festzulegen, obwohl ich immer noch an die Zukunft professioneller Webentwickler glaube, auch weil viele Firmen inzwischen gemerkt haben dürften, dass mit Billiglösungen nichts zu erreichen ist. Aber im Moment ist die Situation wirklich schwierig, vielleicht vergleichbar mit den Kistenschiebern im Hardwarebereich, die auch keinen Blumentopf mehr gewinnen können. Ich merke das in letzter Zeit immer, wenn wir Projektmitarbeiter suchen: Es scheinen im Moment wirklich viele gute Leute auf der Straße zu stehen.
eventuell auch verschiedene Layouts für verschiedene Medien anzubieten und automatisch die korrekte Variante auszuwählen, wächst, und ich finde es problematisch, dem nur mit prinzipieller Ablehnung gegenüber zu treten.
Aber das mache/n ich/wir keineswegs! Gerade CSS bietet doch die Möglichkeit, jedem Ausgabemedium ein angepasstes Stylesheet zukommen zu lassen. Dazu ist Javascript überhaupt nicht nötig, mit Tabellen wird es unmöglich.
Einen Versuch, Recht zu behalten, mache ich noch: Ich habe neulich mal eine gute Seite gefunden zum Thema der verschiedenen Größenangaben für Schriften im Web, ich muss nochmal nachsuchen, dort wurde recht ordentlich dargelegt, welche Schattenseiten die verschiedenen Formate jeweils haben. Was spricht dagegen, wenn man als Zusatzleistung per Javascript und CSS versucht, jeweils optimal große Schriften nachzuladen, so kompliziert ist es ja nicht. Solange man die JS-lose Elite nicht völlig vor den Kopf stößt, kann man doch ganz komfortable Lösungen stricken.
Den Hintergrund für meinen "Zwergenaufstand" will ich auch noch nennen: Ein konkretes Projekt, das angesichts der Menge der Inhalte
wirklich Lösungen erfordert, die mit einer Liste nicht übersichtlich abzuarbeiten sind und eine siteinterne Suche als Ersatz für eine entsprechende Menüstruktur finde ich auch nicht gerade prickelnd. Ich versuche zur Zeit immer noch, mit Hilfe von Erfahrungen aus der Datenbankprogrammierung, die Inhalte zu "normalisieren", aber irgendwie stößt man da immer wieder an Grenzen. Wenn man sich die großen Sites anschaut, scheint dies auch ein reales Problem beim derzeitigen Stand der Technik zu sein. Hast Du dafür noch Tipps parat?
Viele Grüße
Mathias Bigge
-
Hi,
Und zwar wenn der Besucher auf die Seite geht, soll bei den Auswahllisten das jeweilige heutige Datum angezeigt werden. Und nicht das er es erst zusammensuchen muss. bitte mal ausprobieren!
was hast Du bisher probiert, und woran ist es gescheitert?
<form action="mailto:" method="post" enctype="text/plain">
http://www.praast.de/ffq/mailto.htm
Cheatah
-
Hi,
Und zwar wenn der Besucher auf die Seite geht, soll bei den Auswahllisten das jeweilige heutige Datum angezeigt werden. Und nicht das er es erst zusammensuchen muss. bitte mal ausprobieren!
was hast Du bisher probiert, und woran ist es gescheitert?
<form action="mailto:" method="post" enctype="text/plain">
Cheatah
Probiert habe ich das bisher:
<script language="JavaScript">
<!--
function datumdt(){
var mydate=new Date();
var year=mydate.getYear();
if (year < 1000)
year+=1900;
var day=mydate.getDay();
var month=mydate.getMonth();
var daym=mydate.getDate();
if (daym<10)
daym="0"+daym;
var dayarray=new Array("Sonntag","Montag","Dienstag","Mittwoch","Donnerstag","Freitag","Samstag");
var montharray=new Array("Januar","Februar","März","April","Mai","Juni","Juli","August","September","Oktober","November","Dezember");
document.write("<select name='Tagname' size='1'><option selected>"+daym+"</option></select><select name='Monat' size='1'><option> "+montharray[month]+"</option></select> ,<select name='Jahr' size='1'><option> "+year+"</option></select> Uhrzeit:");
}
//-->
</script>Aber ich möchte das der Benutzer dann trotzdem noch nacher in option Feld ein anderes Datum auswählen kann aber wie?
-
Hi,
Aber ich möchte das der Benutzer dann trotzdem noch nacher in option Feld ein anderes Datum auswählen kann aber wie?
warum kann er das denn nicht?
Cheatah
-
Hi,
Aber ich möchte das der Benutzer dann trotzdem noch nacher in option Feld ein anderes Datum auswählen kann aber wie?
warum kann er das denn nicht?
Cheatah
Naja weil ich es nicht weiß wie man sowas programmiert deshalb frage ich ja! :-)
Christoph
-
Hi,
Aber ich möchte das der Benutzer dann trotzdem noch nacher in option Feld ein anderes Datum auswählen kann aber wie?
warum kann er das denn nicht?
Naja weil ich es nicht weiß wie man sowas programmiert deshalb frage ich ja! :-)
hm, ich habe den Code nicht getestet, aber für mich sah es so aus, als würde ein Auswahlfeld ausgegeben werden. Damit verstehe ich dann Dein Problem nicht mehr.
Cheatah
-
Hi,
Ok nochmal. Teste am besten den Code selber mal aus. Also das Javascript zeigt mir ein Auswahlfeld an mit dem jeweiligen Datum, ganz logisch. Aber das wars dann auch schon. Ich kann dann im listenfeld nichts anderes auswählen!!! Ich möchte aber vielleicht einen Termin in 3 Wochen haben und das müsste ich auch dann noch auswählen können. Aber das Javascript zeigt mir immer nur das jeweilige heutige Datum an und mehr nicht. Shit ist das schwer zu erklären. Am besten wirklich den Code testen dann siehst du ja hoffentlich selber wie ich das meine.
<script language="JavaScript">
<!--
function datumdt(){
var mydate=new Date();
var year=mydate.getYear();
if (year < 1000)
year+=1900;
var day=mydate.getDay();
var month=mydate.getMonth();
var daym=mydate.getDate();
if (daym<10)
daym="0"+daym;
var std=mydate.getHours()
var min=mydate.getMinutes()
var dayarray=new Array("Sonntag","Montag","Dienstag","Mittwoch","Donnerstag","Freitag","Samstag");
var montharray=new Array("Januar","Februar","März","April","Mai","Juni","Juli","August","September","Oktober","November","Dezember");
document.write("<select name='Tagname' size='1'><option selected>"+daym+"</option></select> . <select name='Monat' size='1'><option> "+montharray[month]+"</option></select> . <select name='Jahr' size='1'><option> "+year+"</option></select> Uhrzeit:<select name='stdmin' size='1'><option selected>"+std+"."+min+"</option></select>");
}
//-->
</script>
<body>
<script language="JavaScript">
<!--
datumdt();
// -->
</script>
</body>Ok bis bald und frohes testen :-)
-
Hi,
Ok nochmal. Teste am besten den Code selber mal aus.
ah. Der Code sah mir hinreichend umständlich aus, als daß Du für Deine dayarrays etc. auch entsprechende <option>s geschrieben haben könntest. Bei näherer Betrachtung stelle ich fest, daß Du das vergessen hast - naja, dann klappt's natürlich nicht mit dem Nachbarn.
Übrigens solltest Du mal darüber meditieren, welchen Sinn Formular-Elemente ohne Formular, sprich: <form>-Tag machen :-)
Cheatah
-
-
-
-
-
-
-
Hi.
Und zwar wenn der Besucher auf die Seite geht, soll bei den Auswahllisten das jeweilige heutige Datum angezeigt werden.
Du musst nur beim heutigen Tag, Monat, Jahr <option> um selected ergaenzen :
<option selected>26</option>
Lass das Listenfeld dynamisch durch ein JavaScript schreiben und ermittle vorher das heutige Datum.
CU
Thomas Dwardokus