Kommentare für Working Draft

Kommentar zu Revision 71: Error.stack, Physical Units & DOM Mutation Observers von Guido

Guido — Thu, 17 May 2012 15:36:59 +0000

Der Link zu Hitch stimmt nicht.

Kommentar zu Revision 71: Error.stack, Physical Units & DOM Mutation Observers von Franky

Franky — Wed, 16 May 2012 08:05:50 +0000

von welcher platform redest du jetzt? außerdem ist es ja egal, ob es “virtuelle” dpi oder “reale” dpi sind, solang ich dann beim zeichnen nicht die “virtuellen” dpi nehm um direkt auf den “realen” display zu zeichen. Eg. “virtuelles” display hat 640 x 480 auf 4 inch (also 160 dpi) , reales 1280×960 auf 4 inch (also 320 dpi), das virtuelle bild wird also einfach um den faktor 2 vergrößert … solange die anwendung also nicht macht “ich krieg 160 dpi, also zeichen ich auf dem realen display jetzt ne länge-in-inch / 160dpi lange linie in pixel” ist alles grün und sollte im Output passen.

Ein gänzlich anderes Problem ist natürlich dass bei Windows XP z.B. immer 96 dpi drin steht (bzw gibts irgendwo ein dropdown wo man 3-4 verschiedene dpi-zahlen einstellen kann), ganz egal was man für einen display hat -> dort ist die Info ziemlich fürn Arsch, aber das ist ein Problem von Windows, nicht vom Ansatz per se (ich bild mir ein, Mac OSX hat die dpi richtig erkannt wie ich das letzte mal nen display angesteckt hab).

Kommentar zu Revision 71: Error.stack, Physical Units & DOM Mutation Observers von Schepp

Schepp — Wed, 16 May 2012 07:24:22 +0000

Das ist aber nicht die echte, physische vorhandene DPI-Zahl. Es ist nur eine virtuelle. Und genau das ist das Problem.

Kommentar zu Revision 71: Error.stack, Physical Units & DOM Mutation Observers von Franky

Franky — Wed, 16 May 2012 07:00:40 +0000

DPI kriegen is relativ watscheneinfach (wenn man mal davon ausgeht dass der der display-treiber keinen blödsinn liefert):

windows: http://msdn.microsoft.com/en-us/library/ms701681(v=vs.85).aspx
linux/mac: http://stackoverflow.com/questions/2621439/how-to-get-screen-dpi-linux-mac-programatically
android: http://stackoverflow.com/questions/3166501/getting-the-screen-density-programmatically-in-android
iOS: geth sicher auch, aber für die drei unterschiedlichen Display-Größen kann man auch einfach hardcoden.

Kommentar zu Revision 71: Error.stack, Physical Units & DOM Mutation Observers von Nico

Nico — Wed, 16 May 2012 03:30:49 +0000

Heute ist mit TweenNano/TweenLite/TweenMax (jetzt GSAP) eine der besten Tweening-Librarys für ActionScript auch für JavaScript veröffentlicht worden. Das ist finde ich durchaus eine Erwähnung wert, denn die Library ist sehr ausgereift, schnell und bietet einiges an Funktionen.

Kommentar zu Revision 70: JS Styleguides, Barrierefreiheit & Web Intents von Alex Müller

Alex Müller — Fri, 11 May 2012 21:58:07 +0000

Muss euch wiedersprechen. Beschreibende Kommentare sind wirklich irrelevant.
Das Problem ist, dass sich der Code meistens schneller ändert als das Kommentar und dann steht im Kommentar irgendwas, was nicht mehr mit dem Code übereinstimmt.
Wichtiger ist es Code zu schreiben, den man versteht und Kommentare nur dann zu verwenden, wenn man tatsächlich begründen muss, warum man eine Entscheidung getroffen hat.
Siehe auch Clean-Code-Developer:
http://www.clean-code-developer.de/Source-Code-Konventionen.ashx
Richtig kommentieren:
Warum?
Unnötige oder gar falsche Kommentare halten beim Lesen auf. Der Code sollte so klar und deutlich sein, dass er möglichst ohne Kommentare auskommt.
Kommentiert werden sollte nicht was man tut, sondern, wenn überhaupt, wieso man etwas tut.

Kommentar zu Revision 69: CSS Battle Royale – Opera von Jeremy Keith

Jeremy Keith — Fri, 04 May 2012 08:57:06 +0000

Why I didn’t use matchMedia (or a polyfill)? As the blog posts stated over and over again, the whole point was that I was trying not to repeat my breakpoints in two places. If that weren’t a concern, then yeah, I would have just used matchMedia.

I wasn’t saying “matchMedia sucks!” I was just looking for a solution to my particular situation. I’m not saying anyone else should use the same solution.

I blogged about a possible solution *that other people suggested*. You spoke about a different possible solution. That’s great.

You think the solution I wrote about is too complicated? That’s absolutely fine.

But your conclusion “So JavaScript kann der oder nicht, oder?” doesn’t strike me as particularly helpful.

Next time I’m going to write some JavaScript, I’ll be sure to run it by you first to get your seal of approval.

Kommentar zu Revision 69: CSS Battle Royale – Opera von Dirk

Dirk — Thu, 03 May 2012 18:34:07 +0000

“Content Choreography in Responsive Web Design” — die Demo gefällt mir sehr. Aus den gleichen Gründen wie Schepp sie genannt hat. Ich arbeite gerade an einem Projekt, bei welchem das Markup, welches ich für ein sinnvolles Desktop-Layout benötige, keine sinnvolle Reihenfolge für die Linearisierung ergibt und auch umgedreht (mobile first) würde für den Desktopbereich kein Schuh draus werden.

In einem solchen Fall (der bei etwas komplexeren Screenlayout vermutlich gar nicht mal so selten sein wird), ist der Einsatz von Flexbox auf Mobilgeräten nur Neuordnung der Reihenfolge echt ein Segen.

Kommentar zu Revision 68: Ein aus scharfem Pink und Grunzern von Jochum

Jochum — Wed, 02 May 2012 21:58:28 +0000

Das Klackern der Tastatur im Hintergrund war diesmal sehr nervig.
Ansonsten wie immer gute Beiträge!

Kommentar zu Revision 67: Meteor, Media Queries, Light Table von Schepp

Schepp — Wed, 02 May 2012 07:45:16 +0000

Das Problem mit dem Normalisieren ist, dass es pro Spur stattfinden müsste, da wir alle unterschiedlich laut sind. Würden wir das Normalisieren erst zum Schluss nach dem Mergen durchführen, dann wären die Unterschiede immer noch dieselben, nur auf anderem Gesamtlautheitsniveau. Normalisieren kann ich hier lokal auch und das mache ich auch immer nebst ggfls. einer Rauschentfernung. Problem ist jedoch eher, dass wir nicht alle ideale Mikros zum Podcasten haben, und die zuviel Randgeräusche mitnehmen. Und bei Gästen ist es immer schwer.