nicht angemeldet
Gunnar Bittersmann
suit
Gunnar Bittersmann
suit
suit
Gunnar Bittersmann
suit
molily
Gunnar Bittersmann
molily
Struppi
Struppi
MudGuard
suit
Hallo,
ich möchte gerne die Conditional Comments mit einbringen doch das klappt irgend nicht, so wie es auf all den Seiten im Internet steht. Kann mir einer helfen?
Quellcode html.datein:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<title>Test</title>
<script type="text/javascript" src="js/prototype.js"></script>
<script type="text/javascript" src="js/scriptaculous.js?load=effects,builder"></script>
<script type="text/javascript" src="js/lightbox.js"></script>
<link rel="stylesheet" href="css/lightbox.css" type="text/css" media="screen" />
<link rel="stylesheet" type="text/css" href="css/layout.css" />
<style type="text/css">
#boxnavi2 {margin-top:815px; }
<!--[if IE6]><link rel="stylesheet" type="text/css" href="css/layout_ie6.css" /><![endif]-->
</style>
</head>
<body>
... Textinhalte der einzelen Boxen
</body>
</html>
Quellcode layout_ie6.css:
@charset "ISO-8859-1";
/* CSS Document */
body {
height:; background-image:url(../images/hgr.gif);
background-repeat:no-repeat;
margin:0; padding:0;
font-family:Verdana, Arial, Helvetica, sans-serif; font-size:14px; }
#boxlogo {
position:absolute;
margin-top:10px; margin-left:5px;
height:180px;
width:150px; }
weitere Boxen...
Mfg
Sam
Mahlzeit Sam,
ich möchte gerne die Conditional Comments mit einbringen doch das klappt irgend nicht, so wie es auf all den Seiten im Internet steht.
Doch, Du musst es nur <http://de.selfhtml.org/css/layouts/browserweichen.htm#alternative@title=richtig machen> ... kleiner Tipp: manchmal haben Leerzeichen doch eine Bewandnis.
Kann mir einer helfen?
Du selbst. :-)
MfG,
EKKi
ich möchte gerne die Conditional Comments mit einbringen doch das klappt irgend nicht, so wie es auf all den Seiten im Internet steht. Kann mir einer helfen?
Auf den "IE 6" statt "IE6" wurdest du ja schon hingewiesen.
Ich möchte dir noch eine andere Strategie vorstellen.
Wenn du im body ein div mit einer id setzt, welche mittels Conditional Comments nur der IE sieht, dann kannst du alles im gleichen CSS File notieren wie folgt:
<body id="body">
<!--[if IE 7]><div id="msie7"><![endif]-->
<!-- hier der normale HTML Code -->
<!--[if IE 7]></div><![endif]-->
</body>
~~~und im CSS kannst du dann
schreiben:
~~~css
.someclass{display:inline-block;}
#msie7 .someclass{ display:inline}
Ich finde das besser zu warten, als Anweisungen über zig Files verstreut zu editieren.
Contra kann vielleicht der Umfang der Korrekturen sein.
mfg Beat
@@Sam:
ich möchte gerne die Conditional Comments mit einbringen
Warum??
Warum schreibst du Anpassungen für IEs nicht per '* html'-Hack (IE 6) bzw. '*:first-child+html'-Hack (IE 7) in _das eine_ Stylesheet?
„Conditional Comments (CC) stellen »by design« ein Wartbarkeitsproblem dar.“ [Meiert]
Live long and prosper,
Gunnar
„Conditional Comments (CC) stellen »by design« ein Wartbarkeitsproblem dar.“ [Meiert]
Lieber Gunnar
Hast du meinen Vorschlag zur Kenntnis genommen?
Ich gebe dir dann recht, wenn es sich um viele statische Seiten handelt, in die du nachräglich diese Comments einarbeiten musst.
Im Rahmen eines dynamisch zusammengebauten HTML Textes sehe ich da aber keinen Einwand. Und ...
#msie7
ist einfach viel klarer, für jeden der es liest.
mfg Beat
„Conditional Comments (CC) stellen »by design« ein Wartbarkeitsproblem dar.“ [Meiert]
Nicht alles, was Meiert so vonsicht gibt ist wirklich gut :)
IMHO sind CSS-Hacks ein Wartbarkeitsproblem - jede Sonderlösung für jeden Browser (auch wenn dadurch Redundanzen entstehen) sind wesentlich übersichtlicher.
Hi suit!
IMHO sind CSS-Hacks ein Wartbarkeitsproblem - jede Sonderlösung für jeden Browser (auch wenn dadurch Redundanzen entstehen) sind wesentlich übersichtlicher.
Die Übersichtlichkeit ist ja kein Argument, bzw. als Argument in dieser Diskussion völlig fehl am Platze. Es geht um die Wartbarkeit.
Wieso soll ich mein HTML-Markup verhunzen, wenn ich Belange des Aussehens und des Designs einfach ins CSS auslagern kann?
Wie organisierst du denn deine Scripte? Würde es dich nicht unheimlich nerven, wenn du auch noch die JavaScripte über CC auslagerst?
Wäre das nicht ebenfalls eine Konsequenz, die du in Kauf nehmen müsstest?
Dann bräuchtest du schließlich auch keine Weichen für behinderte Browser, oder?
Schreibst du die ganzen Frameworks und Bibliotheken um, damit sie in das CC-Konzept passen?
Ehrlich gesagt geht mir der Sinn der CC nicht auf. Ich arbeite mit CSS-Hacks und fahre gut damit. Das Gehuddel mit extra Stylesheets für jede IE-Version kommt mir nicht in die Tüte. Bah! *schüttel*
MfG H☼psel
IMHO sind CSS-Hacks ein Wartbarkeitsproblem - jede Sonderlösung für jeden Browser (auch wenn dadurch Redundanzen entstehen) sind wesentlich übersichtlicher.
Die Übersichtlichkeit ist ja kein Argument, bzw. als Argument in dieser Diskussion völlig fehl am Platze. Es geht um die Wartbarkeit.
Eben. Wartbarkeit kann Übersichtlichkeit bedeuten.
Wieso soll ich mein HTML-Markup verhunzen, wenn ich Belange des Aussehens und des Designs einfach ins CSS auslagern kann?
Die Schönheit des HTML braucht durch zwei Conditional Comments nicht zu leiden.
Die Schönheit des CSS kann mit Hacks schiffbruch erleiden. Siehe unten.
Wie organisierst du denn deine Scripte? Würde es dich nicht unheimlich nerven, wenn du auch noch die JavaScripte über CC auslagerst?
Alles vermischen ist kein guter Diskussionsstil. Es geht hier um den Vorzug von CC, die als zuverlässige Methode nun mal da sind.
Ehrlich gesagt geht mir der Sinn der CC nicht auf. Ich arbeite mit CSS-Hacks und fahre gut damit. Das Gehuddel mit extra Stylesheets für jede IE-Version kommt mir nicht in die Tüte. Bah! *schüttel*
Ich glaube der Streit lässt sich nicht lösen. Man muss entscheiden auf der Basis des Umfangs des CSS.
Wenn das CSS zu gross wird, ist es gerechtfertigt, separate Files zu senden, aber jene Browser, die sie nicht brauchen, nicht zu belasten.
Bei kleineren Files finde ich ALL-IN-ONE Wartungsfreundlich.
Allerdings befremden mich CSS-Hacks. Sie sind keine Methoden. Sie sind nur Hacks deren Kolateralschaden unbekannt genug ist, dass man sie verwendet.
mfg Beat
@@Beat:
Allerdings befremden mich CSS-Hacks. Sie sind keine Methoden. Sie sind nur Hacks deren Kolateralschaden unbekannt genug ist, dass man sie verwendet.
??
* html foo {bar: baz} hat keinen Kollateralschaden. Punkt.
Kein vernünftiger Browser sieht das 'html'-Element als Nachfahre eines anderen Elements an. Auch in zukünftige Browser wird solch Unsinn nicht implementiert werden. Damit ist das für alle Ewigkeiten als Angabe nur für IE < 7 brauchbar.
Allerdings wären mir conditional comments in CSS(!!) auch lieber als Hacks: http://forum.de.selfhtml.org/archiv/2009/2/t183832/#m1218554
Auf der Suche nach dem Posting bin ich doch glatt auf http://forum.de.selfhtml.org/archiv/2008/1/t164983/#m1075845 gestoßen. Count me as converted.
Live long and prosper,
Gunnar
Auch in zukünftige Browser wird solch Unsinn nicht implementiert werden.
Absichtlich vielleicht nicht - aber es gibt immer wieder newcomer-Browser die CSS magelhaft bis garnicht unterstützen - ich würde mich jedenfalls nicht darauf verlassen :).
Wohlgemerkt dürfte der Star-HTML-Hack sehr sehr sicher sein.
* html foo {bar: baz}hat keinen Kollateralschaden. Punkt.
Kein vernünftiger Browser sieht das 'html'-Element als Nachfahre eines anderen Elements an. Auch in zukünftige Browser wird solch Unsinn nicht implementiert werden. Damit ist das für alle Ewigkeiten als Angabe nur für IE < 7 brauchbar.
Es hilft mir leider nicht, an die Vernunft zu appelieren. Und an deine Erfahrung bezüglich Hacks reiche ich nicht heran.
Didaktisch gesehen sind einfach CCs sehr viel vorteilhafter.
Count me as converted.
Ich finde es eigentlich schade, dass man hier schon beinahe einen Glaubenskrieg veranstaltet. Schliesslich geht es doch um das im Kontext und für den Autoren geeignete Mittel.
mfg Beat
»» IMHO sind CSS-Hacks ein Wartbarkeitsproblem - jede Sonderlösung für jeden Browser (auch wenn dadurch Redundanzen entstehen) sind wesentlich übersichtlicher.
Die Übersichtlichkeit ist ja kein Argument, bzw. als Argument in dieser Diskussion völlig fehl am Platze. Es geht um die Wartbarkeit.
Übersichtlichkeit = Wartbarkeit - wenn ich für Alle Browser ein Stylesheet habe und für die Extrawürste des IE6 ein weiteres, für die Extrawürste des IE7 noch ein ergänzendes usw ist das für mich Übersichtlicher und Wartbarer.
Ich denke ich hab' mich da etwas unklar ausgedrückt:
Wieso soll ich mein HTML-Markup verhunzen, wenn ich Belange des Aussehens und des Designs einfach ins CSS auslagern kann?
Wer hat das gesagt? Folgendes stellt die von mir bevorzugte Lösung dar - das ist nur unwesentlich mehr HTML als in deinem Fall. Klar ist das ein HTTP-Request mehr bei den IEs, aber imho vertretbar und ich hab' alle Extrawürste für einen Browser gesammelt in einem File.
<link rel="stylesheet" type="text/css" href="css/screen.css" media="screen, projection" />
<!--[if ie 6]><link rel="stylesheet" type="text/css" href="css/screen_ie6.css" media="screen, projection" /><![endif]-->
<!--[if ie 7]><link rel="stylesheet" type="text/css" href="css/screen_ie7.css" media="screen, projection" /><![endif]-->
Wie organisierst du denn deine Scripte? Würde es dich nicht unheimlich nerven, wenn du auch noch die JavaScripte über CC auslagerst?
Warum? JavaScript liefert keine Stilinformationen mit - das schaltet idR. nur Klassen hin und her - wenn irgend ein IE eine Extrawurst benötigt, kommt das in sein CSS-File :)
Wäre das nicht ebenfalls eine Konsequenz, die du in Kauf nehmen müsstest?
Dann bräuchtest du schließlich auch keine Weichen für behinderte Browser, oder?Schreibst du die ganzen Frameworks und Bibliotheken um, damit sie in das CC-Konzept passen?
Nein, das ist davon nicht betroffen
in deinm Fall heissts meinetwegen .jsfeatureein und .jsfeatureaus sowie #msie6 .jsfeatureein und #msie6 .jsfeatureaus - in meinem Fall gibts halt 2x die Variante 1 - 1x für alle Browser und 1x in screen_ie6.css, Falls die extrawurst nötig ist.
Mit umsichtigem CSS (allgemein) komme ich da idR. (bei einer 08/15-Webseite) auf 500 bis 750 Zeilen, rund 25 Zeilen für den IE6 (in seinem CSS) und etwa 10 Zeilen für IE 7 aus (in seinem CSS-File).
Ehrlich gesagt geht mir der Sinn der CC nicht auf. Ich arbeite mit CSS-Hacks und fahre gut damit. Das Gehuddel mit extra Stylesheets für jede IE-Version kommt mir nicht in die Tüte. Bah! *schüttel*
Wie bereits erwähnt bekommt nicht jeder Browser ein eigenes CSS-File, der IE6 und 7 bekommen exakt das selbe vorgesetzt wie alle anderen Browser - nur für ein paar winzige Dinge bekommen sie andere, ergänzende Regeln, die gemäß der Spezifität überschrieben werden.
@@suit:
Wer hat das gesagt? Folgendes stellt die von mir bevorzugte Lösung dar - das ist nur unwesentlich mehr HTML als in deinem Fall. Klar ist das ein HTTP-Request mehr bei den IEs, aber imho vertretbar und ich hab' alle Extrawürste für einen Browser gesammelt in einem File.
Aha. Und bei Änderungen musst du u.U. 3 Dateien anfassen: screen.css, screen_ie6.css und screen_ie7.css. Gute Wartbarkeit ist für mich was anderes.
Live long and prosper,
Gunnar
Gute Wartbarkeit ist für mich was anderes.
Gute Wartbarkeit heisst eben nicht immer "schnell alles in einem File finden" - dass ich unter Umständen drei Files anfassen muss, ist kein Gegenargument.
Ansonsten würde sämtliche software auf dieser Welt aus einem File bestehen :p
Gute Wartbarkeit ist für mich was anderes.
Gute Wartbarkeit heisst eben nicht immer "schnell alles in einem File finden" - dass ich unter Umständen drei Files anfassen muss, ist kein Gegenargument.
Ich denke, das ist von deinem Editor abhängig.
Ich bekomme des öfteren den Fenster-Groove. Es ist für mich wirklich übersichtlicher, in einem File zu arbieten und die Folding Methoden des Editors zu verwenden (die im leider verstorbenen JEdit viel besser waren als im aktuellen Notepad++).
Ein weiterer Punkt betrifft die Cascading Rules.
Wenn ich alles im gleichen File habe, dann werden die MSIE Korrekturen in der logischen Folge und nach den sofort übersehbaren Regeln angefasst.
Wenn ich aber ein extra MSIE-File betreibe, dann werden diese Regeln später eingebunden. Es gelten unter Umständen nicht mehr die gleichen Cascading Abfolgen der Verarbeitung.
mfg Beat
Mahlzeit Gunnar Bittersmann,
Aha. Und bei Änderungen musst du u.U. 3 Dateien anfassen: screen.css, screen_ie6.css und screen_ie7.css.
Öhm, nein. Bzw. nur dann, wenn sich aus den generellen Änderungen in der Datei "screen.css" wieder Probleme mit dem IE in irgendeiner Version ergeben. Dann müsste man aber auch an zwei Baustellen (in einer Datei) basteln, wenn man alles in einem Stylesheet hat.
Ich finde ein sauberes Stylesheet, in dem keine das Verständnis erschwerenden Sonderlocken für irgendwelche speziellen Browser enthalten sind, sondern nur die für alle geltenden grundlegenden Layout-Bestimmungen, hat etwas für sich.
Gute Wartbarkeit ist für mich was anderes.
Was denn z.B.?
MfG,
EKKi
@@EKKi:
Dann müsste man aber auch an zwei Baustellen (in einer Datei) basteln, wenn man alles in einem Stylesheet hat.
Die Stellen, an denen gebaut wird, liegen aber unmittelbar untereinander, so dass ich da von einer Baustelle sprechen würde.
Oder sind Fundament und Wände bei einem Hausbau verschiedene Baustellen?
»» Gute Wartbarkeit ist für mich was anderes.
Eine Baustelle anstatt drei.
Live long and prosper,
Gunnar
Oder sind Fundament und Wände bei einem Hausbau verschiedene Baustellen?
Natürlich sind das verschiedene Baustellen die auch Teilweise von verschiedenen Spezialisten betreut werden. Das Dach macht der Tachtecker, den Estrich auf der Bodenplatte macht ein Estrichleger - die Wände stellt ggf. ein Zimmerer auf (Holzwände) und die Fenster bekommt man vom Gaulhofer :)
Eine Baustelle anstatt drei.
Drei Baustellen die nebeneinander sind, wo sich die Handwerker ggf. gegenseitig auf die Finger treten sind manchmal schlechter als 3 Baustellen etwas weiter auseinander :)
Man kennt das von Autobahnbaustellen und ausfahrten - was ist dir lieber, eine 15-Kilometer-Baustelle ohne Ausfahrt oder 3 Stück 15-Kilometerbaustellen mit je einer Ausfahrt dazwischen?
Ach wie ich schlechte Vergleiche liebe :p
bei Änderungen musst du u.U. 3 Dateien anfassen
Muss ich nicht zwangsläufig, nur wenn sich etwas ändert, was einen geänderten Fix in IE 6 und 7 nach sich zieht - das ist selten der Fall, wenn man nicht gerade das Layout ändert.
Und selbst wenn ich drei Dateien anfassen muss: Ja, und? Ob ich drei Dateien öffne, darin nach einem Selektor suche bzw. einen Selektor hinzufüge, oder in einer Datei die entsprechenden Abschnitte mit den Selektor-Hacks suche - das fällt m.M.n. überhaupt nicht ins Gewicht bzw. wiegt für mich überhaupt nicht die Vorteile auf, die ich durch eine zentrale Einbindung von browserspezifischen Styles habe - im Gegensatz zur hundertfachen Wiederholung derselben Selektor-Hacks.
Mathias
Mahlzeit Hopsel,
Wieso soll ich mein HTML-Markup verhunzen, wenn ich Belange des Aussehens und des Designs einfach ins CSS auslagern kann?
Wieso soll ich meine CSS-Anweisungen für ALLE Browser verhunzen (und damit Warnungen, Hinweise usw. erzeugen), wenn ich gezielt nur mangelhaften Exemplaren Sonderlösungen vorsetzen kann?
Wie organisierst du denn deine Scripte? Würde es dich nicht unheimlich nerven, wenn du auch noch die JavaScripte über CC auslagerst?
Du wirst lachen - aber genau das habe ich teilweise gemacht:
[...]
<head>
[...]
<link rel="stylesheet" type="text/css" media="screen" href="/styles/screen.css">
<!--[if IE]>
<link rel="stylesheet" type="text/css" media="screen" href="/styles/screen_IE.css">
<script type="text/javascript" src="/scripts/IE.js"></script>
<![endif]-->
</head>
[...]
Damit bekommen vernünftige Browser nur die allgemeinen CSS-Anweisungen. Internet Explorer bekommen ihre Sonderlocken (innerhalb der Datei "screen_IE.css" mittels entsprechende Hacks für jede Version gesondert) und in der Javascript-Datei kann ich bei zu alten Versionen (< 7) z.B. onmouseover-Events hinzufügen, die entsprechende Klassen setzen, damit einigermaßen passable Hover-Effekt möglich sind.
Schreibst du die ganzen Frameworks und Bibliotheken um, damit sie in das CC-Konzept passen?
Ich mache das schon eine Weile so, habe entsprechende Vorlagen bzw. Templates und es scheint ganz passabel zu funktionieren. Es sind nur 4 Zeilen, die im Kopf jeder HTML-Datei auftauchen müssen (der meistens aus entsprechenden Vorlagen bzw. Templates kommt oder per PHP gebildet wird).
Ehrlich gesagt geht mir der Sinn der CC nicht auf. Ich arbeite mit CSS-Hacks und fahre gut damit.
Ich mit beidem.
Das Gehuddel mit extra Stylesheets für jede IE-Version kommt mir nicht in die Tüte. Bah! *schüttel*
Nicht für jede Version ein extra-Stylesheet - lediglich für den IE an sich. Innerhalb des extra-IE-Stylesheets kann man dann ja mit geeigneten CSS-Hacks die jeweiligen Versionen "reparieren". Ich sehe keine Notwendigkeit, vernünftige Browser mit ungültigem CSS-Code zu belästigen.
MfG,
EKKi
Wieso soll ich mein HTML-Markup verhunzen, wenn ich Belange des Aussehens und des Designs einfach ins CSS auslagern kann?
Wieso soll ich meine CSS-Anweisungen für ALLE Browser verhunzen (und damit Warnungen, Hinweise usw. erzeugen), wenn ich gezielt nur mangelhaften Exemplaren Sonderlösungen vorsetzen kann?
Weil es sowieso geschieht, wenn Opera über ein -moz-some-property motzt.
mfg Beat
Weil es sowieso geschieht, wenn Opera über ein -moz-some-property motzt.
Ich dachte Opera wär soweit standarkonform, dass man nicht über standardkonformes CSS motzt :)
Wie organisierst du denn deine Scripte? Würde es dich nicht unheimlich nerven, wenn du auch noch die JavaScripte über CC auslagerst?
Was ist das für ein Vergleich?
Wenn ich Scripte habe, die nur im IE ausgeführt werden sollen: Dann binde ich sie natürlich mit CC ein.
Einem browserübergreifenden Script stehen viel bessere Möglichkeiten zur Verfügung, auf den Browser zu reagieren - durch Objektabfragen, durch Testcases, durch Conditional Compilation und viel mehr. CCs, die auf Browserversionen abzielen, und Selektor-Hacks sind dagegen ein Witz. Aber im Bereich CSS hat man eben nicht die Möglichkeiten von JavaScript. Selbst wenn: Die Browserfehler sind bei CSS einfach ganz anders geartet, sodass man die Modelle schwer aufeinander übertragen kann.
Mathias
Hi molily!
Wie organisierst du denn deine Scripte? Würde es dich nicht unheimlich nerven, wenn du auch noch die JavaScripte über CC auslagerst?
Was ist das für ein Vergleich?
Manchmal dürft ihr mich einfach nicht zu ernst nehmen. Ich habe maßlos übertrieben. =)
Ich denke, dass beide Varianten, CCs und CSS-Hacks, abhängig vom Projekt, zu vollkommen befriedigenden Lösungen führen.
Letztendlich erinnert mich die ganze Diskussion an die Spitz- und die Dickender aus Gullivers Reisen. ;-)
Aber Grundsatzdiskussionen werden nirgendwo so ausführlich und bereichernd geführt wie im Selfhtml-Forum. Und ich habe viel Freude beim Lesen der Antworten.
Trotzdem habe ich Recht! Vielleicht...
MfG H☼psel
@@suit:
Nicht alles, was Meiert so vonsicht gibt ist wirklich gut :)
Wenn’s um den HTML-5-Hype geht, geb ich dir recht. ;-)
IMHO sind CSS-Hacks ein Wartbarkeitsproblem - jede Sonderlösung für jeden Browser (auch wenn dadurch Redundanzen entstehen) sind wesentlich übersichtlicher.
Ich finde es wesentlich übersichtlicher, nicht alle Regeln für einen bestimmten Browser ortsnah zu haben, sondern alle Regeln für einen bestimmten Selektor (Elementtyp, Klasse, ID, …).
Live long and prosper,
Gunnar
Ich finde es wesentlich übersichtlicher, nicht alle Regeln für einen bestimmten Browser ortsnah zu haben, sondern alle Regeln für einen bestimmten Selektor (Elementtyp, Klasse, ID, …).
Ja, im Prinzip wäre das optimal, wenn der Aufwand, der sich daraus ergibt, einem die Sache nicht verleiden würde. Ich muss nämlich immer wieder denselben Aufbau wiederholen: Eine Kommentierung, die klar macht, dass dieser Bereich ein Browser-Bugfix ist, auf welchen Browser aufgezielt wird und den Bug beschreiben. Dann ein spezieller Selektor- oder Syntax-Hack, die Site-weit einheitlich sein sollten. Die »Browsererkennung« wird also an dutzenden Stellen wiederholt und ich muss mich um die korrekte Einbindung kümmern. Zudem bin ich komplett an Selektor- oder Syntax-Hacks gebunden und kann keine proprietären Eigenschaften wie zoom oder filter verwenden, ohne das Stylesheet invalide zu machen.
Mathias
Zudem bin ich komplett an Selektor- oder Syntax-Hacks gebunden und kann keine proprietären Eigenschaften wie zoom oder filter verwenden, ohne das Stylesheet invalide zu machen.
Es gibt keine invaliden Stylesheets.
Es gibt eine Beschreibung wie Browser mit Regeln umzugehen haben, die sie nicht kennen, oder wie sie mit Verletzungen von Regeln umgehen sollen, die sie implementiert haben.
Es gibt keine validen Stylescheets, weil du keine Version angeben kannst, nach der validiert werden soll.
Was du als valide bezeichnest, ist ein optimales Stylesheet, in dem ein Maximum an Code auch interpretiert wird.
mfg Beat
Es gibt keine validen Stylescheets, weil du keine Version angeben kannst, nach der validiert werden soll.
Bei der Validierung gebe ich sie an. Wo auch sonst?
Was du als valide bezeichnest, ist ein optimales Stylesheet, in dem ein Maximum an Code auch interpretiert wird.
Nein.
Ich bezeichne ein CSS-konformes Stylesheet als valide. Wenn ich »praxistauglich« und »funktionsfähig« gemeint hätte, hätte ich das auch gesagt.
Die Verwendung von nicht in CSS definierten, proprietären Eigenschaften wie zoom oder filter ist praktisch kein Problem, weil andere Browser sie einfach ignorieren - das ist mir klar. Habe ich Gegenteiliges behauptet? Ich habe gesagt, dass man solche Stylesheets nicht validieren kann. Nicht mehr, nicht weniger.
Mathias
Es gibt eine Beschreibung wie Browser mit Regeln umzugehen haben, die sie nicht kennen, oder wie sie mit Verletzungen von Regeln umgehen sollen, die sie implementiert haben.
fürs Protokoll:
Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification
W3C Candidate Recommendation 19 July 2007
4. Syntax and basic data types
4.2 Rules for handling parsing errors
Es ist ein Unterschied, ob ein CSS-File syntaktisch korrekt ist oder ob es den verfügbaren Eigenschaften und Werten einer bestimmten Revision folgt.
Es gibt keine validen Stylescheets, ...
Dazu passend hab ich mal einen interessanten Artikel gefunden
Struppi.
Es gibt keine validen Stylescheets, ...
Dazu passend hab ich mal einen interessanten Artikel gefunden
Kernsatz dort:
»Wenn die Menge der geprüften formalen Anforderungen größer ist als die Vorgabe der Spezifikation und kleiner als ›vollständig‹, dann kann man diesen Prozeß nicht mehr ›validieren‹ nennen.«
Boah, das ist ja mal was ganz neues, dass formale Grammatiken die gesamten Erfordernisse der technischen Spezifikationen, mit denen wir zu tun haben, gar nicht abdecken können! Wer hätte das gedacht: Validierung ist nicht gleich standardkonform ist nicht gleich sinnvoll!
Äh, Moment mal: wissen wir das nicht schon seit ... ich weiß gar nicht, wie lange lese ich hier schon mit ... mindestens sieben bis acht Jahren?
Mit demselben Argument könnte man auch sagen, es gibt kein valides (X)HTML, weil DTD und selbst XML-Schema und RelaxNG-Grammatik nicht alle Anforderungen der jeweiligen Markup-Sprache abdecken. Dabei ist »valide« im SGML-/XML-Kontext ganz klar definiert und heißt nichts anderes, als diese Konformität zur formalen Grammatik. Dennoch ist anerkannt, dass ein sogenannte HTML-Validator Extraprüfungen macht, die über DTD- bzw. Schema-Validität hinausgehen.
Nun ist die Definition von »valide« im CSS-Standard recht dürftig. Ebenso umfasst der CSS-Standard keine formale Grammatik, die annähernd die Anforderungen der Eigenschafts-Wert-Kombinationen abdeckt. Solche Regeln gibt es natürlich, die kann man dem Standard entnehmen und ein Prüfprogramm dafür schreiben. Dementsprechend weiß jeder, was mit »validem CSS« im allgemeinen Sprachgebrauch gemeint ist.
Die dümmste Konsequenz aus diesen Beobachtungen wäre, den CSS-Validator nicht mehr CSS-Validator zu nennen und zu sagen, man könne CSS gar nicht validieren - weil er ja notwendigerweise »inkonsequent« arbeiten muss, also gar nicht alle Erfordernisse prüfen kann. Nur was sollte das bringen? Ständig auf darauf aufmerksam machen, dass der CSS-Standard in dem Punkt einen Fehler hat, dass der sogenannte Validator weit über die problematische Definition von CSS-Validität hinausgeht und dass manche Regeln einfach nicht automatisiert prüfbar sind?
Mit dem Wort »valide« gibts keine Unklarheiten im allgemeinen Sprachgebrauch, solange einem bewusst ist, dass es kein einmal fest definiertes, ultimatives Verfahren meint, sondern eben eine möglichst gute, aber unvollständige Prüfung der Standardkonformität. Ich sehe kein Problem dabei, das Wort so zu benutzen, und ich denke auch, dass das Wort so benutzt wird, wenn von »Validierung« und »Validator« gesprochen wird. Man sollte deshalb aber auch nicht erbsenzählerisch und äußerst technizistisch ein Sprechverbot aufstellen und das Wort »valide« verbannen, solange es nicht hunderprozentige Standardkonformität bedeutet.
Mathias
Mit dem Wort »valide« gibts keine Unklarheiten im allgemeinen Sprachgebrauch, solange einem bewusst ist, dass es kein einmal fest definiertes, ultimatives Verfahren meint, sondern eben eine möglichst gute, aber unvollständige Prüfung der Standardkonformität. Ich sehe kein Problem dabei, das Wort so zu benutzen, und ich denke auch, dass das Wort so benutzt wird, wenn von »Validierung« und »Validator« gesprochen wird. Man sollte deshalb aber auch nicht erbsenzählerisch und äußerst technizistisch ein Sprechverbot aufstellen und das Wort »valide« verbannen, solange es nicht hunderprozentige Standardkonformität bedeutet.
Ich betrachte den W3C Tester wie auch die diversen Browser-Fehler-Konsolen als Debugging Tools. Der W3C Tester mag die Qualität haben, dass du ihm ein bestimmtes Lexikon wählen kannst. In der Praxis ist das aber irrelevant, weil das Lexikon der konkreten Browser genau so gut ist. "Valides" CSS ist ja nicht das Ziel, sondern effektives CSS.
Wenn ich dabei ein paar MSIE Sonderregeln anführe, die der CSS Validator nicht kennt, die aber effektiv nicht zur Invalidität des CSS insgesamt führen, weil CSS mit Fehlertoleranz konzipiert wurde, dann betone ich die praktische Seite von CSS.
Ob ich nun den W3C Validator oder die Browser-Fehlerkonsole zu Hilfe nehme, damit ich Typos von Absicht unterschieden kann... mir ist letzteres lieber.
Ich habe diese kleine Kontroverse eröffnet weil du gerne eine "valide" Version wolltest (MSIE Eigenschaften bleiben ausgesondert). Andere Stimmen wollten nicht die Fehlerkonsole voller Nachrichten. Ich habe da spöttisch eingeworfen: Auch Opera motzt über -moz-some-prop.
Die Vorstellung von einem CSS, dass auf einer utopischen Instanz abgesegnet sei, ist für mich Praxisfern. Ich lese CSS mit Verstand. ich lasse es mir nicht ungelesen in eine Note einpacken.
Ich habe diese kleine Kontroverse eröffnet weil du gerne eine "valide" Version wolltest
Erstmal zur Klarstellung: Ich habe bisher überhaupt nicht gesagt, was ich will - das kommt auch ganz auf die Umstände an, welche Methoden ich selbst wählen und empfehlen würde -, sondern bloß darauf hingewiesen, dass eine Validierung erschwert wird, wenn man proprietäre Eigenschaften (v.a. ohne Vendor-Präfix) im Haupt-Stylesheet verwendet wird. Das verhält sich ähnlich zu diesem Nachteil:
Andere Stimmen wollten nicht die Fehlerkonsole voller Nachrichten.
Ich will gleichsam die Fehlermeldungen des Validators möglichst nicht voller Fehlermeldungen habe, wo gar keine wirklichen Fehler sind, sondern absichtlich von mir für bestimmte Browser eingefügte Deklarationen. Das ist ein Grund, warum ich IE-spezifische Eigenschaften in den Fällen auslagere , in denen ich von der Validierung oft Gebrauch mache.
Ich habe da spöttisch eingeworfen: Auch Opera motzt über -moz-some-prop.
Tja, das ist schlicht ein Opera-Fehler, der dem Seitenautor meistens wenig hilft.
Mathias
»» Es gibt keine validen Stylescheets, ...
Dazu passend hab ich mal einen interessanten Artikel gefunden
Nach meinem Veständnis (und der Wikipedia ;) bezeichnet „Verifikation“ das Testen gegen eine formale Spezifikation (worauf der Autor im Artikel abhebt), „Validierung“ dagegen ist eine Form der Plausibilitätskontrolle, die sicher stellt, dass der beabsichtigte Einsatzzweck erfüllt wird. Insofern könnte man schon von „validen“ Stylesheets sprechen.
„Conditional Comments (CC) stellen »by design« ein Wartbarkeitsproblem dar.“ [Meiert]
Hast du dir diese Argumentation überhaupt angesehen, die diese zitierte These belegen soll? Wenn ja, welche Argumente findest du stichhaltig?
Mathias
@@molily:
»» „Conditional Comments (CC) stellen »by design« ein Wartbarkeitsproblem dar.“ [Meiert]
Hast du dir diese Argumentation überhaupt angesehen,
Die Frage war rhetorisch?
Wenn ja, welche Argumente findest du stichhaltig?
„CC sollten vermieden werden, da sie […] mit wesentlich höherer Wahrscheinlichkeit HTML-Änderungen bedeuten, sobald eine neue Version des Internet Explorers erscheint, eine alte geht, oder vielleicht »einfach nur« IE-Stylesheets neu arrangiert werden.“
„Irgendeine Änderung einer Deklaration im »Haupt-Stylesheet«, die bereits im IE-Stylesheet für den Internet Explorer überschrieben wurde, kann andernfalls Konfusion bedeuten (»warum benimmt sich der IE anders«) […]“ – zumal der IE nicht so gesprächig die Quelle einer Regel angibt wie bspw. Firebug.
„Diese Problematik ist logisch, da das »Prinzip der Nähe« verletzt wird, konzeptionell zusammengehörige Regeln mittels CC getrennt werden.“ – Sagte ich in diesem Thread ja auch schon.
Live long and prosper,
Gunnar
„CC sollten vermieden werden, da sie […] mit wesentlich höherer Wahrscheinlichkeit HTML-Änderungen bedeuten, sobald eine neue Version des Internet Explorers erscheint
Kann ich nicht nachvollziehen. Ich verweise mal auf https://forum.selfhtml.org/?t=185702&m=1232778.
Und wo bitte ist das Problem dabei, eine läppische Zeile in ein Master-Template hinzuzufügen?
eine alte geht
Was soll das bedeuten?
Wenn ich eine alte IE-Version nicht mehr unterstützen will, dann lösche ich den CC und das zugehörige Stylesheet.
Ja, richtig: Dann muss ich im Master-Stylesheet eine Zeile löschen.
Aber wo ist das Problem dabei? Friert die Hölle ein wegen dieser Änderung?
Im Vergleich dazu: Wenn ich IE-spezifische Regeln über 27 Stylesheets verteilt habe, muss ich diese alle editieren, diese Regeln heraussuchen und händisch löschen. Das ist doch nicht einfacher.
oder vielleicht »einfach nur« IE-Stylesheets neu arrangiert werden.“
Was soll da neu arrangiert werden? Wieso sollte ich das tun? Wann kommt das vor?
„Irgendeine Änderung einer Deklaration im »Haupt-Stylesheet«, die bereits im IE-Stylesheet für den Internet Explorer überschrieben wurde, kann andernfalls Konfusion bedeuten (»warum benimmt sich der IE anders«) […]“
Hier sehe ich keinen signifikanten Unterschied:
Wenn ich einen Bereich umformatiere, dann muss ich jeweils darauf achten, was für IE-Fixes für den Bereich gelten.
Bei einem ausgelagerten IE-Stylesheet muss ich dort nachschlagen, ansonsten muss ich im aktuellen Stylesheet nach einem Fix suchen. Klar, der »liegt nahe« und fällt daher eher ins Auge. Dem stimme ich zu.
Es kann also sein, dass mich der naheliegende IE-Fix daran erinnert, ihn zu aktualisieren, wenn ich nicht von selbst daran denke. Aber den Fall, dass ich mich verzweifelt frage, warum sich der IE anders verhält, ohne darauf zu kommen, als erstes im IE-Sylesheet nachzuschauen - den halte ich für ziemlich konstruiert. Der Grund, warum sich der IE (absichtlich) anders verhält, ist doch in erster Linie das IE-Stylesheet - dafür habe ich es eingebunden. Wie kann ich plötzlich vergessen, dass ich IE-Fixes auslagere? ;) Diese besagte Konfusion dauert deshalb ganze 15 Sekunden.
Also, ich finde diesen Fall reichlich hypothetisch und an den Haaren herbeigezogen. Ich kann bestätigen, dass ich oftmals nicht weiß, welche Regeln auf ein Element wirken oder z.B. welche Eigenschaft gerade hasLayout auslöst. Da ist es echt schwierig, die ganze Vererbung im IE 6 ohne ein Tool wie Firebug hinzubekommen. Die IE 7 Developer Toolbar und auch die IE 8 Developer Tools arbeiten m.E.n. ebenfalls nicht ganz korrekt, was das Zurückverfolgen von Styles angeht.
Aber bisher kam es nur sehr, sehr selten vor, dass die Fehldarstellung daher kam, dass im IE-Stylesheet für den jeweiligen Selektor noch veraltete Fixes herumlagen, die nach der Änderung des Haupt-Stylesheets überflüssig und kontraproduktiv geworden sind - und ich partout nicht darauf kam, die Ursache dort zu suchen.
„Diese Problematik ist logisch, da das »Prinzip der Nähe« verletzt wird, konzeptionell zusammengehörige Regeln mittels CC getrennt werden.“ – Sagte ich in diesem Thread ja auch schon.
Ja, das ist ein Argument. Wenn auch kein sonderlich stichhaltiges. Ich wüsste nämlich nicht, wo das Problem besteht, wenn man diese Arbeitsweise verinnerlicht hat. Ich mache das täglich und es ist für die Beteiligten kein Problem, IE-Fixes in die zugehörigen Stylesheets zu schreiben. Es wäre für sie genauso eine Bürde, jedes Mal die richtigen Selektor-Hacks herauszusuchen und die Abgrenzung zu den normalen Styles korrekt vorzunehmen. Klar, auch damit kommt man irgendwann zurecht. Ich halte das für eine Gewöhnungssache. In einem Team muss man sich auf eines einigen. Beides erfordert Einarbeitung, beides hat Schwachstellen.
Was mir die Sache vereinfachen würde, wenn ich häufig gebrauchte Fixes wie zoom:1 als hasLayout-Trigger zum Einschließen von Floats und zur generellen Stabilisierung des Layouts direkt ins Haupt-Stylesheet schreiben könnte - dummerweise macht das das CSS invalide. Ich vergesse es häufig, hasLayout anzuschalten, wenn ich in standardkonformen Browsern einen Block Formatting Context erzeuge. Allerdings glaube ich nicht, dass das Vergessen damit zu tun hat, in welche Datei ich diese Fixes schreibe.
Mathias
@@molily:
Und wo bitte ist das Problem dabei, eine läppische Zeile in ein Master-Template hinzuzufügen?
Was meinst du mit „Master-Template“? Von einem CMS war hier nie die Rede.
Oder meinst du ein Include, in dem alle Stylesheet-Links und CCs stehen und das per SSI oder PHP in alle HTML-Dokumente eingebunden wird?
Wenn ich eine alte IE-Version nicht mehr unterstützen will, dann lösche ich den CC und das zugehörige Stylesheet.
Wenn du ein wie auch immer geartetes „Master-Template“ hast. Wenn du das in allen einzelnen HTML-Dateien tun musst – viel Spaß. Und der wächst mit dem Umfang der Website.
Ja, richtig: Dann muss ich im Master-Stylesheet eine Zeile löschen.
„Master-Stylesheet“?? Was soll das sein? Jedenfalls nicht, wo CCs drin vorkommen können.
Im Vergleich dazu: Wenn ich IE-spezifische Regeln über 27 Stylesheets verteilt habe, muss ich diese alle editieren, diese Regeln heraussuchen und händisch löschen. Das ist doch nicht einfacher.
Wenn schon die Regeln über 27 Stylesheets verteilt sind (was man nicht tun sollte), dann doch so, dass jedes Stylesheet für einen bestimmten Bereich der Seiten zuständig ist und man nur dasjenige Stylesheet (diejenigen wenigen Stylesheets) ändern muss, deren Bereich man gerade neu gestaltet. Und die man gerade sowieso auch für andere Browser bearbeitet.
»» oder vielleicht »einfach nur« IE-Stylesheets neu arrangiert werden.“
Was soll da neu arrangiert werden? Wieso sollte ich das tun? Wann kommt das vor?
Weiß nicht. Vielleicht eine Extrawurst für IE 8 hinzufügen (falls das irgendwann erforderlich sein sollte).
Bei einem ausgelagerten IE-Stylesheet muss ich dort nachschlagen, ansonsten muss ich im aktuellen Stylesheet nach einem Fix suchen. Klar, der »liegt nahe« und fällt daher eher ins Auge. Dem stimme ich zu.
Es kann also sein, dass mich der naheliegende IE-Fix daran erinnert, ihn zu aktualisieren, wenn ich nicht von selbst daran denke. Aber den Fall, dass ich mich verzweifelt frage, warum sich der IE anders verhält, ohne darauf zu kommen, als erstes im IE-Sylesheet nachzuschauen - den halte ich für ziemlich konstruiert.
Ich nicht. Es kam bei mir schon vor, dass ich Extra-Regeln für IEs nicht gleich gesehen habe, obwohl sie per Hacks in dem _einen_ Stylesheet standen.
Der Grund, warum sich der IE (absichtlich) anders verhält, ist doch in erster Linie das IE-Stylesheet - dafür habe ich es eingebunden.
Oder ein Kollege …
»» „Diese Problematik ist logisch, da das »Prinzip der Nähe« verletzt wird, konzeptionell zusammengehörige Regeln mittels CC getrennt werden.“ – Sagte ich in diesem Thread ja auch schon.
Ja, das ist ein Argument. Wenn auch kein sonderlich stichhaltiges.
YMMV.
Ich wüsste nämlich nicht, wo das Problem besteht, wenn man diese Arbeitsweise verinnerlicht hat.
Wenn. Ich denke, es ist leichter, die Arbeitsweise mit einem Stylesheet zu verinnerlichen.
Live long and prosper,
Gunnar
Wenn du ein wie auch immer geartetes „Master-Template“ hast. Wenn du das in allen einzelnen HTML-Dateien tun musst – viel Spaß. Und der wächst mit dem Umfang der Website.
Nö...
Ich verweise nur kurz auf JEdit und den akuellen Notepad+. Die notwendigen Tools sind hier fester Bestandteil der Editoren. Wer da suchen muss, ist betriebsblind.
mfg Beat
Was meinst du mit „Master-Template“?
Na das Template, wo ich den head für eine große Menge an Unterseiten festlege.
Von einem CMS war hier nie die Rede.
So? Also wurde stillschweigend angenommen, dass überhaupt nicht mit Templates gearbeitet wird? Dann war Meierts Aussage also doch nicht so allgemeigültig?
Oder meinst du ein Include, in dem alle Stylesheet-Links und CCs stehen und das per SSI oder PHP in alle HTML-Dokumente eingebunden wird?
Ja, so kann man es auch nennen.
Wenn du ein wie auch immer geartetes „Master-Template“ hast.
Hier wird doch jedem Einsteiger schon empfohlen, mit Includes zu arbeiten. Wieso stellst du es plötzlich als so abwegig hin?
Wenn du das in allen einzelnen HTML-Dateien tun musst – viel Spaß. Und der wächst mit dem Umfang der Website.
Nein. SELFHTML z.B. ist eine riesige Sammlung von statischen HTML-Dokumenten, genauso SELFHTML aktuell. Dateiübergreifendes Suchen/Ersetzen habe ich da über bis zu 1500 Dokumente gemacht. Wenn ich nur eine feste Zeile ersetzen oder einfügen muss, ist das überhaupt kein Problem mit einem mittelmäßigen Editor oder einem Helferprogramm. Da wächst der Aufwand überhaupt nicht.
„Master-Stylesheet“?? Was soll das sein?
Ups, ich meinte natürlich Template.
Wenn schon die Regeln über 27 Stylesheets verteilt sind (was man nicht tun sollte)
Warum nicht?
dann doch so, dass jedes Stylesheet für einen bestimmten Bereich der Seiten zuständig ist
Genau.
und man nur dasjenige Stylesheet (diejenigen wenigen Stylesheets) ändern muss, deren Bereich man gerade neu gestaltet. Und die man gerade sowieso auch für andere Browser bearbeitet.
Richtig, aber das bezog sich auf den von Meiert angesprochenen Fall, dass man eine IE-Version nicht mehr unterstützen will.
oder vielleicht »einfach nur« IE-Stylesheets neu arrangiert werden.“
Was soll da neu arrangiert werden? Wieso sollte ich das tun? Wann kommt das vor?Weiß nicht. Vielleicht eine Extrawurst für IE 8 hinzufügen (falls das irgendwann erforderlich sein sollte).
Und wieso muss ich da die Stylesheets neu arrangieren?
Ich muss wie gesagt höchstens ein IE-8-Stylesheet einfügen - worin ich kein großes Problem sehe.
Ich denke, es ist leichter, die Arbeitsweise mit einem Stylesheet zu verinnerlichen.
Vielleicht kannst du Selektor-Hacks wie »*:first-child+html« aus dem Kopf und tippst CSSDOC-@bugfix-Kommentare im Schlaf. ;)
Mathias
» Wenn schon die Regeln über 27 Stylesheets verteilt sind (was man nicht tun sollte)
Warum nicht?
» dann doch so, dass jedes Stylesheet für einen bestimmten Bereich der Seiten zuständig ist
Genau.
Das heißt also, du hast für angenommene 27 Bereiche unterschiedliche CSS Dateien, aber nur eine für die Hacks? Das ist doch unlogisch, das bedeutet du schleppst alle Hacks für jeden Eventualfall in einer Datei mit rum und was ist wenn sich zwei Hacks von unterschiedlichen CSS Dateien gegenseitig beeinflussen?
Also für mich macht Gunnars vorgehensweise mehr Sinn.
Struppi.
Das heißt also, du hast für angenommene 27 Bereiche unterschiedliche CSS Dateien, aber nur eine für die Hacks?
Ja, die natürlich auch nach den Bereichen der Seite geordnet ist - welche der Ordnung der Bereich-Stylesheets entspricht.
Das ist doch unlogisch
Was wäre logisch? Dass ich weitere 27 IE-Stylesheets anlege?
Okay, meinetwegen wäre das »logisch«, aber welchen Vorteil würde es mir bieten? Ich finde auch in dem einen IE-6-Stylesheet den entsprechenden Teil schnell wieder.
das bedeutet du schleppst alle Hacks für jeden Eventualfall in einer Datei mit rum
Das verstehe ich nicht.
und was ist wenn sich zwei Hacks von unterschiedlichen CSS Dateien gegenseitig beeinflussen?
Was heißt »von unterschiedlichen CSS Dateien«? Alle Hacks stehen ja in einer. Natürlich gibt es da Vererbung, wenn ich z.B. allen .allgemeineKlasse hasLayout gebe, dann ist #spezifischesElement mit .allgemeineKlasse natürlich auch davon betroffen.
Das ist ja auch in den meisten Fällen Absicht - wenn nicht, dann ist aber meine Organisation der Klassen fehlerhaft bzw. manche Regeln sind zu allgemein.
Mathias
Was wäre logisch? Dass ich weitere 27 IE-Stylesheets anlege?
Okay, meinetwegen wäre das »logisch«, aber welchen Vorteil würde es mir bieten? Ich finde auch in dem einen IE-6-Stylesheet den entsprechenden Teil schnell wieder.
Das sagst du, aber bei der angenommen Größe würde ich da Probleme kriegen etwas zu finden, die habe ich z.T. schon bei wesentlich weniger CSS Dateien und das ganz ohne IE Dateien.
» das bedeutet du schleppst alle Hacks für jeden Eventualfall in einer Datei mit rum
Das verstehe ich nicht.
Was? Das es unterschiedliche Hacks gibt? Bei 27 CSS Dateien kommt es eventuell vor, dass ein Bug auf einer Seite auftritt, der auf einer anderen Seite nicht relevant ist.
Was heißt »von unterschiedlichen CSS Dateien«? Alle Hacks stehen ja in einer. Natürlich gibt es da Vererbung, wenn ich z.B. allen .allgemeineKlasse hasLayout gebe, dann ist #spezifischesElement mit .allgemeineKlasse natürlich auch davon betroffen.
Das ist ja auch in den meisten Fällen Absicht - wenn nicht, dann ist aber meine Organisation der Klassen fehlerhaft bzw. manche Regeln sind zu allgemein.
Wie gesagt, ich hatte bisher zuwenig Probleme mit dem IE, als das ich überhaupt auf die Idee gekommen bin eine Extradatei für den anzulegen, daher fallen mir keine konkreten Beispiele ein. Aber wie schon erwähnt, es gibt viele Hacks die height:1% verwenden, was passiert nun, wenn du einem Elemente mit solche einem Hack eine definierte Höhe geben willst? Dann bist du erstmal am suchen
Struppi.
es gibt viele Hacks die height:1% verwenden, was passiert nun, wenn du einem Elemente mit solche einem Hack eine definierte Höhe geben willst? Dann bist du erstmal am suchen
Deswegen triggere ich hasLayout immer mit zoom:1. Wenn ich einen anderen zoom-Wert setze, weil ich einen Zoom will, dann bleibt hasLayout.
Wenn ein Element eine feste Höhe hat, »hat« es bereits »Layout«, sodass kein weitere hasLayout-Trigger notwendig ist. Damit ich aber unabhängig davon bin, nehme ich zoom:1, das verbleibt dann als Sicherheit für den Fall, dass ich die feste Höhe mal herausnehme (kann natürlich auch zum Verhängnis werden).
Mathias
Deswegen triggere ich hasLayout immer mit zoom:1.
und hast damit nicht valides CSS ;-)
Wie gesagt, ich hab das bisher so selten gebraucht, dass mir eine separate Datei unnötig erscheint.
Struppi.
So? Also wurde stillschweigend angenommen, dass überhaupt nicht mit Templates gearbeitet wird? Dann war Meierts Aussage also doch nicht so allgemeigültig?
Nicht dass ich ihm das vorwerfen würde, wenn es so wäre - im Gegenteil. Ich halte einige seiner Einwände für zutreffend - und zwar unter bestimmten Bedingungen, in denen ich CCs nicht empfehlen würde bzw. sie als nicht sonderlich vorteilhaft bezeichnen würde.
Leider macht er diese Grundannahmen nicht immer deutlich und differenziert daher zu wenig. Mit einem reißerischen und apodiktischen Stil à la »Why “Conditional Comments” Are Bad, Repeat: Bad« kann man die komplexe Realität natürlich nicht einholen.
Als er diese englischsprachigen Blogposts letztes Jahr geschrieben hat, hat er zurecht viel Kritik geerntet. Dumm nur, dass davon offenbar überhaupt nichts in den zusammenfassenden deutschsprachigen Artikel aus diesem Jahr eingeflossen ist, da war selbst das Fazit in http://meiert.com/en/blog/20080824/to-be-clear/ weitsichtiger.
Deswegen halte ich den Artikel für eine sehr schlechte Diskussionsgrundlage und halte es für daneben, wenn du (Gunnar) hier jeden, der CCs einsetzt, willkürlich mit einem »Warum???« angehst und ihm diese apodiktischen Behauptungen um die Ohren haust. Das ist ungefähr so stupide wie die Imperative »Benutze keine Frames!« (mit Verweis auf den unbrauchbaren Subotnik-Artikel) oder »Benutze keine Layouttabellen!« (mit Verweis auf den unbrauchbaren »Why Tables for layout is stupid«-Artikel).
Mathias
Das ist ungefähr so stupide wie die Imperative »Benutze keine Frames!« (mit Verweis auf den unbrauchbaren Subotnik-Artikel) oder »Benutze keine Layouttabellen!« (mit Verweis auf den unbrauchbaren »Why Tables for layout is stupid«-Artikel).
Zustimmung.
Hier mangelt es leider oft an geeigneteren Imperativen. Sowas wie »You cannot do it by yourselfhtml!« (mit Verweis auf einen Tellerrand) oder »Go bite reality!« (mit Verweisen auf Praxis, Praxis und Praxis).
Viele Grüße
_Dirk
Hier mangelt es leider oft an geeigneteren Imperativen.
(Das war übrigens gar nicht so arrogant gemeint wie es vielleicht klingt.)
Viele Grüße
_Dirk
@@molily:
Hier wird doch jedem Einsteiger schon empfohlen, mit Includes zu arbeiten. Wieso stellst du es plötzlich als so abwegig hin?
Tu ich nicht. Nur war in diesem Thread bis zu meiner Nachfrage noch nicht die Rede von Includes.
Dateiübergreifendes Suchen/Ersetzen habe ich da über bis zu 1500 Dokumente gemacht. Wenn ich nur eine feste Zeile ersetzen oder einfügen muss, ist das überhaupt kein Problem mit einem mittelmäßigen Editor oder einem Helferprogramm. Da wächst der Aufwand überhaupt nicht.
Dateien müssen erstmal in den Editor geladen werden (wenn man das dateiweite Suchen/Ersetzen nicht per Kommandozeile erledigt). Und dann wollen die 1500 Dateien auch noch (per FTP o.ä.) zum Server übertragen werden.
»» Wenn schon die Regeln über 27 Stylesheets verteilt sind (was man nicht tun sollte)
Warum nicht?
27 Requests anstatt einem (zumindest beim erstmaligen Aufruf einer Seite der Site). [http://www.webkrauts.de/2008/12/13/sehr-sehr-schnelle-seiten-website-performance-best-practice/]
Vielleicht kannst du Selektor-Hacks wie »*:first-child+html« aus dem Kopf
Ja. So viele sind’s ja nun auch nicht. '* html' und '*:first-child+html' hat man da schneller im Kopf als man sich weigern könnte, sie zu lernen. ;-) Und Hacks für andere Browser braucht man so selten, dass man sie bei Bedarf nachschlagen kann.
Dennoch wäre mir eine saubere Lösung innerhalb von CSS(!!) auch lieber. Noch besser als CCs in CSS wären da wohl @-Regeln à la
@user-agent IE < 7
{
#foo
{
display: inline; /* fixes IE doubled float margin bug */
}
}
Schön wär’s. Noch schöner wär’s, es wären keine Extrawürste für IrgendEinen Browser nötig.
Live long and prosper,
Gunnar
Nur war in diesem Thread bis zu meiner Nachfrage noch nicht die Rede von Includes.
Doch, Meiert hat schon kategorisch widersprochen, dass Templates und Suchen/Ersetzen die notwendige Änderung vom HTML vereinfacht, bevor wir es überhaupt angesprochen haben. ;)
Dateien müssen erstmal in den Editor geladen werden (wenn man das dateiweite Suchen/Ersetzen nicht per Kommandozeile erledigt). Und dann wollen die 1500 Dateien auch noch (per FTP o.ä.) zum Server übertragen werden.
Ich musste natürlich keine 1500 Dateien mit FTP irgendwohin übertragen. Wenn ich ein Projekt dieses Umfangs habe, dann nutze ich eine entsprechende Infrastruktur - z.B. eine Versionsverwaltung und einen Deployment-Mechanismus.
27 Requests anstatt einem
Ich rede hier vom Verfassen der Stylesheets, nicht vom Ausliefern. Man sollte die Organisation von Stylesheets strikt von solchen technischen Erfordernissen trennen. Und gleichzeitig diesen Erfordernissen genügen. Ein Widerspruch besteht nicht.
Dennoch wäre mir eine saubere Lösung innerhalb von CSS(!!) auch lieber.
Ja. Allerdings hat es auch Vorteile, wenn ich mehrere IE-Bugs mit demselben Fix an einer zentralen Stelle erschlagen kann. Das mit der »Nähe« Das lädt zu Wiederholungen ein. Meistens ist es ja bloß zoom:1 und solche Kleinigkeiten.
#a { normale Styles }
/**
* Bug XYZ, trigger hasLayout to fix
* @see http://...
*
* @bugfix
* @affected IE6
* @css-for all browsers
* @valid yes
*/
* html #a { zoom: 1; }
#b { normale Styles }
/**
* Bug XYZ, trigger hasLayout to fix
* @see http://...
*
* @bugfix
* @affected IE6
* @css-for all browsers
* @valid yes
*/
* html #b { zoom: 1; }
Das bringts ja auch nicht, da gefällt mir das lieber:
Stylesheet für alle:
#a { normale Styles }
#b { normale Styles }
IE-6-Stylesheet:
/* trigger hasLayout to fix XYZ */
#a, b { zoom: 1; }
Allein diese Trennung erspart mir den Dokumentations-Overhead, der in einem »gemischten« Stylesheet durchaus Sinn macht, in einem reinen IE-6-Stylesheet aber nur Offensichtliches wiederholt bzw. Irrelevantes besagt.
Mathias
Hallo,
bei meinen eigenen CMS-Geschichten fand ich ein unverselles Template für den HTML-Head nicht optimal und bin erstmal bei einem möglichst kompletten Template für einen Bereich oder einen Seiten-Typ gelandet. Also müßte ich je nach Projekt mehrere, z.B. fünf, Templates anpassen.
Ansonsten bleibt noch der Vorteil, notfalls in einem eigenen Stylesheet für einen bestimmten Browser ungenierter invaliden CSS-Code einsetzen zu können.
/* trigger hasLayout to fix XYZ */
#a, b { zoom: 1; }Allein diese Trennung erspart mir den Dokumentations-Overhead, der in einem »gemischten« Stylesheet durchaus Sinn macht, in einem reinen IE-6-Stylesheet aber nur Offensichtliches wiederholt bzw. Irrelevantes besagt.
Da sind doch Korrekturen und Kommentare direkt an der "Sache", in einem nur ergänzenden IE-6 Stylesheet wäre der Bezug zum anderen CSS-Code vielleicht unklar.
Die Kommentare bei einem gemeinsamen Stylesheet ließen sich vor Auslieferung, etwa per PHP, relativ leicht ausfiltern. Wenn der IE 6 nur ein eigenes Stylesheet erhalten würde, wäre die Wartung vielleicht auch wieder umständlicher.
Grüsse
Cyx23
Hast du dir diese Argumentation überhaupt angesehen,
Die Frage war rhetorisch?
Nein, weil der Artikel viele schlicht absurde Herleitungen enthält, von denen ich nicht vermutet habe, dass sich deine Zustimmung gerade auf diese stützt - das vereinfacht die Diskussion darüber, weil wir diese schwachen Ausführungen gleich überspringen können und die Position dort prüfen können, wo sie uns am stärksten vorkommt.
Mathias
Mahlzeit Gunnar Bittersmann,
„CC sollten vermieden werden, da sie […] mit wesentlich höherer Wahrscheinlichkeit HTML-Änderungen bedeuten, sobald eine neue Version des Internet Explorers erscheint, eine alte geht, oder vielleicht »einfach nur« IE-Stylesheets neu arrangiert werden.“
Das kommt darauf an. Und zwar darauf, ob man für jede IE-Version eigene Stylesheets per CC einbindet (IMHO eine schlechte Idee - u.a. aus o.g. Grund) ... oder ob man nur ein generelles IE-Stylesheet einbindet und innerhalb dessen dann per passendem CSS-Hack die verschiedenen Versionen anspricht (IMHO die einzig vernünftige Variante).
„Irgendeine Änderung einer Deklaration im »Haupt-Stylesheet«, die bereits im IE-Stylesheet für den Internet Explorer überschrieben wurde, kann andernfalls Konfusion bedeuten (»warum benimmt sich der IE anders«) […]“ – zumal der IE nicht so gesprächig die Quelle einer Regel angibt wie bspw. Firebug.
Jein. Wenn man weiß, dass der IE ein schrottiger Browser ist, für den irgendwelche Ausnahmen nötig sind (und wer wüsste das nicht?) und weiterhin weiß, dass ausnahmslos ALLE Ausnahmen für den IE in EIN zentrales Stylesheet ausgelagert worden sind, dann ist klar, wo man zu suchen hat, wenn alle anderen Browser sich mal wieder richtig verhalten und nur der IE rumzickt.
„Diese Problematik ist logisch, da das »Prinzip der Nähe« verletzt wird, konzeptionell zusammengehörige Regeln mittels CC getrennt werden.“ – Sagte ich in diesem Thread ja auch schon.
Das mag sein. Andererseits werden aber allen richtigen Browsern keine kaputten Regeln vorgesetzt und alle Sonderlocken für den einen "Browser" an einer zentralen Stelle gebündelt.
MfG,
EKKi
Warum??
Warum schreibst du Anpassungen für IEs nicht per '
* html'-Hack (IE 6) bzw. '*:first-child+html'-Hack (IE 7) in _das eine_ Stylesheet?„Conditional Comments (CC) stellen »by design« ein Wartbarkeitsproblem dar.“ [Meiert]
Das sehe ich auch so.
Ein gesondertes Stylesheet (worüber ich bisher nicht mal nachgedacht habe) für den IE ist ja nur nötig, um CSS Bugs zu beheben. Diese sollten natürlich an der Stelle behoben werden, wo sie auftreten. Man kann ja schlecht bei jeder Änderung in allen IE-Hack Dateien nachschauen ob diese davon betroffen ist.
Struppi.
Mahlzeit Struppi,
Man kann ja schlecht bei jeder Änderung in allen IE-Hack Dateien nachschauen ob diese davon betroffen ist.
Wieso "allen [...] Dateien"? Es reicht doch eine - in der kann dann per passendem CSS-Hack die jeweilige Browser-Version separat "gepatcht" (bzw. deren Verhalten berichtigt) werden.
Und diese eine zusätzliche CSS-Datei für den IE muss man nur anfassen, wenn irgendeine Version dieses "Browsers" mal wieder in irgendeiner Form herumzickt - ansonsten hat man in den normalen CSS-Dateien sauberen Code ohne irgendwelche Hacks, mit dem alle vernünftigen Browser wunderbar klarkommen.
MfG,
EKKi
» Man kann ja schlecht bei jeder Änderung in allen IE-Hack Dateien nachschauen ob diese davon betroffen ist.
Wieso "allen [...] Dateien"? Es reicht doch eine - in der kann dann per passendem CSS-Hack die jeweilige Browser-Version separat "gepatcht" (bzw. deren Verhalten berichtigt) werden.
Ich las hier im Thread schon sowas wie:
<!--[if IE6]>
<!--[if IE7]>
usw.
Aber egal.
Und diese eine zusätzliche CSS-Datei für den IE muss man nur anfassen, wenn irgendeine Version dieses "Browsers" mal wieder in irgendeiner Form herumzickt - ansonsten hat man in den normalen CSS-Dateien sauberen Code ohne irgendwelche Hacks, mit dem alle vernünftigen Browser wunderbar klarkommen.
Wenn du eine Änderung an einem Element machst, z.b. eine Höhenangabe vergibst wo vorher keine war und für eine bstimmte IE Version ein Hack ist, dass du z.b. height:1% verwendest, dann viel Spaß beim suchen. Und so kann ich mir noch mehr Hacks vorstellen, die bei der Formatierung Probleme bereiten können, wenn anderswo Werte geändert werden.
Da halte ich es für praktikabler z.b. den Hack direkt unter der Formatierung des Elements zu schreiben.
Struppi.
Da halte ich es für praktikabler z.b. den Hack direkt unter der Formatierung des Elements zu schreiben.
Ich auch.
Aber egal ob Hack oder #msie id
Wenn eine Site sehr umfangreich ist, dann besteht ja die Chance, dass das Entwickler-CSS vom Produktions-CSS verschieden ist.
Das wäre zugleich der Fall, wo du dir Bandbreite sparen willst.
In der Entwicklung kannst du in der Tat alles im gleichen File schreiben.
Für das Produktionssystem kannst du dir mit einem Filter mehrere CSS-Files nachträglich erstellen lassen.
Hier dürfte allerdings der #msie7 Selektor klare Vorteile für einen Parser haben.
mfg Beat
Mahlzeit Struppi,
Ich las hier im Thread schon sowas wie:
<!--[if IE6]>
<!--[if IE7]>
usw.
Ich auch. Aber ich vertrete - wie bereits mehrfach geäußert - die Ansicht, dass ein einzelnes separates Stylesheet für alle IEs mit dort untergebrachten verschiedenen Hacks für die jeweiligen Versionen, sinnvoller ist, als für jede neue IE-Version oder -Unterversion einen neuen CC anzulegen.
Da halte ich es für praktikabler z.b. den Hack direkt unter der Formatierung des Elements zu schreiben.
Und ich halte es für besser, vernünftigen Browsern keinen kaputten CSS-Code vorzusetzen. Der eine Browser, für den Sonderlocken nötig sind und der die Möglichkeit bietet, für ihn separate Stylesheets einzubinden, bekommt diese dann auch auf diesem Wege - das belästigt den Rest nicht.
MfG,
EKKi
» Da halte ich es für praktikabler z.b. den Hack direkt unter der Formatierung des Elements zu schreiben.
Und ich halte es für besser, vernünftigen Browsern keinen kaputten CSS-Code vorzusetzen. Der eine Browser, für den Sonderlocken nötig sind und der die Möglichkeit bietet, für ihn separate Stylesheets einzubinden, bekommt diese dann auch auf diesem Wege - das belästigt den Rest nicht.
OK, du denkst an den Browser und ich an den der den Code pflegen muss, das sind halt zwei unterschiedliche Ansätze. Wobei ich mir auch nicht soviel Gedanken um den IE mache, Hauptsache in den anderen Browser sieht es gut aus :-)
Struppi.
Mahlzeit Struppi,
OK, du denkst an den Browser und ich an den der den Code pflegen muss, das sind halt zwei unterschiedliche Ansätze.
Unterschiedliche Ansätze schon. Aber ich sehe - ähnlich wie molily - nicht so sehr ein Problem darin, in einem Stylesheet den "richtigen" CSS-Code stehen zu haben und in einem anderen dann die Verhunzungen für einen bestimmten sog. "Browser". So ist der "richtige" CSS-Code wenigstens sauber und übersichtlicher.
Wobei ich mir auch nicht soviel Gedanken um den IE mache, Hauptsache in den anderen Browser sieht es gut aus :-)
Genau. Deswegen bekommen die ja von mir auch nur ein sauberes Stylesheet und keine Krücken.
Sämtliches Gefummel, Gefrickel und Herumgebiege bekommt nur der IE zu sehen.
MfG,
EKKi
@@EKKi:
Sämtliches Gefummel, Gefrickel und Herumgebiege bekommt nur der IE zu sehen.
Die Hacks für Firefox bekommt nur der IE zu sehen?
Oder zählen die nicht unter „[s]ämtliches Gefummel, Gefrickel und Herumgebiege“?
Live long and prosper,
Gunnar
Mahlzeit Gunnar Bittersmann,
»» Sämtliches Gefummel, Gefrickel und Herumgebiege bekommt nur der IE zu sehen.
Die Hacks für Firefox bekommt nur der IE zu sehen?
Ich meinte - wie meinem Beitrag unschwer zu entnehmen ist - das "Gefummel, Gefrickel und Herumgebiege", das man normalerweise für den IE in irgendeiner Version einbauen muss.
Aber das Aus-dem-Zusammenhang-reißen von Zitaten scheint ja gerade groß in Mode zu sein ...
Oder zählen die nicht unter „[s]ämtliches Gefummel, Gefrickel und Herumgebiege“?
Nicht, wenn vorher eindeutig und unmissverständlich vom IE und dessen Befindlichkeiten die Rede war.
Aber wer mich unbedingt missverstehen WILL, soll das meinetwegen gerne tun ...
MfG,
EKKi
@@EKKi:
Ich meinte - wie meinem Beitrag unschwer zu entnehmen ist - das "Gefummel, Gefrickel und Herumgebiege", das man normalerweise für den IE in irgendeiner Version einbauen muss.
Und ich meinte – wie durch ein wenig Nachdenken unschwer zu erkennen ist – das es nicht konsequent ist, das „Gefummel, Gefrickel und Herumgebiege“ für IEs in ein spezielles Stylesheet zu verfrachten; das „Gefummel, Gefrickel und Herumgebiege“ für andere Browser dagegen im Hauptstylesheet zu hacken.
das Aus-dem-Zusammenhang-reißen
▲
Aus dem Zusammenhang gerissen: korrekte Schreibung: das Aus-dem-Zusammenhang-Reißen
▲
Live long and prosper,
Gunnar
Mahlzeit Gunnar Bittersmann,
Und ich meinte – wie durch ein wenig Nachdenken unschwer zu erkennen ist – das es nicht konsequent ist, das „Gefummel, Gefrickel und Herumgebiege“ für IEs in ein spezielles Stylesheet zu verfrachten; das „Gefummel, Gefrickel und Herumgebiege“ für andere Browser dagegen im Hauptstylesheet zu hacken.
Nunja - der IE bietet eine Möglichkeit, Firefox hingegen nicht. Außerdem muss man AFAIK für den IE erheblich mehr Sonderlocken drehen als für alle anderen Browser. Allein schon durch ihre Masse wird jedes Stylesheet unübersichtlich, wenn man wissen will, wie die Regeln "eigentlich" aussehen.
BTW: was für "Gefummel, Gefrickel und Herumgebiege" z.B. für den Firefox kennst Du denn so? Ich könnte jetzt aus dem Stehgreif kein Beispiel nennen, das so extrem wäre wie der tägliche Kampf mit dem IE und deshalb ein eigenes Stylesheet rechtfertigen würde (wenn der Firefox denn die Möglichkeit bieten würde, separat eins zu laden).
»» das Aus-dem-Zusammenhang-reißen
▲
Aus dem Zusammenhang gerissen: korrekte Schreibung: das Aus-dem-Zusammenhang-Reißen
Der heutige Haarspalter-Award geht damit an Dich ...
MfG,
EKKi
@@EKKi:
»» Und ich meinte – wie durch ein wenig Nachdenken unschwer zu erkennen ist – das es nicht konsequent ist, das „Gefummel, Gefrickel und Herumgebiege“ für IEs in ein spezielles Stylesheet zu verfrachten; das „Gefummel, Gefrickel und Herumgebiege“ für andere Browser dagegen im Hauptstylesheet zu hacken.
Nunja - der IE bietet eine Möglichkeit, Firefox hingegen nicht. Außerdem muss man AFAIK für den IE erheblich mehr Sonderlocken drehen als für alle anderen Browser.
Weder das eine noch das andere ändert was an der Inkonsequenz eines speziellen IE-Stylesheets.
BTW: was für "Gefummel, Gefrickel und Herumgebiege" z.B. für den Firefox kennst Du denn so?
Das „Gefummel, Gefrickel und Herumgebiege“ für Firefox 2 bei 'display: inline-block'.
Der heutige Haarspalter-Award geht damit an Dich ...
Danke. Den hab ich mir aber auch redlich verdient. >;->
Live long and prosper,
Gunnar
@@Gunnar Bittersmann:
»» »» […] das es nicht konsequent ist […]
Ich kaufe ein S.
[…] an der Inkonsequenz […]
Grmpf, ich meinte eigentlich eher „konsistent“ und „Inkonsistenz“.
Fremdwörter sind Glückssache.
Live long and prosper,
Gunnar
Grmpf, ich meinte eigentlich eher „konsistent“ und „Inkonsistenz“.
Fremdwörter sind Glückssache.
<write where="subconscious mind">hey, die Losung lautet 'Inkontinenz'.</write>
mfg Beat
Hi,
<style type="text/css">
#boxnavi2 {margin-top:815px; }
<!--[if IE6]><link rel="stylesheet" type="text/css" href="css/layout_ie6.css" /><![endif]-->
</style>
In einem style-Element darf nur CSS-Code stehen, kein Link-Element.
cu,
Andreas
In einem style-Element darf nur CSS-Code stehen, kein Link-Element.
@import wäre dafür geeignet, um weitere CSS-Files nachzuladen - allerdings tun das dann andere Browser auch :)