Tools gewünscht? (Seite 8)

Hallo Heiko

Schade das nicht jedes CMS so qualitativ gestaltet ist wie deines!

Da würde ich sogar in Versuchung geraten das mal zu testen!

Okay dann bin ich davon überzeugt das als nächstes Flo davon zu überzeugen es gilt!

Gruß

Jörg

Raptor schrieb:

Hm? Wozu das? Inline-Styles sind doch nicht verboten?

Nein - verboten sind sie nicht.

Wozu? Vorbildfunktion! Du ermittelst mit dem Tool die vorhandenen Inline-Styles und schreibst einen langen Absatz über Spaghetti-Code. Inline-Styles sind Spaghetti-Code.

Was sind die Nachteile von Inline-Styles?
Sie lassen sich nicht zentral bearbeiten.
Sie stehen in der Bearbeitungsabfolge an letzter Stelle, lassen sich also nicht durch ein Stylesheet überschreiben (nur ggf. durch den Zusatz !important bei der jeweiligen Regel, falls im Inline-Style selbst nicht auch ein !important steht).
Daraus folgt, dass sie entsprechend nachteilig für die Ausgabe einer Seite in unterschiedlichen Medien (Bildschirm, Drucker, Handheld usw.) sind, wenn dafür unterschiedliche Anweisungen für Styles sinnvoll sind.

Gérard

gerard schrieb:

Nein - verboten sind sie nicht.

Wozu? Vorbildfunktion! Du ermittelst mit dem Tool die vorhandenen Inline-Styles und schreibst einen langen Absatz über Spaghetti-Code. Inline-Styles sind Spaghetti-Code.

Was sind die Nachteile von Inline-Styles?
Sie lassen sich nicht zentral bearbeiten.
Sie stehen in der Bearbeitungsabfolge an letzter Stelle, lassen sich also nicht durch ein Stylesheet überschreiben (nur ggf. durch den Zusatz !important bei der jeweiligen Regel, falls im Inline-Style selbst nicht auch ein !important steht).
Daraus folgt, dass sie entsprechend nachteilig für die Ausgabe einer Seite in unterschiedlichen Medien (Bildschirm, Drucker, Handheld usw.) sind, wenn dafür unterschiedliche Anweisungen für Styles sinnvoll sind.

Ist mir schon klar, dass es gut ist, wenn man alles zentral haben kann.
Allerdings ist es für mich persönlich vorteilhafter, wenn ich gewisse Sachen "vor Ort", also mittels Inline-Style, erledigen kann, vor allem dann, wenn es spezifische unique Eigenschaften sind (z.B. die Schrift-Grösse der Keywords beim Tool). Oder wenn z.B. mehrere Tabellen gleich aussehen, aber jeweils eine andere Spaltenbreite der ersten Spalte haben müssen, dann lege ich die jeweilige Breite mittels Inline-Style im ersten fest. Das ist aber auch eine Folge des Programmierens, denn wenn ich die Breite einer Spalte während des Designens mehrmals anpassen muss, dann find ich es einfach zu umständlich jedes mal den Wert in der externen CSS-Datei zu ändern.

Aber du hast recht, ich muss meine eigenen Regeln auch selber einhalten. Daher werde ich jetzt zum Beispiel die Inline-Styles aus meiner Tool-Hauptseite verbannen (das macht mir Spass).. Nun, nicht ganz, da die Social-BM-Links jeweils einen spezifischen CSS-Wert benötigen.

Raptor schrieb:

Aber du hast recht, ich muss meine eigenen Regeln auch selber einhalten. Daher werde ich jetzt zum Beispiel die Inline-Styles aus meiner Tool-Hauptseite verbannen (das macht mir Spass).. Nun, nicht ganz, da die Social-BM-Links jeweils einen spezifischen CSS-Wert benötigen.

Du wirst sehen, dass sich das lohnt.

@Jörg: Ich werde heute mein Inline-Style vielleicht doch noch verbannen und durch ein img ersetzen.

der_booker schrieb:

Du wirst sehen, dass sich das lohnt.

Jetzt weiss ich wieder, woran ich letztes mal gescheitert bin: der IE unterstützt CSS3 nicht...
Egal! Ich werde trotzdem mit "div:nth-child(even){ ... }" arbeiten. Die IE-User müssen da halt eine Layout-Einbusse ertragen müssen. Aber der Vorteil ist grösser: Ich muss nicht mal mit IDs oder Klassen arbeiten und kann ganz einfach ein neues Element anhängen. Und irgendwer muss ja die neuen Standards vorwärts bringen, bzw die IE-Benutzerzahl rückwärts.
Macht Spass.

Raptor schrieb:

Jetzt weiss ich wieder, woran ich letztes mal gescheitert bin: der IE unterstützt CSS3 nicht...
Egal! Ich werde trotzdem mit "div:nth-child(even){ ... }" arbeiten. Die IE-User müssen da halt eine Layout-Einbusse ertragen müssen. Aber der Vorteil ist grösser: Ich muss nicht mal mit IDs oder Klassen arbeiten und kann ganz einfach ein neues Element anhängen. Und irgendwer muss ja die neuen Standards vorwärts bringen, bzw die IE-Benutzerzahl rückwärts.
Macht Spass.

Wie Du siehst, schauen sich auch andere Deine Webseite an und sehen aufgrund Deiner Tools zu Dir auf. Diese Vorbildfunktion kannst Du eben noch gerechter werden, wenn Du mit einem sauberer Source arbeitest.
Ich zähl auf Dich.

So,
ich habe wieder mal was zusammengebastelt. Hansen hat mir dazu die Idee geliefert:
Der CodeCompressor (beta)

Mit dem CodeCompressor lässt sich der Quelltext von Web-Dokumenten wie HTML, CSS oder JavaScript säubern und komprimieren, indem überflüssige Leerzeichen, Leerzeilen und Kommentare entfernt werden. Des Weiteren kann man diese Dateien mittels gzip komprimieren, um noch mehr Speicherplatz und Traffic zu sparen.

Für Verbesserungsvorschläge bin ich wie immer offen. Falls jemand Bugs findet, bitte melden.

Raptor schrieb:

Für Verbesserungsvorschläge bin ich wie immer offen.

Bei css sollte es die Möglichkeit geben, die Regeln jeweils in einer Zeile zusammenzufassen.

Gérard

Hallo Florian

Kannst du das Tool erweitern das b und i Elemente durch strong und em Elemente ersetzt werden?

Gruß
Jörg

joerg schrieb:

Kannst du das Tool erweitern das b und i Elemente durch strong und em Elemente ersetzt werden?

Das sollte man besser in einem eigenen Tool machen (das evtl. erweitert werden könnte).

Gérard