Die Feature-Vielfalt der Developer Tools und die gute Integration in den Browser machen Chrome zur Zeit zur besten Debugging-Umgebung, die man sich als Webentwickler wünschen kann. Das eigentlich Tolle den Devtools sind die vielen kleinen Dinge, die das Leben leichter machen. Es ist sicher total nützlich, dass man JavaScript-Profiling betreiben kann und Performance-Daten exportieren kann, aber für den Alltag sind dann doch weniger die die Super-Nerd-Features und die Brot-und-Butter-Funktionen als die die Kleinigkeiten wichtig. Ich dachte ich schreibe mal alle dieser Kleinigkeiten auf, die mir so einfallen und von denen ich mir gewünscht hätte, dass man sie mir eher verrät. Falls euch eine Funktion oder eine Erweiterung fehlt: ab in die Kommentare damit!
Allgemeines
Cache abschalten: In den Settings (Klick auf das Zahnrad-Icon unten rechts) kann man unter „Disable cache“ den Browser-Cache abschalten. Diese Abschaltung gilt nur, während der Web Inspector auch geöffnet ist.
Zoom: Der Web Inspector ist eine ganz normale HTML-Seite, kann also auch gezoomt werden. Einfach reinklicken und die Tastenkombination für Textvergrößerung/verkleinerung bemühen.
Inspektor inspizieren: Wenn der Inspektor eine normale HTML-Seite ist, können wir ihn auch inspizieren. Einfach einen Web Inspector öffnen, dann in einem anderen Fenster chrome://inspect aufrufen. Unter „Other“ findet ihr den geöffneten Inspector und könnt ihn inspizieren. Vor allem nützlich für Custom Styles …
Custom Styles: Wenn der Inspektor eine normale HTML-Seite ist und wir ihn inspizieren können, können wir für ihn auch eigene Styles verwenden. Der Body des Inspectors hat die ID -webkit-web-inspector, was als Namespace für inspectorspezische Custom Styles genutzt werden kann. Ich persönlich nutze dies um die Schrift größer einzustellen.
Themes: Wenn der Inspektor eine normale HTML-Seite ist und wir ihn inspizieren können und wir für ihn auch eigene Styles verwenden können, können wir auch komplette Themes benutzen. Die erste Anlaufstelle hierfür ist devthemez.com.
Overrides: In den Settings (Zahnrad im Web Inspector unten rechts) gibt es die Overrides mit denen sich diverse Devices simulieren lassen. Diese Simulation macht aber mehr als nur den User Agent String auszutauschen: zum Beispiel wird auch der Viewport des Browsers auf die Maße des Geräts skaliert. Für den ersten Eindruck beim Resposive-Designen sehr praktisch. Ebenso kann man dort Fake-Sensordaten und Fake-Geolocation-Koordinaten wählen.
Print Emulieren: Da wo auch die Overrides sind gibt es die Möglichkeit Chrome einen Media Type unter „Emulate CSS Media“ zu verordnen. So kann man z.B. die Printversion einer Seite gestalten, ohne ständig in die echte Druckansicht wechseln zu müssen. Klappt natürlich auch mit anderen Media Types.
Keyboard Shortcuts: Unterscheiden sich von Betriebssystem zu Betriebssystem, sind aber unter „Shortcuts“ in den Settings einzusehen. Sollte man genau so auf dem Kasten haben wie die Shortcuts in Editor/IDE.
Konsole
Omnipräsente Konsole: Eigentlich braucht es in den Devtools gar kein eigenes Konsolen-Panel, denn in jedem anderen Panel lässt sich am unteren Rand schon eine Konsole einblenden. Das funktioniert entweder mit einem Klick auf den entsprechenden Button (zweiter von links) oder mit einem beherzten Druck auf ESC
Konsole für Frames: Konsolenbefehle lassen sich ganz einfach im Kontext eines (I)Frames ausführen. Unter jeder Konsole gibt es ein Menü, das standardmäßig auf „<top frame>“ steht. Hat man Frames in der Seite, kann man diese hier auswählen – und schon meint ein window in der Konsole das window-Objekt des Frames und nicht mehr das der Elternseite.
Konsolen-Nachrichten behalten: In den Settings lassen sich Nachrichten in der Konsole mit „Preserve log upon navigation“ eine längere Lebensdauer einhauchen, so dass sie erhalten bleiben, wenn man durch die Gegend navigiert.
$(): Wählt in der JavaScript-Konsole ein einzelnes Element anhand eines CSS-Selektors aus. Beispiel: $('body')
$$(): Wählt in der JavaScript-Konsole mehrere Elemente anhand eines CSS-Selektors aus. Beispiel: $$('p.foo')
$0: In der JavaScript-Konsole verfügbare Referenz auf den DOM-Knoten, der gerade im Elements-Panel angewählt ist. Beispiel: console.log($0)
$1, $2, $3, $4: Element-Auswahl-History. $1 ist eine Referenz auf das Element, das vor $0 angewählt war, $2 ist eine Referenz auf das Element, das vor $1 angewählt war und so weiter.
$_: merkt sich das Ergebnis des zuletzt in der Konsole evaluierten Ausdrucks. Tippt man beispielsweise 1 + 2 ein, erhält man nicht nur sofort 3 zurück, sondern dieser Wert ist dann auch für die spätere Verwendung in $_ zu finden.
inspect(): Konsolen-Funktion, die das übergebene Element im Elements-Panel anwählt. Beispiel: inspect($2)
console.dir(): während ein log() eines DOM-Knotens den Inhalt des Knotens anzeigt, zeigt dir() den Knoten als JavaScript-Objekt mitsamt sämtlichen Properties an. Beispiel: console.dir($0)
console.count(): Wenn gezählt und ausgegeben werden soll, wie oft etwas passiert, reicht es, console.count() mit einen String als Identifikator zu füttern; den Rest übernimmt der Browser.
Stringersetzung in console.log(): Es gibt mehrere Platzhalter für Stingersetzung, die in einen String als erstes Argument andere Variablen einbauen. Es gibt %s formatiert eine Ersetzung als String, %d und %i formatieren als Integer, %f als Fließkommazahl, %o als DOM- und %O als JavaScript-Objekt. Beispiel: console.log('Um %f gab es %d Elemente', Date.now(), document.childNodes.length)
CSS in console.log(): Mit dem Platzhalter %c lassen sich CSS-Formatierungen in Konsolen-Output einbauen. Beispiel: console.log('%cRot %cGroß', 'color:red', 'font-size:2em')
console.warn(): Zeigt Warnungen als solche an, d.h. garniert mit dem passendem Icon. Beispiel: console.warn('Vorsicht!')
console.error(): Zeigt Fehler als solche an, d.h. mit dem passendem Icon und Stack Trace. Beispiel: (function foo(){ console.error('Fail'); })()
Multi-console.log(): Die Log-Funktionen können mehre Dinge auf einmal ausgeben, wenn man ihnen einfach mehrere Arguments mitgibt (und die Ersetzungsmöglichkeiten nicht benutzt). Beispiel: console.log('Foo', 42, [])
Gruppierungs-Funktionen: Konsolen-Meldungen aller Art lassen sich in übersichtliche, zusammenklappbare Gruppen zusammenfassen. Einfach mit console.group('Titel der Gruppe') beginnen, dann alles mögliche loggen und die Gruppe mit console.groupEnd() schließen. Gruppen können verschachtelt werden und mit console.groupCollapsed('Titel der Gruppe') lässt sich eine zu Beginn eingeklappte Gruppe eröffnen.
Event-Überwachung: Wer nur wissen möchte, ob ein Event überhaupt stattfindet, braucht dafür keinen Code in irgendwelche Dateien schreiben, denn die Konsole tut es auch. So lässt man sich z.B. jeden Klick auf das Body-Element loggen: monitorEvents(document.body, 'click')
Timing: Die Konsole hat eingebauter Timer-Funktionen. Mit console.time('Foo') startet man einen Timer mit der ID Foo, der sich mit console.timeEnd('Foo') wieder stoppen lässt. Ausgegeben wird dann die Zeit, die für zwischen time() und timeEnd() durchgeführten Operationen verbraucht wurde.
Elemente
Suche: Das Elements-Panel hat seine eigene Suchfunktion, mit der sich schnell das komplette DOM durchforsten lässt. Einfach im Web Inspector mit der entsprechenden Tastenkombination die Suche öffnen und z.B. nach „<div“ suchen. CSS-Selektoren funktionieren in der Suchbox auch: „div div“ findet nur Div-Elemente, die mindestens einen Div-Vorfahren haben. XPath funktioniert auch.
Drag & Drop: Wenn das Layout mal schnell rearrangiert werden soll reicht es schon, in Elements-Panel die Elemente an die richtige Stelle zu ziehen.
Element-Status erzwingen: Im Kontextmenü von Elementen gibt es unter „Force Element State“ die Möglichkeit, Elemente dauerhaft in z.B. den :hover-Status zu versetzen.
Metrics editieren: Die Werte der Metrics-Box können nach einem Doppelklick direkt bearbeitet werden, ohne dass man den Umweg über CSS nehmen muss.
Style-Änderungen speichern: Änderungen an bestehenden Style-Regeln oder Metrics können einfach persistiert werden, denn der Inspector baut die Änderungen automatisch in die entsprechenden Einträge im Sources-Panel ein. Dort kann man nach den Änderungen einfach die betroffene CSS-Datei heraussuchen und speichern.
DOM-Breakpoints: Im Kontextmenü von Elementen gibt es unter „Break on …“ die Möglichkeit, Breakpoints für Modifikationen an diesem Element zu setzen, dass der Debugger anhält, wenn auf diesem Element Attribute oder Kindelemente verändert werden. Diese Breakpoints lassen sich dann in der rechten Leiste unter „DOM-Breakpoints“ wieder entfernen. Zum Test einfach mal einen DOM-Breakpoint für Attributänderungen setzen und in der Konsole $0.classList.add('foo')
ausführen
Network
Timeline sortieren: Klar, im Network-Panel kann man die Requests nach ihrer Gesamtzeit oder alphabetisch sortieren. Aber auch die Sortierung nach einzelnen Zeitverbrauchsmerkmalen ist drin! Hierzu einfach auf den Header der „Timeline“-Spalte klicken und dort wahlweise nach Latenz, Dauer oder Start- und Endzeiten der Requests sortieren.
Debugging
debugger-Statement: Ein in JavaScript-Code fest eingebauter Breakpoint. Klappt nicht nur in Chrome, sondern in den meisten Browsern. Beispiel: if(shouldNeverHappen){ debugger; }
Conditional Breakpoints: Ob ein im Browser gesetzter Breakpoint tatsächlich das Programm anhält, kann man vom Ergebnis einer JS-Expression abhängig machen. Einfach einen Breakpoint setzen, Kontextmenü öffnen und „Edit Breakpoint“ auswählen, die Expression der Wahl eintippen und fertig – das Programm wird nur gestoppt, wenn besagte Expression true zurückgibt.
Breakpoint Actions: Man kann in Conditional Breakpoints jede JS-Expression verwenden die man möchte, das Programm stoppt nur, wenn true zurückgegeben wird. Ein console.log() würde mit seinem Rückgabewert undefined das Programm nicht stoppen, aber es würde ausgeführt werden. So kann man console.log()-Aufrufe in Code einbauen, ohne einen Editor zu bemühen! (Quelle)
Pretty Print: Wenn ihr im Sources-Panel ein minifiziertes Stück JavaScript-Code aufruft, kann es der Web Inspector deobfukskieren. Dazu einfach den Button mit den Schweifklammern unten links bemühen.
Break on Exception: Der Pause-Button direkt neben Pretty Print veranlasst den Browser, die Webseite im Falle einer unbehandelten Exception einzufrieren, so dass man leicht nachvollziehen kann, was gerade schief gelaufen ist.
Error.stack: Error-Objekte haben in JavaScript eine Eigenschaft namens stack, die man direkt nutzen kann um Stack Traces als Plaintext einzusammeln. Diese kann man dann anzuzeigen oder loggen. Beispiel: try { existiertNicht(); } catch(err) { console.log(err.stack); }
Watch Expressions: Öfter dabei ertappt, die immer gleichen Befehle in die Konsole zu scheiben? Welchen Wert hat x jetzt, welchen Wert hat x jetzt? Das geht auch einfacher: Im Sources-Panel können unter „Watch Expressions“ mehrere Ausdrücke zur Überwachung hinterlegt werden. Diese dann alle auf einmal nach einiger Zeit oder einem Reload zu aktualisieren ist dann nur noch die Sache eines Klicks auf den Refresh-Buttons.
Breakpoints für XHRs und Events: Im Sources-Panel gibt es auch die Möglichkeit Breakpoints für XHRs (entweder alle Requests oder nur Requests an bestimmte URls) und Events einzurichten. Hierzu einfach die jeweiligen Panels unter der Debugger-Steuerung bemühen.
Coding
Deus Ex HTML: Ihr braucht mal schnell eine HTML-Seite um etwas zu testen? Einfach einen neuen Tab öffnen und data:text/html,<!doctype html> in die Adresszeile schreiben.
Hot Swapping: Im Browser durchgeführte Änderungen an einer JavaScript-Datei greifen sofort und ohne speichern und neuladen der Seite. Einfach im Sources-Panel die Datei öffnen, etwas ändern und die Änderungen anwenden (Speichern-Hotkey). Zum Testen einfach mal auf dieser Seite die Funktion foo verändern!
Snippets: Falls ihr öfter mal das gleiche JavaScript in den Devtools abfahren möchtet, könnt ihr im Browser entsprechende Snippets vorrätig halten. Diese lassen sich im Snippets-Tab unter Sources wie jeder andere Codeschnipsel direkt anlegen und bearbeiten.
Diffs: An den Sources rumgebastelt aber keine Ahnung mehr alles genau verändert wurde? Kein Problem: Im Kontextmenü des Texteditors gibt es den Punkt „Local Modifications“, über den sich ein schönes Diff abrufen lässt.
Erweiterungen und Libraries
LiveReload: Ich hoffe einfach mal, dass dass schon von euch allen benutzt wird. Wenn nicht: ihr macht was falsch.
CoffeeConsole: Eine kleine CS-Konsole direkt im Web Inspector
Log: Einfaches formatiertes Consolen-Logging via JS-Library. Unterstützt (ein wenig) Markdown!
Tincr Vereinfacht das In-Browser-Editing mit einer praktischen Autosave-Funktion. In dem Moment, in dem ihr in Chrome etwas ändert, wird die betroffene Ressource automatisch gespeichert.
Es ist mal wieder soweit: Leser fragen Fragen zu HTML5, CSS3 und JavaScript, der HTML5-Erklärbär antwortet. Eure Frage fehlt? Kein Problem: einfach eine E-Mail schreiben oder per Twitter melden!
HTML5-Outlines in the wild
Dieser ganze Krempel mit Überschriften, Sectioning und Outline-Algorithmus, bei dem man jeden neuen Abschnitt einfach mit <h1> beginnen kann (und sollte), dass ist doch reine Fiktion, oder? Und das <hgroup>-Element ebenso?
„Reine Fiktion“ ist eine etwas zu starke Wortwahl. Es gibt durchaus Implementierungen des Outline-Algorithmus, z.B. in Form von h5o und auch eine moderne Browser können <h1>-Elemente wie andere Headlines stylen, wenn ihre Position in der Outline das hergibt. Aber an vielen wichtigen Stellen wo er möglicherweise wichtig sein könnte (z.B. beo Suchmaschinen) fehlt es noch so sehr an Unterstützung, so dass ich nicht empfehlen würde, groß auf den Outline-Algorithmus zu setzen. Entsprechend nutzlos ist dann auch <hgroup>, das mittlerweile aber auch abgeschafft werden soll.
Media-Metadata
Wie kann ich Medieninformationen man aus den <audio>- und <video>-Tags beziehen und welche Daten gibt es da zu holen?
Sobald die Metadaten geladen wurden (Event loadedmetadata auf dem betroffenen Element, readyState auf HAVE_METADATA) gibt es die Eigenschaft duration für die Laufzeit der Mediendatei in Sekunden. Bei Videos gibt es dann auch noch videoHeight und videoWidth für die Maße der Videodatei … und das war es dann praktisch auch schon. Die Spezifikationen schreiben darüber hinaus noch vor, dass man herausfinden können soll, welche Audio- und Videospuren es gibt, aber zur Zeit scheint es noch keinen Browser zu geben, der diese Features unterstützt.
Wenn wir noch weiter in die Zukunft schauen, gibt es noch das track-Element, mit dem sich Dinge wie Untertitel und Annotationen an ein Video bínden lassen. Grundsätzlich gibt es auch schon Browser in denen das teilweise funktioniert und grundsätzlich gibt es auch einen Track-Typ namens in-band metadata track aber das ist alles noch ein ganz weiter Weg zur Einsatzreife.
Was tun? Nun, entweder die Metadaten mit einem Ajax-Request nachreichen oder sie im Video-Markup einbetten (Stichwort data-*-Attribut) oder einfach mit JavaScript die Informationen aus der Videodatei selbst auslesen. Wenn das Format bekannt ist, ist das mit der File API kein Hexenwerk.
Mit dem zweiten Parameter kann man festlegen, welche Dokumente bzw. welche Origins (Domains bzw. Host-Protokoll-Port-Kombinationen) das Event empfangen dürfen. Mit '*' sendet man seine Nachricht an potenziell alle Dokumente, die der Browser gerade geöffnet hat und in denen ein entsprechendes Script auf onmessage lauscht. Möchte man das nicht, kann man sich mit 'http://foo.com' versichern, dass kein Dokument, das nicht auf foo.com liegt, an die Nachricht kommen kann. Wenn man einigermaßen sensible Daten übermitteln möchte, sollte man auf diesen Parameter also nicht verzichten!
Was ist mit den rel- und rev-Attributen passiert?
Leider kann ich in dem wirklich empfehlenswerten HTML5-Buch nichts zu den Attributen rel und rev finden. Wie verhält es sich hier bei HTML5? Gibt es auch eine offizielle Liste aller gültigen Values?
Für das rel-Attribut gibt es eine Liste der möglichen Werte in den HTML5-Spezifikationen. Das rev-Attribut wurde hingegen in HTML5 entfernt. Rein hyptertext-theoretisch gesehen wäre es zwar eigentlich ein sehr wichtiges Attribut (für Backlinks, siehe HTML 4.01), aber kein Browser hat damit je etwas sinnvolles gemacht - und da Webstandards nur das abbilden, was es in Browsern sowieso schon gibt, existiert es konsequenterweise in HTML5 nicht mehr.
Weitere Fragen?
Eure Fragen zu HTML5, JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach eine E-Mail schreiben oder Twitter bemühen und ein bisschen Geduld haben – falls ich gerade unterwegs bin, kann es mit Antwort manchmal etwas dauern, doch früher oder später schreibe ich garantiert zurück.
Der Juni bietet gleich vier Möglichkeiten, sich von mir in unterschiedlichem Umfang HTML5 und CSS3 erklärbären zu lassen (und nebenbei ganz Bayern zu bereisen):
10. und 11. Juni in München: HTML5-Schulung bei der Open Source School. Mein bewährtes dreitägiges HTML5-Standardprogramm stattet die Teilnehmer im Druckbetankungsverfahren mit so gut wie allem aus, was man zu HTML5 wissen muss. Von semantischem Markup bis hin zu Canvas-Frameworks ist alles dabei. Geboten wird ein großer Praxisanteil, kleine Arbeitsgruppen und ein Buch gibt es obendrein. Nächster folgender Termin ist erst im Oktober.
12. - 14. Juni in München: CSS3 bei der Open Source School. Mein zweitägiges CSS3-Standardprogramm katapultiert die Teilnehmer in das CSS3-Zeitalter, in dem Webfonts und Farbverläufe fließen. Einen großer Praxisanteil, kleine Arbeitsgruppen und ein Buch als Bonus gibt es auch hier. Vor Oktober kommt auch diese Veranstaltung nicht wieder, also zuschlagen!
15. und 16. Juni in Garmisch-Partenkirchen: Sessions zu HTML5 und CSS3 im Rahmen des DPK-BootCamp 2013. Ideal für alle, die schon immer mal eine kleine Magazin-Webapp bauen wollten und keine Lust haben, zu sehr in nerdigste Untiefen abzusteigen.
27. Juni in Nürnberg: Workshop im Rahmen der Web Developer Conference 2013. Es wird eine schöne kleine HTML5-App mit modernen JavaScript-Techniken (Unit Testing, AMD-Module, vieles mehr) gebaut.
Man kann es mit Ubuntu als Betriebssystem vergleichsweise gut aushalten, weil es gut funktioniert. kann man so ziemlich alles machen, und alle Dinge tun was sie sollen. Allein, die Art und Weise wie sie tun, das ist teilweise ganz schön diskutabel und so manche Design-Entscheindung verleitet geradezu zum Fazialpalmieren. Meine Wenigkeit erschlägt das Ganze immer mit ein paar zusätzlichen Stücken Software, die ich im Folgenden einfach mal aufliste – jedenfalls die Software, die ich im Moment bei Raring Ringtail 13.04 im Einsatz habe. Falls ihr noch mehr in dieser Richtung vorschlagen wollt: Ab damit in die Kommentare!
Neuen Nautilus loswerden: in Ubuntu 13.04 wird aus unerfindlichen Gründen Nautilus 3.6 verwendet, eine schlecht integrierte, fehlgeleitete Karikatur des vorherigen Dateimanagers mit der Versionsnummer 3.4 – hässliches Aussehen, Funktionen fehlen, Hotkeys tun es nicht mehr usw. Einen gepatchten, zu Ubuntu 13.04 kompatiblen Nautilus 3.4 gibt es bei Webupd8. Installieren und alle Probleme verschwinden.
Unity konfigurieren:Unsettings ist ein GUI zur Konfiguration von Unity. Neuerdings gibt es mit dem Unity Tweak Tool auch eine offizielle Lösung, aber warum die nicht standardmäßig installiert ist, ist mir schleierhaft. Aber beide Tools funktionieren ganz gut. Das Wichtigste ist die Auswahl der passenden Hintergrundfarbe für das Dash.
Gepatchtes Notify-OSD: Die Ubuntu-Notifications sind in ihrem Auslieferungszustand nicht konfigurierbar, also müssen eine gepatchte Version und ein damit kompatibler Konfigurator) her. Auch hier: Hintergrundfarbe das wichtigste, Kontrolle über Positionierung und Timeout nice to have.
Compiz konfigurieren: Falls man auf die (aus Canonical-Sicht wohl völlig abwegige) Idee kommen sollte, seinen Window Manager konfigurieren zu wollen: sudo apt-get install compizconfig-settings-manager && ccsm
Das ist ungefähr der Werkzeugkasten, mit dem ich mir alle halbe Jahr, nach jedem Release, den Desktop wieder in genehme Form bringe. Ich verstehe nicht, warum man die Konfiguratoren nicht zum Standard macht bzw. eigene bereitstellt. Bei rechtlichen Fragen (Codecs usw.) habe ich vollstes Verständnis, aber hier muss man einfach Böswilligkeit und/oder Arroganz unterstellen. Canonical hält mich anscheinend für blöder als ich bin und ihre Designer für besser als sie sind. Grr … aber hey, immerhin kann man die Sachen patchen und alles andere fluppt ja ganz gut. Und alles zu patchen hat mich gestern abend auch nur 30 Minuten gekostet.
