|
||||
Zitat:
Nachtrag: Über die Seite von Ingo vorbestellt
__________________
http://www.dieter-welzel.de http://www.webseiten-infos.de http://bluelight-rock.de http://www.jurafernstudium.de Dreamweaver CS5 | Windows 7 | IE 9, 8, 7, 6 | Firefox 6 | Opera 11.5 | Safari 5 Geändert von DieterWelzel (07.08.2008 um 16:32 Uhr) Grund: Nachtrag |
Sponsored Links |
Sponsored Links |
|
||||
Ich habe mir grad eben die Leseprobe ein wenig durchgelesen und ich muss dazu sagen:
Daumen hoch, echt nicht schlecht - werde mir das Buch sicher auch zulegen und drin stöbern Eine Frage dazu hätte ich aber noch, warum vergleicht ihr nicht einfach die IE-Versionen allgemein mit Conditional Comments - sondern bindet die älteren Versionen mit Starhacks ein? ...schließlich gibt es den gewaltigen Unterschied mit dem doppelten-margin-Bug bei 5.4999 und 5.5+ (bis IE6.0 SP1) und die Conditional Comments erlauben auch die direkte Überprüfung der Versionsangaben, sogar mit range (von...bis): Code:
<!--[if (gte IE 5.5000)&(lte IE 6)]>...<![endif]--> Grüßel, Unsk1ll3d
__________________
Ich bin keine Signatur, ich putz hier nur Geändert von Unsk1ll3d (16.08.2008 um 01:34 Uhr) |
|
|||
Danke für deine interessante Frage.
Vorab: Für uns ist eine jede Hacking-Strategie nicht als etwas Grundsätzliches oder als Festlegung anzusehen, sondern eher als eine individuelle problembezogene Lösung. Wir diskutieren im Kapitel 10 Debugging, in den Abschnitten 10.6 und 10.7, ausführlich das Hacking, wir definieren, was wir darunter verstehen (* s.u.), und wieso, wann und wie es eingesetzt wird. Auf diesem Weg verdeutlichen wir dabei unsere persönliche Hacking-Strategie. Wir vertreten die Auffassung, dass Conditional Comments (CC) unstandardisierte, herstellereigene HTML-Hacks sind; sie sind ein Teil des Hacking-Problems, nicht dessen Lösung. Weniger CSS-Hacks mit mehr HTML-Hacks einzukaufen, ist ein Nullsummenspiel. Wir setzen uns mit einfachen und sehr komplexen CC auseinander, z.B. erläutern wir die CC-Konstruktionen von Stu Nicholls in seinen Tabellenmenüs. CC sind eine vergleichsweise saubere Lösung, jedoch im HTML einer Seite verankert. In vielen Fällen ist es ausreichend, nur ein CC zu verwenden, und innerhalb dessen mit dem Star-HTML-Hack zu arbeiten. Wir belassen es gerne bei nur einem CC. Es ist überhaupt nichts falsch daran, viele, differenzierte CC zu benutzen, wie du vorschlägst. Beide Wege führen dazu, dass standardkonforme(re) Browser die Hacks nicht sehen. Es ist im individuellen Fall zu entscheiden, welcher Weg eine leichtere Wartbarkeit aufweist. In den ersten Tagen des IE7 wurde das "richtige" Hacking zur Doktrin, mittlerweile haben sich die Gemüter etwas beruhigt. Pragmatische Ansätze sind wichtiger denn Dogmen, da Hacking unverändert notwendig ist. Der IE6 wird Webdesigner und Entwickler noch lange verfolgen. Dies ist immer wieder ein hitzig diskutiertes Thema, daher gehen wir im Debugging-Kapitel sehr intensiv darauf ein und vertreten unsere Position, die ich hier nur anreißen konnte. Der praktische Einsatz findet sich an vielen Stellen im ersten und dritten Teil des Buches. * Eine Arbeitsdefinition: Hacks sind all das, was an einer Seite geändert wird, um eine Fehldarstellung oder Fehlfunktion in einem Browser zu verhindern, obwohl diese Maßnahmen der Spezifikation zufolge unnötig wären. Webautoren sollten Hacks dokumentieren. Geändert von IChao (16.08.2008 um 11:48 Uhr) Grund: tipppfähler |
|
||||
Meine Meinung dazu: Dass man überhaupt einen CC braucht, ist schon schlimm genug. Aber gleich 4 oder 5 davon ins HTML zu schreiben, geht einfach gar nicht Denn der HTML-Code soll die Inhalte der jeweiligen Seite transportieren, daher sollte man ihn möglichst frei von Zusätzen, die ein fehlerhafter grafischer Browser benötigt, halten. Auch das verstehe ich als Teil der wünschenswerten Trennung von Inhalt und Design.
Jede IE-Version lässt sich innerhalb eines CCs (den alle IE-Versionen lesen) problemlos mit verschiedenen Hacks ansprechen, das sollte man sich zunutze machen und den HTML-Code so "sauber" wie möglich halten - und es bei einem CC belassen. |
|
||||
Da muß ich Heiko uneingeschränkt zustimmen.
Sauberer Code ist übersichtlicher und damit fehlerfreier als ein Gefrickel aus allen möglichen CCs und Hacks. Der wirkt dann auch irgendwie "ästhetischer" als eine zusammengestoppelte Müllhalde. Viele trennen hier zwar Design von Technik - aber: sie gehören zusammen. Ein unschöner Code ergibt keine "schöne" Technik. |
|
||||
Zitat:
Ist der Code sauber, profitiert neben dem Webmaster auch der Benutzer (zB durch semantischen und logischen Code bzw relative Fehlerarmut). |
|
||||
Zitat:
Aber vorallem darum das man sich bei Wartungen nicht durch alle möglichen CC's kämpfen muss... Das wiederum bringt dem Benutzer eine sache: Die Seite ist womöglich schneller wieder online
__________________
Meine Spielwiese: http://blog.kanedo.net Ich bei Flickr? Da: Flickr: Fotostream von kanedo-projekt Für open Source Liebhaber: open Com Auch ich Zwitschere als @kanedo |
|
|||
Die Seite für den Nutzer gibt es nicht ohne den Entwickler. Die Sauberkeit entscheidet mit über die Wartbarkeit des Codes. Die Sauberkeit hat damit direkt etwas mit den Kosten der Entwicklung und Wartung einer Seite zu tun. Wenn die Seite nicht mehr vernünftig gewartet wird, weil der Code eine Katastrophe ist, hat der Nutzer am Ende recht wenig davon.
Die Frage ist also nicht, ob es hier "nur" um die Sauberkeit gehe, sondern, welche Konsequenzen sich für das tägliche Coden ergeben, gerade "weil" es um die Sauberkeit geht. Und damit mal kurz zurück zum Thema. Die Guidelines in einem Team können sich für mehrere CC's aussprechen oder nur für einen CC. Dem konformen Browser ist das egal, solange die Hacks separiert sind. Er wirft beim Parsen aus seiner Sicht nur einen oder eben mehrere HTML-Kommentare heraus. Für den konformen Browser sind Seiten mit mehreren CC nicht unsauberer als gut kommentierte Seiten. Es geht damit einzig um die Technik des Webautors/Front-End-Teams, und hierbei finde ich Dogmen unangemessen. Mir ist es allein wichtig, darauf hinzuweisen, dass auch CC's Hacks sind, dass man seine Hacks separieren sollte und vor allem, dass man sie dokumentieren sollte. Es kann nicht gutgehen, wenn beispielsweise in einem unaufgeräumten Code überall position:relative herumliegt, ohne dass nach einem halben Jahr irgend jemand noch wüsste, ob es ein Hack für den IE ist (damit er etwas überhaupt darstellt) oder ob tatsächlich gemäß Spezifikation in die Stapelung und Positionierung eines Gefüges eingegriffen werden soll. |
Sponsored Links |
|
||||
Zitat:
machen und das im FF auszutesten. Dann folgt die (eventuelle) Anpassung an die diversen IEs (ich denke, da reichen 6+7, Kommentieren ist dabei Pflicht). Je klarer und einfacher der Code ist umso besser für mich und damit auch für den Betrachter. Das ist nebenbei eine der wichtigsten Sachen beim Programmieren: Fasse Dich kurz. |
Sponsored Links |
Stichwörter |
buch, css-debugging, css-techniken |
Themen-Optionen | |
Ansicht | |
|
|
Ähnliche Themen | ||||
Thema | Autor | Forum | Antworten | Letzter Beitrag |
CSS Buchtipp Eric A. Meyer | vistahr | Ressourcen | 2 | 01.11.2006 19:53 |
CSS Tips & Tricks | Webnauts | Ressourcen | 0 | 26.08.2006 00:04 |
CSS Menue Browserkompatibel! ICH DREH DURCH! | haSta | CSS | 24 | 02.03.2006 19:42 |
Eric Meyer's CSS | Petty | Ressourcen | 0 | 21.11.2005 09:18 |
Mozilla ignoriert externes css | DarkWanderer | CSS | 9 | 22.09.2005 12:39 |