nicht angemeldet
Howto: Popups mit JavaScript
0 0 0 0 0
Howto: Popups mit JavaScript
Hallo zusammen,
Seit geraumer Zeit unterhalte ich ein Howto, welches die richtige (d.h. verantwortungsbewusste) Verwendung von Popupfenster auf Webseiten diskutiert und erörtert, wie sinnvoll die Verwendung von den verschiedenen HTML- und JavaScript-Lösungen ist.
In den letzten Tagen habe ich das Howto ausgebaut, sodass es auch metatechnische Hinweise und Argumente anführt. Es soll versuchen, denjenigen Seitenautoren, welche sich um Zugänglichkeit und Interoperabilität bisher keine Gedanken gemacht haben und freundliche Hinweise mit dem Argument abgewehrt haben, dass die Mehrheit sowieso die Software X einsetzt, welche die Technologie Y problemlos unterstützt, benutzbare Alternativlösungen aufzeigen - soweit Überzeugungsarbeit überhaupt möglich ist.
Da mittlerweile immer mehr Besucher über Suchmaschinen zu dem Howto finden, würde ich mich darüber freuen, wenn es von fachkundigen Netzbewohnern gegengelesen wird und ich so es weiter verbessern kann.
Konstruktive sowie destruktive Kritik, Kommentare, Ergänzungen und Verbesserungsvorschläge sind herzlich erwünscht. Für Diskussionen bin ich offen, ob per PM oder hier.
Die Adresse lautet: http://home.t-online.de/home/dj5nu/js-popup.html
Viele Grüße,
Mathias Schäfer
-
hi Mathias,
Seit geraumer Zeit unterhalte ich ein Howto, welches die richtige (d.h. verantwortungsbewusste) Verwendung von Popupfenster auf Webseiten diskutiert und erörtert, wie sinnvoll die Verwendung von den verschiedenen HTML- und JavaScript-Lösungen ist.
Der Anspruch, ein "howto" zu schreiben, ist schon sehr, sehr hoch. Grundsätzlich ist an der "Idee" nichts Verkehrtes zu finden, und auch die Art - oder Konzeption - wie du herangegangen bist, ist nicht ganz verkehrt.
Es gibt jedoch ein paar _ganz dicke_ "ABER":
- ein Howto sollte semantisch und syntaktisch "stimmen". Es gibt sehr viele Rechtschreibfehler auf deiner Seite, und als ich sie durch den Validator gejagt habe - naja, schau selbst mal nach.
- schon der erste link zu einem Popup-Fenster (leider kann ich keine Textmarke angeben, weil es keine gibt) öffnet sich in einem neuen Fenster, das keine Scrollbalken zuläßt. Aber der Inhalt des Fensters ist deutlich umfangreicher als das, was ich angezeigt bekomme
- einige andere "bugs" sind zu klein, um sie jetzt schon anzusprechen.Grundsätzlich sollte dir bekannt sein, daß die Mehrheit der "Stammuser" (wow, ich mag diesen Begriff überhaupt nicht und verwende ihn hier zum erstenmal) popups generell ablehnt. Ich mag die Dinger auch nicht. Jetzt kriege ich also von dir eine Bedienungsanleitung geliefert, wie ich solches Zeugs "richtig" programmieren soll, und diese "Bedienungsanleitung" hat sogar einen durchaus ernstzunehmenden Hintergrund. Och nöööööööööööö ...
Wenn ich etwas über popups erfahren möchte, so ist es einzig die Frage, wie ich die Dinger _absolut_ und _vollständig_ unterdrücken und verbieten kann.
Kannst du in dein gut gemeintes howto auch noch an alllererster Stelle den Hinweis aufnehmen, daß man mit popups die möglichen Besucher einer Seite nur quält, statt ihnen Orientierungen zu geben? Das trifft insbesondere auf deine Anmerkungen zu <body onload="popup"> zu - ich halte es für eine fürchterliche Frechheit, mir damit eben so ein popup-Fenster aufzuzwingen, sobald ich eine Seite öffnen möchte. Siehe die Gestaltung bei http://www.t-online.de - wobei das winzige Werbefenster dort noch vergleichsweise "human" ist.
Überlege dir nochmal bitte, ob du der Gemeinschaft der Web-Besucher mit deinem "howto" einen echten Dienst erweist oder ob du dazu beiträgst, daß diejenigen, die ihre Besucher bisher schon mit popups geärgert haben, diesen Ärger jetzt noch gezielter und effizienter machen können.
Grüße aus Berlin
Christoph S.
-
Hi, Christoph
Warum so streng? Mir gefällt die Site sehr gut, sowohl inhaltlich, als auch bezüglich der Gestaltung. Eine angenehme Ausnahme im Klicki-Bunti-Krieg "da draußen".
- ein Howto sollte semantisch und syntaktisch "stimmen". Es gibt sehr viele Rechtschreibfehler auf deiner Seite, und als ich sie durch den Validator gejagt habe - naja, schau selbst mal nach.
Die genannte Seite ist valide, die sprachliche Qualität wiegt IMHO die paar Tippfehler mehr als auf.
- schon der erste link zu einem Popup-Fenster (leider kann ich keine Textmarke angeben, weil es keine gibt)
Doch, die gibt's. Allerdings könnten es noch mehr sein und ich würde sie prominent plazieren, um sie bequem verlinken zu können.
öffnet sich in einem neuen Fenster, das keine Scrollbalken zuläßt. Aber der Inhalt des Fensters ist deutlich umfangreicher als das, was ich angezeigt bekomme
Das ist allerdings richtig und sollte noch geändert werden. Weiters fehlt beim zweiten Link auf dieses Popup blur() bzw. focus(), damit dieses wieder in den Vordergrund kommt.
Grundsätzlich sollte dir bekannt sein, daß die Mehrheit der "Stammuser" (wow, ich mag diesen Begriff überhaupt nicht und verwende ihn hier zum erstenmal) popups generell ablehnt. Ich mag die Dinger auch nicht. Jetzt kriege ich also von dir eine Bedienungsanleitung geliefert, wie ich solches Zeugs "richtig" programmieren soll, und diese "Bedienungsanleitung" hat sogar einen durchaus ernstzunehmenden Hintergrund. Och nöööööööööööö ...
Doooooooch - http://home.t-online.de/home/dj5nu/js-popup.html#jshowto4 und alles wird gut ;)
Wenn ich etwas über popups erfahren möchte, so ist es einzig die Frage, wie ich die Dinger _absolut_ und _vollständig_ unterdrücken und verbieten kann.
Naja, nicht nur in http://home.t-online.de/home/dj5nu/js-popup.html#jshowto3 wird recht eindringlich davon abgeraten, JS ohne Alternative zu verwenden. Letztenendes wird von auch von PopUps selbst abgeraten, siehe http://home.t-online.de/home/dj5nu/js-popup.html#jshowto6a. Mein Kompliment.
(PopUp) [...] die möglichen Besucher einer Seite nur quält [...] fürchterliche Frechheit, [...] diesen Ärger jetzt noch gezielter und effizienter machen
Wenn man die Seite aufmerksam liest, steht IMHO genau das dort ;) Danke an Mathias 'molily' für diese Seite. Gebookmarked und für tauglich befunden, den PopUp-Kiddies um die Ohren zu schlagen.
LG Orlando
--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html-
upsa, Orlando ...
ich mag zwar manchmal "streng" sein, aber hoffentlich nicht ungerecht.
Wir sollten uns weiterführenden (konstruktiven) Streit für
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.htmlaufheben ;-)
Grüße aus der Berliner Morgendämmerung
Christoph S.
-
Hi nochmal,
ich mag zwar manchmal "streng" sein, aber hoffentlich nicht ungerecht.
nein, so war's auch nicht gemeint. Allerdings habe ich eine Reflexantwort herausgelesen (oder hineininterpretiert?), die sich der arme Mathias so nicht verdient hat. Alles IMHO natürlich ;)
Wir sollten uns weiterführenden (konstruktiven) Streit für
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html
aufheben ;-)Och, wir streiten doch nicht. Aber ja, ich freue mich schon auf eine Plauderei :)
LG
<img src="http://www.menshealth.com/images2/food2/muscle.jpg" border=0 alt="">
Orlan*scnr*do
-
-
-
Hallo, Christoph!
Danke erst einmal für das detailreiche Feedback.
Der Anspruch, ein "howto" zu schreiben, ist schon sehr, sehr hoch. Grundsätzlich ist an der "Idee" nichts Verkehrtes zu finden, und auch die Art - oder Konzeption - wie du herangegangen bist, ist nicht ganz verkehrt.
Ich habe nie behauptet, dass es Anspruch auf Vollständigkeit oder Perfektion hat; ich möchte niemanden belehren oder Lösungen vorschreiben, sondern nur Ideen vermitteln. Ich denke, das habe ich mit der offenen Form des Howtos getan. Es soll, wie gesagt, die Vor- und Nachteile aufzeigen und vor allem wollte ich herausstellen, dass es keine endgültig richtige Lösung für Popups gibt (außer sie auszurotten... Endlösung der Popupfrage, jaja ;-)).
Natürlich ist das Howto subjektiv gefärbt, natürlich möchte ich die mir wichtigen Aspekte in den Vordergrund stellen (z.B. die Barrierefreiheit), aber eigentlich soll es argumentativ überzeugen.
Es gibt zuhauf Seiten über JavaScript-Popups, welche den üblichen href="javascript:window.open..." bzw. href="#" onclick="..." Murks kommentarlos anbieten. Dem wollte ich etwas entgegensetzen, was nicht so engstirnig oder zumindest weniger engstirnig ist.Ich habe mich trotzdem deiner Einwände erdreist, es ins Web zu stellen :), weil ich dachte, es könne (ab)helfen. Glücklicherweise darf jeder das Existenzrecht meiner Seite anzweifeln; ich hingegen mache von der Möglichkeit der Veröffentlichung Gebrauch, selbst wenn oder gerade weil es manchen nicht gefällt. ;)
- ein Howto sollte semantisch und syntaktisch "stimmen". Es gibt sehr viele Rechtschreibfehler auf deiner Seite, und als ich sie durch den Validator gejagt habe - naja, schau selbst mal nach.
"Sehr viele Rechtschreibfehler" kann ich nicht nachvollziehen, wenn wir unter Rechtschreibfehler dasselbe verstehen. Deutlich viele Tippfehler sind mir in den letzten Tagen dennoch aufgefallen, was wohl eher an zuwenig Schlaf und den übrigen "Umgebungsvariablen" liegen dürfte.
Wenn dir irgendetwas arg Grobes aufgefallen ist, was ich nicht mit meinem kreativen Umgang mit Sprache rechtfertigen kann ;), schreibe mir bitte mal eine Mail, ich würde mich freuen.
Und der HTML-Validator vermeldet nur, dass er nichts zu vermelden hat, der CSS-Validator gratuliert mir, dabei wüsste ich nichts zu feiern. Wegen dem Popup-Quatsch bin ich extra schweren Herzens von meinem Grundsatz Strict auf Transitional umgestiegen, jetzt wirf mir das nicht auch noch vor, ich schäme mich, aber es musste sein. :)- schon der erste link zu einem Popup-Fenster (leider kann ich keine Textmarke angeben, weil es keine gibt) öffnet sich in einem neuen Fenster, das keine Scrollbalken zuläßt. Aber der Inhalt des Fensters ist deutlich umfangreicher als das, was ich angezeigt bekomme
Oh, da hast du Recht, das war nicht so gewollt, die Scrollbars sollten schon aktiviert sein. Abgesehen davon sollte das nur als Beispiel dienen, nicht als: hier hast du den Quelltext, füge ihn in deine Seite ein.
Nicht dass die Leser das missverstehen, sonst frage ich hier in ein paar Tagen, wie man die rechte Maustaste und damit den Quelltext schützt *lol*, und zwar interoperabel, auch unter Lynx, w3m, links, dem CERN line mode browser und vor allem bei Macintosh-Eintastenmäusen... ;)Ein Inhaltsverzeichnis ist in Arbeit. Wie du vielleicht gesehen hast, ist das Howto eines meiner Projekte meiner Homepage, und aus Funktionalität bin ich von dem Standarddesign der restlichen Seiten abgewichen, für die momentan mehrere Layouts parallel entwickelt werden, die dann eigentlich auch rückwirkend auf die Projektseiten angewendet werden sollten. Da gibt es dann auch benutzbare feststehende Inhaltsverzeichnisse etc. Deswegen ist alles noch ganz "frisch" und experimentell. Linkanker dafür existieren wie Orlando bemerkt hat schon.
Grundsätzlich sollte dir bekannt sein, daß die Mehrheit der "Stammuser" (wow, ich mag diesen Begriff überhaupt nicht und verwende ihn hier zum erstenmal) popups generell ablehnt. Ich mag die Dinger auch nicht. Jetzt kriege ich also von dir eine Bedienungsanleitung geliefert, wie ich solches Zeugs "richtig" programmieren soll, und diese "Bedienungsanleitung" hat sogar einen durchaus ernstzunehmenden Hintergrund. Och nöööööööööööö ...
Da musst du mich wohl missverstanden haben. (Siehe auch Orlandos Posting.) Auch wenn ich hier wohl nicht bewusst einer Gruppe von Regulars nach dem Mund schreibe, kann ich Popups ebenso auf den Tod nicht ausstehen, leider zwingen sie einen dazu, ab und an JavaScript zu aktivieren.
Die Konklusion des Howtos ist, wie die Argumentation und eigentlich schon der erste Satz zeigen sollen, dass aus den genannten Gründen von der Benutzung jeglicher Popups abzuraten ist. Wenn man trotzdem darauf besteht, dann ist es imho die "verdammte Pflicht" jedes Netzbewohners diese so zu programmieren, dass jeder die betroffene Seite auch mit deaktiviertem JavaScript und Popup-Antipathie problemlos betrachten kann.Wenn ich etwas über popups erfahren möchte, so ist es einzig die Frage, wie ich die Dinger _absolut_ und _vollständig_ unterdrücken und verbieten kann.
Das sehe ich ganz genauso, und die einzige Möglichkeit, dies zu erreichen, ist meines Erachtens die Aufklärung derjenigen Menschen, die JavaScript-Popups fehlerhaft und missbräuchlich gestalten - deshalb und aus keinem anderen Grund mein Howto.
Außerdem ich verstehe dein Problem nicht, ich wüsste nicht, wann ich das letzte Mal in meinen Browsern Popups gesehen habe. :) Ach doch, erst gestern, um die Negativbeispiele des Howtos zu testen.
Jeder soll meinetwegen dutzende, hunderte, tausende Popups aufpoppen lassen, http://www.raus.de/crashme/ das ist mir am liebsten. ;-> Solange es mein JavaScriptfreies browsen nicht einschränkt; mich tangiert JavaScript so gesehen nicht. Und wenn doch, dann konfiguriert man seinen Lieblingsbrowser halt so, dass er Popupfenster ignoriert, andere harmlose/sinnlose JavaScripts aber zulässt.Kannst du in dein gut gemeintes howto auch noch an alllererster Stelle den Hinweis aufnehmen, daß man mit popups die möglichen Besucher einer Seite nur quält, statt ihnen Orientierungen zu geben? Das trifft insbesondere auf deine Anmerkungen zu <body onload="popup"> zu [...]
Ehm, da musst du mich wohl erneut missverstanden haben, ich werde das wohl eindeutiger formulieren müssen; oder ich missverstehe dich jetzt: Das <body onload="...">-Beispiel im ersten Absatz sollte als Negativbeispiel gedacht sein.
Ich finde die Struktur und Reihenfolge so okay. Denn wer nur den Code kopieren will, soll dies tun, der wird aber auch für ewig dumm bleiben, das kann ich nicht verhindern, da kann ich noch soviele Hasstiraden gegen JavaScript ablassen. Wenn ich die Leute zum weiterlesen animieren kann und sie so mindestens zur "Huch, ich verjage mir meine Besucher"-Erkenntnis treiben kann, hat mein Anliegen Erfolg gehabt.
Ich wollte kein Pamphlet schreiben, welches meinen Hass gegenüber JavaScript im Allgemeinen und Popups im Speziellen ausdrückt. Wenn ich direkt anfange mit "Popups sind schlecht, benutzt sie nicht", dann entspricht das zwar meiner Meinung und meiner Absicht, jedoch vermutete ich, dass dies die wenigsten beeindrucken wird. Dahingegen wird sich jeder noch so ignorante Döspaddel von dem Argument überzeugen lassen, dass er sich mit JavaScript-Popups selbst ins Knie schießt, auch wenn ihm die vollständige Problematik nicht bewusst ist und er sich kein Stück darum schert, ob bspw. Menschen mit Behinderungen seine Seite betrachten können.
Eine Beispielsituation wäre, dass man einem Webmaster, welcher einer inhaltlich hochwertige Seite unterhält, die jedoch bedauerlicherweise aufgrund der Verwendung von JavaScript unzugänglich ist, ruhig und sachlich die Problematik schildert und ihm diem Adresse des Howtos an die Hand gibt. Darin sehe ich Erfolgspotenzial.
Überlege dir nochmal bitte, ob du der Gemeinschaft der Web-Besucher mit deinem "howto" einen echten Dienst erweist oder ob du dazu beiträgst, daß diejenigen, die ihre Besucher bisher schon mit popups geärgert haben, diesen Ärger jetzt noch gezielter und effizienter machen können.
Ich kann diese Einwände nicht verstehen, denn meine einzige Absicht war, dem Leser zu vermitteln, dass die Benutzung von JavaScript für Popups nicht gutzuheißen ist; und dies nicht in einem unsachlichen Tonfall, sondern mittels Argumenten und Alternativvorschlägen.
Abgesehen davon, wenn ein Seitenautor ein Popup öffnen möchte, dann findet er das dazu nötige Wissen auf tausenden anderen Netzseiten. Und nur weil man dieses Wissen auch missbrauchen und verantwortungslos einsetzen kann, sollte man es nicht verbieten. JavaScript ist böse(TM), zensiert SELFHTML! ;-) (Das könnte man so endlos bis 1984 zurück- bzw. fortsetzen.)Grüße,
Mathias (der sich die Vorschläge zu Herzen nimmt und noch einiges herumbasteln wird) -
Hallo Christoph,
immer wenn ich dein ansonsten wunderbares sbpower-Bild sehe, denke ich, schon wieder ein kaput antialisierter Text. Kleiner Text ist sehr schwer zu setzen, schau Dir einfach mal z.B. Deine Es an, die sehen beide unterschiedlich aus (das rechte wirkt schwacher, weil das schwarz ganz raus "antalisiert" wurde). Auch machen bei geraden Linien antialisierung keinen Sinn, so sehen die Es oben dicker aus (zwei Pixel linien) als unten. Ich gebe gerne zu, daß ich da immer etwas überpingelig bin, und verstecke meinen Gegenvorschlag ja auch hier absolut OT in einem Thread ,-)
Entweder hatte ich auch eine andere Schrift als Du oder mein Programm setzte Arial anders, bei mir, ich gebe es zu, ist das Selfbrowser einen Pixel größer, sorry für diesen "fehler" bei meinem Entwurf, ansonsten biete ich Dir "meinen" Entwurf Deines wie gesagt sehr schönen Logos an. Hier erst Deins, darunter zum Vergleich meine Schriftsetzung.
<img src="http://home.arcor.de/schnauss/bilder/sbpower.gif" border=0 alt="">
<img src="http://www.stempelgeheimnis.de/diverses/sbpower.gif" border=0 alt="">
Chräcker, der neumalkluge Pingel....
-
hi Chräcker,
immer wenn ich dein ansonsten wunderbares sbpower-Bild sehe, denke ich, schon wieder ein kaput antialisierter Text.
richtig, das mit dem Antialiasing hätte nicht sein brauchen, außerdem hab ich eigentlich ausversehen zwei verschiedene Schriften genommen.
Ich ersetze ganz eifach meine Grafik durch deine, fertig ;-)dankesehr
Christoph S.
PS: wenn ich die Grafik ersetzt habe, wird niemand mehr deine Anmerkung verstehen können *g*
-
Hallo,
richtig, das mit dem Antialiasing hätte nicht sein brauchen,
oh, beim meinem Versuch habe ich auch antialisiert, mein Programm kann es nur scheinbar besser als Deins ;-)))
PS: wenn ich die Grafik ersetzt habe, wird niemand mehr deine
Anmerkung verstehen können *g*oder noch besser: sie werden mit der Lupe drangehen und denken: typisch Chräcker, wollte bestimmt nur wieder ein posting mehr absetzen, der hat auch immer was zu meckern ,-)))
Chräcker
-
hi,
oh, beim meinem Versuch habe ich auch antialisiert, mein Programm kann es nur scheinbar besser als Deins ;-)))
Ich nehme Corel Photopoint 10. Und vielleicht lags auch daran, daß ich "Transparenz" eingestellt hatte
oder noch besser: sie werden mit der Lupe drangehen und denken: typisch Chräcker, wollte bestimmt nur wieder ein posting mehr absetzen, der hat auch immer was zu meckern ,-)))
Is ja auch prompt passiert *g*
Christoph S.
-
Moin!
oder noch besser: sie werden mit der Lupe drangehen und denken: typisch Chräcker, wollte bestimmt nur wieder ein posting mehr absetzen, der hat auch immer was zu meckern ,-)))
Is ja auch prompt passiert *g*Wo?
viele Gruesse,
Einbecker
P.S.: SCNR ;-)
-
-
-
-
Moin Chraecker!
<img src="http://home.arcor.de/schnauss/bilder/sbpower.gif" border=0 alt="">
<img src="http://www.stempelgeheimnis.de/diverses/sbpower.gif" border=0 alt="">
Also, ich finde, die Bilder sehen wirklich fast identisch aus... Aber gut, ich denk mir, typisch Chraecker, wollte bestimmt nur wieder ein Posting mehr absetzen - der hat auch immer was zu meckern.
Viele Gruesse,
Einbecker
P.S. SCNR
-
Hallo,
<img src="http://www.stempelgeheimnis.de/diverses/sbpoweralt.gif" border=0 alt="">
<img src="http://www.stempelgeheimnis.de/diverses/sbpower.gif" border=0 alt="">
Also, ich finde, die Bilder sehen wirklich fast identisch aus...
naja, vielleicht muß ich mal meine Brille putzen.....
Chräcker
-
Moin Chraecker!
<img src="http://www.stempelgeheimnis.de/diverses/sbpoweralt.gif" border=0 alt="">
<img src="http://www.stempelgeheimnis.de/diverses/sbpower.gif" border=0 alt="">
Hey cool... Kannst du das nicht mal als CGI Umsetzen - Ich meine, die Welt waere bestimmt an einem CraeckersBrilleEmulator brennend interessiert ;-)
naja, vielleicht muß ich mal meine Brille putzen.....
nein, das sind eigentlich nur die Tesafilmstreifen, die Du da draufgeklebt hast, um auch mal wie Schumi "das Visier abreissen zu koennen" ;-)
Viele Gruesse,
Einbecker
-
hi ;-)
du solltest dich vielleicht dazu durchringen, Threads möglichst vollständig zu lesen. Ich habe nämlich die Grafik, die Chräcker noch unter http://www.stempelgeheimnis.de/diverses/sbpoweralt.gif (absichtlich kein link) gespeichert hat, auf seinen Rat hin sofort ersetzt mit einer auch Chräckers pingeligen Ansprüchen genügenden Version. Und das habe ich auch in einem posting in diesem Thread angekündigt.
Hey cool... Kannst du das nicht mal als CGI Umsetzen - Ich meine, die Welt waere bestimmt an einem CraeckersBrilleEmulator brennend interessiert ;-)
sofern ich zur "Welt" zähle, wäre ich das auch. Aber über CGI gehts meines Wissens bisher nicht - kommt drauf an, was man unter "CGI" versteht. Möglich wäre es über PHP
nein, das sind eigentlich nur die Tesafilmstreifen, die Du da draufgeklebt hast
also, für die Tesafilmstreifen erhebe ich Copyright-Gebühren, weil die wirklich von mir sind, und sich meine Aufmerksamkeit gegenüber dem Forum doch irgendwann mal refinanzieren lassen müßte. Chräcker hat mein file lediglich geklaut und bezüglich dieser Grafikdatei absolut nix Innovatives in Richtung Tesafilm bisher unternommen, um das mal klarzustellen!
;-)
Christoph S.
-
Hallo,
oh, ich glaube schon, das Einbecker das richtig verstanden hat, sein Zitat meiner Befürchtung war zu genau ;-) Und um auch "fürs Archiv" es festzuhalten: die Grafik ist alleine Christophs Werk und sah nicht so aus, wie die verwaschene da oben, das war nur eine Rheinische Übertreibung ,-)))
und zum tesafilm: wenn ich mich recht erinnere, habe ich den Adventsbeitrag letzten Jahres schon mit tesafilm zusammengeklebt,
<img src="http://www.atomic-eggs.com/selfspezial/advent/2001/5/santaclaus.gif" border=0 alt="">
und zur zeit klebt auf meiner eigenen Werbeseite ein Blatt Papier, ebenfalls mit tesafilm. Habe Tesa natürlich nicht erfunden, aber als html-Tag nutze ich den schon etwas länger ,-)))))
Jawohl ja,
Chräcker
(an die Brillenseite denke ich....;-))
-
Moin!
oh, ich glaube schon, das Einbecker das richtig verstanden hat, sein Zitat meiner Befürchtung war zu genau ;-)
Wie? Nein, ich lese Threads grundsaetzlich nie komplett, und Scherze mache ich auch keine.
... Ruhe dahinten! Wer hat da gelacht? Das ist eine wahre Aussage... Verdammt... Hier glaubt mir ja eh keiner... Oder doch, Christoph? ;-)
Und um auch "fürs Archiv" es festzuhalten: die Grafik ist alleine Christophs Werk und sah nicht so aus, wie die verwaschene da oben, das war nur eine Rheinische Übertreibung ,-)))
Kann ja jeder sagen :-P
Und an Christoph:
Hey cool... Kannst du das nicht mal als CGI Umsetzen - Ich meine, die Welt waere bestimmt an einem CraeckersBrilleEmulator brennend interessiert ;-)
sofern ich zur "Welt" zähle, wäre ich das auch. Aber über CGI gehts meines Wissens bisher nicht - kommt drauf an, was man unter "CGI" versteht. Möglich wäre es über PHPHm... merkwuerdig - wenn es ueber PHP geht, dann _sicher_ auch ueber CGI. Siehe SelfHTML: "Die CGI-Schnittstelle (Common Gateway Interface - Allgemeine Vermittlungsrechner-Schnittstelle) ist eine Möglichkeit, Programme oder Scripts im Web bereitzustellen, die von HTML-Dateien aus aufgerufen werden können, und die selbst HTML-Code erzeugen und an einen Web-Browser senden können."
CGIs sind imho (und auch in der vieler anderer) Programme, die ueber die CGI-Schnittstelle angebunden sind - und ein blur-Effekt sollte mit jedem Grafik-Toolkit moeglich sein ;-)
Viele Gruesse,
Einbecker (heute gegen die Thread-Reinheitsgebote verstossend)
-
ähm, ja, also ....
wenn du mich so direkt ansprichst:
... Ruhe dahinten! Wer hat da gelacht? ... Hier glaubt mir ja eh keiner... Oder doch, Christoph? ;-)
manchmal glaub ich dir was
Hm... merkwuerdig - wenn es ueber PHP geht, dann _sicher_ auch ueber CGI. Siehe SelfHTML: "Die CGI-Schnittstelle (Common Gateway Interface - Allgemeine Vermittlungsrechner-Schnittstelle) ist eine Möglichkeit, Programme oder Scripts im Web bereitzustellen, die von HTML-Dateien aus aufgerufen werden können, und die selbst HTML-Code erzeugen und an einen Web-Browser senden können."
CGIs sind imho (und auch in der vieler anderer) Programme, die ueber die CGI-Schnittstelle angebunden sind - und ein blur-Effekt sollte mit jedem Grafik-Toolkit moeglich sein ;-)wenns lediglich um diesen simplen blur-Effekt ginge, hättest du recht. Aber PHP kann mehr als bloß "blur", damit kannste kleine Grafiken "schreiben" - und so eine wie meiner kleine Signaturgrafik wäre wahrscheinlich auch "programmierbar"
Und wenn wir erstmal in den aufdämmernden Zeiten der SVG-Grafiken gelandet sein werden, gibts diese Frage nach CGI-Übermittlung von Grafikdaten eh nicht mehr ;-)
Grüße aus Berlin
Christoph S.
-
-
Hi Chräcker,
und zur zeit klebt auf meiner eigenen Werbeseite ein Blatt Papier,
ebenfalls mit tesafilm. Habe Tesa natürlich nicht erfunden, aber
als html-Tag nutze ich den schon etwas länger ,-)))))hast Du tatsächlich eine eigene DTD geschrieben,
in welcher <tesa> ein valider tag ist?Viele Grüße
Michael-
Hallo,
hast Du tatsächlich eine eigene DTD geschrieben,
in welcher <tesa> ein valider tag ist?aber nein, daß wäre ja keine echte "Tesafilmlösung" mehr ;-))))
Chräcker
-
hi ;-)
hast Du tatsächlich eine eigene DTD geschrieben,
in welcher <tesa> ein valider tag ist?
aber nein, daß wäre ja keine echte "Tesafilmlösung" mehr ;-))))stimmt, das TAG muß natürlich <tesafilm> heißen, und jetzt tu mal bitte so, als ob du eine entsprechende DTD schon längst geschrieben hättest !
(kannst du selbstverständlich noch nicht freigeben und nix genaueres dazu sagen, weil noch nicht unter GNU-Lizenz)Verschwörergrüße aus Berlin
Christoph S.
-
-
-
-
-
-
-
-
-
-
Moin moin!
Bin begeistert, muss ich sagen. In klarem Deutsch geschriebener Text (ok, ein paar Rechtschreibfehler sind drin), der das Problem genau richtig angeht. Und das saubere HTML, das nur wegen target nicht als Strict durchgeht, gibt nochmal Extra-Punkte. *g* Nur solltest Du vielleicht noch unterbringen, dass man die Popups, wenn man es denn nicht lassen kann, wenigstens resizable und mit Scrollbar machen soll. Es gibt naemlich auch viele solche Popups da draussen, die man nur zur Haelfte lesen kann, weil der Text einfach nicht ins Fenster passt und keine Scrollbars da sind. (Dabei natuerlich anbringen, dass der Autor nicht wissen kann, wie gross bei mir die Schrift ist.)
Apropos Schriftgroesse, dass Du diese einfach auf 80% verkleinerst, nehme ich Dir dann aber uebel. Das ist fuer laengere Texte absolut nicht akzeptabel. Das letter-spacing macht die Sache nicht besser. Das ist zwar nicht ganz so schlimm wie die Schriftverkleinerung, aber fuer Fliesstext ist davon generell abzuraten.
Die Ueberschriften wuerde ich nicht in der Art "Die Lösung, erster Versuch: ..." nennen, sondern nur "Erster Versuch: ...". Entsprechend beim zweiten Versuch. Es gibt naemlich viele Leute da draussen, die Probleme beim Erfassen laengerer texte haben, und wenn die gleich in der Ueberschrift "Loesung" lesen, kopieren die einfach die erste Code-Zeile raus und Du hast nichts gekonnt.
Besonders gefaellt mir auch der Absatz ueber die "Zurschaustellung von möglicherweise geheucheltem Problembewusstsein" ;-)
So long
--
Discovering the usefulness of the "command.com" shell on Windows 9x is left as an exercise to the reader :)
-- from Perl's README.win32 file-
Hallo, Calocybe,
Bin begeistert, muss ich sagen. In klarem Deutsch geschriebener Text (ok, ein paar Rechtschreibfehler sind drin), der das Problem genau richtig angeht.
Freut mich. :) Wäre nett, wenn du mir schwerwiegende Fehler, die die aufgefallen sind, mailen könntest. Denn entweder finde ich sie nicht (nie), weil ich sie übersehe oder ich bin mir dessen nicht bewusst, was auf das Gleiche herauskommt.
Und komme mir nicht mit Groß/Kleinschreibung, die neue Rechtschreibung legitimiert jede Abweichung von der Regel. ;) Oft können wie gesagt Tippfehler oder HTML Entity-Murks auftreten.Nur solltest Du vielleicht noch unterbringen, dass man die Popups, wenn man es denn nicht lassen kann, wenigstens resizable und mit Scrollbar machen soll.
Ist notiert und ich werde den Hinweis aufgreifen und mit einbeziehen.
Apropos Schriftgroesse, dass Du diese einfach auf 80% verkleinerst, nehme ich Dir dann aber uebel. Das ist fuer laengere Texte absolut nicht akzeptabel. Das letter-spacing macht die Sache nicht besser. Das ist zwar nicht ganz so schlimm wie die Schriftverkleinerung, aber fuer Fliesstext ist davon generell abzuraten.
Ja, dieses Problem belastet schon seit geraumer Zeit mein Gewissen, das nehme ich mir selbst schon fast übel. Für Fließtext sollte man die Schriftgröße 1em benutzen, also die Browservorgabe, die der Benutzer als Maßstab festgelegt hat, das ist gewiss.
Das letter-spacing sollte eigentlich nur das Schriftbild auflockern und den Text "öffnen", also den Grauwert erhellen, nicht die kleinere Schriftgröße kompensieren... Wie du siehst, habe ich eine kuriose Einheit für das letter-spacing benutzt: 1px, denn 0.05em o.ä. schien mir unpassend und funktioniert nur auf ausgewählten Browsern, und prozentuale Angaben unterstützt kein Browser, bin mir nichtmal sicher ob sie in diesem Falle erlaubt sind.
Mal im Ernst, hast du das mit den 80% gemerkt, weil die Schrift dir zu klein und unleserlich/augenstrapazierend erschien oder weil du es im Code gelesen hast...? Vielleicht erklären folgende Erläuterungen etwas mein Anliegen.Erst einmal ist der ganze Spuk nur für grafische Browser; indem ich CSS, am besten extern, benutze, sind grundlegende Probleme der Interoperabilität und Zugänglichkeit erst einmal gelöst, denn jede CSS-Formatierung ist optional und soll nur die logische Strukturierung hervorheben. Selbst wenn ich komplizierte Navigationen mit CSS spinne, müssten sie auch ohne Stylesheets problemlos benutzbar sein. Meist spiele ich mit durch CSS versteckten Seiteninhalten, beispielsweise Trennzeichen zwischen Links, wenn du die WCAG kennst, weißt du wovon ich spreche.
IMHO ist es unter anderem ein "Problem" der benutzten Schriftarten. Natürlich programmiert man nur nach Schriftarttypen (serif, sans-serif, monospace, fantasy etc.), aber ich möchte zur typographischen Gestaltung die Schriftart Verdana nicht missen, ich finde sie lesbar und einfach "ästhetisch". (Arial/sans-serif finde ich hingegen viel zu steril und Times New Roman/serif erscheint mir oft charakterlos, als hätte man die Schriftart nicht bewusst gewählt, als wäre sie nur default-Einstellung und nicht Teil der Komposition, auch wenn sie sich für Fließtext geradezu anbietet aufgrund ihrer Lesbarkeit.)
Dies ist ein optionales Feature meiner Seiten, was bei einer großen Mehrheit der Benutzer funktioniert, denn sie nutzen Windows und Verdana ist installiert. Die Benutzbarkeit meiner Seiten schränkt es sicher nicht ein, wenn diese Schriftart nicht vorhanden ist - oder doch?Als den Seitencharakter prägendes Gestaltungselement wirft es jedoch das Problem auf, dass Verdana eine im Vergleich zu den Schriftarttypen, welche als Ersatz auf Nicht-Windows-Systemen eingesetzt werden, andere Größenrelation hat. D.h. der Platz, den ein Zeichen bei gleicher Schriftgröße in Times New Roman, Arial und Verdana einnimmt, ist völlig unterschiedlich, ebenso das Verhältnis von Buchstabenbreite und Buchstabenhöhe. Deswegen nutze ich den Workaround Schriftgröße 0.8em für Fließtext (p, ol, ul, dl etc.) nur, um die vergleichsweise wuchtige Schriftart Verdana so zu verkleinern, dass sie ungefähr bei 80%iger Größe der 100%igen Größe anderer Schriftarten bei gleicher Schriftgröße entspricht. Nur so kann ich auf einem durchschnittlichen Bildschirm die gewünschten Informationen präsentieren. Bei einem simplen "hängenden" Layout wie beim Howto kann man das natürlich noch eventuell vernachlässigen.
Irgendwann ist meines Erachtens das Argument der grenzenlosen Skalierbarkeit in alle Richtungen ausgereizt, nämlich wenn es um komplexere Layouts und deren Benutzbarkeit geht. Angenommen man hat die Voraussetzungen 640x480 Pixel Bildschirmauflösung (eingeschränkt durch Menü-, Symbol- und Adressleisten) und 12pt entspricht 1em (bei 96 dpi). Wenn man nun ein Layout wie folgendes http://home.t-online.de/home/dj5nu/sterne.html etablieren möchte, dann muss man (der Seitenautor) ggf. die Schriftgröße anpassen (!=1em), damit man überhaupt Navigation/Inhaltsverzeichnis und Seiteninhalt nebeneinander darstellen kann. (Dies gilt insbesondere wenn man Verdana als dominierenden Schrifttyp benutzt, was im Beispiel für mich eigentlich der Hauptgrund war.)
Schlimm, aber wahr; ich möchte behaupten, dass aus gleichem Grund 90% der Webseiten einerseits immer kleinere Schriftgrößen benutzen als die Benutzervorgabe, nämlich oft 8-10pt für Fließtext und dass dies andererseits zusammengeschüttelt mit Tabellenlayout einen lethalen Cocktail für die Skalierbarkeit darstellt. Dennoch hat dieses pixelgenaue Layout den Vorteil, dass es durch eine Festbreite von vielleicht 750 Pixeln interoperabler scheint als so manche CSS-Lösung. Da sich die Größenverhältnisse (Text, Bilder) nicht einer Veränderung der Bildschirmauflösung anpassen, scheitert jeder Versuch von Komposition schon im Ansatz. Schließlich gibt es keine Schriftgrößeneinheit für Prozent der Fensterbreite usw.
Da fällt mir nur so ein automatischer Javascript-Zoom ein, der beim IE den Fensterinhalt an die Fenstergröße anpasst über die proprietäre CSS-Eigenschaft zoom.Denn wie kann ich feststellen, ob der Text XYZ in der Größe 1em und in verschiedenen Schriftarten nicht breiter ist als die Navigationsbox, welche 20% oder meinetwegen 15em breit ist? Wie soll das Layout bei gleichbleibender em-Vorgabe, aber kleiner oder größer werdender Bildschirmauflösung funktionieren? Richtig, die Lösung ist: man arbeitet wieder mit absoluten Angaben, aber dann könnten wir auch wieder mit Tabellenlayout anfangen, oder noch besser, Frames. Denn das skaliert so wie Opera Seiten vergrößert.
Da ich in einem CSS-Layout nur mit relativen Angaben wie em oder Prozent arbeiten kann, muss ich die Schrift so zusammenstauchen, dass sie - unter besonderer Berücksichtigen der gewählten Schriftart das Layout nicht sprengt, was in einem gewissen Sinne feststehend sein muss.
Ich sehe da keine Möglichkeit, dem Teufelskreis zu entrinnen. :) Bisher bin ich durch die wirklich Geheimnisse des CSS-Layouts eingestiegen, d.h. ich habe es nie perfekt hinbekommen.
Ich habe Probleme damit, zu einem Tabellenlayout (nicht statisch) ein CSS-Äquivalent zu erstellen, bei dem die Vorteile im Bezug auf klare und interoperable Seitenstrukturierung gegenüber der Tabellenversion überwiegen.(Das sollte alles nicht rechtfertigen, ich werde die Schriftgröße trotz Verdana auf 1em setzen.)
Die Ueberschriften wuerde ich nicht in der Art "Die Lösung, erster Versuch: ..." nennen [...]
Verstehe schon, hatte ich auch geplant. Gerade fiel mir beim Formulieren des Inhaltsverzeichnissen auf, dass die Überschriften doch eindeutiger sein sollten, damit die Struktur klarer wird.
Besonders gefaellt mir auch der Absatz ueber die "Zurschaustellung von möglicherweise geheucheltem Problembewusstsein" ;-)
Hoffentlich versteht man, was ich meine. Ich finde solche Hinweise ansonsten völlig albern, aber "man will ja niemanden auf die Füße treten" - für mich ist das fast schon die höchste Stufe des P.C.-Alarms. Wer glaubt, man könne durch Anhängen von "Innen" an Wörter patriarchalische Strukturen zerschlagen, beruhigt und betrügt sich nur selbst - oder will andere beindrucken. Deswegen "möglicherweise geheuchelt". Wenn der erste "Sexist" schreit, kichere ich mir amüsiert, aber auch enttäuscht-seufzend, ins Fäustchen.
Mathias
-
Hallo, Calocybe,
Ich bin's nochmal.
D.h. der Platz, den ein Zeichen bei gleicher Schriftgröße in Times New Roman, Arial und Verdana einnimmt, ist völlig unterschiedlich, ebenso das Verhältnis von Buchstabenbreite und Buchstabenhöhe.
Habe gerade gefunden: http://www.w3.org/TR/REC-CSS2/fonts.html#propdef-font-size-adjust
Das Problem ist also allgemein bekannt und Abhilfe steht schon seit vier Jahren im Standard, aber scheinbar unterstützt kein moderner Browser das Attribut.Mathias
-
Moin moin!
Freut mich. :) Wäre nett, wenn du mir schwerwiegende Fehler, die die aufgefallen sind, mailen könntest. Denn entweder finde ich sie nicht (nie), weil ich sie übersehe oder ich bin mir dessen nicht bewusst, was auf das Gleiche herauskommt.
Michael hat sich dessen ja zum Glueck schon angenommen. *g*
Das letter-spacing sollte eigentlich nur das Schriftbild auflockern und den Text "öffnen", also den Grauwert erhellen, nicht die kleinere Schriftgröße kompensieren...
Schon klar, war auch nicht so gemeint. Da ist die Rhetorik daneben gegangen. *g*
Ich weiss, dass das besser aussieht. Wenn es normalen Text nicht schwerer lesbar machen wuerde, wuerde ich es auch so einsetzen.Wie du siehst, habe ich eine kuriose Einheit für das letter-spacing benutzt: 1px, denn 0.05em o.ä. schien mir unpassend und funktioniert nur auf ausgewählten Browsern, und prozentuale Angaben unterstützt kein Browser, bin mir nichtmal sicher ob sie in diesem Falle erlaubt sind.
Das ist fuer ein Screenlayout auch sicherlich nicht verkehrt. 1px ist normalerweise fuer alle Fontgroessen gut, die man fuer Fliesstext so findet. %-Angaben sind da uebrigens nicht erlaubt.
Mal im Ernst, hast du das mit den 80% gemerkt, weil die Schrift dir zu klein und unleserlich/augenstrapazierend erschien oder weil du es im Code gelesen hast...?
Ersteres. Die genaue Zahl hab ich dann natuerlich noch im Code nachgelesen.
Erst einmal ist der ganze Spuk nur für grafische Browser;
Da faellt mir ein, Dir fehlt definitiv noch ein MEDIA="screen" im <LINK> oder ein @media screen { } im Stylesheet. ;-)
IMHO ist es unter anderem ein "Problem" der benutzten Schriftarten. Natürlich programmiert man nur nach Schriftarttypen (serif, sans-serif, monospace, fantasy etc.), aber ich möchte zur typographischen Gestaltung die Schriftart Verdana nicht missen, ich finde sie lesbar und einfach "ästhetisch". (Arial/sans-serif finde ich hingegen viel zu steril und Times New Roman/serif erscheint mir oft charakterlos, als hätte man die Schriftart nicht bewusst gewählt, als wäre sie nur default-Einstellung und nicht Teil der Komposition, auch wenn sie sich für Fließtext geradezu anbietet aufgrund ihrer Lesbarkeit.)
Verdana ist tatsaechlich eine der am besten lesbaren Bildschirmschriftarten. Sie wurde naemlich speziell dafuer entwickelt. Und deshalb ist es auch meine eingestellte Praeferenz.
Dies ist ein optionales Feature meiner Seiten, was bei einer großen Mehrheit der Benutzer funktioniert, denn sie nutzen Windows und Verdana ist installiert. Die Benutzbarkeit meiner Seiten schränkt es sicher nicht ein, wenn diese Schriftart nicht vorhanden ist - oder doch?
Noe noe, solange das sans-serif noch als Fallback dasteht, ist alles prima. ... Ausser bei denen, die Times New Roman so geil finden, dass sie es ueberall auf ihrem Bildschirm sehen wollen. ;-)
Wenn Du Deinem <LINK>-Element noch ein TITLE-Attribut mitgibst, ist es uebrigens fuer Mozilla-Benutzer sehr einfach, dieses abzuwaehlen, wenn es ihnen gar zu sehr auf den Sack geht. (Falls Du Mozilla hast, kannst Du Dir das mal auf der oben verlinkten Seite ansehen. Da hab ich auch gleich noch mit ein paar alternativen Stylesheets experimentiert.)
Als den Seitencharakter prägendes Gestaltungselement wirft es jedoch das Problem auf, dass Verdana eine im Vergleich zu den Schriftarttypen, welche als Ersatz auf Nicht-Windows-Systemen eingesetzt werden, andere Größenrelation hat. D.h. der Platz, den ein Zeichen bei gleicher Schriftgröße in Times New Roman, Arial und Verdana einnimmt, ist völlig unterschiedlich, ebenso das Verhältnis von Buchstabenbreite und Buchstabenhöhe. Deswegen nutze ich den Workaround Schriftgröße 0.8em für Fließtext (p, ol, ul, dl etc.) nur, um die vergleichsweise wuchtige Schriftart Verdana so zu verkleinern, dass sie ungefähr bei 80%iger Größe der 100%igen Größe anderer Schriftarten bei gleicher Schriftgröße entspricht.
Wenn ich das richtig verstehe, gehst Du dabei aber davon aus, dass alle ihre Browser so eingestellt haben, dass sie serif bei 1em gut lesen koennen. Das kannst Du aber wirklich nicht voraussetzen. Viele Leute stellen tatsaechlich eine sans-serif-Schriftart ein, diese dann aber entsprechend kleiner (ich z.B. Verdana/13px). Times New Roman kann ich bei 13px aber nicht mehr (angemessen fliessend) lesen. Deswegen filtere ich wenigstens schon alle <FONT FACE> Anweisungen aus (manche sind so dreist und setzen gleich noch ein SIZE="-1" dazu!), bei Verwendung von CSS nuetzt mir das nur nichts (dafuer habe ich ein Bookmarklet, das mir alle externen Stylesheets abschaltet).
Das Problem der unterschiedlichen wirklichen Schriftgroessen bei gleicher font-size kenne ich auch. Und so wie ich font-size-adjust verstanden habe, ist das nur fuer den Fall gedacht, wenn mehrere Schriftarten in font-family angegeben sind und die erste nicht verfuegbar ist. Hier ist aber das Problem, dass man eine von der Benutzereinstellung abweichende Schriftart waehlt (oder auch nicht - weiss man ja dummerweise noch nicht mal). Und da steht CSS gegenwaertig noch voellig auf dem Schlauch.
Eine Loesung waere vielleicht, etwas wie apparent-font-size einzufuehren und darueberhinaus in den Browsereinstellungen Defaultgroessen fuer jede generische Schriftfamilie festlegen zu lassen (denn serif und sans-serif lassen sich bei auch bei korrigierter font-size noch unterschiedlich gut lesen), und fuer jede generische Familie unterschiedlich einen unterschiedlichen Ausgangspunkt dafuer zu setzen, was 1em meint. Ist wohl ein ziemlich komplexes Thema, und eigentlich hab ich auch gar keine Ahnung von Typesetting. *g* Weiss nicht, ob die sich fuer CSS3 was zu dem Thema ausdenken.
Irgendwann ist meines Erachtens das Argument der grenzenlosen Skalierbarkeit in alle Richtungen ausgereizt, nämlich wenn es um komplexere Layouts und deren Benutzbarkeit geht. Angenommen man hat die Voraussetzungen 640x480 Pixel Bildschirmauflösung (eingeschränkt durch Menü-, Symbol- und Adressleisten) und 12pt entspricht 1em (bei 96 dpi). Wenn man nun ein Layout wie folgendes http://home.t-online.de/home/dj5nu/sterne.html etablieren möchte, dann muss man (der Seitenautor) ggf. die Schriftgröße anpassen (!=1em), damit man überhaupt Navigation/Inhaltsverzeichnis und Seiteninhalt nebeneinander darstellen kann. (Dies gilt insbesondere wenn man Verdana als dominierenden Schrifttyp benutzt, was im Beispiel für mich eigentlich der Hauptgrund war.)
Durchgestyltes Design steht letztlich einfach im Widerspruch zur Ruecksicht auf die Benutzerpraeferenzen (siehe auch http://www.cs.tut.fi/~jkorpela/styles/harmful.html). Man kann mit CSS bis zu einem gewissen Grad beides unter einen Hut bringen, aber irgendwo ist eine Grenze. Wenn eine Designidee diese Grenze ueberschreitet, muss man sich wohl entscheiden. Damit meine ich vor allem, dass man hinter dieser Grenze 'em' *nicht mehr* benutzen sollte, um sich auf die Benutzereinstellungen zu beziehen, denn damit impliziert man eine Annahme ueber die beim Benutzer eingestellte Defaultschrift(art|groesse), und diese Vermutung ist einfach nicht gerechtfertigt.
Dann ist es an der Zeit, 'px' zu benutzen. Das hat natuerlich den Nachteil, dass diejenigen, die ihre Schrift absichtlich auf 20px eingestellt haben, weil sie halt auch ohne Brille mal am PC sitzen wollen oder was weiss ich, mit den z.B. 13px eines bestimmten Designs nicht mehr klar kommen. IMHO impliziert das Festlegen der Groesse auf diese Art auch tatsaechlich die Aussage, dass dem Autor sein Design wichtiger ist als der Komfort des Besuchers. Nun ja, das muss jeder fuer sich selbst entscheiden.
Vielleicht gehst Du auch den Weg, alternative Stylesheets anzubieten, um den Benutzern, die so gar nichts mit Deinem Design anfangen koennen, eine weniger offensive Variante zu bieten. Hat leider den Nachteil, dass zum Zeitpunkt Mozilla meines Wissens der einzige Browser ist, der der Spec in diesem Punkt nachkommt.
Schlimm, aber wahr; ich möchte behaupten, dass aus gleichem Grund 90% der Webseiten einerseits immer kleinere Schriftgrößen benutzen als die Benutzervorgabe, nämlich oft 8-10pt für Fließtext
IMHO machen die das, weil der IE in der Defaulteinstellung die Schrift viel zu gross macht (fuer den durchschnittlichen Surfer) und deswegen alle glauben, man muesse die Schriftgroesse grundsaetzlich erstmal eine Stufe runterregeln.
Ich sehe da keine Möglichkeit, dem Teufelskreis zu entrinnen. :)
Zwischen den Zeilen habe ich wohl anklingen lassen, dass ich CSS nicht fuer so wirklich ausgereift halte. ;-)
Hoffentlich versteht man, was ich meine. Ich finde solche Hinweise ansonsten völlig albern, aber "man will ja niemanden auf die Füße treten" - für mich ist das fast schon die höchste Stufe des P.C.-Alarms. Wer glaubt, man könne durch Anhängen von "Innen" an Wörter patriarchalische Strukturen zerschlagen, beruhigt und betrügt sich nur selbst - oder will andere beindrucken. Deswegen "möglicherweise geheuchelt".
Es geht ja die Vermutung um, dass gerade die, die in dieser Sache uebermaeszig p.c. sind und immer fleissig ihren Text verunstalten, oftmals in Kopf ein besonders grosses Problem mit der Emanzipation haben.
So long
--
Falscher oder fehlender Kaffee. Benutzer angehalten.-
Hallo, Roland!
[...]
Dies ist ein optionales Feature meiner Seiten [...] Die Benutzbarkeit meiner Seiten schränkt es sicher nicht ein, wenn diese Schriftart nicht vorhanden ist - oder doch? Noe noe, solange das sans-serif noch als Fallback dasteht, ist alles prima.
Das sollte eigentlich keine Frage sein bzw. eine argumentative Frage, denn im nächsten Absatz wollte ich beweisen, warum das eventuell entgegen der Annahme problematisch sein könnte. :) Denn wenn ich 0.8em für Verdana-Fließtext benutze, um der Schrift die gleiche Größe wie bei Arial/Helvetica 1em zu geben, ist es schon ein Problem, wenn der Benutzer Verdana nicht hat, dann kann $user den Text eventuell nicht lesen, weil er nicht so eine wuchtige Schrift wie Verdana nicht hat. [...]
Wenn Du Deinem <LINK>-Element noch ein TITLE-Attribut mitgibst, ist es uebrigens fuer Mozilla-Benutzer sehr einfach, dieses abzuwaehlen, wenn es ihnen gar zu sehr auf den Sack geht.
[...] Ich wollte sowieso dem Benutzer die Wahl des Stylesheets überlassen, erst recht wenn ich eines Tages auf einen PHP-/Perl-fähigen Netzspeicherplatz wechsle. [...]
Clientseitig habe ich das schon ein wenig erprobt... http://home.t-online.de/home/dj5nu/js-dom-nodelisting.html Aber du kannst dir denken, was ich von JavaScript-Lösungen halte.
Was hältst du/was haltet ihr eigentlich davon, die Textbreite zu begrenzen? [...] Natürlich trägt eine begrenzte Spaltenbreite enorm zur Lesbarkeit dar, aber wie wir festgestellt haben, kann man nicht von der Breite Xem darauf schließen, wieviel Text denn im Endeffekt beim Benutzer in einer Zeile angezeigt wird.
[...] Deshalb hatte ich immer zu Ungunsten mancher Benutzer, welche hohe Bildschirmauflösungen gebrauchen, keine direkte Begrenzung der Fließtextbreite angegeben (nur eine indirekte, also bspw. 80% Textbreite da 20% die feste Navigation ausmacht usw.). Dadurch können im schlimmsten Fall über 200 Zeichen in einer Zeile zu finden sein, was grausig zu lesen ist.
Die Alternative ist natürlich, vor vornherein mit Pixeln zu arbeiten. [...] Eine feste Spaltenbreite von circa 600px für @media screen erscheint mir für den Fall sogar das einzig Sinnvolle [...].
Wenn ich das richtig verstehe, gehst Du dabei aber davon aus, dass alle ihre Browser so eingestellt haben, dass sie serif bei 1em gut lesen koennen. Das kannst Du aber wirklich nicht voraussetzen.
Ehm, nein, so war das nicht direkt gemeint; aber wenn du fragst, ob ich davon ausgehe, dass beim Benutzer 1em großer Fließtext (unabhängig vom Schrifttyp) generell lesbar ist, dann würde ich mit "ja, aber" antworten. (Irgendwas muss ich voraussetzen [...].)
Deswegen filtere ich wenigstens schon alle <FONT FACE> Anweisungen aus (manche sind so dreist und setzen gleich noch ein SIZE="-1" dazu!), bei Verwendung von CSS nuetzt mir das nur nichts (dafuer habe ich ein Bookmarklet, das mir alle externen Stylesheets abschaltet).
In Opera huschen meine Fingerchen deswegen immer über [ctrl] und/oder [g].
Durchgestyltes Design steht letztlich einfach im Widerspruch zur Ruecksicht auf die Benutzerpraeferenzen (siehe auch http://www.cs.tut.fi/~jkorpela/styles/harmful.html). Man kann mit CSS bis zu einem gewissen Grad beides unter einen Hut bringen, aber irgendwo ist eine Grenze. Wenn eine Designidee diese Grenze ueberschreitet, muss man sich wohl entscheiden.
Als ein mich als verantwortungsbewusst nennender Seitenautor :) plädiere ich grundsätzlich dafür, trotz dieser Unvereinbarkeit die Gratwanderung zu versuchen, jedem Benutzer eine problemlos und gleichzeitig ansehnliche und individuell gestaltete Seite zu bieten. Wenn ich beispielsweise extensiv CSS nutze, damit ich dem Benutzer Navigation und Inhaltsverzeichnis fest auf dem Bildschirm verankern kann, dann ist der Nutzen davon in erster Linie die gesteigerte Benutzbarkeit.
Die radikale Sicht von Jukka Korpela, dass alleinig der Nutzer über die endgültige Präsentation der Seite haben soll, kann ich nicht verstehen. Für mich ist die individuelle Gestaltung einer Seite ebenso prägend wie deren Inhalte.
Der Essay ist mir ein wenig zu abstrakt und unverständlich um einige Kritikpunkte nachvollziehen zu können. [...] Zugegeben kenne ich nur CSS als Stylesprache, weshalb es sicher bessere Alternativen geben kann, ohne dass ich es mir vorstellen kann. Ich als Nutzer empfinde CSS als relativ einfach zu erlernen und trotzdem enorm leistungsstark. Mit einem Repertoire an einer Handvoll CSS-Eigenschaften kann man schon anspruchsvolle Designs erstellen. Das Einarbeiten in komplexere CSS-Syntax geht meiner Meinung nach auch problemlos.
Natürlich kann man Styles auch missbrauchen, das ist klar, aber ich denke, so wie ich es nutze, nämlich um die HTML-Struktur zu unterstreichen (von mir verfasste Seiten sind meist massiv inhaltslastig), kann es nur sinnvoll sein.
<q>It seems that the current style sheet model provides no easy way to formulate practical rules in order to avoid such conflicts.</q> (Ende Absatz "The incompleteness of the specification", es geht ungefähr um die Unvereinbarkeit von Benutzer- und Autorenstylesheets) Das sagt genau das aus, was du meintest, dem stimme ich auch vollkommen zu, ich würde es jedoch nicht unbedingt als Problem sehen, sicher kann es problematisch werden. Es ist die Aufgabe der Autoren und der Benutzeragenten, Autoren- und Benuutzerinteressen vereinbar zu machen.
Man kann den Autor nicht durch die Verabschiedung von Technologien lenken, die ihn nur einschränken. So etwas führt zu der Verbreitung unfreier, proprietärer Technologien. HTML ist eines von wenigen plattformunabhängigen, offenen Formaten mit einer Macht, die es auszubauen gilt.
Jukka Korpela fordert simple Stylesheets und indirekt eine Vereinfachung von CSS hin zu einer streng markupunterstützenden Stylesprache. Es wird auch auf Schwächen von HTML eingegangen, also dass es oft zur Strukturierung unbrauchbar ist. Sicher hat auch einerseits die HTML-Spezifikation Lücken und manchmal schlägt HTML zur adäquaten logischen Strukturierung fehl, andererseits unterstützen oft wenige Browser eine angemessene Visualisierung logischer Elemente. Die Definition mancher Tags ist missverständlich (http://www.w3.org/TR/html401/struct/text.html#edef-STRONG) und bspw. abbr und acronym werden erst seit kurzem im Mozilla per default visualisiert.
Insgesamt finde ich nicht, dass die CSS-Spezifikation dieses Problem der Unvereinbarkeit von Autor- und Leserinteressen auslöst. Im Gegensatz, sie kann durch strikte Trennung von Struktur und Präsentation sogar dazu beitragen, dass der Benutzer einfacher das Autorenstylesheet und somit alle unnötigen Formatierungen zugunsten der selbstgewählten Styles abschalten kann. [...] Wenn man ihn eine einfach gehaltenen Stylesprache vorsetzt, verübt er wieder Verbrechen an der Menschlichkeit durch Tabellenlayout und font-Tags, damit die Seite einigermaßen aussieht.
<q>The common idea of designing Web pages with newspaper-like format is therefore inherently archaic</q>
Natürlich, keine Einwände. Aber bitte, man mache die Augen auf, das Web ist dominiert von pixelgenauem, perfektem Layout, auf dass der Benutzer keinen Einfluss hat. Man kann dies nicht verändern, indem man Standards herausgibt, die dies verbieten. Es gibt ein Verlangen nach Seiten mit perfektem Aussehen [...].
<q>...careful and detailed design of layout is not only unnecessary but also harmful</q>
Dass Webseiten gestalterisch anspruchsvoll und gutaussehend sein wollen, finde ich gut und richtig. So wie Herr Korpela seine Vision (Utopie?) beschreibt, gelingt es ihm nicht, abzustreiten, dass er nicht von layoutlosen, langweiligen und hässlichen Seiten schwärmt. Der Benutzer wird sich im Endeffekt gegen die Seiten entscheiden, die Korpela als benutzerfreundlich bezeichnen würde.
<q>...it should be regarded as a relief that the author neither can nor need care about presentation issues.</q>
Ach was - imho hat ein Netzautors gleichzeitig die Rolle des Designers, der gestalterische Mittel nutzt, um dem Leser (Betrachter) der Netzseite die Informationen ansprechend und interessant zu vermitteln [...].
<q>author's dominance over presentation</q>
Heutzutage bestimmt diese Art des "Webdesigns" das komplette Netz. Bis auf ein paar Idealisten, Träumer und Styleindividualisten ("wir") verfasst niemand mit HTML logisch strukturierte Webseiten. Diese Tendenz kann man nicht stoppen, indem man sie beweint oder verbieten will, sondern indem man sinnvollere Alternativen aufzeigt.
Insofern missachtet Jukka Korpela die Realität (vgl. auch Publishing on the Web Is Different (http://www.cs.tut.fi/~jkorpela/webpub.html). Denn diese zeigt, dass die Entwicklung des Netzes anders verlief und sich die Praxis der alten Medien auch so auf das Netz übertragen hat [...]. HTML wird nicht so eingesetzt, wie es von den Erfindern gedacht war, [...] diese Entwicklung [war] voraussehbar; Browserhersteller implementierten Features in ihre Software, [...] die das W3C nur halbherzig und aus Zwang in den Standard übernahm. Das Web wurde m.E. erst dadurch populär, dass HTML missbraucht wurde [...]. Mit HTML 3.2 ohne font und Tabellen konnte man keine für den Leser ansprechende Webseiten gestalten. Erst durch die massive Unterstützung von CSS durch die Benutzeragenten ist es überhaupt möglich, grafisch hochwertige Netzseiten für Bildschirmausgabegeräte zu verfassen, welchen strukturierendes HTML zugrunde liegt.
Ich finde es einfach blind, dass Herr Korpela diesen "Fortschritt" bei der Gestaltung von Netzseiten (wenn auch mit den falschen Mitteln) vereitelt und als archaisch und rückschrittig bezeichnet [...]. Jeder wirft jedem vor, die Idee des Webs/die Idee von HTML falsch verstanden zu haben und es zu missbrauchen. [...] [Es] wird sofort klar, welche Fraktion sich durchgesetzt hat und vor allem welche Webseiten den Besuchern gefallen.
Wer heutzutage Netzseiten mit den dazu richtigen Werkzeugen gestaltet (CSS), schießt sich nur selber ins Knie, da die auf Bildschirmpräsentation gemünzten (geMÜNZten?) Gestaltungsstrukturen einfacher und interoperabler mit Tabellenlayout und Frames realisierbar sind. Es nützt beinahe gar nichts, wenn man dem Autor diese Layouttechniken verbietet und als nonkonform brandmarkt (dass damit gebaute Seiten technischer Quark sind, ist offensichtlich). Mit der Einstellung wird auch in den nächsten 10 Jahren niemand Netzseiten in XHTML Strict verfassen. [...] Wohl die wenigsten werden auf Stylesheets umsteigen, um sich selbst einzuschränken, weil sie plötzlich so gut zum Benutzer sein wollen. Bei jeder Liebe und Verständnis zum Sinn und Zweck von HTML - die "Entwicklung" darf auf keinen Fall heißen, dass sich die 10 Jahre alte Entwicklung des Webs zurückgeworfen wird, wenn Entwicklung hier sicher nicht nur Fortschritt bedeutete.
IMHO impliziert das Festlegen der Groesse auf diese Art auch tatsaechlich die Aussage, dass dem Autor sein Design wichtiger ist als der Komfort des Besuchers.
[...] Diejenigen Autoren, die sich überhaupt Gedanken darum machen, dass der Benutzer ein Mitspracherecht [...] hat, dürften wohl einen sehr geringen Prozentsatz ausmachen. Diejenigen Nutzer, die Seiten nach ihrem Belieben rendern lassen [...] gehören ebenfalls einer Minderheit an. Die Nutzergruppe, die einfach nur cool gestylte Seiten will [...] ist klar dominierend, vor allem weil sie daran gewöhnt ist.
Zwischen den Zeilen habe ich wohl anklingen lassen, dass ich CSS nicht fuer so wirklich ausgereift halte. ;-)
Ausgereift für was? Sicherlich ist es nicht dafür ausgereift, um die gestalterische Vielfalt, die man durch (schwachsinnige) Nutzung von HTML erreichen kann, durch CSS zu ersetzen. [...]
(Nachricht war zu lang, ich musste massiv kürzen. Hoffe einiges bliebt verständlich.)
Mathias
-
Aeh... verdammt, ich wollte doch eigentlich heute frueh gleich nach dem Aufstehen antworten, und jetzt hab' ich's total vergessen. Daher muss ich mal entgegen jedweder Regel ein kleines Threadverlaengerungsposting machen, damit ich die Antwort noch *morgen* frueh schreiben kann. Man moege mir die Unflaetigkeit verzeihen. *g*
So long
-
Moin moin!
Wenn Du Deinem <LINK>-Element noch ein TITLE-Attribut mitgibst, ist es uebrigens fuer Mozilla-Benutzer sehr einfach, dieses abzuwaehlen, wenn es ihnen gar zu sehr auf den Sack geht.
[...] Ich wollte sowieso dem Benutzer die Wahl des Stylesheets überlassen, erst recht wenn ich eines Tages auf einen PHP-/Perl-fähigen Netzspeicherplatz wechsle. [...]
Clientseitig habe ich das schon ein wenig erprobt... http://home.t-online.de/home/dj5nu/js-dom-nodelisting.html Aber du kannst dir denken, was ich von JavaScript-Lösungen halte.Ich habe tatsaechlich eher an eine Loesung in JS gedacht. Wer kein JS kann, dem geht ja nichts verloren. Eigentlich muesste der Browser ja ohnehin durch eingebaute Funktionalitaet einen Wechsel des Stylesheets ermoeglichen. Ich wuerde aber via JS noch die Moeglichkeit offerieren, die Wahl in einem Cookie zu speichern.
Was hältst du/was haltet ihr eigentlich davon, die Textbreite zu begrenzen? [...] Natürlich trägt eine begrenzte Spaltenbreite enorm zur Lesbarkeit dar, aber wie wir festgestellt haben, kann man nicht von der Breite Xem darauf schließen, wieviel Text denn im Endeffekt beim Benutzer in einer Zeile angezeigt wird.
[...] Deshalb hatte ich immer zu Ungunsten mancher Benutzer, welche hohe Bildschirmauflösungen gebrauchen, keine direkte Begrenzung der Fließtextbreite angegeben (nur eine indirekte, also bspw. 80% Textbreite da 20% die feste Navigation ausmacht usw.). Dadurch können im schlimmsten Fall über 200 Zeichen in einer Zeile zu finden sein, was grausig zu lesen ist.Orlando und ich hatten vor kurzem den Konsens gebildet, dass der Benutzer sein Browserfenster gewoehnlich so eingestellt hat, dass er eine angenehme Textbreite vorfindet, waehrend noch Platz fuer ein oder zwei Menuespalten an den Raendern ist. Benutzer an sehr grossen Bildschirmen haben nach allgemeiner Auffassung (dieses Forums) ihre Browser praktisch nie im Vollbild. Widersprochen hatte damals keiner. ;-) Ich fahre jedenfalls ganz gut mit meinem etwa 960 Pixel breiten Fenster (rein nach Gefuehl eingestellt). Auf heise.de habe ich eine sehr angenehme Textbreite, hier im Selfforum ist der Text ein bisschen zu breit, aber durchaus noch im vertraeglichen Rahmen.
Die Alternative ist natürlich, vor vornherein mit Pixeln zu arbeiten. [...] Eine feste Spaltenbreite von circa 600px für @media screen erscheint mir für den Fall sogar das einzig Sinnvolle [...].
Wie bei so vielen layout-beeinflussenden Umgebungsvariablen ist wohl auch das Geschmackssache. *g*
Wenn ich das richtig verstehe, gehst Du dabei aber davon aus, dass alle ihre Browser so eingestellt haben, dass sie serif bei 1em gut lesen koennen. Das kannst Du aber wirklich nicht voraussetzen.
Ehm, nein, so war das nicht direkt gemeint; aber wenn du fragst, ob ich davon ausgehe, dass beim Benutzer 1em großer Fließtext (unabhängig vom Schrifttyp) generell lesbar ist, dann würde ich mit "ja, aber" antworten. (Irgendwas muss ich voraussetzen [...].)
Kann man halt aufgrund der unterschiedlichen Lesbarkeit bei gleicher Pixelgroesse nicht. Schade.
Durchgestyltes Design steht letztlich einfach im Widerspruch zur Ruecksicht auf die Benutzerpraeferenzen (siehe auch http://www.cs.tut.fi/~jkorpela/styles/harmful.html). Man kann mit CSS bis zu einem gewissen Grad beides unter einen Hut bringen, aber irgendwo ist eine Grenze. Wenn eine Designidee diese Grenze ueberschreitet, muss man sich wohl entscheiden.
Als ein mich als verantwortungsbewusst nennender Seitenautor :) plädiere ich grundsätzlich dafür, trotz dieser Unvereinbarkeit die Gratwanderung zu versuchen, jedem Benutzer eine problemlos und gleichzeitig ansehnliche und individuell gestaltete Seite zu bieten.
Ja schon, mache ich ja auch. Leider kann man bei einer Gratwanderung auch mal zu einer Seite runterfallen.
Die radikale Sicht von Jukka Korpela, dass alleinig der Nutzer über die endgültige Präsentation der Seite haben soll, kann ich nicht verstehen. Für mich ist die individuelle Gestaltung einer Seite ebenso prägend wie deren Inhalte.
Ich wuerde den Artikel auch nicht 100% fuer mich uebernehmen, ich finde nur, er liefert sehr gute Denkansaetze. Viele waeren nicht nur nicht selber auf solche Ideen gekommen, wie er/sie (?) darin aeussert, sie koennen sich sowas noch nicht mal vorstellen! Dabei muss man doch nur mal ein paar Science-Fiction-Filme/Serien schauen, um Ideen zu bekommen, wo die Entwicklung hingehen koennte.
Ob die Gestaltung einer Seite zum Inhalt gehoert (Chraecker predigt das ja hier immer vehement *g*), kommt imho auch auf die Art der Seite an. Wenn ich z.B. Allerwelttools vorstelle, die ich programmiert habe, wuesste ich nicht, welche Aussage ich da mit einem bestimmten Design noch unterstreichen koennte. Ginge es jedoch um ein Spiel, so soll natuerlich das Design die Atmosphaere dieses Spiels reflektieren. Das finde ich ja auch ok, aber man kann das auch in einer Weise realisieren, ohne dass der Besucher staendig das Gefuehl hat, dass ihn die ganze Zeit jemand mit FUCK YOU von der Seite anbruellt. In dem Paradebeispiel von Jukka, naemlich einer Zeitung, deren Ziel es hauptsaechlich ist, Information zu vermitteln, sehe ich wiederum auch keinen Sinn in einer uebersteigerten Wertbetonung eines bestimmtes Layouts (das sich obendrein oft nach traditionellen Paradigmen aus dem Printbereich richtet, die fuer das Web kaum zu uebernehmen sind).
Also kurzum: Kommt drauf an, naemlich auf die Art der Seite.
Ich als Nutzer empfinde CSS als relativ einfach zu erlernen und trotzdem enorm leistungsstark. Mit einem Repertoire an einer Handvoll CSS-Eigenschaften kann man schon anspruchsvolle Designs erstellen. Das Einarbeiten in komplexere CSS-Syntax geht meiner Meinung nach auch problemlos.
Leistungsstark, um ein vorgegebenes Design/Layout umzusetzen, ja. Aber nicht um Autorenvorgaben und Benutzerwuensche halbwegs friedfertig unter einen Hut zu kriegen. Dafuer ist es voellig untauglich.
Nehmen wir mal mich: Ich kann weiss als Hintergrundfarbe nicht ausstehen, weil es durch die grosse Helligkeit die Augen ueber Gebuehr beansprucht und extrem schnell zur Ermuedung fuehrt. Nun kann ich zwar mit einem geeigneten UA (User Agent) ein Benutzerstylesheet definieren, in dem ich meine praeferierte Hintergrundfarbe mit !important kennzeichne. Aber damit mache ich jeglichen Override von Seiten des Autors unmoeglich, was ich gar nicht will. Viele Seite haben durchaus angenehme Hintergrundfarben gewaehlt. Ich will nur gerne alles ueber einem gewissen Helligkeitslevel ausblenden. Kriege ich mit CSS aber nicht hin.
Und wenn ich jetzt als Autor aufgrund dieser Erkenntnis soweit gehe, auf meinen eigenen Seiten keine globalen Farbvorgaben zu machen, sondern die Benutzereinstellungen zu respektieren, aber gerne so wie Du gewisse Strukturelemente oder vielleicht ein zur Seite positioniertes DIV durch Hintergrundfarben deutlicher hervorheben will, dann habe ich mit CSS keine Chance. Man braeuchte eine Moeglichkeit, so etwas wie "relative" Farbangaben zu machen, also z.B. im Vergleich zur eingestellten Hintergrundfarbe einen Bereich etwas gruener oder etwas heller zu machen. In CSS dagegen muss ich mit festen Farben arbeiten. Entweder ganz oder gar nicht. Zu Recht beschwert sich der Validator z.B. auch wenn ich eine Vordergrundfarbe angebe, ohne auch die Hintergundfarbe zu spezifizieren.
Dies sind nur meine beiden brennensten Probleme.
<q>It seems that the current style sheet model provides no easy way to formulate practical rules in order to avoid such conflicts.</q> (Ende Absatz "The incompleteness of the specification", es geht ungefähr um die Unvereinbarkeit von Benutzer- und Autorenstylesheets)
Das sagt genau das aus, was du meintest, dem stimme ich auch vollkommen zu, ich würde es jedoch nicht unbedingt als Problem sehen, sicher kann es problematisch werden. Es ist die Aufgabe der Autoren und der Benutzeragenten, Autoren- und Benuutzerinteressen vereinbar zu machen.Solange man CSS benutzt, wird da leider der beste UA nicht viel machen koennen.
Versteh' mich nicht falsch, ich will auf keinen Fall CSS gleich wieder abschaffen, und ne bessere Moeglichkeit faellt mir auf Anhieb auch nicht ein. Ich finde es auch wichtig fuer den Fortschritt des WWW als Wissenspool, der eine strikte Trennung von Inhalt und Design zur elementaren Voraussetzung macht (und genau das wird ja durch CSS gefoerdert). Nur ist es halt noch lange nicht der Weisheit letzter Schluss.
Man kann den Autor nicht durch die Verabschiedung von Technologien lenken, die ihn nur einschränken. So etwas führt zu der Verbreitung unfreier, proprietärer Technologien.
Ja, sicher, das haben wir ja seit etwa 1995 gesehen.
Insgesamt finde ich nicht, dass die CSS-Spezifikation dieses Problem der Unvereinbarkeit von Autor- und Leserinteressen auslöst.
Nein, das nicht. Ich sagte ja schon, dass ich die beiden Ziele fuer grundsaetzlich widerspruechlich halte (wenn man nur konsequent genug auf beiden "insistiert"). Und ich glaube, auch Jukka Korpela hat die Schuld nicht auf CSS geschoben. ("Some of the above-mentioned serious problems could be alleviated by modifying and clarifying the specifications. However, inherent and unavoidable difficulties would remain.")
-
<q>The common idea of designing Web pages with newspaper-like format is therefore inherently archaic</q>
Natürlich, keine Einwände. Aber bitte, man mache die Augen auf, das Web ist dominiert von pixelgenauem, perfektem Layout, auf dass der Benutzer keinen Einfluss hat. Man kann dies nicht verändern, indem man Standards herausgibt, die dies verbieten. Es gibt ein Verlangen nach Seiten mit perfektem Aussehen [...].
Ja leider, aber imho eher auf Seiten der Auftraggeber. Vielen Besuchern fallen manche Dinge ueberhaupt nicht auf, die fuer Designer tagelang Feintuning betreiben (muessen). Und wenn eine Framegrenze 3 Pixel zu weit rechts ist und deswegen nicht mehr buendig mit irgendeinem Bild liegt, dann sieht das der Besucher zwar, aber die meisten kuemmert das doch nicht die Bohne, wage ich mal zu behaupten. Also diese ganze Layoutgeilheit finde ich schon sehr uebertrieben (was nicht heisst, dass ich meine eigenen Ideen nicht auch mit einem perfektionistischen Spieltrieb umzusetzen versuchen wuerde).
<q>...careful and detailed design of layout is not only unnecessary but also harmful</q>
Dass Webseiten gestalterisch anspruchsvoll und gutaussehend sein wollen, finde ich gut und richtig. So wie Herr Korpela seine Vision (Utopie?) beschreibt, gelingt es ihm nicht, abzustreiten, dass er nicht von layoutlosen, langweiligen und hässlichen Seiten schwärmt.
Aeh... also bleibt der Eindruck, dass er nicht davon schwaermt, oder? ;-) Aber ich glaube, Du meintest das Gegenteil. *g*
Der Benutzer wird sich im Endeffekt gegen die Seiten entscheiden, die Korpela als benutzerfreundlich bezeichnen würde.
Der, der das Design wichtiger als den Inhalt findet, ja. Aber ich glaube nicht, dass Jukka in dem Artikel ueber die redet.
<q>...it should be regarded as a relief that the author neither can nor need care about presentation issues.</q>
Ach was - imho hat ein Netzautors gleichzeitig die Rolle des Designers, der gestalterische Mittel nutzt, um dem Leser (Betrachter) der Netzseite die Informationen ansprechend und interessant zu vermitteln [...].
S.o. (Kommt imho auf die Art der Seite an.)
Heutzutage bestimmt diese Art des "Webdesigns" das komplette Netz. Bis auf ein paar Idealisten, Träumer und Styleindividualisten ("wir") verfasst niemand mit HTML logisch strukturierte Webseiten. Diese Tendenz kann man nicht stoppen, indem man sie beweint oder verbieten will, sondern indem man sinnvollere Alternativen aufzeigt.
Insofern missachtet Jukka Korpela die Realität (vgl. auch Publishing on the Web Is Different (http://www.cs.tut.fi/~jkorpela/webpub.html). Denn diese zeigt, dass die Entwicklung des Netzes anders verlief und sich die Praxis der alten Medien auch so auf das Netz übertragen hat [...].
Ich glaube, der Artikel sollte auch lediglich mal ein Idealbild zeichnen. Konkrete Loesungsansaetze sind da ja eher nicht vorhanden. Insofern kann man da glaub ich keine Realitaetsferne vorwerfen.
Ich finde es einfach blind, dass Herr Korpela diesen "Fortschritt" bei der Gestaltung von Netzseiten (wenn auch mit den falschen Mitteln) vereitelt und als archaisch und rückschrittig bezeichnet [...]. Jeder wirft jedem vor, die Idee des Webs/die Idee von HTML falsch verstanden zu haben und es zu missbrauchen. [...] [Es] wird sofort klar, welche Fraktion sich durchgesetzt hat und vor allem welche Webseiten den Besuchern gefallen.
Es lesen auch viele die Bild, weil sie an Informationen nicht weiter interessiert sind. Mit dem Verlangen nach bunten Webseiten sehe ich das durchaus aehnlich. Und wir wollen nicht vergessen, dass die Marketingheinis oftmals wahrscheinlich die einzigen sind, die die nach ihren Vorstellungen entstandene Website geil finden.
Bei jeder Liebe und Verständnis zum Sinn und Zweck von HTML - die "Entwicklung" darf auf keinen Fall heißen, dass sich die 10 Jahre alte Entwicklung des Webs zurückgeworfen wird, wenn Entwicklung hier sicher nicht nur Fortschritt bedeutete.
Will ich auch nicht verlangen, moechte aber anmerken, dass man manchmal eben zuruecksetzen muss, wenn man in eine Sackgasse gefahren ist.
IMHO impliziert das Festlegen der Groesse auf diese Art auch tatsaechlich die Aussage, dass dem Autor sein Design wichtiger ist als der Komfort des Besuchers.
[...] Diejenigen Autoren, die sich überhaupt Gedanken darum machen, dass der Benutzer ein Mitspracherecht [...] hat, dürften wohl einen sehr geringen Prozentsatz ausmachen. Diejenigen Nutzer, die Seiten nach ihrem Belieben rendern lassen [...] gehören ebenfalls einer Minderheit an. Die Nutzergruppe, die einfach nur cool gestylte Seiten will [...] ist klar dominierend, vor allem weil sie daran gewöhnt ist.Wirklich? Davon bin ich nicht ueberzeugt.
Zwischen den Zeilen habe ich wohl anklingen lassen, dass ich CSS nicht fuer so wirklich ausgereift halte. ;-)
Ausgereift für was? Sicherlich ist es nicht dafür ausgereift, um die gestalterische Vielfalt, die man durch (schwachsinnige) Nutzung von HTML erreichen kann, durch CSS zu ersetzen. [...]
Ich meinte vor allem eben, Benutzerwuensche und Designvorgaben unter einen Hut zu bringen. Aber es hat auch seine Maengel, wenn man wirklich ganz knallhart ein Layout durchboxen will. CSS geht von einem Box model aus, bei dem die Breite des Inhalts (fast) immer durch die Innenweite der umgebenden Boxen vorgegeben wird. Versuch z.B. mal eine Ueberschrift mit border-bottom in einem bestimmten Stil zu unterstreichen, aber die Linie nur ueber die Textbreite gehen zu lassen, nicht laenger oder kuerzer.
(Nachricht war zu lang, ich musste massiv kürzen. Hoffe einiges bliebt verständlich.)
Ach deswegen die ganzen Auslassungszeichen. Haettest ja auf zwei Postings verteilen koennen. Ich konnte so jetzt leider auch nicht auf alles eingehen, weil mir zu manchem dann einfach die Begruendung oder Beispiele gefehlt haben.
Oha, musste ich jetzt auch machen. Kuerzen hat beim besten Willen nicht mehr gereicht.
Jetzt hab ich aber genug geschrieben, kann ich auch erstmal was essen gehen. *g*
So long
--
Opinions expressed are those of the keyboard, and do not reflect on me or higher-ups.
-
-
-
-
-
Moin!
Konstruktive sowie destruktive Kritik, Kommentare, Ergänzungen und Verbesserungsvorschläge sind herzlich erwünscht. Für Diskussionen bin ich offen, ob per PM oder hier.
Ich kann die <code>-Abschnitte im Fließtext nicht lesen. Die sind... kaum größer als 4 Pixel, oder so. Jedenfalls absolut unlesbar.
Mag ja sein, daß es an Opera liegt. Kann auch sein, daß durch font-size:inherit die Größe von 0.8em für den umgebenden <p>-Bereich nochmal angewandt wird, also auf 0.64em herausläuft. Jedenfalls ist da irgendwas schief.
- Sven Rautenberg
-
Hallo, Sven!
Sorry, gerade ist mitten im Posting Opera gecrasht, wer weiß warum, deswegen der zweite Versuch ein wenig kürzer.
Ich kann die <code>-Abschnitte im Fließtext nicht lesen. Die sind... kaum größer als 4 Pixel, oder so. Jedenfalls absolut unlesbar.
Mag ja sein, daß es an Opera liegt. Kann auch sein, daß durch font-size:inherit die Größe von 0.8em für den umgebenden <p>-Bereich nochmal angewandt wird, also auf 0.64em herausläuft. Jedenfalls ist da irgendwas schief.font-size:inherit hatte ich eingebaut, weil ich vermutete, dass Mozilla das macht ohne font-size:inherit, was du vermutest, was Opera macht, nachdem ich es eingebaut habe. :)
Denn der vom code-Tag umschlossene Text wurde im IE riesig und im Mozilla winzig bis unleserlich dargestellt. - Dabei muss das wohl eher an den browsereigenen Standardschriftgrößen als an vererbten Styles liegen.
Mit Calocybe diskutiere ich gerade über die negativen Auswirkungen des font-size:0.8em für alle Fließtextelemente.
Gerade wollte ich die Standardschriftgröße für monospace testweise dem (sans-)serif-Wert anpassen, aber da crasht dann auch Mozilla. :)Ich benutze hier auch größtenteils Opera (6.03) und die von dir genannten Probleme treten komischerweise nicht auf (dafür halt in Mozilla 8)). Ich werde die Angabe wohl ganz rausnehmen.
Grüße,
Mathias
-
-
Hallo !
eine Verbesserung hätte ich noch:
<a href="foo.html" onclick="return oeffnefenster('foo.html');">
Das geht besser so:
<a href="foo.html" onclick="return oeffnefenster(this.href);">So läßt sich der Link auch mit einem Editor bearbeiten, evtl. läßt sich das noch auf das Target ausweiten:
<a href="foo.html" taregt="fenster" onclick="return oeffnefenster(this.href, this.target);">Dann öffnet sich sogar ohne JS ein neues Fenster.
Struppi.
-
Hallo, Struppi!
eine Verbesserung hätte ich noch:
<a href="foo.html" onclick="return oeffnefenster(this.href);">Das leuchtet mir ein, das werde ich so übernehmen.
So läßt sich der Link auch mit einem Editor bearbeiten, evtl. läßt sich das noch auf das Target ausweiten:
<a href="foo.html" taregt="fenster" onclick="return oeffnefenster(this.href, this.target);">
Dann öffnet sich sogar ohne JS ein neues Fenster.Klar, ohne JavaScript öffnet sich aber auch bei target="_blank" ein neues Fenster.
Den einzigen Vorteil darin sehe ich, dass man *mehrere* Popups öffnen kann und dann mit einfachen Links auf diese referenzieren kann.Die Funktion sähe so aus:
function oeffnefenster3 (url, target) {
fenstername=target; // (*)
var fenstername=window.open(url, target, "width=640,height=480,status=yes,scrollbars=yes,resizable=yes");
fenstername.focus();
return false;
}(*) Evtl. unnötig, aber er soll den Variableninhalt von target als neuen Variablennamen verwenden, ich weiß nicht, wie man das in JavaScript löst, aber so funktioniert es.
Die Links sähen dann so aus:
<a href="foo.html" target="fenster1" onclick="return oeffnefenster3(this.href, this.target);">...</a>
<a href="foo2.html" target="fenster1">...</a>
<a href="bar.html" target="fenster2" onclick="return oeffnefenster3(this.href, this.target);">...</a>
<a href="bar2.html" target="fenster2">...</a>Ehrlich gesagt weiß ich nicht, ob ich den Menschen eine Lösung empfehlen soll, wie man mehrere Popups realisieren kann, eigentlich wollte ich mit dem Howto davon abraten, Popups überhaupt zu benutzen. Meiner Meinung nach ist ein Popup schon mehr als zuviel.
Dennoch danke für die Tipps.
Mathias
-
Gruesse!
eine Verbesserung hätte ich noch:
<a href="foo.html" onclick="return oeffnefenster(this.href);">Finde die Idee gut, haette man eigentlich schonmal eher drauf kommen koennen.
Die Funktion sähe so aus:
function oeffnefenster3 (url, target) {
fenstername=target; // (*)
var fenstername=window.open(url, target, "width=640,height=480,status=yes,scrollbars=yes,resizable=yes");
fenstername.focus();
return false;
}(*) Evtl. unnötig, aber er soll den Variableninhalt von target als neuen Variablennamen verwenden, ich weiß nicht, wie man das in JavaScript löst, aber so funktioniert es.
Noe. Du legst da zwei Variablen an, eine globale und eine funktionslokale (wegen var), und beide heissen 'fenstername' und verwenden keineswegs den Inhalt von target als Variablenname. Die globale hat als Inhalt den Inhalt von target, ist also eine Kopie davon. Die lokale hat als Inhalt die Fensterreferenz, die von window.open() zurueckgegeben wird. Da diese Variable aber beim Funktionsende ihre Gueltigkeit verliert, schmeisst Du an dieser Stelle die Fensterreferenz einfach weg. Schade. *g*
Willst Du den Inhalt von target als Variablenname benutzen, musst Du mit eval() arbeiten. Ungetestet:
function oeffnefenster3 (url, target) {
var wnd = window.open(url, target, "width=640,height=480,status=yes,scrollbars=yes,resizable=yes");
wnd.focus();
eval(target + " = wnd");
return false;
}Das setzt aber auch voraus, dass es in der Funktion nicht zufaellig eine Variable mit dem Namen gibt, der in target steht, sonst wuerde diese naemlich benutzt statt eine neue globale anzulegen.
Ehrlich gesagt weiß ich nicht, ob ich den Menschen eine Lösung empfehlen soll, wie man mehrere Popups realisieren kann, eigentlich wollte ich mit dem Howto davon abraten, Popups überhaupt zu benutzen. Meiner Meinung nach ist ein Popup schon mehr als zuviel.
Yupp.
So long
--
In God we trust, everybody else we monitor... -
Hallo, Struppi!
eine Verbesserung hätte ich noch:
<a href="foo.html" onclick="return oeffnefenster(this.href);">Das leuchtet mir ein, das werde ich so übernehmen.
So läßt sich der Link auch mit einem Editor bearbeiten, evtl. läßt sich das noch auf das Target ausweiten:
<a href="foo.html" taregt="fenster" onclick="return oeffnefenster(this.href, this.target);">
Dann öffnet sich sogar ohne JS ein neues Fenster.Klar, ohne JavaScript öffnet sich aber auch bei target="_blank" ein neues Fenster.
Den einzigen Vorteil darin sehe ich, dass man *mehrere* Popups öffnen kann und dann mit einfachen Links auf diese referenzieren kann.Ich habe den Namen mit eingebaut, weil du damit vermeiden kannst, das jedesmal ein neues Fenster geöffnet wird.
Im gegensatz zu '_blank' das ja jedesmal ein Fenster öffnet.Die Funktion sähe so aus:
function oeffnefenster3 (url, target) {
fenstername=target; // (*)
var fenstername=window.open(url, target, "width=640,height=480,status=yes,scrollbars=yes,resizable=yes");
fenstername.focus();
return false;
}(*) Evtl. unnötig, aber er soll den Variableninhalt von target als neuen Variablennamen verwenden, ich weiß nicht, wie man das in JavaScript löst, aber so funktioniert es.
Ich weiß zwar nicht wieso, ist aber soweit ich das sehe überflüssig.
Ehrlich gesagt weiß ich nicht, ob ich den Menschen eine Lösung empfehlen soll, wie man mehrere Popups realisieren kann, eigentlich wollte ich mit dem Howto davon abraten, Popups überhaupt zu benutzen. Meiner Meinung nach ist ein Popup schon mehr als zuviel.
wie gesagt mit der this.href, this.target Lösung, läßt es sich realisieren, das ein JS popup auch ohne JS ein Fenster öffnet, aber eben kein zweites Fenster, wenn man ein Target angibt.
Struppi.
-
Hallo, Struppi.
<a href="foo.html" taregt="fenster" onclick="return oeffnefenster(this.href, this.target);">
Klar, ohne JavaScript öffnet sich aber auch bei target="_blank" ein neues Fenster.
Den einzigen Vorteil darin sehe ich, dass man *mehrere* Popups öffnen kann und dann mit einfachen Links auf diese referenzieren kann.Ich habe den Namen mit eingebaut, weil du damit vermeiden kannst, das jedesmal ein neues Fenster geöffnet wird.
Im gegensatz zu '_blank' das ja jedesmal ein Fenster öffnet.Sorry, klar, habe dich verstanden, wenn auch spät. Chronische Zerknirschung, bitte zu entschuldigen.
Danke für den Hinweis und die Erklärung, ich werde es so in das Howto aufnehmen.Mathias
-
-
-
-
Hi Mathias,
Die Adresse lautet: http://home.t-online.de/home/dj5nu/js-popup.html
sehr schön - macht Spaß zu lesen, danke.
Konstruktive sowie destruktive Kritik, Kommentare,
Ergänzungen und Verbesserungsvorschläge sind
herzlich erwünscht.
Für Diskussionen bin ich offen, ob per PM oder hier.Man nutzt JavaScript und trägt die auszuführende Funktion,
die das Fenster öffnet, in den href-Attribut_das_ Attribut.
Durch verschiedene Angaben im dritten Funktionsparameter
kann man das Aussehens des Fenstersdas Aussehen_.
explizit auf die Verwendung bestimmter Sprachkonstrukte,
Objekteigenschaften oder - methoden hinweisen möchte,Leerzeichen vor "methoden" weg.
Eine größe Gruppe der Netzsurfer haben JavaScript deaktiviert.
haben -> hat
schwankt in den Monaten des Frühjahrs 2002 zwischen
11-12 Prozent.entweder "im Bereich von" oder "zwischen 11 und 12".
welches dementsprechend hohe Ansprüche an die Technik und
die Authentizität der visuelle Gestaltung der Seite legt,der visuellen_ Gestaltung
So gehen dem Seitenbetreiber wiederrum Besucher verloren.
wiederrum -> wiederum
weist öffentliche Institutionen an, dass deren Internet-
angebot an "von behinderten Menschen grundsätzlich
uneingeschränkt genutzt werden können". [Quelle 13]Singular (Angebot) <-> Plural (können)
schadet man nicht nur einer großen Benutzergruppe
indem man sie benachteiligt und ausschließt,Komma vor "indem" fehlt.
Dies kann vor allem für Firmen welche extensiv Geschäfte
über das Internet abwickeln, fatal sein.Komma vor "welche" fehlt.
Wenn man auch bei Benutzern, die JavaScript deaktiviert
haben, das Linkziel in jedem Fall in einem neuen Fenster
öffnen willl,willl -> will
Ebenso werden Vollbildfunktionen missbraucht und um den
Benutzer irrezuführen werden sogar Titelleisten ausgeschaltet
und durch Grafiken simuliert, damit dem Surfer ...Ich würde Kommata vor "und" sowie vor "werden" setzen.
Man unterbreitet dem Benutzer also einen Möglichkeit des
simultanen Aufrufens von Informationen,einen -> eine
überlässt ihm aber gleichzeitig die Wahl, ob und wie von
dieser Möglichkeit Gebrauch machen will -da fehlt ein "er" nach "wie".
Wann immer es geht, sollte man auf Frames.
Ja, was denn? ;-)
Welche Fallstricke gibt es beim beim Öffnen eines Fensters?",
ein "beim" zuviel.
Wie verhindere ich, dass sich bei Klick auf einen Link,
Wirklich kein Wort zwischen "bei" und "Klick"?
sowie verallgemeinernde Personengruppenbezeichnugnen
nugnen -> nungen
Viele Grüße
Michael-
Hallo, Micahel.
Vielen herzlichen Dank für die Verbesserungen (ich meine es). Die Fehler hätte ich aus Unaufmerksamkeit nie gefunden. (Ok, einig hatte ich schon in der neuen Fassung, an der ich arbeite, ausgeMERZt.)
Echt peinlich was ich für ein Quatsch schreibe, ohne es zu merken. Ich sollte XHTML mit Hand und Stift schreiben, vielleicht kommt etwas besseres heraus.explizit auf die Verwendung bestimmter Sprachkonstrukte,
Objekteigenschaften oder - methoden hinweisen möchte,Leerzeichen vor "methoden" weg.
Da ist keins. ;-) (Ehrenrettung...)
Wie verhindere ich, dass sich bei Klick auf einen Link,
Wirklich kein Wort zwischen "bei" und "Klick"?Ist wortwörtlich aus http://dcljs.de/faq/schnell.php#FensterGroesse_return zitiert. Mach mich nicht für die Dummheit anderer verantwortlich. :) Wenigstens Copy&Paste kann ich ohne Tipp- und Flüchtigkeitsfehler.
Nochmals Danke für die Mitarbeit.
Mathias-
Hallo, Micahel.
^^^
Ich lege mich ins Bett, das bringt heute nichts mehr. Entschuldige vielmals.M.
-
-