Jetstrap - The Bootstrap Interface Builder. Eventuell mal angucken - damit kann man Bootstrap Sites in ihrer Struktur entwerfen ohne mit dem CSS selber rumfummeln zu müssen. Der Output kann dann als Basis für die eigene Website benutzt werden. Schaut ganz nett aus.
html
Toolbox, H5 und twentytenfive sind Wordpress-Templates die auf HTML5 aufbauen. Ich sollte mir das mal angucken und schauen ob ich mein eigenes Theme nicht auf einem davon aufbaue, anstelle es vom Standard-Theme abzuleiten. Da ich derzeit ein Subtheme vom Standard Twentyten bin, könnte warscheinlich Twentytenfive am einfachsten sein - aber auch Toolbox könnte interessant sein, weil es ein wirklich minimales Theme ist, das ich als echte Basis verwenden könnte.
Chromium Blog: HTML Video Codec Support in Chrome. Woah. Google schmeisst H.264 aus dem video-Support von chrome raus und setzt voll auf Theora und WebM.
Oxymoron CSS Framework - ich kann Zed sehr gut verstehen. CSS treibt mich auch gelegentlich in den Wahnsinn.
Elixirgraphics - und hier gibts nette Themes für RapidWeaver. Besonders Lime, Factory und Nimbus gefallen mir. Sprout ist auch ganz nett. Und ja, ich weiß, keine freien Themes - aber hey, gutes Design ist ein Haufen Arbeit.
seyDesign Professional RapidWeaver themes - noch mehr RapidWeaver Themes und ein paar Open Source Versionen - mit denen könnte ich mir auch mal die Innereien so eines Themes genauer angucken.
YourHead Software - bin noch am überlegen, ob ich mir deren Plugins für RapidWeaver hole. Aus dem letzten MacHeist hab ich ja RapidWeaver recht günstig kriegen können und die ersten Experimente sind wirklich nett. Und die YourHead-Plugins bauen alle auf JavaScript auf anstelle von Flash, das könnte gut für statische Websites benutzt werden. Außerdem ist deren internes Datenformat einfach Ordner voller XML-Files, da könnte man auch was mit Tools machen.
Futurebox, lightbox without the JavaScript - muss ich mir mal angucken, das könnte ganz witzig in meinem Blog sein. Auch wenn dann natürlich diverse Browser ohne CSS3 Support nix damit anfangen können. So what?
Perfect multi-column CSS liquid layouts - iPhone compatible - wow. Das sieht sehr vielversprechend aus, vor allem der Punkt "keine Browser Hacks".
The Floating Boxes CSS Layout - vom gleichen Autor wie die vorherigen Layouts. Auch sehr interessant.
Warum Ihre Internet-Erfahrung langsam ist - "Wenn Inhalte König sind, warum gibt es dann so wenig davon im Web? Und warum jammern Content-Anbieter wie Salon immer über ihre enormen Bandbreitenkosten, wenn doch 99% dessen, was sie versenden — und das ist eine exakte Messung, keine Übertreibung — Spam ist?"
Dean Edwards: IE7.js version 2.0 (beta) - neue Version der genialen JavaScript Lib, die aus dem IE einen halbwegs konformen Browser macht.
Reset Reloaded - interessanter Ansatz bei den CSS-Default-Differenzen verschiedener Browser: einfach alles sauber zurücksetzen, so das Stylesheets auf gemeinsamer Basis anfangen können.
Faster Page Loads With Image Concatenation - interessante Idee, kleine Images zusammennageln und per CSS nur Ausschnitte zeigen. Reduziert Image-Requests drastisch.
QuirksMode - for all your browser quirks - Sammlung von Infos zu Browser-Differenzen und Möglichkeiten der Umgehung derselben.
HTML5, XHTML2, and the Future of the Web - werden natürlich all die XML-Proponenten wieder ignorieren. Aber es bleibt Fakt: die Zukunft des Web wird noch lange von HTML dominiert, nicht von XHTML. Und nein, kaputtes XHTML mit falschen Headern auszuliefern ist keine Lösung, sondern ein Problem ...
Why you should be using HTML 4.01 instead of XHTML - mehr zu XHTML vs. HTML
WebSnapr - Vorschaubildchen für Links. Interessantes Konzept.
Understanding HTML, XML and XHTML - HTML is probably what you want. Mal von einem geschrieben, der was davon versteht: einem der Programmierer von Safari. Keine Ahnung wie oft ich mir den Bockmist über "XHTML ist das bessere HTML" schon hab anhören müssen. Wer nicht explizit die Vorteile von XHTML - z.B. Einbettung von andren XML-Dialekten - nutzen will oder kann, sollte schlicht und einfach HTML nehmen.
The "Triple-X" hack - an exclusive CSS filter for IE7 - CSS hacks für IE7. Braucht man garantiert später mal ...
Colorblind Web Page Filter - ein Filter, mit dem man Webseiten auf Verträglichkeit mit verschiedenen Formen von Farbblindheit prüfen kann.
Open Source Web Design - ein Haufen Webdesigns zum runterladen und benutzen. Ideal für Design-Loser wie mich
Migrate apps from Internet Explorer to Mozilla - interessanter Artikel der eine Reihe von Fallstricken beim Wechsel zwischen IE und Mozilla.
CSS Fisheye - CSS-Lupen-Effekt in einem Textblock.
Fiddling with iWeb
Wenn eine Software solchen HTML Code erzeugt, dann ist sie definitiv scheisse. Und dabei interessierts mich nicht sonderlich, ob sie von Apple kommt. Sowas ist heute ein absoluter Tiefschlag in Richtung aller, die sich mit semantischer Auszeichnung beschäftigen und aller, die sich mit Accessibility beschäftigen. Ähnlich wie beim PhotoCasting-Debakel zeigt Apple mal wieder, da sie dann doch leider immer mal wieder zu "außen hui, innen pfui" tendieren.
Und ganz ehrlich - nicht nur der Code ist eine Katastrophe, sondern auch die generierten URLs - hat bei Apple noch nie jemand was von menschenwürdigen URLs gehört? Ach, watt frag ich, RSS Enclosures kennen sie ja auch nicht ...
Mehr zu iWebs HTML gibts bei Todd Dominey zu lesen.
Introducing Sandvox | Karelia Software - Web-Editor der zur Abwechslung mal neben dem WYSIWYG-Editing auch Standard-Compliance, Accessibility und sogar Uploads mittels SFTP unterstützt. Klingt so, als hätte da jemand seine Hausaufgaben gemacht.
Web Developer Extension - schon an tausend Stellen geblogged, aber nur hier als Merker: die neue Webdeveloper-Toolbar für FireFox 1.5. Unerlässlich für jeden Webschrauber.
Webstemmer - HTML-Grabber der aufgrund des Layouts den eigentlichen Kerntext von Websites extrahiert.
CSS2/DOM - Styling an input type="file" - wilde Hacks um File-Upload-Buttons mit CSS oder JavaScript zu stylen.
Weblogs - Variation auf den vorigen Link, hier JavaScript und CSS zusammen.
Und wir machen alle Fehler erneut
Es gibt im Moment einiges an Aktivität im Bereich der Microformats - die Idee dahinter: Informationsblöcke nicht in XML kodiert abzulegen, sondern in vordefiniertem HTML. Dazu werden dann die CSS Klassen benutzt, um zu definieren was ein einzelnes Format ist. Logischerweise gibt es Probleme mit kollidierenden Stylings - was für ein Wunder. Ich selber bin jedenfalls immer wieder erstaunt, wie viel Energie Entwickler auf saublöde Ideen verwenden können.
Wir hatten mal ein HTML, das sich nicht nur mit Semantik beschäftigte, sondern auch mit Layout. Und das produzierte die allseits beliebten FONT-Tag-Orgien in HTML-Seiten. Im Laufe der Zeit hat sich bei den meisten die Idee durchgesetzt, das Trennung von Semantik und Layout sinnvoll ist - Semantik als Auszeichnungsgrundlage für den Inhalt, Layout in die CSS Files und als Verbindung zwischen diesen die IDs und Klassen an Tags. Zusätzlich mit DIV und SPAN "anonyme" Tags ohne vordefinierte Semantik (ausser "das ist ein Block von Text" und "das ist eine Inline-Strecke von Text" - wobei diese Bedeutung problemlos überladen werden kann), für die Sachen die mit der normalen Semantischen Auszeichnung nicht gehen (was hauptsächlich an der selten dämlichen Idee von HTML liegt, das es zwar Auszeichnungen für Überschriften gibt, aber keine Auszeichnungen für Abschnitte von Texten, zu denen diese Überschriften gehören würden).
Was machen Microformate jetzt? Nunja, die gleiche blöde Idee, etwas zu missbrauchen - nämlich in diesem Fall die oben angesprochenen Verbindungsstücke zwischen der Semantik und dem Layout. Microformats geben diesen eine Bedeutung - z.B. wäre eine DIV mit einer Klasse 'description' dann die Beschreibung eines Reviews - lest euch die Details in der hReview Referenz durch. Sorry, aber sowas muss einfach zu Konflikten führen - haben die Pappnase noch nie was von Namespaces gehört? Die Microformats addressieren explizit XHTML - und das hat genau für den Zweck der Einbettung eben Namespaces. Und wenn man meint, man müsse schon eine so blöde Idee wie diese umsetzen - könnte man dann nicht wenigstens schlau genug sein, den Teilen etwas kryptischere, aber dafür eindeutigere Klassen zu geben?
Wie gesagt, erstaunlich wie viel Energie in solche dämlichen Ideen gehen, die dazu verdammt sind mehr Probleme als Lösungen zu schaffen.
IE7 und Auswirkungen auf CSS Hacks
IE7 and the demise of CSS hacks ist über die IE CSS Hacks die man so im Laufe der Zeit liebgewonnen hat und die bei IE6 dringend notwendig sind, um CSS Layouts wenigstens präsentabel auf den IEs zu machen. Mit IE7 wird sich da einiges ändern - und einige davon werden nicht mehr funktionieren.
Dringende Empfehlung: Umstellen auf conditional comments und Verschieben der CSS Korrekturen in ein eigenes Stylesheet, das für den IE dann hinzugeladen werden kann. Leider kann man damit nur CSS Elemente für den IE zufügen, nicht vorhandene Elemente vor dem IE verstecken - möglicherweise kann man da aber was mit Überschreiben von Elementen machen.
Im IE Blog ist eine Liste der Hacks die problematisch mit IE 7 sein werden.
Wenn Webdesigner ein Schimpfword ist
Zum Beispiel bei solchen Firmen, die gegen ALT-Attribute an IMG-Tags wettern und die dann auch noch fälschlicherweise ALT-Tags nennen. Naja, Inkompetenz ist deren Konzept:
Just exactly what text can a person read or see in a 1 x 1 pixel gif? Zippo. Thus, the text or line reader, JAWS, cynthia, etc, should be smart enough to see that the image size of Height="1" and Width="1" and automatically know it's a spacer and then make a if-then condition to NOT PRONOUNCE alt tag in the spacer.gif.
Ich hab ja selber eine ganze Menge Table-Layouts schon bearbeitet - unter anderem weil sie einfach nunmal da waren - und ich kann mich nicht daran erinnern wann die Spacer tatsächlich in 1x1-Pixel ausgegeben wurden. Klar, das Bild selber war nur 1x1 Pixel gross, aber die width und height Angaben an den IMG-Tags natürlich entsprechend der Grösse die aufgespannt werden sollten. Ausserdem waren noch jede Menge andere Layout-Elemente als IMG-Tags im Source, alle Kandidaten für ALT="" - aus gutem Grund, Layout-Grafiken sollen von Screen-Readern korrekt umgangen werden. Nach deren Vorstellung aber soll wohl der Screeenreader erst das für ihn völlig unnütze Grafikelement laden und draufgucken wie gross es ist. Nur weil die Trolle zu faul sind ALT="" an IMG-Tags zu schreiben.
Oh, und sie verlangen von Screenreadern auch noch mehr Intelligenz:
HERE IS SIMPLE SOLUTION so EVERYONE WILL NOT HAVE TO RE-WRITE THEIR PAGES just for you.
READ THE BIG TEXT FIRST, either font tags with say 3 to 7, or CSS styles with the biggest fonts sizes. Next, read the 2nd largest fonts second, and so on. This is JUST LIKE WHAT HUMAN WOULD DO ANYWAY.....So, look for Font tags with a setting 7 or 6 or 5 or 4 and down and in that order and then start reading it. Same with CSS, PIXELS sizes of say 24px should be read FIRST, NOT LAST!! How hard can this be? This what the browsers do anyway, so why can't you do it?
Genau. Sollen doch die Screenreader sich aus der Tagsoup raussuchen was sie brauchen (inklusive Analyse von font-Tags und solchem Müll), anstelle das der Designer sich mal überlegt was er produziert und eine einigermaßen logische Struktur für textonly-Browser liefert. Hey, wozu gibt es wohl seit HTML 1 die h-Tags und ihre Freunde? Ach watt, ist sicherlich alles nur Einbildung ...
Aber bei denen findet man eh noch mehr Perlen, wie zum Beispiel die Diskussion über CSS vs. Tabellen-Layouts, in denen CSS natürlich so richtig schlecht gemacht wird. Weil sie so ganz und gar garnix kapiert haben was CSS ausmacht und warum man HTML und CSS trennt und was daran die gute Idee ist. Weil sie vermutlich in ihrem ganzen traurigen Designerleben keine einzige gute Idee hatten und sie deshalb nicht mal erkennen würden wenn sie ihnen mit nem dicken Knüppel auf die Rübe haut, die gute Idee.
Achja, zum Ende noch ein Wort der Warnung an aktuellere Designer: guckt euch lieber nicht deren Sourcecode an, denn der wird euch Haarausfall, aufgerollte Fussnägel und faulige Zähne verursachen
LiveSearch mit WordPress klappt
Ich hab mir gerade mal LiveSearch angeguckt und ein bischen herumgespielt damit. Liess sich mit etwas Hacken in WordPress integrieren. Wenn ihr jetzt in das Suchformular rechts einen Begriff eingebt, kommt nach einer kurzen Verzögerung eine Liste von Suchergebnissen - und zwar die Titel der Postings. Das ganze benutzt die normale WordPress-Suche, das sind also die gleichen Ergebnisse die ihr auch bekämt wenn ihr einfach Enter drücken würdet - nur dank Ajax einfach fixer und als direkte Inline-Liste. Witzige Sache. Sollte mit aktuellen IEs, mit Mozilla-Abkömmlingen und aktuellen Safaris funktionieren.
Was allerdings seltsamerweise bei mir nicht funktioniert, obwohl meines Erachtens der Code identisch ist zu der BitFlux-Seite, sind die Cursor-Tasten zur Bewegung in den Suchergebnissen. Irgendwie findet der nicht die erste Zeile oder sowas - sehr seltsam. Aber der Teil interessiert mich eigentlich eh nicht so doll, von daher störts mich nicht wenn der nicht funktioniert.
Hmm. Safari funktioniert tadellos, aber mein FireFox unter OS X will irgendwie nicht. Sehr seltsam das ganze. Genauer gesagt tuts das mit dem FireFox erst, wenn ich einmal ein Zeichen mit Backspace gelöscht habe oder einmal Space eingebe. Danach läufts sauber. Kann mir das mal jemand erklären? Witzigerweise funktioniert die Cursortastennavigation in den Suchergebnissen mit dem FireFox - wenn man denn mal eine Liste von Ergebnissen hat ...
Update: seltsamerweise funktioniert jetzt im Safari die Cursor-Tasten-Navigation. Irgendwas ist hier sehr strange ...
Safari und der Rabenhorst
Weiss irgendjemand warum sich der Safari von Tiger auf dem Rabenhorst verabschiedet? Und wenn es jemand weiss, kann er es dem Kai mitteilen, damit der das behebt und ich nicht jedesmal einen Artikel neu schreiben muss, nur weil ich wieder mal was dafür bei ihm nachgucken wollte?
Das seltsame: wenn ich mit PithHelmet bei seiner Site JavaScript abschalte, passiert nix. Nur hat seine Site kein JavaScript - einzig der Jabber-Status (der übrigens ohne JavaScript-Aktivierung extrem gross angezeigt wird) wird über ein OBJECT-Tag statt über ein img-Tag eingebunden. Obs das OBJECT-Tag für PNGs ist, was den Safari in den Orkus schickt?
Ah, ja, nach ein bischen graben, es scheint wirklich so zu sein. Geht zu dieser Seite und ihr werden das gleiche Problem haben - der Safari crashed. Anscheinend wird das OBJECT-Tag benutzt um PNGs auch auf älteren IEs anzuzeigen - dabei wird das gleiche PNG per OBJECT Tag und enthaltenem IMG Tag referenziert. Führt nur leider zu crashes mit Safari 2.0.
Warum jetzt aber das deaktivieren von JavaScript (nicht das deaktivieren von Plugins, was man ja beim OBJECT-Tag eher vermuten würde!) dazu führt das der Safari nicht crashed und das PNG falsch (zu gross) darstellt, das kapier ich ehrlich gesagt nicht so ganz ...
Oh, und der Bug mit object-Tags scheint schon länger zu existieren - älteste Reports aus 2003 die ich in Google gefunden habe. Wäre doch mal nett wenn Apple den Bug auch wirklich fixen würde. Oder irgendjemand anderes, wo doch jetzt der Source frei verfügbar ist.
Bei der Suche nach Debugging-Hilfe bin ich übrigens über diesen Artikel über CrashReporterPrefs gestolpert - in Tiger kann man den Crash-Dialog erweitern und dann auch gleich einen Debugger anhängen wenn ein Crash auftritt. Sehr nett zum Wühlen in CrashDumps
Übrigens hat OmniWeb - obwohl es auch auf dem WebCore-Framework aufsetzt - das Problem nicht. Wär ja auch zu einfach gewesen ...
Update: der Übeltäter ist gefunden. Es waren die WebDevAdditions für Safari - ich habe einfach die aktuelle b11 installiert und schon fluppt alles wieder ganz normal.
Firefox erhält SVG-Unterstützung - endlich eine erste unabhängige SVG-Implementierung und vor allem eine breite Plattform für dieses Format.
/IE7/ ist ein Projekt das mittels JavaScript-Library dem IE6 CSS vernünftig beibringt. Damit sollen auch :before und :after in Kombination mit content: funktionieren - für HTML-freie rounded corners oder HTML-freie Link-Kennzeichnung durch Symbole nicht ganz unwichtig ...
Simulation von :before mit content: in IE6
Der IE6 kann ja nunmal nicht mit :before klarkommen, wenn man darüber per content: über das CSS Inhalt in die Seiten bringen will. Ziemlich nervig, wenn man das benutzt. Das IE7-Projekt von dem ich im vorigen Artikel schreibe funktioniert bei mir aber auch nicht verlässlich - z.B. unter einem Citrix-Server will er das nicht ausführen, warscheinlich fehlen ihm irgendwelche Sicherheitseinstellungen dort. Strange. Egal, ich hab mir das Problem selber mal angeguckt und eine recht kompakte Lösung gefunden, jedenfalls für meine spezielle Spielart des Problems: ich will nämlich nur Icons vor einen Link stellen.
Dazu haben Links eine von drei Klassen oder keine Klasse: class="zu" definiert ein zugeklapptes Navigationselement, class="auf" ein aufgeklapptes, class="ohne" einen Link der nicht speziell angehübscht werden soll und alle anderen Links kriegen ein Standard-Icon.
Dazu hänge ich einfach unten in die Datei kurz vor dem /body folgenden Code:
var links = document.getElementsByTagName("a");
for (var i=0; i
Den ganzen Kram packe ich dann am besten noch in einen bedingten Kommentar für den IE, so das er nur von diesem überhaupt ausgeführt wird. That's it. Simpel und wirksam. Deaktiviertes JavaScript ist in meinem Fall nicht kritisch, da ohne JavaScript auf dem System (ist eine Business-Lösung mit hoher Interaktivität) demnächst eh nix mehr laufen wird- Ajax braucht nunmal JavaScript als eine Komponente ...
Html Validator for Firefox and Mozilla - wow. Klasse Extension: macht direkt eine Validierung der angezeigten Webseite und integriert sich in den Source-View zwecks Debugging der Fehler. Sehr nett - und in den letzten Tagen durch mehrere Weblogs gelaufen (weiss nicht mehr wo ich es zuerst gesehen habe).
TidBITS: What You Get Is What You CSS, With Style Master 4.0 - klingt sehr interessant, ein Programm, mit dem man CSS-Files editiert und direkt in Verbindung mit verschiedenen Webseiten anzeigen lassen kann. Muss ich mir mal angucken, denn CSS-Files von Hand dengeln und damit rumprobieren ist manchmal dann doch recht nervig, sowas offline vorbereiten zu können wäre ganz nett. Update: sorry, aber nach einem ersten Test ist das Teil wieder von der Platte geflogen. Gute Idee, lahme und unintuitive Umsetzung.
Gefunden beim photomatt: Nifty Corners sind abgerundete Ecken die ohne Bilder auskommen. Wahlweise direkt mit HTML und etwas CSS oder CSS und etwas JavaScript, das den DOM-Tree entsprechend umschreibt.
The Man in Blue > Experiments > widgEditor ist ein Wysiwig-Editor für HTML der Textareas im Browser austauscht und in JavaScript geschrieben ist. Er hat einen integrierten Fallback auf normale Textareas, so das Browser ohne JavaScript immer noch mit normalem Text arbeiten können. Und er produziert sauberes XHTML. Und: er funktioniert bei mir tatsächlich mal vernünftig.
Bildbeschneidung mit DHTML und PHP dahinter. Könnte in einem Photo-Plugin ganz praktisch sein.
Und wer kein Lisp mag oder kann, vielleicht hilft ja SAJAX - Simple Ajax Toolkit by ModernMethod - XMLHTTPRequest Toolkit for PHP das nicht nur PHP sondern auch noch Io, Lua, Perl, Python und Ruby unterstützt.
Usable XMLHttpRequest in Practice ist ein interessanter kleiner Artikel der anhand eines Beispiels die Nutzung von XMLHttpRequest erläutert und auf Useability-Aspekte eingeht.
Skidoo Too : Ruthsarian Layouts
Skidoo Too : Ruthsarian Layouts ist ein recht simples 3-Spalten-Layout mit einer flexiblen Mittelspalte. Das Besondere: die Reihenfolge des Sources ist so, das die mittlere Spalte zuerst kommt. Dadurch ist die Useability für Lynx-Benutzer besser, weil sie sofort an den Content kommen und nicht erst die Navigation überlesen müssen. Das Layout ist Public Domain.
Er hat auch auf der Seite noch ein weiteres Layout das zwei flexible Spalten hat und nur die linke Spalte fest vorgibt, gleiche Source-Reihenfolge.
Introducing sIFR: The Healthy Alternative to Browser Text
Introducing sIFR: The Healthy Alternative to Browser Text beschreibt eine auf JavaScript, CSS und Flash aufbauende Methode um Textstyling von den Beschränkungen von CSS zu lösen und beliebige Fonts zu verwenden.
Die Technik arbeitet ähnlich wie Image-Replacements durch CSS, nur das der ausgetauschte Text mit der Seite mitwachsen kann (z.B. wenn der Benutzer einen grösseren Basefont eingestellt hat). Hat ein Besucher Flash und JavaScript verfügbar, werden entsprechend markierte Textbereiche durch ein Flash-Rendering ersetzt.
Hat der Besucher kein Flash oder ist JavaScript deaktiviert, sieht er ganz normale Textinhalte über die Möglichkeiten des Browsers. Die Accessibility bleibt also weitestgehend erhalten - das HTML bleibt semantisch und Screenreader bei Textbrowsern sowie semantisch gesteuerte HTML Reader sollten problemlos damit klar kommen, Sehbehinderte mit grossen Fonts auch - durch Deaktivierung von Flash zum Beispiel würde der eingestellte Userfont gewählt.
Besser als CSS-Image-Replacement für Header ist es allemal, da es sich an die dynamische Umgebung wesentlich besser anpassen kann. Image-Replacements werden nicht gezoomed und unterstützen kein Copy-and-Paste der Inhalte (was von Flash ebenfalls unterstützt wird).