Neues Feature für Webentwickler im Firefox-Inspector: hover, active und focus simulieren

Nachdem im Firefox seit irgendeiner Version 10+ ein eigener HTML-Inspektor vorhanden war, der Firebug in so ziemlich allen Belangen „unterlegen“ war, hat sich mit einem „Killer-Feature“ seit Version 14 das Blatt gewendet.

Screenshot des Inspectors aus Firefox 13

Screenshot des Inspectors aus Firefox 13

Was dem Firebug bisher immer abging war das ordentliche Untersuchen von :hover, :focus und :active-Stati von Elementen.

Screenshot des Inspectors aus Firefox 14

Mit dem Inspector in Firefox 14 lassen sich die Stati :hover, :focus und :active fest einstellen, so dass man CSS-Dropdown-Menüs bequem auch in den tieferen Ebenen untersuchen kann. Die Releasenotes schweigen erstaunlicherweise sich bezüglich dieses extrem nützlichen Features übrigens aus…

So. Nun bin ich auf den Nachschlag des Firebug-Entwicklers sehr gespannt.

(Wer sich jetzt fragt, welches Projekt hier als Beispiel für das neue Feature herhalten musste: das Projekt heisst leDashboard und soll ein iGoogle-Ersatz werden.

Warum 1-click-Software-Installationen eine eher schlechte Idee sind

Einer meiner Kunden möchte eine zusätzliche Internetseite lauchen und diese auf WordPress aufbauen, da auch Mitarbeiter einfach damit arbeiten können. Zugegeben: Die Verwaltung von DokuWiki kann man auch als eher schwierig empfinden, muss man aber nicht. Diejenigen meiner Kunden, die DokuWiki bisher einsetzen sind zwar schon lange „User“, in die Schublade der „HTML-Schreiber“ oder „Wikipedia-Autoren“ kann man sie aber nicht stecken. Trotzdem kommen Sie mit der Syntax gut zurecht und bauen ansehnliche Dinge damit zusammen.

Um sich das System vorher anzuschauen, hat er sich bei seinem Hoster mittels einer 1-click-Installation WordPress installiert. Beim Versuch, in dieser WordPress-Installation das Theme zu kopieren und als Child Theme zu duplizieren, fiel mir auf, dass genau das nicht ging. Das kopieren hat zwar funktioniert, die Themes wurden aber nicht „erkannt“.

Die 1-click-Installation hat den WordPress-Folder darüber hinaus mit dem Owner „root“ erzeugt, etwas, das ich weder über die SSH-Verbindung noch mit einem FTP-Client ändern kann. Darüber hinaus hat die Routine eine bereits vohandene Datenbank genommen und die Tabellen mit einem wp320DE_-Prefix erzeugt. Weiterlesen

Link-Ecke #14

  1. Interview mit mir beim Parkrocker

    Was soll ich dazu groß sagen?

  2. Neue Referenz für flexible Layouts: Hicksdesign

    Wir Webkrauts predigen ja seit langer Zeit, dass sich wahrhaft gute Webdesigns anpassen müssen an ihre Umgebung. Anders als gedruckte Zeitungen nehmen sie immer die Form an, die gerade am besten zur Nutzungssituation passt.

    Kleine Demontration von CSS Media Queries, die jetzt auch hier im Blog zum Einsatz kommen um den Netbook-Usern mehr Content auf den Screen zu bringen indem der Header für sie ausgeblendet wird.

  3. Watchblogs: Wächter über dem Mainstream

    All diese Seiten verbinden Expertise und aufklärerische Leidenschaft mit den Stärken der Blogs: Geschwindigkeit, Vernetzung, flexible Formen. Doch Watchblogs sind mehr als eine Plattform, auf der Medienmenschen über miese Kollegen und Verlage schimpfen. Viele Interessen- und Randgruppen dokumentieren durch Media Monitoring Diskriminierung und schaffen klare Gegenstimmen.

    Wahnsinn. Hat da eine Zeitung mal nachgedacht? Es scheint so.

  4. eEtiquette – 101 Leitlinien für die Digitale Welt

    Früher war alles einfacher: Ein Mann war ein Gentleman, eine Frau eine Dame und Knigge regelte seit über 200 Jahren wie die Menschen miteinander umzugehen hatten. Und heute?

    (via @michaeloeser)

  5. RIAA Accounting: Why Even Major Label Musicians Rarely Make Money From Album Sales

    It starts off with a band getting a massive $1 million advance, and then you follow the money […]

    Interessanter Artikel darüber, was ein Künstler am Ende von seinem Vorschuss hat und was er von dem produzierten Album noch so reinbekommt. Oder auch nicht. (via fefe)

  6. Bürger, nutzt die Informationsfreiheit!

    Eine Revolution in Richtung Transparenz: Das Informationsfreiheitsgesetz. Doch ohne wissbegierige Antragsteller keine Informationsfreiheit: Eine Kultur der Informationserteilung hängt auch von Bürgern und Journalisten ab, die das Recht nutzen.

    via bildblog

Der Tag an dem ich lernte, Conditional Comments zu lieben

Es gibt ja viele Möglichkeiten, eine Seite pixelgenau zu designen, so dass Sie in allen Browsern läuft gleich aussieht.

  1. Man baut die Seite aus Imageready-gesliceten Bildern in einem Tabellenlayout zusammen
  2. Man baut die Seite aus Imageready-gesliceten Bildern in einem DIV-Layout zusammen
  3. Man baut die Seite mit einem Tabellenlayout zusammen
  4. Man benutzt ordentliches (x)HTML mit CSS-Hacks
  5. Man benutzt ordentliches (x)HTML und Conditional Comments mit validem CSS
  6. Man benutzt ordentliches (x)HTML und valides CSS

Das Problem des gleichen Layouts betrifft im übrigen fast ausschließlich die Webbrowser aus Redmond. Eine valide Seite sieht in 95% aller Fälle in Firefox, Opera und Safari identisch aus. Lediglich der IE mit seinem verkorksten Boxmodel haut da quer. Der IE 8 im übrigen nur noch ganz selten.

Was nehm‘ ich denn da?

Dass wir die Punkte 1-3 vergessen können, sollte sich von selbst erklären. Tabellenlayouts sind rückständig und codeüberladen, außerdem semantisch unsinnig und barrierelastig.

Bleiben die Punkte 4-6 übrig. Wie man sieht, sind die Möglichkeiten ihrer Unsinnigkeit absteigend geordnet und dementsprechend werden wir diese drei Möglichkeiten jetzt mal durchgehen.

(x)HTML mit CSS-Hacks

CSS-Hacks sind kleine „Tricks“, die Interpretationsfehler bei Browsern ausnutzen um bestimmte CSS-Anweisungen nur für bestimmte Browser zugänglich zu machen. Diese Technik ist relativ zielgenau, auch weil es dafür entsprechende Zielhilfen gibt. Problem an der Geschichte ist, dass es leicht möglich ist, das CSS damit invalide zu machen, was zukünftig nicht vorhersehbare Bugs im Rendering noch nicht erschienener Browser erzeugen kann.

(x)HTML und Conditional Comments mit validem CSS

Die sauberste Möglichkeit, einem Rendering, dass von einzelnen Versionen des IE (und es ist in 95% aller Fälle mindestens einer der IEs der querschießt) zerschossen wird, zusätzliche CSS-Regeln beizubringen, sind CSS Conditional Comments. Hier werden zusätzliche CSS-Anweisungen für den Internet Explorer eingebunden. Dabei kann man sowohl ein paar zusätzliche Regeln mittels eines <style>-Tags einbringen oder einfach direkt ein zusätzliches Stylesheet einbinden.

Nachteil ist natürlich, dass diese Methode nur auf Internet-Explorer-Versionen unter Windows anwendbar sind. Meine bisherige Erfahrung hat aber gezeigt, dass Hacks/Workarounds im großen und ganzen nur für den IE nötig sind. Meistens auch unterschiedliche Lösungen für unterschiedliche Versionen.

Vorteil bei dieser Technick ist das Aufrechterhalten sämtlicher Validität in HTML und CSS, auch wenn man in den IE-Stylesheets unter Umständen Hacks einsetzt. Durch die Einbindung der Conditional Comments in Form eines speziell syntaktischen HTML-Kommentars werden andere Browser diese einfach ignorieriern und nicht ins DOM aufnehmen, wie es der IE tut, sofern er mit der Zielversion des Kommentars übereinstimmt.

Die restlichen 5% von Problemen, die sich damit nicht lösen lassen erfordern meist etwas Nachdenken über die CSS-Struktur und wie man Dinge anders beschreiben könnte. Allerdings muss man auch hier eventuell die IE-Styles dann nachpflegen, besonders wenn man am HTML etwas ändert.

(x)HTML mit validem CSS

Die „reinste“ Möglichkeit von allen. Erstrebenswert, aber eine Herausforderung, die sich gewaschen hat. Pixelgenaues Arbeiten ohne irgendwelche Kniffe ist kaum möglich. Für einfache Designs geht das bestimmt noch so halbwegs, aber dieses Blogdesign käme schon nicht ohne Extraregeln für den IE 6 aus, wenn ich ihn unterstützen wollte – was ich nicht will.

Vorteil ist bei dieser Methode eine sehr hohe Zukunftssicherheit, während man sich hier nicht allzusehr auf pixelgenaues Arbeiten versteifen sollte. Irgendein IE macht immer einen Strich durch die Rechnung.

Zusammenfassung

Wenn möglich, ohne Hacks, ohne Conditional Comments und Co. Wenn aber unbedingt hier im IE und da was im IE gemacht werden muss (wofür es natürlich mehrere Gründe geben kann, meistens ist es ein Kundenwunsch), dann am besten mit Conditional Comments.

Links

Warum die CSS-Evangelisten doch gar nicht so falsch liegen

Neulich bei Technikwürze: Die 13 Punkte des Mike Davis und warum Tabellenlayout angeblich und womöglich doch gar nicht so schlecht ist. Im Podcast gab es eine Diskussion um die Denkanregung, doch mal über den blinden „CSS-Evangelismus“ nachzudenken. Der Originalartikel findet sich ebi isolani: „The shallowness of CSS evangelism„.

Gerade im Bereich Traffic wird auch in TW diskutiert, sei es ja möglich, ebensogroße Datenmengen zu laden, wie bei Tabellenlayouts, gerade bei aufwendigen Stylings und unter der Prämisse, dass bei einem sauberen Stil das CSS getrennt geladen wird und somit einen weiteren HTTP-Request benötigt (inklusive Overhead).

Das mag beim ersten Besuch der Seite durchaus stimmen, aber dafür ist es dann ja egal, ob man nun CSS oder Tabellen hat. Beim zweiten Klick muss das CSS-Layout aber nicht alles nochmal laden. Nur das HTML-Gerüst wird ausgetauscht, der Rest (CSS) bleibt gleich. Eine Seite mit vielen PIs hat damit also im „Long Tail“ deutliche Vorteile.

Weiter stellt man die SEO-Vorteile auf den Prüfstand. Ich bin der Meinung, ein ordentlich gemarkuptes Layout mit entsprechender Dokumentstruktur wird immer einen Vorteil gegenüber den Table-Layouts haben, denn

  • die Content/Code-Quote ist höher, es gibt im HTML keinen so großen Overhead, damit ist die Keyworddichte pro Zeichen deutlich höher
  • das CSS juckt eine Suchmaschine nicht. HTML wird indexiert. Weiteres im Punkt obendrüber
  • Suchmaschinen machen oft einen nicht unerheblichen Teil des Traffics aus. Weniger HTML = Weniger Traffic

Ein wichtiger Punkt ist allerdings die Zukunftssicherheit und die Wartbarkeit der Seite(n). Ich habe allein mit CSS schon einige Sachen umgestyled, die man mit einem Tabellenlayout nicht hätte machen können – jedenfalls nicht so schnell und pragmatisch.

Und was ich tagtäglich erlebe sind HTML-Tabellen in generierten Seiten. Hier mal eine Ausgabe, da mal eine Ausgabe und das alles in verschachtelten Tabellen. Das Gerüst wird verdammt schnell verdammt unübersichtlich, auch mit Tools wie Firebug und der IE-Developer-Toolbar. Klar kann man sowas auch mit einem DIV/CSS-Layout produzieren, aber bei weitem nicht so schnell.

[poll id=“5″]