Die meisten von uns haben ja sicherlich bereits von Listen in HTML-Dokumenten gehört, die gibt es als <ol>, <ul> oder auch <dl> (wozu es übrigens erst kürzlich einen tollen Artikel gab). Oftmals verwenden wir dabei Symbole zum verdeutlichen von Funktionalitäten, wie wir es etwa im Beispiel-Screenshot sehen können. Wir schalten die Listenpunkte durch list-style: none; im CSS einfach ab und verpassen den jeweiligen Punkten ein Symbol wie z.B. ein kleines Häuschen als Symbol für die Startseite.
Zur Realisierung solch grafischer Listenpunkte gibt es im Prinzip 3 Herangehensweisen die ich erst einmal kurz vorstellen möchte:
Wer ist für Überstunden, Haarausfall, Ratlosigkeit und Unproduktivität in unserer Branche verantwortlich? Richtig: Der Internet Explorer.
Nun ist bei David eine kleine Diskussion entbrannt, die sich darum dreht, in wie weit man heute bei der Umsetzung von Webseiten den Internet Explorer unter Version 7 unterstützen sollte.
Meine Meinung: Für Webseiten mit geschäftlichem Hintergrund, bei der es auf jeden Besucher ankommt, ist eine Optimierung für den Internet Explorer ohne zweifel notwendig, bei meiner Arbeit sogar teilweise noch für den IE5… je nach Zielgruppe.
Auf der anderen Seite sehe ich jedoch, das es wohl keinen anderen Weg mehr gibt die Nutzer zumindest zu einem Update auf den Internet Explorer 7 zu bewegen, als diese ganz einfach zu zwingen. Was helfen kleine Hinweise wie “Sie setzen einen veralteten Webbrowser ein, bitte aktualisieren Sie auf eine aktuelle Version”, wenn der Nutzer am anderen Ende eh alles auf der Seite ansehen kann? User sind Faul und niemanden interessiert solch ein Hinweis, solange nicht drastische Nachteile für Ihn dadurch entstehen.
Mensch, der Weihnachtswahn kommt in diesem Jahr aber auch reichlich früh, und dann auch noch so dicht aufeinander!
Erst werden Stöckchen geworfen und nun, am 01.12.2007, wird auch der aus den Vorjahren bekannte Weihnachtskalender der Webkrauts fortgesetzt.
Da ich nun auch seit geraumer Zeit auf der Mitgliedslist stehe, hatte ich bereits ein wenig Einblick in die Themen die da vom 1-24 auf uns warten und kann nur sagen das sich ein täglicher Besuch mit Sicherheit lohnen wird.
Neu in diesem Jahr ist, das die Beiträge in Form von “Advents-Quickies” erfolgen. Lange Beiträge wie im letzten Jahr werden also nicht kommen, damit auch die Leser mit Zeitmangel die Beiträge verfolgen können.
Gerrit van Aaken hat gestern sein HTML/CSS/JS-Kickstart-Paket vorgestellt. Eine sehr feine Sache wie ich finde, die jeder Webentwickler auf der Festplatte haben sollte.
Der Ablauf ist ja fast bei allen Entwicklern der selbe. Man macht/bekommt eine Layout-Datei welche nun im nächsten Schritt in ein XHTML-Dokument portiert werden muss um danach dann in den meisten Fällen als Template für ein CMS dienen zu können.
In einem Startup-Paket werden dabei alle Features vereint die man bei einer Design-Umsetzung in den meisten Fällen eh benötigen würde. Bei mir heißt das das eine index.html mit einer gewissen Struktur samt DOCTYPE und Metatags vorhanden ist, als auch eine Ordnerhierarchie mit CSS-Dateien für Screen, Print und Browserhacks (IE6).
Das CSS beinhaltet zudem bereits einige Resets und Klassen die sich im Alltag als nützlich erwiesen haben.
In Gerrits Paket wurde zudem bereits jQuery integriert, was ich als sehr nützlich ansehe, denn mittlerweile gehört auch jQuery bei mir zu fast allen neuen Umsetzungen dazu.
Da mir das Kickstart-Paket sehr gefallen hat habe ich mir dieses einmal vorgenommen und meinen persönlichen Ansprüchen nach noch einmal modifiziert, denn nur so ist ein schneller Start aus meiner Sicht möglich. Jeder hat einen etwas anderen Workflow und somit auch unterschiedliche Vorlieben was solch ein Paket angeht. Wer sich evtl. für meine Vorlieben interessiert, kann sich nun also auch meine Modifikation herunterladen.
Im Prinzip wurde dem Paket erstmal ein gewisses Grundmarkup beschert, was sich hier jedoch auf <div id="wrapper"> und ein <h1> beschränkt. Denn diese beiden Elemente sind aus meiner Sicht erstmal bei jedem Projekt der Grundstein. Das CSS-Reset von Eric Meyer wurde in die screen.css übernommen und ein wenig komprimiert. Das spart ein wenig Ladezeit. Die ie7.css wurde ebenfalls verbannt, da ich in letzter Zeit eher weniger Probleme mit dem IE7 hatte und daher die kleine Anzahl an Hacks auch in die screen.css übernehmen kann.
Ansonsten wurden noch einige Feinheiten wie z.B. ein Favicon zur schnellen Identifikation im Browser, robots.txt, sowie einige Metatags beigelegt. Schauts euch einfach an und sagt mir eure Meinung.
Es gibt ja unzählige Wege und Anleitungen wie man Spam in seinen Formularen mindern oder ganz verdrängen könnte. Ob Captchas, Rechenaufgaben oder Dienste wie Akismet, sie alle haben ihre Vor und Nachteile.
Bei Arne fand ich nun eine relativ simple Lösung die aber perfekt zu funktionieren scheint.
Der Trick ist denke ich nichts neues, aber dafür sehr effektiv. Um Spambots möglichst eindeutig zu erkennen wird in diesem Beispiel ein zusätzliches Input-Feld im Quelltext eingebunden und im Stylesheet über display:none; bzw. visibility:hidden; für alle CSS fähigen Browser ausgeblendet. Nun füllen Spambots in der Regel ja alle vorhandenen Formularfelder mit irgendwelchem Quatsch aus, beachten dabei jedoch kein CSS. Der “normale” User füllt also das zusätzliche Input-Feld nicht aus, da er es gar nicht sehen kann. Der Spambot hingehen füllt das Feld mit irgendwelchem Müll.
Nun muss man mit einer Programmiersprache wie PHP oder ASP nur noch checken ob das Feld gefüllt wurde, ist dies der Fall kann dann davon ausgegangen werden das es sich um Spam handelt.
Für mich stellt sich dabei nur die Frage der Barrierefreiheit. Soweit ich weis interpretieren Screenreader ja CSS auch teilweise und lesen Objekte mit display:none ebenfalls nicht vor… hat da vielleicht schon jemand Erfahrungen mit gemacht?
Zu guter letzt kann man sich dann noch fragen, wie lange die Spambetreiber denn brauchen werden um ihre Programme so zu stricken, das diese auch CSS halbwegs interpretieren können.
Ich möchte euch einmal kurz eine Einweisung zu einem kleinen Javascript geben, welches wirklich sehr einfache und hübsche Überblendeffekte für Fotos ermöglicht.
Ich stand letztens vor dem “Problem” das ein Kunde eine einfache Slideshow als Designelement in seine neue Webseite einbinden wollte. Da ich nicht der erfahrenste in Sachen Flash bin (aus gutem Grund) schaute ich mich nach einer Lösung für JavaScript um und bin nach einigem Suchen auch auf die perfekte Lösung gestoßen.
Mit Clearing habe ich als Float-Lover ja eher selten Problem, wenn ich in meinem Stylesheet bzw. meiner XHTML-Struktur denn mal ein Clearing benötige, dann habe ich dass ganz easy über <br class="c" />, wobei die Klasse c hier für clear:both steht, gelöst.
Das ist von der Semantik her vielleicht nicht ganz so schick, jedoch dafür mit allen Browsern funktionell, simpel und schlank im Quelltext.
Ich persönlich werde diese Lösung wohl auch noch weiter verwenden, bzw. werde bei festen Layouts auch weiterhin auf eine Umgebung aus gefloateten Elementen setzen, etwas besseres und kompatibleres gibt es für mich derzeit einfach nicht :)
Wer jedoch wirklich 100% semantischen Quelltext will, der kommt oft um eine Lösung ohne zusätzliches Markup nicht herum.
Für all diese CSS-Fanatiker hat Robert Nyman einmal die gängigsten Clearing-Methoden zusammengefasst. Mit Codebeispielen, Demos und den Nachteilen der jeweiligen Technik.
Ein guter Überblick wie ich finden,den man auf jeden Fall einmal gelesen haben sollte.
In letzter Zeit liest man als Webdesigner immer mehr von dem YAML-Framework für CSS basierte Webseiten. YAML soll, so habe ich es zumindest verstanden, viele grundlegende Elemente und Formatierungen bereits mit sich bringen, die im Nachhinein dann noch variiert und angepasst werden können.
Nun habe ich mir in letzter Zeit einige Projekte die mit YAML umgesetzt wurden angesehen, und ich verstehe einfach den Sinn des ganzen nicht? Eine Zeitersparnis? Wohl kaum!
CSS ist nicht wirklich komplex, jedenfalls bei weitem nicht so komplex wie z.B. Programmiersprachen wie PHP, JavaScript oder Ruby. Wozu hier ein Framework benötigt wird ist mir wirklich rätselhaft.
Bin ich mal ehrlich, so muss ich gestehen dass ich evtl. seit 18 Monaten effektiv auf CSS setze, und mich konsequent von Tabellen befreit habe. Anfangs war alles natürlich noch ein wenig holperig, doch schon nach 2-3 Umsetzungen brauchte kaum eine Webseite länger als einen Nachmittag zur reinen XHTML & CSS-Umsetzung, und das ohne sich dabei auf nur eine kleine Anzahl von Browsern festzulegen.
YAML hat zwar gute Ansätze, doch finde ich es persönlich einfach unnütz. Jeder der sich eine kurze Zeit mit semantischem XHTML und CSS auseinander setzt wird schnell in der Lage sein, flexible Layouts umzusetzen und das auch Browser übergreifend.
Für mich persönlich bietet YAML derzeit einfach kaum Vorteile. Der Quelltext ist bei manchen Seiten einfach alles andere als logisch, semantisch oft erst recht nicht. Es wird Code übertragen der einfach nicht sein müsste, auch in den CSS-Dateien.
Ein weiteres Manko ist wie ich finde die fehlende Unterstützung des IE5, der leider immer noch nicht das zeitliche gesegnet hat. Hier setzt YAML darauf, dem User einfach kein Stylesheet auszugeben. Ich will nicht angeben, doch bisher ist es mir fast immer gelungen meine Projekte fast vollständig für den IE5 umzusetzen, und das mit minimalem Aufwand und vielleicht 200 Byte mehr Quelltext.
Ich würde gerne von den Anwendern des Frameworks erfahren wo hier wirklich die Vorteile liegen, vielleicht erkenne ich Sie auch einfach nur nicht.
Ich würde an Anfänger jedoch appellieren, sich einfach ein gutes Buch zum Thema zu kaufen und anhand von Projekten gaaaaanz viel zu üben. Das ist auf lange Sicht hin sicherlich besser, als sich von einem Framework abhängig zu machen.
Eine kleine Starthilfe auf die ich persönlich seit einiger Zeit zurückgreife ist übrigens das schmale Standard Template von Manuela Hoffmann.
Zwar nicht perfekt, aber als Ausgangsbasis zu gebrauchen.
P.s.: Ich sollte mir in Zukunft angewöhnen nicht mehr so oft das Wort “einfach” zu verwenden ;)
Viele von uns Bloggern nutzen die tollen Dienste des kostenlosen Feedhosters Feedburner. Dieser Service speichert den die Feeds der eigenen Weblogs auf den eigenen Servern zwischen und kann somit bei viel besuchten Blogs enorm zur Ressourcenschonung beitragen.
Doch dies ist selbstverständlich nicht alles was Feedburner so bietet. Neben dem normalen Hosting können die eigenen Feeds z.B. auf Fehler hin geprüft werden, oder auch Statistiken zu den Lesern erstellt werden.
Worauf ich in diesem Beitrag jedoch im speziellen hinaus will, ist optimierte Ausgabe der Feedabonnenten auf dem eigenen Blog.
swfIR steht für swf Image Replacement und ist sozusagen das Gegendstück zu SIFR, welches je bekanntermaßen dafür genutzt wird, auch Systemfremde Schriftarten, barrierefrei in Webseiten einbinden zu können.
swfIR interessiert sich jedoch nicht für Schriftarten. Mit swfIR ist es vielmehr möglich, Elemente auf Webseiten mit hübschen Effekten wie z.b Schlagschatten, Rotationen, runden Rahmen oder automatischer Bildgrößenanpassung zu versehen. Interessant sind diese Effekte wohl vor allem für automatisch generierte Bilder, bzw. bei generellem Massenaufkommen von Bildern. Hier macht die Anwendung wirklich Sinn, denn bei einer eventuellen Änderung im Design muss das Bildmaterial nicht im geringsten angefasst bzw. verändert werden.
swfIR baut sowohl auf JavaScript als auch Flash. Ist eine der beiden Techniken nicht auf dem System vorhanden wird die Grafik ganz einfach ohne Effekt(e) wiedergegeben, von daher sollte auch der Punkt der Barrierefreiheit geklärt sein.
Das Paket kommt unobtrusive daher, es braucht also wieder nur einen geringen Aufwand, die Effekte in den eigenen Quelltext einzupflegen, der Rest passiert wieder über die Manipulation des DOMs.
Wiegen tut das ganz “nur” 23KB, ein verkraftbarer Wert wie ich finde, es sei denn der Quelltext strotzt eh schon vor CSS-Dateien, Bildern und JavaScripten.
Gefunden via: Jowra
Wie evtl. einige schon mitbekommen haben, nutze ich seit der neuen Hackthenet-Version eine Art Lightbox, welche jedoch auf den Namen Thickbox hört und einige tolle Vorteile mit sich bringt.
Zum einen wäre da, das die Thickbox “nur” 31Kb wiegt. Die Thickbox basiert zudem nicht auf den JS-Frameworks Scriptacolous oder Prototype sondern auf dem immer beliebteren jQuery. Da wäre also schon der zweite Vorteil. jQuery bringt viele gute und tolle Effekte mit sich, welche in der 31KB-Variante der Thickbox also bereits integriert wären. Wer eine kleine Kostprobe will, der möge einfach auf das Artikelbild klicken :)
Die Thickbox bietet jedoch noch andere Vorteile:
Zum einen werden Bilder automatisch der Browsergröße angepasst, kommt also jemand mit einer 800×600 Auflösung daher bleibt ihm das Scrollen erspart, das Bild wird automatisch proportional herunter gerechnet. Das ganze wird dann zwar etwas pixelig, jedoch ist diese Methode ja auch nur für die Ausnahme bestimmt.
Ein weiterer Vorteil ist, das die Thickbox nicht nur mit allen möglichen Bildformaten umzugehen weis, nein, jeglicher Browserinhalt kann mit Ihr hervorgehoben werden, sei es ein JPG, PNG oder auch ein PDF. Worauf ich jedoch hinaus will, ist die Möglichkeit von AJAX abrufen, also auch der Nutzung von HTML innerhalb der Thickbox, so ist es z.B. möglich ein schickes Loginformular bei einem Klick einfaden zu lassen, wirklich etwas sehr nützliches und innovatives.
Auch eine Galerieunterstützung (also das Vor und Zurückklicken innerhalb einer Bildershow) ist kein Problem.
Einzig Abstriche beim Effekt muss man evtl. tätigen, so klappt sich die Bühne nicht wie bei der Lightbox auseinander, sondern wird “nur” durch eine schöne Ladeanimation angekündigt und dann eingefadet.
Und noch ein Tpp:
Wer übrigens wirklich nur mal eben ein Bild schön einbinden möchte, dabei die 100KB der Lightbox scheut und die tollen Dinge der Thickbox nicht benötigt, der sollte auf die Slimbox zurückgreifen.
Sie arbeitet mit dem Mootools-Framework und ist Alles in Allem nur 21Kb “fett”. Die Slimbox unterscheidet sich im Effekt und der Anwendung dabei in keinster Weise zur Lightbox 2.0.
Versprochen ist versprochen. In meiner immer kleiner werdenden Freizeit hab ichs endlich mal geschafft das Design für den neuen Blog zu entwerfen und auch schon umzusetzen, natürlich in feinstem und kleinstem XHTML ;)
Was jetzt also noch kommen muss is die Blogsoftware. Da ich mich selber als TXPLover bezeichnen würde fällt meine Wahl eben auch wieder auf dieses tolle CMS...also Textpattern.
Das Design kam übrigens bei meinen “Testern” schon um ein vielfaches besser an als es das jetzige tut, alles in allem kommt die neue Seite auch einfach etwas frischer daher…der neue Slogan lautet daher auch “Ganz was frisches”... Also, ihr dürft gespannt sein :)
