nicht angemeldet
Ich habe es getan!
… und Ihr solltet es auch tun :)
In index.html:
<![if gt IE 6]>
<style type="text/css">
@import url("index.css");
</style>
<![endif]>
</head>
<body>
<p id="browserupdate"><a href="browserupdate.html"><img src="browserupdate.gif" alt=""></a></p>
In index.css:
p#browserupdate {
display:none
}
In browserupdate.gif:
In browserupdate.html:
Grundsätzlich sollen hier alle Seiten mit jedem Browser betrachtbar sein. Dafür gibt es seit über 10 Jahren technische Standards, an die ich mich halte - dummerweise halten sich aber einige Browser nicht daran.
Der Aufwand, für einzelne veraltete Browser angepasste Versionen dieser Seiten herzustellen, steht in keinem Verhältnis zum Nutzen. Abgesehen von dieser eher kosmetischen Problematik, leiden alle dieser alten Browser an gravierenden Sicherheitslücken, über die sich Viren verbreiten und persönliche Daten gestohlen weren können.
Aus diesem Grund erhalten solche Browser sämtliche Inhalte hier nur noch in einer Version mit sehr rudimentärer Gestaltung, in der Hoffnung, damit einen Anreiz zum Wechsel auf einen sicheren, besseren Nachfolger zu geben.
Diese Liste ist eine Auswahl an Browsern, die ich in ihrer jeweils aktuellen Version empfehlen kann. Unter Windows sind Opera und Firefox die beste Wahl.
-
Hab ich früher auch gemacht, sogar noch heftiger (an IEs als text/plain ausgeliefert).
Ich empfehle http://browser-update.org/ zu benutzen und das was du da machst ggf. im noscript.--
sh:( fo:| ch:? rl:( br:& n4:& ie:{ mo:} va:) de:µ_de:] zu:) fl:( ss:| ls:[ js:( -
Hallo,
solch ein Browser Bashing kommt mir nicht so elegant vor. Abgesehen von grundsätzlichen "weltanschaulichen" Fragen nach freier Browserwahl und Abwärtskompabilität mag hier noch dazukommen, dass in bestimmten Umgebungen die Browser gar nicht so einfach gewechselt werden können bzw. dürfen. Das Erscheinen von Windows 7 ist aber sicherlich ein Anlass, Browserausstattung usw. neu zu hinterfragen.
<style type="text/css">
@import url("index.css");Das mit dem import erscheint mir umständlich, Netscape 4 läßt sich, falls er tatsächlich irgendwo noch auftaucht, auch anders und wahrscheinlich besser ausschliessen, und die späteren Versionen des IE 4 werden vom import nicht abgeschreckt und laden das Stylesheet trotzdem.
Grüsse
Cyx23
-
Hallo!
Abgesehen von grundsätzlichen "weltanschaulichen" Fragen nach freier Browserwahl und Abwärtskompabilität mag hier noch dazukommen, dass in bestimmten Umgebungen die Browser gar nicht so einfach gewechselt werden können bzw. dürfen.
Das Thema hatten wir letztens auch schon mal hier!
Als Argument wird dann meistens die "Security-Policy" des jeweiligen Unternehmens angeführt. Sorry, aber die Erde dreht sich unaufhaltsam weiter. Was können Millionen von Webdesigern dafür, wenn Unternehmen auf proprietäre Software Lösungen setzen und aus welchen Gründen auch immer, die kostenlosen (und z.T. Open Source) Alternativen nicht nutzen wollen?Das Erscheinen von Windows 7 ist aber sicherlich ein Anlass, Browserausstattung usw. neu zu hinterfragen.
Ich sehe es als nicht sinnvoll an, diese Frage an ein Betriebssystem zu knüpfen! Vielmehr sollte es eine Frage der Weiterentwicklung der Web-Standards und deren Unterstützung seitens der Browser sein.
<style type="text/css">
@import url("index.css");Das mit dem import erscheint mir umständlich, Netscape 4 läßt sich, falls er tatsächlich irgendwo noch auftaucht, auch anders und wahrscheinlich besser ausschliessen, und die späteren Versionen des IE 4 werden vom import nicht abgeschreckt und laden das Stylesheet trotzdem.
Wovon redest du hier? ;-)
Ich hatte auch mal einen ZX81 vor meinem C64 ...!
Manche Dinge sollte man einfach auch irgendwann mal in Frieden Ruhen lassen - RIP.Gruß Gunther
-
Hallo,
Ich sehe es als nicht sinnvoll an, diese Frage an ein Betriebssystem zu knüpfen!
Dann nenn es die Ausstattung der Kunden, deren Kunden bzw. der Besucher usw..
Wovon redest du hier? ;-)
Dass ich externe Stylesheets anders einbinden würde.
Grüsse
Cyx23
-
Hallo,
Ich sehe es als nicht sinnvoll an, diese Frage an ein Betriebssystem zu knüpfen!
Dann nenn es die Ausstattung der Kunden, deren Kunden bzw. der Besucher usw..
Ja, von mir aus kannst du es nennen wie du willst. Ich vermag darin trotzdem keinen Grund zu erkennen, warum man 'daran' nichts ändern sollte.
Wovon redest du hier? ;-)
Dass ich externe Stylesheets anders einbinden würde.
Für mich las sich das anders, nämlich eher so, als dass man heutzutage noch darauf achten sollte, die besagten Browser (bewußt) auszuschließen.
Gruß Gunther
-
Hallo,
Dass ich externe Stylesheets anders einbinden würde.
Für mich las sich das anders, nämlich eher so, als dass man heutzutage noch darauf achten sollte, die besagten Browser (bewußt) auszuschließen.
Mich interessiert beides, der bewußte Umgang mit älteren Browsern bietet sich an der Stelle auch an. Und genau das wird doch im Ausgangscode versucht, nur sind die eingesetzten "Weichen" für den IE4 nicht hinreichend tauglich, und der Netscape 4 erhält unnötigerweise (noch/nur) das Stylesheeet mit der import-Anweisung.
Der Ausgangscode mit dem Gif mag natürlich unter dem Aspekt der Barrierefreiheit auch noch problematisch sein.
Interessant ist übrigens http://www.w3c.de/sieben.html, "Universelle Zugangsmöglichkeiten" umd "Entwicklungsfähigkeit":
"...nutzbar zu machen, gehört zu den Hauptzielen des W3C, unabhängig davon, welche Hard- oder Software sie verwenden"
"Prinzipien der Einfachheit, der Modularität, der Kompatibilität und der Erweiterbarkeit sind richtungsweisend für unser Design"
Da passt es schlecht, gegen Prinzipien wie Zugänglichkeit und Kompatibilität zu verstoßen, um irgendwann angeblich das Web zu verbessern oder ein paar Webdesignern einen ruhigeren Schlaf zu bescheren.
Grüsse
Cyx23
-
Hallo,
Interessant ist übrigens http://www.w3c.de/sieben.html, "Universelle Zugangsmöglichkeiten" umd "Entwicklungsfähigkeit":
"...nutzbar zu machen, gehört zu den Hauptzielen des W3C, unabhängig davon, welche Hard- oder Software sie verwenden"
Interessant! Und genau unter diesem Aspekt frage ich mich immer, warum sie dann in ihre Standards nichts integrieren, womit man genau dieses_einfach & zuverlässig_erreichen kann!?
Mal abgesehen davon, dass ein solches Postulat, gerade in sich technisch sehr schnell weiterentwickelnden Bereichen wie Hard- und Software (also auch das Internet), in meinen Augen völliger Unsinn ist! All zu oft hat die Vergangenheit schon gezeigt, dass der teils zwanghafte Drang nach vollkommener Abwärtskompatibilität eine "ordentliche & sinnvolle" Weiterentwicklung verhindert hat. Aktuelles Beispiel: XHTML 2.
Der nächste Satz ist so schön, dass ich auf die einzelnen Punkte gerne einzeln eingehen möchte.
"Prinzipien der Einfachheit,
[Ironie]Das findet sich imho ja u.a. auch in den CSS-Specs wieder.[/Ironie]
Ganz ehrlich empfinde ich die Weiterentwicklung von CSS als eine immer weitere Verkomplizierung einer im Ansatz für die Aufgaben, für die es mittlerweile "missbraucht" werden soll, unzureichenden Ausgangsbasis. Und dabei könnte man bspw. für das reine Layout durchaus andere Techniken einführen, die dann wirklich_einfach_wären!der Modularität,
Das ist vom Grundgedanken ja eine tolle Sache. Nutzt mir in der Praxis nur leider meistens nichts, weil es keine geeigneten Möglichkeiten gibt, das Vorhandensein, bzw. das Verständnis der einzelnen Module wirkungsvoll und zuverlässig zu ermitteln.
der Kompatibilität und
Dazu habe ich oben bereits etwas geschrieben.
Manchmal wäre es besser aus den Fehlern der Vergangenheit zu lernen und mal einen sauberen Schnitt zu machen. Was in keinster Weise bedeuten muss/ würde, dass dadurch alles bisherige nicht mehr funktionieren würde.der Erweiterbarkeit sind richtungsweisend für unser Design"
Auch so ein heroischer Grundsatz! In meinen Augen wenig hilfreich und in der Praxis kaum funktionierend. Denn das würde bedeuten, dass ich zu jedem Zeitpunkt, an dem ich etwas festlege, schon genau wissen müsste, womit oder wodurch es zukünftig evt. mal erweitert werden soll.
Da passt es schlecht, gegen Prinzipien wie Zugänglichkeit und Kompatibilität zu verstoßen, um irgendwann angeblich das Web zu verbessern oder ein paar Webdesignern einen ruhigeren Schlaf zu bescheren.
Es geht doch gar nicht darum, gegen die Prinzipien der Zugänglichkeit und der Kompatibilität zu verstoßen. Der Punkt hier ist doch ein völlig anderer, nämlich warum man sich bewußt oder unbewußt, unnötigerweise als Bremser der Weiterentwicklung der Web-Standards betätigen muss!
Wobei imho das W3C mittlerweile selber zur größten Bremse wird, nachdem selbst Microsoft nach etlichen Jahren eingesehen hat, dass an den Standards kein Weg vorbeiführt. Und hätten sie das schon vor gut 10 Jahren eingesehen, hätten wir weder diese Diskussion, noch viele der alltäglichen Probleme im Webdesign!
Gruß Gunther
-
Hi there,
Es geht doch gar nicht darum, gegen die Prinzipien der Zugänglichkeit und der Kompatibilität zu verstoßen. Der Punkt hier ist doch ein völlig anderer, nämlich warum man sich bewußt oder unbewußt, unnötigerweise als Bremser der Weiterentwicklung der Web-Standards betätigen muss!
Es ist aber nicht unbedingt die Aufgabe eines, sagen wir einmal "Webworkers" im weitesten Sinne, die Weiterentwicklung von Webstandards voranzubringen sondern ich sehe die Aufgabe darin, Inhalte möglichst vielen Nutzern zu vermitteln.
Wobei imho das W3C mittlerweile selber zur größten Bremse wird, nachdem selbst Microsoft nach etlichen Jahren eingesehen hat, dass an den Standards kein Weg vorbeiführt.
Bremse auf dem Weg wohin? Es ist ja nicht so, daß die Entwicklung irgendwelcher HTML-Versionen oder Stylesheetspezifikationen ein vorgezeichneter Weg in einem göttlichen Plan wäre. Der Standard selbst muss zunächst das Ziel sein, und da sehe ich nicht, wo das W3C bremst. Und ganz egal, was MS "eingesehen" hat, es hapert halt immer noch an den Umsetzungen der Standards, nicht an deren Definitionen.
Und hätten sie das schon vor gut 10 Jahren eingesehen, hätten wir weder diese Diskussion, noch viele der alltäglichen Probleme im Webdesign!
Mag ja sein, alleine, ich sehe diese Einsicht nicht. Ich glaub das erst, wenn der IE9 mit Gecko-Engine ausgeliefert wird...;)
-
Hi,
[...] es hapert halt immer noch an den Umsetzungen der Standards, nicht an deren Definitionen.
Natürlich hapert es auch an den Standards selber.
(Bspw.) Spaltenlayouts per float zu realisieren, wozu es nie gedacht war, ist eine der verbreitetsten Perversität - warum hat man es nicht geschafft, den Webseitenautoren dazu ein *vernünftiges*, genau zu diesem und keinem anderen Zweck gedachtes Mittel an die Hand zu geben?
"Gleich lange" Spalten, Verhalten bei zu wenig Platz in der Breite, etc. pp. - das alles hätte ordentlich umgesetzt gehört, mit genau dafür zuständigen Eigenschaften, die einfach und logisch die Kontrolle geben, die der Webdesigner sich wünscht.
Stattdessen begnügen wir uns seit Jahren mit "Hacks", realisieren gewünschtes Aussehen über "Zweckentfremdung" von Eigenschaften ...MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.-
Hi there,
[...] es hapert halt immer noch an den Umsetzungen der Standards, nicht an deren Definitionen.
Natürlich hapert es auch an den Standards selber.
Na gut, einigen wir uns auf noch nicht perfekt;)
(Bspw.) Spaltenlayouts per float zu realisieren, wozu es nie gedacht war, ist eine der verbreitetsten Perversität - warum hat man es nicht geschafft, den Webseitenautoren dazu ein *vernünftiges*, genau zu diesem und keinem anderen Zweck gedachtes Mittel an die Hand zu geben?
Tja, gute Frage, afaik hatte ein Browser, der einmal ähnliche Marktanteile hatte wie später der IE sowas wie einen proprietären multicol-Tag eingebaut. Wahrscheinlich hat man sich damals noch gedacht, ist ohnehin überflüssig, es gibt ja die Tabelle. Vielleicht sträubt man sich ja heute, in einer (so wie HTML endlich wieder verstanden wird) Auszeichnungssprache Elemente für Spalten zu definieren; keine Ahnung, ob sowas in CSS3 drinnen sein wird, aber irgendwie lässt sich das ohne ganz entsprechende Verankerung in HTML vermutlich auch nicht (semantisch korrekt) lösen.
Stattdessen begnügen wir uns seit Jahren mit "Hacks", realisieren gewünschtes Aussehen über "Zweckentfremdung" von Eigenschaften ...
Naja, wenn Du für jeden Zweck ein eigenes Element hast, hast Du auch nicht viel gewonnen, nur die Browser, die kommen dann gar nicht mehr mit...;)
-
Hallo Klawischnigg
Vielleicht sträubt man sich ja heute, in einer (so wie HTML endlich wieder verstanden wird) Auszeichnungssprache Elemente für Spalten zu definieren;
Hat hier irgendjemand irgendwelche HTML-Elemente für Spalten gewünscht?
Wir schreiben doch hier über die Unzulänglichkeiten von CSS!keine Ahnung, ob sowas in CSS3 drinnen sein wird,
Laut W3C Working Draft 30 June 2009 ja.
aber irgendwie lässt sich das ohne ganz entsprechende Verankerung in HTML vermutlich auch nicht (semantisch korrekt) lösen.
Wozu sollten irgendwelche Verankerungen im HTML nötig sein?
Und was meinst du in dem Zusammenhang mit „semantisch korrekt”?Naja, wenn Du für jeden Zweck ein eigenes Element hast, hast Du auch nicht viel gewonnen, nur die Browser, die kommen dann gar nicht mehr mit...;)
Was soll ein Element für Spaltenlayout?
Schau dir das multi-column-model an. Wenn ich das richtig verstanden habe, dann könnte man damit vernünftig arbeiten. Übrigens unterstützt FF3 einige multi-column-Eigenschaften bereits als -moz-column-….Was mich aber besonders an CSS stört:
Bestimmte Eigenschaften werden durch andere ausgelöst, wie z.B. „Block Formatting Context” oder die Anpassung der Breite von Blockelementen an ihren Inhalt. Statt einfach dieses Verhalten als CSS-Eigenschaft zuweisen zu können, müssen andere Eigenschaften missbraucht werden, die dieses Verhalten auslösen.
(In den seltensten Fällen will ich das Elternelement eines gefloateten Elements selbst auch floaten oder ihm ein overflow:hidden verpassen. Ich muss es aber doch tun, um das Float einzuschließen.)Auf Wiederlesen
Detlef--
- Wissen ist gut
- Können ist besser
- aber das Beste und Interessanteste ist der Weg dahin!-
Hi there,
aber irgendwie lässt sich das ohne ganz entsprechende Verankerung in HTML vermutlich auch nicht (semantisch korrekt) lösen.
Wozu sollten irgendwelche Verankerungen im HTML nötig sein?
Und was meinst du in dem Zusammenhang mit „semantisch korrekt”?Naja, wenn ich einen Absatz brauche, verwende ich den <p>-Tag, wenn ich eine Spalte (von mehreren) benötige, verwende ich dann was?
Naja, wenn Du für jeden Zweck ein eigenes Element hast, hast Du auch nicht viel gewonnen, nur die Browser, die kommen dann gar nicht mehr mit...;)
Was soll ein Element für Spaltenlayout?
Keine Ahnung, ChrisB hat das Spaltenlayout als Beispiel auf's Tapet gebracht, persönlich bin ich noch nie in die Verlegenheit
gekommen, so etwas verwenden zu müssen.Was mich aber besonders an CSS stört:
Bestimmte Eigenschaften werden durch andere ausgelöst, wie z.B. „Block Formatting Context” oder die Anpassung der Breite von Blockelementen an ihren Inhalt. Statt einfach dieses Verhalten als CSS-Eigenschaft zuweisen zu können, müssen andere Eigenschaften missbraucht werden, die dieses Verhalten auslösen.(In den seltensten Fällen will ich das Elternelement eines gefloateten Elements selbst auch floaten oder ihm ein overflow:hidden verpassen. Ich muss es aber doch tun, um das Float einzuschließen.)
Ich habe ja nicht behauptet, daß es keine Verbesserungsmöglichkeiten mehr gäbe, ich sehe nur das von Gunther so inbrünstig vorgegebene Entwicklungsziel nicht. Wenn wir hier schon so einen Meinungszoo haben (Dir wäre das wichtiger, dem anderen jenes etc. etc.) dann ist erstens leicht zu sehen, daß man das, noch dazu weltweit, schwer unter einen Hut wird bringen können und das aber zweitens nicht dazu führen darf, daß man wenigstens bestehende Standards auch einhält...
-
Hallo Klawischnigg
Naja, wenn ich einen Absatz brauche, verwende ich den <p>-Tag, wenn ich eine Spalte (von mehreren) benötige, verwende ich dann was?
Wenn du _einen_ Absatz im Spaltenlayout willst, dann gibst du diesem Absatz die Spalteneigenschaften.
Willst du einen umfangreicheren Inhalt mit den enthaltenen Elementen (Überschriften, Textabsätzen …) in Spalten anzeigen, dann gibst du sie dem gruppierenden Element.
Wenn Blöcke nicht geteilt werden sollen, diese kompletten Blöcke aber in Spalten angeordnet sein sollen, dann gibst du dem umschließenden Element die Spalteneigenschaften bringst die Blöcke selbst in den „Block Formatting Context”. Das Beispiel funktioniert zumindest im FF3.0.13.(Dir wäre das wichtiger, dem anderen jenes etc. etc.)
Wobei mein Hauptwunsch ja lediglich darin besteht, die von den Browsern intern sowieso verwendeten, und als Folge anderer CSS-Regeln gesetzten Eigenschaften auch browserübergreifend direkt setzen zu können.
Auf Wiederlesen
Detlef--
- Wissen ist gut
- Können ist besser
- aber das Beste und Interessanteste ist der Weg dahin! -
Hi,
Ich habe ja nicht behauptet, daß es keine Verbesserungsmöglichkeiten mehr gäbe, ich sehe nur das von Gunther so inbrünstig vorgegebene Entwicklungsziel nicht.
Ich leider auch nicht.
Wenn wir hier schon so einen Meinungszoo haben (Dir wäre das wichtiger, dem anderen jenes etc. etc.) dann ist erstens leicht zu sehen, daß man das, noch dazu weltweit, schwer unter einen Hut wird bringen können
Aber mit dem Argument sinnvolle Weiterentwicklung ganz blockieren bzw. von vorherein als zum Scheitern verurteilt abtun?
"Expertenkommisionen" sind natürlich immer mit Vorsicht zu geniessen, und viele Köche können sicher auch den Brei verderben.
Aber erst mal unter Leuten, die täglich damit arbeiten zu ermitteln, für welche der eigentlich "normalsten" Aufgaben sie immer wieder zu Hacks (im Sinne von Zweckentfremdung von Eigenschaften) greifen müssen, weil CSS dafür einfach keine konkrete und sinnvolle Möglichkeit vorgesehen hat, wäre ein Anfang.MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.-
Hallo ChrisB
Aber erst mal unter Leuten, die täglich damit arbeiten zu ermitteln, für welche der eigentlich "normalsten" Aufgaben sie immer wieder zu Hacks (im Sinne von Zweckentfremdung von Eigenschaften) greifen müssen, weil CSS dafür einfach keine konkrete und sinnvolle Möglichkeit vorgesehen hat, wäre ein Anfang.
Um das zu ermitteln wäre noch nicht einmal eine Befragung notwendig.
Sämtliche CSS-Foren und -Blogs sind doch immer wieder mit den selben Fragen zu denselben genau dadurch bedingten Fragen und Lösungsmöglichkeiten („von hinten durch die Brust ins Auge”) voll.Auf Wiederlesen
Detlef--
- Wissen ist gut
- Können ist besser
- aber das Beste und Interessanteste ist der Weg dahin!
-
-
Hi there!
Ich habe ja nicht behauptet, daß es keine Verbesserungsmöglichkeiten mehr gäbe, ich sehe nur das von Gunther so inbrünstig vorgegebene Entwicklungsziel nicht.
Welches 'Entwicklungsziel' habe ich denn so 'inbrünstig' vorgegeben?
Wir reden doch hier in dem Thread mittlerweile von 2 verschiedenen Dingen:
1. Die Weiterentwicklung und Umsetzung der Web-Standards
2. Deren praktische Anwendbarkeit in Abhängigkeit der von Usern verwendeten BrowserLetzteres war eigentlich Ausgangspunkt dieses Threads. Denn ich bin der Meinung, dass es letztlich um ein Zusammenspiel/ -wirken von drei Faktoren/ Parteien geht:
1. W3C - zuständig für die Festlegung und Weiterentwicklung der Standards
2. Browserhersteller - zuständig für die Umsetzung/ Implementierung der Standards in den Browsern
3. User - zuständig für die Verwendung "geeigneter" BrowserFür den Webdesigner bleibt nämlich realistisch betrachtet nur die Schnittmenge aus allen 3 übrig. Völlig außer Frage, bzw. fern jeder Diskussion steht dabei der Punkt, dass man *jedem* Browser als letzte Variante natürlich zumindest immer eine reine HTML-Variante, also ohne jegliches Styling, servieren muss (diesbezüglich habe ich auch nie etwas anderes behauptet).
Wenn wir hier schon so einen Meinungszoo haben (Dir wäre das wichtiger, dem anderen jenes etc. etc.) dann ist erstens leicht zu sehen, daß man das, noch dazu weltweit, schwer unter einen Hut wird bringen können und das aber zweitens nicht dazu führen darf, daß man wenigstens bestehende Standards auch einhält...
Noch so ein Punkt: Ich habe niemals behauptet, dass man sich nicht an bestehende Standards halten soll! Blöd nur, wenn User andererseits Browser verwenden, die das offensichtlich nicht tun. Und ja, ich bestreite, dass es dafür irgendeinen objektiv betrachtet einleuchtenden und nachvollziehbaren Grund gibt. Denn imho kann es nicht Sache/ Aufgabe der Webdesigner sein, dass Firmen auch noch in 5 Jahren "ordentlich gestylte" Seiten angezeigt bekommen, obwohl sie der Meinung sind mit einem IE6 im Web unterwegs sein zu müssen. Wenn sie diesen für ihre proprietären Intranet Anwendungen benötigen - bitte.
Man solltee aber imho auch den wesentlich größeren Teil der User nicht vergessen/ außer Acht lassen, der schlicht aus Unwissenheit um die ganze Problematik einfach mit dem Browser durchs Web surft, nur weil der bei der Installation des OS gerade sowieso schon mit installiert wurde. Auch da halte ich es für durchaus legitim, die User zumindest darauf aufmerksam zu machen.
Zum Punkt des "Meinungszoos": So unterschiedlich sind die Wünsche/ Anforderungen doch gar nicht. ChrisB und Detlef G. haben doch bereits einhellig einige der wichtigsten genannt.
Einen der wesentlichsten Knackpunkte hast du doch schon selber angesprochen:"Cascading Style Sheets (CSS) is a style sheet language used to describe the presentation (that is, the look and formatting) of a document written in a markup language."
CSS hängt somit also unmittelbar von der jeweiligen markup language (in diesem Fall HTML) ab, und in HTML gibt es keine Elemente, für das Layout! Was wiederum aufgrund der Definition auch gar nicht möglich ist, da ein Layout ansich keine Semantik haben kann. Um diesem Problem beizukommen, hat man seinerzeit extra die beiden "inhaltsleeren" (sinnfreien) Elemente SPAN und DIV in HTML eingeführt, um ein "Layouten" per CSS überhaupt zu ermöglichen.
Und hier sind wir bei dem für mich entscheidenden Punkt. Ein Layout *muss* im Verhältnis zum jeweiligen Ausgabemedium stehen. Das bedeutet für mich zwingend, dass ich für mein Layout bestimmte Gegebenheiten des Ausgabemediums "kennen" muss. Das war mit CSS anfangs gar nicht möglich und ist auch heute nur in unzureichendem Maße möglich (etwa durch Media Stylesheets).
Dinge wie die Modularisierung in CSS 3 machen imho nur Sinn, wenn ich diese auch per interner Logik sauber ermitteln kann, was mit CSS 3 aber auch nicht möglich ist/ sein wird.
Beispiel: Nehmen wir bspw. das bereits (von anderen) angesprochene Multi-Column-Layout Modul. Dieses wird man in der Praxis u.a. wohl für das Screen-Design bei/ ab gewissen Viewportgrößen verwenden. Um nun zwischen den alternativen Layouts auszuwählen, kann man das ebenfalls neue Modul der Media Queries verwenden. Und schon stößt man in der Praxis wieder auf das erste Problem, denn die aktuelle Version des Opera (9.64) unterstützt zwar Media Queries, nicht jedoch das Multi-Column-Layout Modul. Also will ich trotz breiterem Viewport bei diesem Browser keine breitere Darstellung meiner Seite, wenn diese nicht in mehreren Spalten angezeigt werden kann.
Warum kann ich nicht ganz einfach z.B. folgendes in mein Stylesheet schreiben?
@if(modul:"Media Query(width,min-width)") and (modul:"Multi-Column-Layout") { #... {} }Zusammenfassend kann man es auch so ausdrücken: Für unterschiedliche Layouts, die an die jeweiligen Ausgabemedien angepasst sind, ist eine gewisse interne Logik von Nöten. Diese fehlte CSS bislang und wird nach jetzigem Stand der Dinge auch in CSS 3 völlig unzureichend sein - Punkt!
Und bereits nach wenigen Stunden des "Herumexperimentierens" mit den Media Queries, bin selbst ich als Laie schon auf das nächste gravierende Problem gestoßen, welches durch das jeweilige Brwoser-Feature des Page-Zooms (der nicht Bestandteil der Standards ist) verursacht wird, bzw. dessen unterschiedliche Umsetzung in den jeweiligen Browsern. Jede der aktuellen Versionen von Firefox, Opera und Safari setzt die Page-Zoom Funktion anders um im Bezug auf die Veränderung der Viweportgröße. Damit kann man dann auch Media Queries quasi komplett in die Tonne treten.
Sorry, aber vernünftige & praxisorientierte Weiterentwicklung stelle ich mir jedenfalls anders vor! Und wenn ich dann solche Aussagen wie "Prinzipien der Einfachheit, der Modularität, der Kompatibilität und der Erweiterbarkeit sind richtungsweisend für unser Design." lese, fällt mir echt nichts mehr ein.
Gruß Gunther
-
Hallo Gunther
Beispiel: Nehmen wir bspw. das bereits (von anderen) angesprochene Multi-Column-Layout Modul. Dieses wird man in der Praxis u.a. wohl für das Screen-Design bei/ ab gewissen Viewportgrößen verwenden.
Interessanterweise wäre es bei diesem Modul nicht nötig nach Fensterbreite zu unterscheiden, das tut es, richtig angewandt, schon von selbst.
Zusammenfassend kann man es auch so ausdrücken: Für unterschiedliche Layouts, die an die jeweiligen Ausgabemedien angepasst sind, ist eine gewisse interne Logik von Nöten. Diese fehlte CSS bislang und wird nach jetzigem Stand der Dinge auch in CSS 3 völlig unzureichend sein - Punkt!
Außer beim Multi-Column-Layout Modul ;-)
Auf Wiederlesen
Detlef--
- Wissen ist gut
- Können ist besser
- aber das Beste und Interessanteste ist der Weg dahin!-
Hallo Detlef!
Beispiel: Nehmen wir bspw. das bereits (von anderen) angesprochene Multi-Column-Layout Modul. Dieses wird man in der Praxis u.a. wohl für das Screen-Design bei/ ab gewissen Viewportgrößen verwenden.
Interessanterweise wäre es bei diesem Modul nicht nötig nach Fensterbreite zu unterscheiden, das tut es, richtig angewandt, schon von selbst.
Das hängt von der Art der Verwendung ab. Es gibt auch "Szenarien", wo man multi-column (in einem 'Container') nur dann haben will, wenn die Gesamtbreite mind. so und soviel Pixel beträgt.
Zusammenfassend kann man es auch so ausdrücken: Für unterschiedliche Layouts, die an die jeweiligen Ausgabemedien angepasst sind, ist eine gewisse interne Logik von Nöten. Diese fehlte CSS bislang und wird nach jetzigem Stand der Dinge auch in CSS 3 völlig unzureichend sein - Punkt!
Außer beim Multi-Column-Layout Modul ;-)
Mag sein, dass das Beispiel nicht optimal ist. Es verdeutlicht aber imho trotzdem, welche Probleme u.a. jetzt schon (wieder) mit Erweiterungen verbunden sind, die gerade mal den Weg in einige wenige aktuelle Brwoser gefunden haben.
Und wie auch schön öfter erwähnt, wäre ein ähnliches Konzept wie MS Conditional Comments in CSS durchaus auch sehr hilfreich, wo man ganz klar & einfach nach der jeweiligen Rendering-Engine und Version unterscheiden könnte.
Alles Dinge, die jedem Designer zu Gute kämen und keinem weh tun würden.
Gruß Gunther
PS: Hier mal ein Link zu meiner aktuellen "Baustelle". Wenn möglich mal mit einer Viewportbreite von mind. 1280px in FF 2,3 oder Safari 4 betrachten http://lostinhyperspace.de/
Und bitte berücksichtigen, ist noch eine "Baustelle"! ;-)-
Hallo Gunther
Das hängt von der Art der Verwendung ab. Es gibt auch "Szenarien", wo man multi-column (in einem 'Container') nur dann haben will, wenn die Gesamtbreite mind. so und soviel Pixel beträgt.
Ja, genau diese Funktionalität beinhaltet das multi-column-Konzept bereits.
Schau dir mal das Beispiel im FF3 an und ändere die Fensterbreite. Alle <p> haben genau die selben Eigenschaften, nur die Breite der Container variiert. Hier sind es zwar keine Pixel sondern em, was für Texte sowieso zutreffender ist.Auf Wiederlesen
Detlef--
- Wissen ist gut
- Können ist besser
- aber das Beste und Interessanteste ist der Weg dahin!-
Hallo Detlef!
Das hängt von der Art der Verwendung ab. Es gibt auch "Szenarien", wo man multi-column (in einem 'Container') nur dann haben will, wenn die Gesamtbreite mind. so und soviel Pixel beträgt.
Ja, genau diese Funktionalität beinhaltet das multi-column-Konzept bereits.
Alle <p> haben genau die selben Eigenschaften, nur die Breite der Container variiert. Hier sind es zwar keine Pixel sondern em, was für Texte sowieso zutreffender ist.Die Funktionsweise und die 2 Alternativen des Multi-Columns-Modul glaube ich schon (richtig) verstanden zu haben.
Korrigier' mich bitte, falls ich mich irre, aber ich möchte ja folgendes erreichen:
Mein 2-Spalten Layout hat eine Gesamtbreite in em (wegen der Zeilenbreite). Nur wenn der Viewport breit genug ist, um für die linke Spalte ein 2-spaltiges Layout zu ermöglichen, soll die Gesamtbreite auf einen größeren em Wert geändert werden. Die rechte Spalte ist immer gleich breit (in em gemessen).Für diesen Zweck kommt man mit dem Multi-Column-Modul alleine nicht aus. Schon deswegen nicht, weil sich für die rechte (einspaltige) Spalte die Breitenangabe ändern muss, wenn die linke Spalte zweispaltig wird. Und ob sie das wird oder nicht, ist halt abhängig von der Viewportbreite.
Gruß Gunther
-
Hallo Gunther
Korrigier' mich bitte, falls ich mich irre, aber ich möchte ja folgendes erreichen:
Mein 2-Spalten Layout hat eine Gesamtbreite in em (wegen der Zeilenbreite). Nur wenn der Viewport breit genug ist, um für die linke Spalte ein 2-spaltiges Layout zu ermöglichen, soll die Gesamtbreite auf einen größeren em Wert geändert werden.Du willst also nicht eine flexible Seitenbreite in der sich die Anzahl und Breite der Spalten dynamisch anpasst sondern praktisch je nach Fensterbreite verschiedene feste Layouts.
Zwischen verschiedenen Layouts wählen bzw. die Breite von Vorfahrenelementen umschalten, kann es natürlich nicht.
Die rechte Spalte ist immer gleich breit (in em gemessen).
Das multi-column-Modul unterstützt keine unterschiedlich breite Spalten.
Deine rechte Spalte muss weiter auf herkömmlichem Weg gebastelt werden.Du hast recht. Trotz seines Verhaltens, das ich mir schon manches Mal gewünscht hätte (und unvollständig mit Javascript gebastelt habe), ist das multi-column-Modul auch nicht so flexibel einsetzbar, wie es möglich wäre.
Eine Möglichkeit mehrere Spaltenbreiten anzugeben, wie z.B. column-width: auto 15em; oder/und right-column-width: 15em, könnte seine Anwendungsmöglichkeit noch wesentlich erweitern.Aber warum diskutieren wir überhaupt darüber?
Das Modul gibt es wohl bereits seit 2001, soweit ich weiß, hat es bis jetzt nur ein Browser (sehr unvollständig) implementiert. Bis es von genügend Browsern unterstützt wird, so dass man es wirklich verwenden könnte, können nach sehr viele Jahre vergehen.Auf Wiederlesen
Detlef--
- Wissen ist gut
- Können ist besser
- aber das Beste und Interessanteste ist der Weg dahin!-
Hallo Detlef!
Aber warum diskutieren wir überhaupt darüber?
Das Modul gibt es wohl bereits seit 2001, soweit ich weiß, hat es bis jetzt nur ein Browser (sehr unvollständig) implementiert.Na ja, erstens sind es schon 2 Browser (Safari kann es per -webkit auch) und so unvollständig finde ich es gar nicht. Es fehlen halt im wesentlichen die anderen Dinge im CSS-Standard, die man in dem Zusammenhang sehr gut gebrauchen könnte.
Bis es von genügend Browsern unterstützt wird, so dass man es wirklich verwenden könnte, können nach sehr viele Jahre vergehen.
Ja, das ist einer der Punkte, die mich immer wieder *ank.....*!
Aber warum soll man nicht bspw. der stetig steigenden Zahl der FF Nutzer diese Möglichkeiten bieten (als Option/ Alternative), wenn ihr Browser sie ja bereits unterstützt?Generell finde ich ja, dass solche reinen Layout-Geschichten in CSS nichts zu suchen haben, und nur dazu führen werden, dass es immer komplizierter und somit die Wahrscheinlichkeit für unterschiedliche Browserinterpretationen größer werden.
Es müsste eine eigene und separate Geschichte für das reine Layouten her. Und zwar eine, die u.a. auch völlige Freiheit im Bezug auf die Reihenfolge von Elementen im Markup bietet!
Gruß Gunther
-
Hallo Gunther
Na ja, erstens sind es schon 2 Browser (Safari kann es per -webkit auch) und so unvollständig finde ich es gar nicht.
OK, der 3.5er FF kennt auch -moz-column-rule, aber column-fill und column-span fehlen noch.
Nicht nur, dass er column-fill nicht kennt, verhält er sich auch wie bei column-fill:auto, balance wäre Standard. Damit ist es nicht möglich ein gelichmäßiges Füllen der Spalten zu erreichen, wenn das Element höher ist (min-height) als für den Inhalt benötigt wird.
Auf column-span kann man zwar verzichten, benötigt dazu in manchen Fällen aber zusätzliche Elemente oder/und muss auch mit anderen CSS-Eigenschaften ein wenig tricksen.
Auch ist das Overflowverhalten bei Floats nicht so, wie es sein sollte.Aber warum soll man nicht bspw. der stetig steigenden Zahl der FF Nutzer diese Möglichkeiten bieten (als Option/ Alternative), wenn ihr Browser sie ja bereits unterstützt?
Das stellt sich nicht ganz so einfach dar. Wenn der Inhalt bei breiteren Browserfenstern in mehreren Spalten angezeigt werden soll, halte ich es für keine Alternative einem Großteil der Seitenbesucher stattdessen unendlich lange Textzeilen vorzusetzen. Also muss ich für die Browser, die es (noch) nicht können irgendeine Alternative basteln. Wenn ich das sowieso getan habe, stellt es keine Vereinfachung dar sondern eher einen zusätzlichen Aufwand, FF ab V3.5 und Webkit ab V3 (und dann Oprera ab V?, und dann …) stattdessen mit CSS3 zu versorgen.
Generell finde ich ja, dass solche reinen Layout-Geschichten in CSS nichts zu suchen haben, …
Wie meinst du das?
Wozu sollte CSS denn sonst da sein, wenn nicht für die Definition der Darstellung?
Oder soll es jeweils eine separate Beschreibungssprache geben, ein nur für Farben, eine für Schriftarten, eine für Größen und Maße, eine für die Anordnung, eine für Hintergründe, …Es müsste eine eigene und separate Geschichte für das reine Layouten her. Und zwar eine, die u.a. auch völlige Freiheit im Bezug auf die Reihenfolge von Elementen im Markup bietet!
Also so ähnlich wie position:absolute, nur dass das Element dabei nicht aus dem Fluss genommen wird sondern an der angegebenen Position bzw. beim angegebenen Element wieder in den Fluss eingefügt wird?
Wie wäre es, mittels Javascript das DOM entsprechend umzuschaufeln.
Auf Wiederlesen
Detlef--
- Wissen ist gut
- Können ist besser
- aber das Beste und Interessanteste ist der Weg dahin!
-
-
-
-
-
-
-
-
-
Hi,
Was mich aber besonders an CSS stört:
Bestimmte Eigenschaften werden durch andere ausgelöst, wie z.B. „Block Formatting Context” oder die Anpassung der Breite von Blockelementen an ihren Inhalt. Statt einfach dieses Verhalten als CSS-Eigenschaft zuweisen zu können, müssen andere Eigenschaften missbraucht werden, die dieses Verhalten auslösen.
(In den seltensten Fällen will ich das Elternelement eines gefloateten Elements selbst auch floaten oder ihm ein overflow:hidden verpassen. Ich muss es aber doch tun, um das Float einzuschließen.)Ganz genau.
Eine weitere Eigenschaft, enclose-floats o.ä., mit Werten meinetwegen yes und no (beispielhaft) - wäre das zu viel verlangt gewesen?
Das wäre absolut eindeutig - und für Browserhersteller sicher auch nicht schwerer umzusetzen gewesen, als die vielen Bedingungen und Wechselwirkungen, die CSS-Eigenschaften je nach Wert auf- und untereinander haben.Ich verstehe das eventuelle Argument, dass man den "Sprachkern" von CSS nicht dadurch verwässern möchte, dass man für jeden Furz eine eigene Eigenschaft bereitstellt. Aber wenn man daran "spart", und sich stattdessen zig Wechselwirkungen überlegt, die weder beim Arbeiten mit CSS noch beim Implementieren [1] Spaß machen - das kann's eigentlich auch nicht sein.
[1] IE und Floats, war mindestens bis zum 8er immer ein unangenehmes Thema. Wenn CSS in der Hinsicht "vernünftiger" aufgebaut gewesen wäre - wer weiss, vielleicht hätte man dann schon mit einem IE 5 vernünftig layouten können ...? ;-)
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.
-
-
-
-
-
-
-
-
-
Moin!
Was können Millionen von Webdesigern dafür, wenn Unternehmen auf proprietäre Software Lösungen setzen und aus welchen Gründen auch immer, die kostenlosen (und z.T. Open Source) Alternativen nicht nutzen wollen?
Wir scheinen uns ja einig zu sein. Was interessiert es die Unternehmen, was für Probleme ein Webdesigner hat? Solange die Inhalte erreichbar sind is doch alles ok. Ob der Webdesigner weint, weil es irgendwem wurscht ist, daß sein tolles Werk nicht in all seiner Pracht bewundert wird, interessiert nun wirklich keine Sau.
Ärgerlich wird es bei Unbenutzbarkeit der Seite. Solche Webdesigner gehören schlicht entlassen. Die können gern Bilder malen gehen oder so.
--
"Die Diebesgilde beklagte sich darueber, dass Mumm in aller Oeffentlichkeit behauptet hatte, hinter den meisten Diebstaehlen steckten Diebe."
- T. Pratchett-
Moin!
Ärgerlich wird es bei Unbenutzbarkeit der Seite. Solche Webdesigner gehören schlicht entlassen. Die können gern Bilder malen gehen oder so.
Ja, das sehe ich genauso!
Ab einem gewissen Punkt gibt es halt "pure HTML". Wobei ich persönlich dann meist eher solche Varianten wie:
"Sie sehen eine grafisch (stark) eingeschränkte Version dieser Webseite ...", oder
"Ihr Browser unterstützt die aktuellen Web-Standards leider nicht ..." bevorzuge.
Und je nach Penetranz als Hinweis auf jeder Seite oder nur einmalig (wenn möglich per Cookie-Steuerung).Gruß Gunther
-
-
-
Abgesehen von grundsätzlichen "weltanschaulichen" Fragen nach freier Browserwahl und Abwärtskompabilität mag hier noch dazukommen, dass in bestimmten Umgebungen die Browser gar nicht so einfach gewechselt werden können bzw. dürfen.
Wer den IE wählt, kann ihn doch nutzen. Nur sollte es halt eine halbwegs neue Version sein. Die kommt doch schon automatisch mit den Updates mit, dachte ich.
Ich seh schon den Hintergrund dieses Problems.
Und ich seh auch den Unterschied zwischen einer kommerziellen Seite mit verstaubten Admins beim Kunden und einer privaten Seite.
Aber manchmal muss man halt seine Voraussetzungen neu überdenken.Was meine Bekannten sehen sollen, bau ich jedenfalls sicher nicht zig mal parallel, nur damit man es mit einem monochrom Monitor in VGA-Auflösung auch noch gut sieht.
-
Hi there,
Wer den IE wählt, kann ihn doch nutzen. Nur sollte es halt eine halbwegs neue Version sein. Die kommt doch schon automatisch mit den Updates mit, dachte ich.
Ich kenn' genug Firmen, in den die Admins dem automatischen Update höheres Gefahrenpotential zuschreiben als den Problemen, die solche Updates angeblich lösen können. BTW, wenn Du in der Firma eine funktionierende Firewall hast, dann brauchst Du ja wirklich kein Update...
-
-
-
Hi there,
… und Ihr solltet es auch tun :)
weiss nicht. Wenn ich auf eine Seite komme, wo ich anstelle des erwarteten Inhalts (was immer das auch sein mag) so eine Belehrung vorfinde, bin ich auch schon wieder weg. Da kannst Du in der Sache hundertmal Recht haben, ich denke nicht, daß Du dieser Weg der zielführende ist, damit schadest Du Dir nur selbst...
-
damit schadest Du Dir nur selbst...
Ich schade mir bestenfalls, wenn ich meine Zeit damit verschwende, für kaum noch 10% der Besucher angepasste CSS-Daten zusammenzupfuschen. Die Arbeit stecke ich lieber in den Inhalt.
Die Design-Nazis, die mit ihrem IE 6 unterwegs sind und statt Inhalt und Nutzen nur auf tolles Klickibunti achten, sind bei mir dann natürlich fehl am Platze - aber das werde ich überleben :)
-
Hi there,
Die Design-Nazis, die mit ihrem IE 6 unterwegs sind und statt Inhalt und Nutzen nur auf tolles Klickibunti achten, sind bei mir dann natürlich fehl am Platze - aber das werde ich überleben :)
sorry, aber ich versteh' Dich nicht. Was hat das mit Design oder Nazi zu tun? Die Realität sieht doch so aus, daß es einfach genug Anwender gibt, denen es sowas von schei**egal ist, mit welchem Browser sie unterwegs sind; die wissen oft nicht einmal, daß es so etwas wie einen Browser gibt, für die ist das IE6-Symbol am Desktop identisch mit dem Zugang zum Internet an sich. Das ist die eine Seite, die andere Seite sind Nutzer in Firmen, die Rechner nutzen, auf denen der IE6 (und nur der) einfach d'rauf ist. Macht zusammen ein Menge theoretischer Besucher, die Deine Seite mit dem IE6 besuchen könnten. Und gerade bei denen geht Dein Belehrungsschildchen wegen mangelnder IT-Kompetenz auf der einen und mangelnder Änderungsmöglichkeit auf der anderen Seite komplett ins Leere.
Bleibt zu erwähnen, daß das von Dir monierte Problem der Mehrarbeit ja keineswegs auf den IE6 beschränkt ist. Für Webapplikationen etc. sind alle IE dank ihrer eingeschränkten DOM- und Eventmodellfähigkeiten und so weiter eine Mehrarbeitskatastrophe. Es kann mir auch beim IE8 noch immer nicht wurscht sein, ob irgendein Element "Layout" hat oder nicht und und und..., dagegen sind die diversen CSS- oder HTMLBugs des IE6 eine Lapalie, schick den IE6 doch einfach in den Quirksmodus oder hol' ihn da raus, Layout oder Design ist wesentlich mehr Besuchern egal als es User gibt, die den IE6 nutzen - vielleicht solltest Du ja mehr Zeit in Dein Konzept investieren als in Möglichkeiten, den IE6-Anwender vor den Kopf zu stossen...
-
-
-
… und Ihr solltet es auch tun :)
Warum soll ich deine destruktive Energie unterstützen?
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische -
Hi,
… und Ihr solltet es auch tun :)
ich werd's meinem Chef weitergeben, dass wir künftig Kunden, die ein paar hundert Fahrzeuge bei uns leasen, keine B2B-Plattform mehr anbieten, weil deren Admins die Software nicht updaten.
Bastele mal schön an Deiner Heimatseite und träum weiter...
Gruesse, Joachim
--
Am Ende wird alles gut. -
Hotti grüßt Dich und Euch alle,
… und Ihr solltet es auch tun :)
Genauh! Unglaublich, wie viele Idioten mit kaputten Browsern durch die Gegend kutschen. Ich fordere einen Tüfff!!! Am besten unterschrieben vom Innenministerium und mit Stempel und Fingerabdruck von Scheuble.
In browserupdate.gif:
Btw., der Link in dem Giv geht nicht zu klicken.
Grüße von Hotti
--
Der Mörder muss kurzsichtig sein. Alle Opfer wurden aus nächster Nähe erschossen.-
Hello,
Btw., der Link in dem Giv geht nicht zu klicken.
*rotfl*
Das liegt am Browser :-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
Btw., der Link in dem Giv geht nicht zu klicken.
*rotfl*
Das liegt am Browser :-)
Oder an meiner Mauss. Seitdem ich die mal über Nacht auf der Terasse hab liegen lassen, fehlt der Schwanz. War bestimmt die doofe Katze von Adolf (unser Nachbar).
Viele Grüße ;-)
Rolf--
Gib nicht dem Nachbarn die Schuld, wenn Du einen Kater hast.
-
-
-
habe d'ehre
… und Ihr solltet es auch tun :)
Schade, kein Link angegeben. Ich hätte schon gerne gesehen, welch revolutionäre und innovative Webseite hier den Leuten vorenthalten wird. ;)
Wilhelm
-
… und Ihr solltet es auch tun :)
Nach den ganzen Kritikern, hier mal mein Senf:
Ich geb Dir 100% recht!
Grüße, Klaus
-
Hallo,
herzlichen Glückwunsch, dass Du die Regeln 2, 4 und 57 von Goldhtml (ja, ja, ist schon etwas angestaubt. 12 Jahre alt und manches stimmt in der Tat nicht mehr ...) so gewissenhaft befolgst. Von der Intention stimmst Du mit Regel 58 überein!
… und Ihr solltet es auch tun :)
Ich werd's lieber bleiben lassen.
Ablehnende Grüße
Vinzenz