. miradlo bloggt » Responsive Webdesign ::: von mobil bis Riesenmonitor

Responsive Webdesign ::: von mobil bis Riesenmonitor

ute — Mon, 03 Oct 2011 08:44:40 +0000

miradlo.com Auflösungen testen

In den letzten Wochen habe ich mich intensiver mit Responsive Webdesign befasst. Hierbei geht darum, die Inhalte einer Seite möglichst optimal für alle Geräte darzustellen. Egal ob mobiles Smartphone oder großer Monitor mit hoher Auflösung alle Nutzer sollen ein Layout finden, was zu ihrem gerade genutzten Gerät passt. Beim Barcamp Stuttgart habe ich am Samstag eine Session zu diesem Thema angeboten, dieser Beitrag enthält die Links und Infos hierzu.

Die Techniken im Hintergrund sind gar nicht so neu, vorgestellt wurde CSS 3 schon vor einigen Jahren. Sinnvoll einsetzbar wurde diese Möglichkeiten jedoch erst seit sie von den wichtigsten Browsern auch interpretiert wurden. Für mobile Geräte konnte man zunächst mittels media="handheld" ein anderes Layout festlegen, Geräte wie das iphone melden sich jedoch gar nicht als handheld und bekamen daher doch wieder dasselbe Design wie Nutzer mit großen Desktopmonitoren.

media queries je nach Auflösung

Mittels media queries aus CSS 3 wird ein Layout je nach Auflösung ausgegeben. Zunächst habe ich ein Layout erstellt wie es in meiner Arbeitsumgebung optimal passt. Mein erster Schritt war also das Layout für eine hohe Auflösung wie z.B. 1920 * 1080 Pixel anzulegen. Danach probierte ich immer kleiner werdende Auflösungen und sobald mir etwas nicht gefiel, passte ich es an. Das habe ich so lange gemacht bis ich eine weitere Verkleinerung nicht mehr für sinnvoll hielt, sprich bei weniger als 300 px Breite erzwinge ich einen Scrollbalken, Beispiel:

@media only screen and (max-width: 429px) {
#mainwrapper{
    min-width: 270px;
}
}

Genauer ansehen könnt ihr euch das CSS layout.css im unteren Teil von der Seite miradlo.com. Testen lassen sich Seiten:

screenfly dort werden diverse Auflösungen je nach Gerät angezeigt, einfach die URL eingeben, z.B: miradlo.com
Responsive Webdesign Testing zeigt direkt mehrere Auflösungen auf einen Blick, auch hier einfach die URL eingeben, z.B: miradlo.com

Responsive Webdesign vs. Apps

Ich halte diese Technik insbesondere für sehr sinnvoll. Damit werden weiterhin dieselben Inhalte auf allen Geräten ausgegeben und trotzdem wird das Design angepasst. Für große Seitenbetreiber, wie wikipedia können auch Apps für iphone, android usw. eingesetzt werden, um mobile Versionen zu nutzen. Bei der Mehrzahl aller Websites ist das jedoch nicht sinnvoll und meist auch finanziell nicht machbar. Plugins wie für WordPress die eine mobile Variante erstellen sind sicher oft besser als nichts, sie zeigen jedoch nicht mehr das Ursprungsdesign der jeweiligen Seite. Responsive Webdesign ist eine gute Lösung für viele Seiten und der Aufwand ist nicht so viel höher wie beim Erstellen einer App.

Je nach Design lässt sich das auch im Nachhinein noch relativ einfach anpassen, das klappt jedoch sicher nicht immer. Das gesamte Design muss mit flexiblen Breiten zurecht kommen. Die einzelnen div-Container müssen problemlos verschiebbar sein, sonst lohnt sich das nicht. Einige weitere Links zu diesem Thema:

Formularelemente und vergrößerte Schrift ::: Zugänglichkeit

ute — Thu, 07 Oct 2010 16:44:36 +0000

Unlesbare Navigation
Teaserinfos laufen in- und übereinander

Fast auf allen Seiten, auch auf ordentlich sauber mit HTML und CSS erstellten, passen die Formularelemente mit meinen Einstellungen nicht.

Ein Klick auf die Bilder führt zur vergrößerten Ansicht.

Benutzerdefinierte Mindestschriftgröße

Einerseits habe ich seit Jahren in dem Browser, den ich normalerweise nutze, eine Mindestschriftgröße eingestellt, weil ich sonst auf sehr vielen Seiten, schlicht nichts lesen kann. Hinzu kommt, dass selbst damit inzwischen viele Seiten eine derart schicke, Minischrift haben, dass ich erneut die Schrift vergrößern muss.

Einfach wäre die Mindestschriftgröße erneut höher zu setzen, doch das geht leider nicht, denn spätestens bei Seiten mit Formularen, sind damit nur noch sehr wenige überhaupt nutzbar. Oft komme ich nicht mal soweit, weil schon vorher die Benutzung nicht mehr klappt:

Insbesondere horizontale Navigationen werden meist schlicht auf eine vordefinierte Schriftgröße festgezurrt und werden unlesbar, wenn die Schriftgröße erhöht wird, z.B. stern.de
Zusammenstellungen wie in vielen Teasern und anderen Bereichen, die Aufmerksamkeit wecken sollen laufen völlig in- und übereinander z.B. auf suedkurier.de

Beschriftung der Eingabefelder unlesbar
Eingabefelder zu klein

Schriftgrößen insbesondere in Formularen und so

Häufig sind Formularelemente mit fixen Werten vordefiniert, wenn ich also die Schriftgröße so setze, wie ich es bequem lesen kann, dann kann ich wichtige zusätzliche Infos nicht mehr lesen:

Eingabefelder sind zu klein um den gesamten geforderten Inhalt lesbar anzuzeigen (Deutsche Bank)
Beschriftung der Eingabefelder unlesbar, bzw. kann sogar ganz verschwinden (suedkurier.de)

Die Konsequenz ist bei mir ein Mischsystem:

eine Mindestschriftgröße die für manche Seiten passt
erhöhen der Schriftgröße, wenn ich etwas lesen will
verringern der Schriftgröße, um Bedienungselemente nutzen zu können

Überflüssig und ärgerlich

Schade, dass nur für schicke Optik so häufig auf zugängliche, nach Webstandards erstellte Seiten verzichtet wird. Das Web ist von seinen Grundlagen her optimal geeignet solche Probleme zu vermeiden und es den Nutzern zu überlassen, welche Einstellungen ihren Bedürfnissen entsprechen. Doch leider gibt es noch immer viel zu viele Designer, die Webseiten entwerfen, als sei es Papier.

Dazu passt die unsägliche Schriftgrößenumrechnung, die pixelgenau und berechenbar sein soll: den Mythos der 62,5% erklärt toscho in einfachen Worten.

Ich wünsche mir, wie viele andere, dass der Unsinn – Papierlayouts im Web 1:1 abzubilden – aufhört. Eine Initiative dazu ist der Blue Beanie Day, siehe: Blaue Mützen : Blue Beanie : 30.11.2010 Webstandards

PS: Falls jemand meint ich solle mal einen Optiker aufsuchen, ja das habe ich getan, ich habe eine Brille für die Ferne und eine Lesebrille, keine von beiden hilft mir am Bildschirm.

Flexible oder pixelgenaue Layouts : Ursachen und Gründe

ute — Sat, 20 Jun 2009 09:42:48 +0000

Ich habe heute in der Linkliste auf zwei Beiträge zu flexiblen Layouts hingewiesen.

Flexible Layouts haben ihre Vorzüge, trotz Seitenzoom der Browser
Ein weiterer Artikel meint es wäre gut nicht über die flexiblen Layouts zu streiten, sondern sie schlicht als Variante zu sehen.
In obigem Artikel wird auf mehrere Videos zu YAML verlinkt, die gibt es auch als eine Präsentation, direkt bei Galileo

onli kommentierte daraufhin recht ausführlich. Beim Schreiben meiner Antwort fiel mir auf, dass es ein bisschen lang wird, deshalb jetzt als eigenen Artikel. onli schrieb:

“Ich bin über die Diskussionen über flexible Layouts immer wieder überrascht. Denn eigentlich führt die Diskussion am Thema vorbei. Das eigentliche Problem dürfte sein, dass CSS in derzeitiger Form ungeeignet ist für das, was ein dynamisches Layout erfordert. Man kann viele Dinge einfach nicht zuverlässig erreichen, die nötig wären: Elementen eine dynamische Größe zuordnen, aber mehreren Elementen immer die gleiche. Nachbarbeziehungen, die über ein float hinausgehen usw usf. Sicher, ich bin kein Profi, aber es scheint mir so, als sei die Ursache der Diskussion dergestalt, dass einige notwendige Layoutanforderungen mit dynamischen Layouts nicht oder nur schwer umsetzbar sind. Die Antwort sind dann aber nicht pixelgenaue Layouts, sondern Verbesserungen am Handwerkszeug.

Ich werde mir bei Gelegenheit die verlinkten Videos anschauen, vielleicht beinhalten diese ja Konzepte, die meine obige Argumentation ad absurdum führt, weil damit dann alles so umsetzbar ist wie ich es mir vorstelle. “

Ich habe ja schon mal recht ausführlich über flexible Layouts geschrieben, ein paar Bildbeispiele wie sich flexible Layouts auswirken habe ich anlässlich eines Wechsels des Hintergrunds mal beschrieben.

Meines Erachtens sind flexible Layouts nicht schwierig, wenn man von vorne herein flexibel denkt. Das Hauptproblem ist, dass ein Design auf Papier in fester Größe entworfen wird und dann eben häufig auch nicht mehr so einfach flexibel umgesetzt werden kann.

Design bedeutet häufig, es ist ein Entwurf eines Designers, der gestern einen Flyer in A5 entwarf, morgen ein Plakat in A0 und deshalb heute beim Entwurf einer Webseite in 1024*768 denkt. Solche Entwürfe können sehr schwierig umzusetzen sein und sind oft auch nicht flexibel lösbar.

Für mich ist jedoch die Grundlage des Webs, dass ich eben nicht weiß, welches System, welche Auflösung mein Nutzer gerade verwendet, dass ich nicht weiß, ob er Schriftgrößen ändert und und und.

Ich versuche deshalb Layouts von vorne herein so zu erstellen, dass es nicht wichtig ist,welche Voraussetzungen gegeben sind. Leider ist die Tendenz jedoch nach wie vor, das Optimieren auf eine Auflösung und nicht das Erstellen eines anpassungsfähigen Layouts.

Yaml von Dirk Jesse auf das sich die Videos beziehen ist ein Framework, was den Webautoren schon vieles abnimmt. Enthalten sind in Yaml bereits Definitionen um Browserfehler zu umgehen. Es gibt z.B. auch WordPress-Yaml-Themes, die sich recht einfach anpassen lassen, weil vieles eben bereits berücksichtigt wurde. Der Nachteil ist offensichtlich, ein Framework muss alles berücksichtigen und ist deshalb schon ein dickeres Ding.

Ich selbst nutze natürlich auch Vorlagen und fange nicht bei jedem Layout bei 0 an, aber ich nutze kein Framework. Für meine eigen Layouts kenne ich mittlerweile den größten Teil der möglichen Probleme und ihre Lösung.

Im Gegensatz zu fast allen Designern entwerfe ich Layouts nicht auf Papier, auch nicht in einem Bildbearbeitungsprogramm, sondern wirklich live auf einer Testseite. Ich sehe so viel schneller, welche Idee problematisch werden könnte und überlege mir Alternativen, noch bevor das erste Layout fertig ist.

Ist CSS ungeeignet für Layouts?

onli überlegt, ob CSS nicht einfach ungeeignet ist und sich das Handwerkszeug verbessern müsste. Nein, das glaube ich nicht. Das Hauptproblem bei CSS-Layouts ohne Tabellen und in modernem Design ist nicht das CSS. Die Realisierung für standardkonforme Browser wie Firefox, Opera, Safari usw. die ist nicht so schwierig. Es kommt selten vor, dass es spezielle Anpassungen braucht, um ein Layout für diese Browser wie gewünscht zu realisieren. Das eigentliche Problem sind die alten Versionen der Internet Explorer und leider in manchen Fällen sogar der aktuelle IE8.

Manches ist irgendwann bekannt und lässt sich recht schnell auch für die IEs anpassen. Aber immer mal wieder passiert es, dass wegen eines IE-Fehlers Stunden drauf gehen, um eine Lösung zu finden. Microsoft möchte, dass jeder ihrer Browser auch die Seiten korrekt darstellt, die für eine fehlerhafte Vorgängerversion optimiert wurden. Dabei entstehen immer wieder Probleme und noch hat jede IE-Version teils haarsträubende Fehler. Das kommt zwar auch bei anderen Browsern mal vor, nur falls Firefox 2.14 etwas falsch darstellt, dann ist es das heute beim Stand von Firefox 3 nicht so schlimm, denn nur wenige nutzen aktuell diese eine Version, wenn ein Layout trotzdem lesbar bleibt, käme kaum ein Webautor auf die Idee, wegen dieser einen Version etwas zu ändern. Beim IE hält eine Version “ewig” der immer noch stark verbreitete IE6 ist aus dem Jahr 2001, da gab es noch gar keinen Firefox…

Was ist die Lösung für dynamische Layouts?

Die eine ultimative Lösung gibt es nicht. Denn ein modernes Layout mit dem Anspruch das zu zeigen, was heute Stand der Technik ist, das passt zu modernen Browsern. Der IE6 kommt aus einer Zeit als ganz andere Designs entworfen wurden, für die Layouts seiner Zeit war er auch kein Traum, aber noch akzeptabel. Für heutige Layouts ist er einfach ungeeignet und das führt dazu, dass es sehr aufwändig wird, wenn ein besonderes, aktuelles Design umgesetzt werden soll.

Meine Layouts, die nicht darauf aufbauen, dass sie pixelgenaue Linienführungen haben, lassen sich schon deshalb viel einfacher umsetzen. Außerdem habe ich nicht den Anspruch, dass ein Layout in jedem Browser absolut identisch aussieht. Für mich genügt es, wenn alles lesbar ist und die Optik nicht völlig verschoben. Wenn der IE6 das “miradlo bloggt”-Bildle nicht genauso darstellt wie alle anderen, dann ist mir das egal, es ist nicht so hübsch, aber auch nicht kaputt, ich höre an dieser Stelle auf und bastele dann nicht noch Stunden weiter, um mit Tricks und Schlichen eine identische Optik zu bekommen.

Wozu auch? Denn mein sich anpassendes Layout sieht je nach Auflösung sowieso immer ein bisschen anders aus. Für mich ist es wichtig, dass Besucher in etwa ein Design bekommen, was aktuell ist, dass alles lesbar und bedienbar ist und möglichst wenig Scrollbalken hat. Dieses Ziel lässt sich mit CSS und flexiblen Layouts recht gut erreichen.

Manches lässt sich nicht dynamisch und zuverlässig erreichen?

onli fragt sich, ob nicht einfach was fehlt um zuverlässig z.B. Elementen eine dynamische Größe zuzuordnen, aber mehreren Elementen dabei immer die gleiche.

Auch das fällt für mich unter Browserprobleme. Es ist mit standardkonformen Browsern durchaus möglich solche Anforderungen zu erfüllen. Die Grenze dessen ist vor allem der IE6. Für mich kein Grund das nicht zu nutzen, denn ich mag die speziellen Stylesheets die per Conditional Comments z.B. nur genau dem IE6 sagen, was er zu tun hat. Damit bekommt der IE6 dann eben etwas was nicht so flexibel ist, aber für einen Browser der so alt ist, kann ich damit leben.

Falsch finde ich etwas nicht zu nutzen, nur weil der IE6 es nicht kann. Ebenso überflüssig finde ich es Tage in eine Lösung für den IE6 zu investieren, nur um irgendwas auch da noch hinzubekommen. Allerdings halte ich auch nichts davon, “das Kind mit dem Bad auszuschütten” und dem IE6 einfach gar kein Layout und Warnhinweise zu geben. Die Nutzer eines IE6 nehmen ihn entweder, weil er ihnen am Arbeitsplatz vorgeschrieben wird oder weil sie nicht in der Lage oder bereit sind einen anderen Browser zu installieren.

Insgesamt meine ich geht es um genau zwei Punkte:

Das Web ist nicht aus Papier, ein Layout sollte daher nicht für “welche Auflösung auch immer” optimiert werden
Eine Webseite muss nicht in jeder Umgebung identisch aussehen

Berücksichtigt man das, dann gibt es kein Problem mit flexiblen Layouts, so einfach ist das.

Heute ganz ohne Spielerei, Design und so… CSS-Naked-Day

ute — Wed, 08 Apr 2009 22:00:16 +0000

ohne CSS also nacktes HTML

Wie was kein Design? Warum, was ist los?

CSS Naked Day

Einen Tag lang sollen mit der Aktion keine Styles anzuzeigen, Webstandards gefördert werden. Denn ohne Styles, Bilder und Design sieht man den Seitenaufbau genauer. Manche Seiten nutzen den internationalen “ganzen Tag” das bedeutet das CSS bleibt für 48 Stunden aus, damit es weltweit alle sehen können, dann dauert der 9. April halt nicht nur 24 Stunden.

Wer sich an Webstandards hält nutzt valides und semantisches Markup in (X)HTML. Die Inhalte sind sinnvoll strukturiert, mit Überschriften, Absätzen, Listen usw. An diese Regeln sollte man sich natürlich immer halten, die Aktion ist nur ein Hinweis um darauf aufmerksam zu machen.

Wem helfen Webstandards?

Unterm Strich allen, denn eine sinnvolle Struktur und korrektes Markup sind ein grundsätzlicher Vorteil. Ansonsten nützen Webstandards:

Suchmaschinen die sowieso kein Design sehen
Tastaturnutzern siehe auch Navigieren mit der Tastatur
- manche mögen keine Maus benutzen
- manche können keine Maus benutzen
- …
es gibt Besucher mit sehr langsamer Internetverbindung, die schalten Styles und Bilder grundsätzlich ab
Screenreader haben nichts von Styles (werden von Blinden genutzt)
Menschen die schlecht sehen oder irgendeine Fehlsichtigkeit haben schauen sich Webseiten ohne oder mit speziell auf sie zugeschnittenen Stylesheets an
Standards machen es leichter unabhängig von den genutzten Voraussetzungen gut funktionierende Webseiten zu erstellen
überarbeitete oder neue öffentliche Seiten müssen sich an Webstandards und einen gewissen Stand der Barrierefreiheit halten
Webstandards sind die Grundlage, um barrierefreie Seiten zu erstellen (nein, nicht jede standardkonforme Seite ist deshalb barrierefrei)
für Stammleser die einen Feed ohne Design bevorzugen ist die Struktur einer gut aufgebauten Seite besser zu verstehen
…

Es gibt viele Gründe, die dafür sprechen, es spricht nichts Nachvollziehbares dagegen (Webseitenerstellungsprogramm XY kann das nicht, ist für mich kein Argument). Trotzdem gibt es noch viel zuwenige Seiten, die sich an Webstandards halten.

Die meisten Redaktionssysteme, CMS (Content Management Systeme) und somit auch die bekannten Blogsysteme können mit Webstandards umgehen. Manche besser, manche schlechter, häufig entstehen die Probleme jedoch erst wenn die Autoren etwas eingeben oder bei Themes, die sich nicht daran halten.

Der CSS-Naked-Day ist eine gute Gelegenheit auch das eigene Blog, die eigenen Seiten mal kritisch zu betrachten. Wer das nicht gleich öffentlich tun möchte, dem kann ich für Firefox die Webdeveloper Toolbar empfehlen, da lassen sich alle Styles mal eben zum Nachsehen deaktivieren. Sowohl auf eigenen, wie auf fremden Seiten ab und zu mal ganz spannend… Für Seamonkey gibt es das auch, Opera bringt ähnliches grundsätzlich mit, für den IE (zumindest für Internet Explorer 7 und gibt es eine ähnliche Toolbar.

Wie lässt sich das für Besucher anzeigen?

Ich habe für CSS-Naked-Day das WP-Plugin genutzt, weil es einfach bequem ist und für einen Tag wollte ich jetzt nicht selbst basteln. Allerdings geht das Plugin soweit ich gesehen habe, dann eben nur von den 24 Stunden des 9. Aprils Ortszeit in Deutschland aus. Wer es lieber selbst ins Theme einbauen mag, findet die Anleitung dazu bei Frank. Eine Liste einiger teilnehmender Seiten gibts Dustin Diaz, in deutscher Version unter nakedcss.de. Auf diesen Seiten gibt es auch Hinweise, wie sich das automatisiert bei anderen Systemen realisieren lässt.

Ganz ohne Automatisierung bietet unser Styleswitcher ganzjährig auch eine Naked-Version. Viel Spaß beim Surfen heute, ich hoffe es wird auch hierzulande einige teilnehmende Seiten geben, schaut doch z.B. auch bei Dieter vorbei.

Sorry, die Funktionen dieser Seite können mit Ihrem Browser nicht genutzt werden

ute — Wed, 18 Mar 2009 23:14:22 +0000

Dieser Artikel ist Teil 9 von 9 der Serie Webstandards und IE

Gestern habe ich mal erzählt, was ich glaube wer welches Vorwissen hat. Am Ende stellte ich die provokante Frage:

Sind all diese Menschen es nicht wert, dass sie eine lesbare Webseite bekommen?

Ich finde sie sind es wert.

Manchmal gibt es gute Gründe, warum etwas mit dem IE6 nicht mehr funktioniert, na dann, dann ist es halt so.
Nicht jedes Layout ist mit sinnvollem Aufwand im IE6 umsetzbar? Kein Problem, dann halt ein einfaches Layout oder auch mal gar kein Layout.
Wir alle, die sich damit befassen wie Webseiten aussehen können, sind auch problemlos in der Lage, je nach Situation, dem IE6 mal
- kein Layout zu geben, oder
- ein stark vereinfachtes Layout und wenn es gar nicht anders geht, dann von mir aus
- den Hinweis, “Sorry, die Funktionen dieser Seite können mit Ihrem Browser nicht aufgerufen werden.“

miradlo bloggt im IE6

Natürlich für manch eine Seite lohnt es sich nicht, viel Aufwand für den IE6 zu betreiben, wenn, wie hier, nur noch sehr wenige diesen Browser nutzen, dann würde ich nicht viel Zeit investieren, um alles optimal anzupassen. Doch ich meine das Recht auf lesbar, wenn irgend möglich, haben alle Besucher, egal ob sie den IE6 nutzen oder irgendeinen anderen Browser.

Webstandards und Barrierefreiheit

Ich denke zurecht legen inzwischen doch einige Webautoren Wert auf Webstandards. Es gibt einige, wenn auch noch viel zuwenige, die weit entfernt von Layouttabellen, “optimiert für irgendwas” auf Browser XY sind. Einer der Vorzüge der derzeitigen Diskussion ist aus meiner Sicht, dass damit das pixelgenaue Layout nochmal angesprochen wird. Denn ebenso wie das völlig unsinnig ist, ist es aus meiner Sicht nicht möglich, sich für Webstandards und ein Web für alle einzusetzen und dann den IE 6 einfach auszuschließen.

Bei unserem Styleswitcher ist die Startseite auch für den IE 6 kein Problem, jedoch das ein oder andere Layout, klappt nicht, dafür müsste es eine Funktion geben, die auch noch Stylesheets für den IE extra einbaut, das war es mir nicht wert. Dort gibt es einen roten, deutlichen Hinweis, dass es sein kann, dass nicht alles so aussieht wie gedacht und dass ein Browser von 2001 eben nicht mehr ganz zeitgemäß ist.

Doch es kann nicht sein, dass zu:

Diese Seite ist optimiert für Browser XY
Diese Webseite ist optimiert für die Auflösung von x*y
Unsere Homepage arbeitet mit Frames, Ihr Browser unterstützt keine Frames

und irgendwelchen Rechtfertigungen für Tabellenlayouts jetzt neu der Hinweis hinzukommt:

“Entschuldigung, Ihr Browser ist veraltet, bitte kommen Sie doch wieder, wenn Sie Browser XY kostenlos runtergeladen haben.”

Identisches Layout für alle Browser?

miradlo bloggt im Firefox

Nein, ich meine nicht, dass ein Layout perfekt und 1:1 in allen Browsern sitzen muss. Pixelgenau ist meines Erachtens nur ein Hinweis darauf, dass jemand das Web nicht verstanden hat.

Mir ist es fast immer egal, ob irgendein Browser irgendwo ein bisschen was anders anzeigt. Der IE 6 hat hier im Blog kein so hübsches “miradlo bloggt” wie die anderen, aber es funktioniert. Manche Abstände passen nicht optimal, aber so ließ er sich mit wenig Aufwand überzeugen alles brav lesbar anzuzeigen. Schiebe ich an Abständen dann verschluckt er sich. Auf einer Kundenseite überlege ich mir solchen Anpassungen, bei unseren eigenen Seiten finde ich unsinnig. Wirklich auffallen wird das nur in zwei Fällen:

hier im Beitrag, weil ich es jetzt explizit erwähne
jemandem der testet wie identisch diese Seiten in verschiedenen Browser aussehen

Diese beiden Situationen sind für mich ganz sicher kein Grund den IE 6 anzupassen. Viele die sagen, sie würden für Kunden anpassen, machen es oft nur für sich selbst, denn Kunden testen ganz selten in mehreren Browsern. Wenn also irgendwo ein bisschen mehr oder weniger Abstand ist fällt es nicht mal auf, wenn das Layout nicht im Seitenverhältnis des goldenen Schnitt pixelgenau ausgerichtet ist.

Für mich zählt es soll einigermaßen aussehen, es soll funktionieren und das war’s. Der IE6 sollte nicht das Maß aller Dinge sein, jedoch schon lange nicht mehr, wenn das klar ist und ebenso klar ist, es muss nicht alles genau identisch funktionieren, prima, dann ist doch gut.

Stoppt den IE6

Ich halte nichts von den Kampagnen und Aktionen:

Stoppt das Web mit Papier zu verwechseln

Die meisten Webautoren, die interessiert sind an Webstandards lieben ihn nicht gerade, aber sie werden sich nicht dieser Kampagne anschließen:

Sondern mehrere weisen daraufhin, dass das Hauptproblem nicht IE x ist, sondern der Anspruch alles exakt in jedweder hochmoderner Technologie abzubilden, egal ob ein Browser von 2009 oder von 2001 stammt.

Fazit zum IE 6

Nein, ich mag ihn nicht meinen speziellen Freund den Internet Explodierer. Wenn ich grad an einem Design bastele, schimpfe ich auch und es ärgert mich, dass ich zusätzlich Zeit aufwänden muss, damit auch der IE mich versteht. Allerdings kann ich aus meiner Erfahrung nur sagen, so toll ist IE 7 ganz sicher nicht, dass ich meine, es wäre sinnvoll, wenn jetzt der mehr genutzt wird.

Andererseits ich nutze kein vorgefertigtes Framework, jedoch gibt es schon ein paar Grundlayouts auf denen ich Neues aufbaue. Ich fange nicht bei null an und ich erfinde das Rad nicht neu, warum auch?! Mit dieser Technik kostet es mich inzwischen meist nur wenig Zeit, noch eben die letzten Anpassungen an die Internet Explorer zu machen. Manchmal kommt es vor, dass etwas richtig Zeit frisst, weil sich doch nochmal ein neuer Bug finden ließ, der nicht in “meinem Beuteschema” gespeichert war. Doch mit jedem Layout werden es weniger davon.

Allerdings komme ich auch nur selten auf die äußerst unkluge Idee in Pixeln nachzumessen, ob das Layout auf allen Browsern identisch ist, wozu auch? Denn Monitor, Größen, Auflösungen, Farben usw. unterscheiden sich sowieso von Rechner zu Rechner, diese Unterschiede sind viel gravierender als ein Pixel rum oder num.

Entschuldigung Ihr Browser ist veraltet…

ute — Tue, 17 Mar 2009 23:08:10 +0000

Dieser Artikel ist Teil 8 von 9 der Serie Webstandards und IE

Ich kenne Kunden, Freunde, Bekannte und so, für die ist:

dieses Google mit dem wählt man sich ins Internet ein
da kann man so eine Adresse von einer Homepage eingeben, dann kommt das
Webdesigner? Sind das die, die eine Homepage machen?
Informatik? Das hat mit Computern zu tun, gell?!
ein Blog? Hm, sollte wohl Block heißen, wusste ich doch, dass die in dem Internet auch noch Zettel und Stift brauchen
ein Browser? Ähm, ich glaube nicht, dass wir das haben, den Computer hat ein freundlicher junger Mann eingerichtet damals…
IE, Internet Explorer? Oh, ja Internet haben wir, das ist mit dem Google, damit wählt man sich da ein.

Ihr grinst?

Styleswitcher im IE6 mit Warnhinweis

Ja, ich auch, aber mal ernsthaft, kennt ihr niemand, dessen Welt noch so oder so ähnlich ist?

Es gibt auch andere:

in unserem Betrieb macht das mit dem Internet der Support
wir haben auch ein Intranet, da stehen Sachen drin, aber da findet man nie was
der Support sagt, das Programm läuft nur so, wenn alles so ist wie jetzt
die schalten auch immer was ab, dann kommt ein Fehler, wenn man was braucht, die Bildzeitung geht bei uns auch nicht
manche Seiten gehen halt nicht bei uns, das macht halt der Support von der IT
alter Browser? Ja, kann sein, die sind schwierig, die erreicht man auch immer schlecht

Ihr amüsiert euch schon wieder?

Ja, ich auch, doch auch das ist keine Seltenheit.

Glaubt irgendjemand, dass diese Menschen was damit anfangen können, wenn eine Seite schreibt:

“Entschuldigung Ihr IE6 ist veraltet und ein unsicherer Browser, installieren Sie doch beispielsweise Firefox.”

Ich glaube es nicht. Mir fallen viele Menschen ein, die etwa soviel übers Internet wissen. Das sind noch nicht einmal die, die noch nie im Internet waren. Es sind Menschen verschiedenster Fachbereiche, nur eben nicht grad der Informatik. Ihre Hobbys sind vielleicht tanzen, malen, fotografieren oder was auch immer, nur eben auch nichts, was mit dem Internet zu tun hat. Ab und zu nutzen sie etwas, sie lernen auch sicher immer dazu, aber sie wissen nicht was der IE ist, sie kennen Firefox nicht und sie wissen nicht wie man etwas installiert.

Sind all diese Menschen es nicht wert, dass sie eine lesbare Webseite bekommen?

Doch ich glaube schon. Welche Lösungen wer dazu überlegt, bzw. durchführt unterscheidet sich grad. Es herrscht keine Einigkeit unter den Webautoren. Bei miradlo werden Seiten mit solch einem Hinweis wie auf miradlo.info die Ausnahme bleiben. Wir werden weiterhin den IE6 unterstützen, aber nicht in jeglicher Hinsicht, doch dazu morgen mehr.

Webprojekt-Vorlage für neue Webauftritte

ute — Wed, 21 Jan 2009 23:01:36 +0000

Je nachdem, wie häufig man ein neues Webprojekt startet, bei dem es anfangs zunächst immer um dieselben Grundlagen geht, lohnt es sich, dafür eine Vorlage, ein Basisprojekt, zu erstellen.

Wir nutzen inzwischen ein ganzes Basisprojekt, in dem die relevanten Templates und Strukturen bereits enthalten sind. Schritt für Schritt geht es um folgende Vorlagen:

CSS-Vorlage

Wohl die meisten, die häufiger ein neues Projekt beginnen, nutzen ein CSS-Template. Ich ändere diese Vorlagen immer mal wieder, aber im Grunde gehe ich prinzipiell immer von derselben Struktur aus:

basis.css in dieser Datei definiere ich Grundelemente, wie z.B. Überschriften, Absätze usw.
layout.css diese Datei ist fürs eigentliche Layout zuständig und enthält die Definitionen, der div-Container, wie sie bei uns möglichst immer eingesetzt werden. Ausnahmen gibt es nur, wenn es gar nicht anders geht, ansonsten nutzen wir:
spezielles.css alle speziellen Definitionen stehen hier:
- seien es genutzte Konstrukte, die stabil und browserübergreifend Bilder einbinden
- die ein oder andere zusätzliche Klasse
- ein spezieller zusätzlicher Container
etwaige sonstige Stylesheets, z.B. für den Druck, zur Anpassung der Internet Explorer per Conditional Comments, oder was sonst eventuell nötig ist

In den Vorlagen dieser Dateien stehen Grundwerte, die so meist benutzt werden. Verändert wird das Layout, individuell sind Logo und Hintergrundbilder, angepasst werden noch Farben und einige weitere Kleinigkeiten pro Projekt.

Viel mehr ändert sich jedoch nur selten, denn der Hauptunterschied liegt ja im Layout des jeweiligen Projekts. Grundelemente werden immer benötigt und Farben eben ans Layout angepasst.

Der Vorzug einer Vorlage ist, dass ich es dort sofort nachziehen kann, wenn mir bei einem Projekt etwas spezielles auffällt, oder ich mal wieder was vereinfachen kann.

HTML-Vorlage

Eine Vorlage der Grundstruktur bieten natürlich auch bereits die meisten Editoren, z.B. der bei uns genutzte Quanta. Wir setzen jedoch so gut wie nie ausschließlich HTML ein. Meist gibt es entweder noch einige eigene Entwicklungen in PHP oder eine Software wird darüberhinaus eingesetzt.

Software-Vorlage ::: z.B. WordPress-Blog

Je nachdem, was man häufig nutzt, bei uns zur Zeit WordPress, ist es sinnvoll sich auch da die relevanten eigenen Anpassungen als Vorlage zu nutzen.

Es gibt eine Reihe von Plugins, die wir üblicherweise nutzen, da sich die jedoch sehr schnell ändern, packe ich ins Basisprojekt nicht alle relevanten Dateien. Keinesfalls gibt es dort das gesamte WordPress, sondern die jeweils aktuelle Version wird genutzt.

Extra sichere ich jeweils die in einem Plugin geänderten und angepassten Dateien, nur selten unterscheiden die sich pro Blog, meist sind diese Anpassungen für alle Blogs identisch.

Als Vorlage gibt es jedoch das Template, von dem ich üblicherweise ausgehe. Dieses habe ich mir aus der leeren und gut kommentierten Vorlage von texto.de erstellt. Bei gravierenden Änderungen in WordPress schaue ich mir die dort jeweils aktuelle Vorlage nochmal an und passe mein Template an. Das jeweilige Theme ist abhängig vom jeweiligen Blog, bzw. Webauftritt mit WordPress, die Grundstrukturen sind jedoch überwiegend wieder gleich.

PHP-Vorlage

Manches läuft bei uns auch in Projekten, die keine weitere Software einsetzen mittels PHP. Es ist einfach nicht sinnvoll reines HTML zu nutzen, da vieles automatisiert einfach besser geht. Jedes Projekt benötigt eine Navigation, automatisiert wird meist irgendwo ein Datum genutzt, Metadaten die nicht projektspezifisch sind werden für alle Seiten gleich eingebunden, es gibt ein Kontaktformular…

Diese Grundlagen, die immer dieselben sind, stehen in unserer PHP-Vorlage. Sobald wir Neues nutzen wird das auch hier nachgezogen, beispielsweise um Spam zu vermeiden, ändert sich regelmäßig etwas.

…noch eine Vorlage?

Ja, eine habe ich noch Nein, es ist nicht direkt “eine Vorlage” hilft aber trotzdem ungemein:

Layoutbildervorlage

Sinnvoll benannte Layoutbilder bilden zunächst einmal das Gerüst, mit dem bereits ein erstes Design möglich ist. Später können die Bilder einfach reinkopiert werden, unter demselben Namen, damit spart man sich das Anpassen der Pfade. Klappt auch für Favicons, Bilder auf Fehlerseiten und ähnliches, was man häufig nutzt.

Falls ich was vergessen hab, oder ihr noch einen praktischen Tipp habt, gerne…

Zoom im Browser ::: Textzoom ::: Seitenzoom ::: Bilder

ute — Fri, 19 Dec 2008 00:14:16 +0000

Dieses Mal mit deutlicher Verspätung, sonst gibt’s ja neue Artikel um kurz nach Mitternacht… Gestern reichte es einfach nicht mehr und heute vormittag gab’s hier kein Netz. Heute abend wollte ich eigentlich erst noch ein Bild hochladen, bevor ich diesen Artikel veröffentlichte, ich habe irgendwann aufgegeben… Dazu ein anderes Mal mehr, hier ist es bereits eine Stunde später (2:14 Uhr) und morgen früh wollen wir ans Tote Meer…

Inzwischen gibt es ja bereits einige Monate den Firefox mit Seitenzoomfunktion, nicht nur mit dem Textzoom. Der Internet Explorer 7 hat diese ursprünglich zuerst bei Opera angebotene Funktion ja ebenfalls, allerdings in einer Form, die völlig unsinnig gelöst wurde.

Wozu überhaupt Seitenzoom?

Nun, den Textzoom gibt es ja schon lange, selbst im Internet Explorer 6, lässt sich die Schrift zweimal vergrößern, falls die Angaben zur Schriftgröße in Pixeln angegeben wurden. Die anderen Browser vergrößern schon lange unabhängig davon in welcher Einheit die Schriftgröße angegeben wurde. Auch gibt es keine Beschränkung des Zooms, falls das Layout es zulässt kann unbegrenzt der Text vergrößert werden.

Ist Seitenzoom dann nicht überflüssig?

Das kommt drauf an. Je nach Layout vergrößert sich mittels Textzoom ja tatsächlich ausschließlich der Text, eine, z.B. auf – 800 Pixel Breite beschränkte – Seite kann somit nicht breiter als eben diese 800 Pixel werden. Das heißt, selbst wenn auf dem Bildschirm genug Platz wäre, um mittels Textzoom vielfach zu vergrößern, so klappt es häufig nicht, weil der vergrößerte Text keinen Platz mehr hat. Siehe auch die Unterschiede zu festem und flexiblem Layout.

Andererseits lassen sich flexible Layouts entwerfen, bei denen die Angaben für die Breite, in Abhängigkeit der genutzen Schriftgröße, gemacht werden. In diesem Fall lässt sich eine Seite bei höherer Auflösung auch entsprechend vergrößern. Wäre die Grundbreite bei etwa 800 Pixel, aber in ‘em’ angegeben, dann ließe sich bei einer Auflösung von 1600 die doppelte Breite nutzen, die Schrift könnte also extrem vergrößert werden und noch immer müsste nicht gescrollt werden.

Warum entwerfen also nicht alle solche flexiblen Layouts?

Es wäre doch perfekt grundsätzlich flexible Layouts anzubieten, damit alle Besucher genau das einstellen können, was für sie am besten passt. Warum tun das also nicht alle Webautoren? Der Hauptgrund ist, dass damit die pixelgenaue Kontrolle verloren geht. In einem festen Layout mit fixer Breite können Webautoren beispielsweise Hintergrundbilder nutzen, die auf den Pixel genau zueinander ausgerichtet werden.

Insbesondere Grafikdesigner, die sich auch mit Druckerzeugnissen befassen, wollen häufig auch bei Webseiten ein absolut exaktes ‘Bild’ erhalten. Entworfen wird daher meist ein Bild, so als wäre es für ein Plakat oder eine Broschüre. Das Problem ist jedoch, dass Webseiten keine Druckerzeugnisse sind. Im Druck weiß man ganz genau welche Größe das Endprodukt haben wird, der Entwurf wird genau dafür optimiert.

Das Web ist jedoch kein Druck und hier gibt es unzählige Variationen

Für den Designer ärgerlich, für die Besucher von der Idee her traumhaft, kann ich im Web, an meinem Rechner aussuchen, was für mich persönlich am besten ist. Die einen haben zwar einen großen Monitor, aber eine niedrige Auflösung, andere nutzen einen kleineren Bildschirm, z.B. am Laptop mit einer höheren Auflösung. Mancher kann auch sehr kleine Schriften noch gut lesen, andere wollen am eigenen Rechner nicht mit der Lupe arbeiten und stellen sich ihre Schriftgrößen deshalb mehrfach vergrößert ein.

Flexibilität von Webseiten

Grundsätzlich schätze ich die Flexibilität, die Webseiten bieten, die Möglichkeit eine Seite eben je nach Wünschen und Voraussetzungen des Lesers anzuzeigen.

Bilder skalierbar einbinden

Für diejenigen, die sich alles vergrößert anzeigen lassen, wären daher höher aufgelöste Bilder ein Vorteil. Leider hat das jedoch auch Nachteile:

übertragene Datenmenge
Ladezeit

Die übertragene Datenmenge wäre bei hochauflösenden Bildern, dann ja auch für diejenigen größer, die die Bilder in kleinerem Format betrachten. Da sich häufig gerade die, die eine schlechtere Verbindung haben, nicht aussuchen können, ob sie eine bessere und schnellere Verbindung möchten, mag ich schon das nicht.
Die Ladezeit ist das nächste Problem. Sie vergrößert sich logischerweise schon mit der größeren Datenmenge. Hinzu kommt noch, dass ich den Bildern, um sie skalierbar zu halten auch nicht die Größenangaben mitgeben kann, sonst skaliert da nichts.

So schön die Idee also einerseits ist, so schwierig finde ich die Entscheidung. Bei Websites mit sehr wichtigen Bildern, beispielsweise bei der Seite einer Malerin war der Kompromiss jetzt Galerien einzubauen, die Vorschaubilder aus den eingebundenen Bildern zeigen. Diese Bilder sind noch immer stark fürs Web optimiert. Es gibt jedoch eine zusätzliche Galerie, die Bilder in recht hoher Auflösung anbietet, aber erst wenn sich jemand auch dafür entscheidet. Diese Lösung gefällt mir ganz gut, denn so werden die mit sehr langsamer oder schlechter Verbindung nicht zu hochauflösenden Bildern gezwungen. Diejenigen, die jedoch interessiert sind und genau schauen wollen, die haben die Möglichkeit, das zu tun.

Skalierbare Hintergrundbilder

Je nach Größe eines Hintergrundbilds besteht für mich dasselbe Problem, wie bei im Quellcode eingebundenen Bildern. Klar, manches Hintergrundbild wäre auch in skalierbarer Version klein genug, um das Problem zu umgehen.
Im Moment bevorzuge ich Layouts mit sich wiederholenden Hintergrundbildern auch im Kopfbereich, z.B. henss.eu damit muss das Hintergrundbild nicht skalierbar sein, um trotzdem mit verschiedenen Auflösungen noch gut zurechtzukommen. Beides sind trotzdem natürlich rein dekorative Bilder, bei denen es nicht so wichtig ist, ob sie in optimaler Qualität sichtbar sind, mit zweifacher Zoomstufe im Firefox sah es bei meinen Tests auch noch ganz gut aus.

Was ich nicht mag, sind feste Layouts, optimiert, z.B. auf 800*600, bei denen ich dann mit meiner Auflösung einen zu zweidrittel leeren Bildschirm habe.

Unterm Strich

Die Möglichkeit Hintergrundbilder zu nutzen, statt Bilder in den Quelltext einzubinden finde ich gut. Denn, ich finde es klasse, dass sich inzwischen die rein dekorativen und nur fürs Layout nötigen Bilder, im Hintergrund einbinden lassen und eben nicht im Quellcode.

Das bietet ja mehrere Vorteile:

die Ladezeit ist geringer, weil – zumindest die meisten – Browser ein Layoutbild dann auch mehrfach nutzen
bei geschicktem Einsatz, lässt sich oft sogar ein und dasselbe Bild für mehrere Bereiche des Layouts nutzen, weil es passend verschoben wird
aufs Laden von Hintergrundbildern kann bei langsamen Verbindungen verzichtet werden

Deshalb meine ich, auf Dauer muss es da noch bessere Wege geben, und wie auch Dieter in seinem Kommentar schon schrieb, die Möglichkeit auch Hintergrundbilder zu skalieren, sollte geschaffen werden. Denn sonst führt es irgendwann wieder zu Murks.
So wie Tabellen für Layouts genutzt wurden, weil es nichts anderes gab, werden sonst womöglich irgendwann wieder Bilder in den Quelltext eingebunden, um sie skalierbar anbieten zu können. Das halte ich jedoch, aus den genannten Gründen, für eine schlechte Lösung.

Webdesign ::: Checkliste um Webauftritte und Blogs zu testen

ute — Mon, 08 Dec 2008 23:01:25 +0000

Wer Webseiten erstellt oder verschiedene Themes in Blogs einsetzt, sollte vor allem bei neuen Layouts, aber auch bei Änderungen testen. Es gibt die unterschiedlichsten Arten das zu tun, wir bei miradlo nutzen dazu eine Checkliste, um nichts zu vergessen. Einer der wichtigsten Punkte bereits während des Erstellens neuer Webseiten sind die regelmäßigen Prüfungen in den Validatoren, Validator-Links siehe Glossar zu Validatoren. Wir passen unsere Checkliste immer mal wieder an, der ein oder andere hat sich auch weitere eigene Punkte notiert oder diese Liste ergänzt.
Unsere Liste ist aufgeteilt in Gruppen von Tests:

Benutzerfreundlich

nur soviel Pflichtfelder wie nötig, nicht gleich den Stammbaum, nur um Kontakt aufzunehmen
nicht eindeutige Linktexte mit zusätzlichem title, klar unterscheidbare verschiedene Namen für Links (nicht zehnmal “mehr” oder “weiterlesen”)
spezielles CSS für print und handheld (klappt aus Zeitgründen grad noch nicht immer)
Sitemaps sobald der Auftritt eine umfangreichere Navigation hat (bei einem 10-Seiten-Auftritt ohne Unternavigation halte ich eine Sitemap für überflüssig)
Fehlerseiten mit vollständiger Navigation (error und forbiddeen für 404, 401 und 403)
favicon zur Orientierung
fremdsprachige Texte bekommen z.B. ein
(allerdings bei “denglischen” Begriffen spare ich mir das)
Links haben verschiedene Auszeichnungen für ihre Zustände (visited, hover, focus, active sind unterscheidbar definiert, so dass sich besuchte Links unterscheiden und auch bei Tastaturnavigation erkennbar ist, bei welchem Link man grad steht)

Les- und benutzbar möglichst ohne Barrieren

Skiplinks für die Navigation (nehmt hier mal die Tastatur zum Navigieren, dann erscheinen die Links die entweder zur Navigation oder zum Inhalt führen)
entweder alt-Texte, die zumindest grob Bilder beschreiben, oder Bildtitelbeschriftungen dann meist kein weiterer alt-Text, wichtig dann jedoch das leere alt-Attribut:
alt=”" (sonst lesen z.B. Screenreader vor:”Alternativtext ein Leerzeichen”
wann immer möglich flexibles, skalierbares Layout (Sonderwünsche, Kundenwünsche, spezielle Anforderungen können Ausnahmen sein, sonst ab 800*600 ohne Scrollen und auf 1680*1050 trotzdem nicht gähnende Leere)
Formulare mit sinnvollen Labels, die die Eingabefelder umschließen
Fehlermeldungen, die man verstehen kann (”die Eingaben sind nicht korrekt” hilft dem Besucher nicht rauszufinden, was jetzt nicht korrekt war)
Grundlayout möglichst mit guten Farb- und Helligkeitskontrasten (online testen von Farbkontrasten einer Seite ist eine Variante, für den Firefox gibts ein Plugin, welches jedoch bei Firefox 3 noch nicht läuft. Bei Hintergrundbildern entscheide ich derzeit nach Augenmaß, da die Tools das noch nicht berücksichtigen)
Definitionen von Hintergrundfarben so, dass auch ohne Bilder kein weißer Text auf weißem Hintergrund steht
Informationen, nicht nur mittels Farben unterscheidbar

Trennung von Inhalt und Layout

sinnvolle Semantik: Seiten beginnen mit h1, bestehen aus Überschriften, Listen, Absätzen…
keine Spielereien, wie: da noch eine Überschrift, weil die grad die passende Größe und Design hat
Textauszeichnungen per CSS sowie Hervorhebungen mittels strong und em
CSS möglichst strukturiert und spezielles für den IE mit Conditional Comments, außerdem möglichst wenige Klassen, sondern eher nutzen der HTML-Elemente
div nur für Strukturen, nicht um alles einzupacken
Hintergrundbilder gibts im CSS

Technisches

Seiten, die mit lesezeichentauglichen URLs zu finden sind (nicht …/unterordner/?seitekr5679-grr…)
alle Grundfunktionen sind ohne JavaScript erreichbar
Seiten werden vom Server mit dem passenden Zeichensatz ausgeliefert (siehe z.B. die Webdeveloper-Toolbar /Informationen/Seitenheader da sollte der Zeichensatz stehen)
“cool URIs don’t change” zumindest nicht ohne passende Weiterleitung (das bedeutet bei Änderungen werden sinnvolle RedirectPermanent Verweise in der .htaccess gesetzt)
regelmäßige Kontrollen aller Links (unter Linux mit dem Link Checker, der im Quanta integriert ist, online für ganze Webauftritte, z.B: bei Link Valet)
Test aller Layouts auf mindestens: IE 5 bis 7, sowie Firefox, Mozilla, Opera, Konqueror, Safari und Links (aktuelle Version von Lynx unter Linux) in aktuellen Versionen (z.B. im Moment auf Firefox 2 und 3) (allerdings teste ich nicht alle Browser bei jeder Änderung an einer Seite nochmal)
Startseite nicht unter verschiedenen Adressen erreichbar (mit und ohne www oder mit und ohne index.dateiendung, auch dafür die .htaccess anpassen, warum nicht siehe double content)

Browser und Auflösungen

Hier geht es noch um Tipps, wie sich bereits beim Entwickeln eines Layouts möglichst viel testen lässt ohne dass der Aufwand ins Unendliche geht. Diese Tipps gehen von einer Linuxumgebung mit einigen installierten Browsern aus. Für Abschlusstests ist eine Windows-Umgebung und möglichst auch ein Mac nötig.

von 800*600 bis 1680*1050 zumindest auf bedienbar prüfen
in einem Standard-Entwicklungsbrowser, meist der Firefox, entwickeln
Seamonkey hier bieten sich spezielle Einstellungen an, da gleiche Engine wie Firefox
Opera
Konqueror nur wenige Sondereinstellungen, da als Safariersatz genutzt
Internet Explorer mindestens IE 6 und IE7
einen Browser immer mit anderer Hintergrundfarbe einstellen (vergessene Farbdefinitionen fallen dann auf, denn meist ist weiß Hintergrundfarbe des Browsers, wenn da eine Definition fehlt, sieht man das nur bei anderer Farbe)
einen Browser immer mit größerer Schriftgröße einstellen (Formularelemente haben da die Tendenz plötzlich unbenutzbar zu werden, das muss nicht sein)
mindestens einen echten Safaritest auf Optik, z.B. mit browsershots.org

Inhaltliche Tests

auf Inhalt, alles verständlich, keine nicht erklärten Fachwörter
Grammatik und Rechtschreibung, Tippfehler (Rechtschreibung einheitlich, nur alte, nur neue, nur deutsche, nur schweizer Version… Es ist egal welche Variante, aber sie sollte durchgängig sein)
durchgängige Ansprache, z.B. siezen wir auf miradlo.com und .de, aber hier auf miradlo.net duzen wir durchgehend auf allen Seiten. Manche Seiten ziehen durchgängig eine Ansprache ohne direkte Anrede vor.
Navigationspunkte vorhanden?
Brotkrümel ok?
Metadaten korrekt? (verschiedene zur Seite passende Titel, Keywords, Description)
korrekte Seiten selektiert? (gerade wenn PHP-Navigationen genutzt werden, kann es passieren, dass da was nicht stimmt)
Mailadressen ok? (wir kodieren Mailadressen mit &irgendwas, damit lässt sich mancher Spam verhindern, im Code sind sie dann jedoch nicht so gut lesbar, deshalb schleicht sich leichter ein Fehler ein)
etwaige Weiterleitungen ok?
Funktioniert der Bildwechsler? Textwechsler? Kontaktformular? (etwaige andere spezielle Effekte, die erscheinen sollten sieht man im Quellcode oder bei Blogs anhand genutzter Widgets und Plugins. Falls Tester und Entwickler nicht dieselbe Person sind, sollte vom Entwickler eine Liste der gewünschten Funktionen gemacht werden. ) Beim Testen von Funktionen mit Besuchereingaben, nicht nur mit korrekten Eingaben testen, sondern gerade auch mit falschen Eingaben, um zu sehen, ob korrekte Fehlermeldungen kommen.
wenn print.css vorhanden: Druckvorschau testen
wenn vorhanden: handheld-CSS testen

Unterm Strich

Beachtet man die obigen Punkte, dann sind Webseiten noch immer nicht zu 100% barrierefrei, aber sie sind für viele leichter zu nutzen. Über manchen Punkt kann man diskutieren, diese Liste stammt von mir, sie enthält im Zweifel meine Sichtweise. Bei miradlo gilt, dass sich alle an diese Liste halten müssen, wenn ein Punkt nicht passt, dann diskutieren wir den und ändern ihn entweder oder machen auch mal eine Ausnahme je nach Auftritt. Wichtig ist, dass man beim Testen weiß, woran man sich orientieren kann, was soll man überhaupt prüfen…

Bei Blogs sollte man bei Updates noch manches andere berücksichtigen.

Tipp für Tests nach Checkliste

Sinnvoll ist es sich eine eigene Testliste zu erstellen, als Grundlage, kann z.B. diese Liste dienen. Die eigene Liste, z.B. fürs eigene Blog oder die eigene Website sollte spezielle Eigenschaften berücksichtigen, weglassen kann man, was man sowieso bei Änderungen bereits automatisch testet. Unsere Liste geht davon aus, dass meist die Webautoren ihre Seite nicht selbst testen, das ist sinnvoll, wenn es möglich ist, denn manche Fehler sieht man selbst nicht. Wer jedoch selbst entwickelt und testet sollte die persönliche Checkliste dementsprechend anpassen.

Progressive Enhancement ::: CSS 3 einerseits jedoch IE 6 andererseits

ute — Mon, 10 Nov 2008 23:07:34 +0000

Dieser Artikel ist Teil 6 von 9 der Serie Webstandards und IE

Progressive Enhancement? im Deutschen könnte man stufenweise Verbesserung oder Erweiterung des Layouts dazu sagen. Hinter diesem Begriff verbirgt sich ein Konzept sich beim Design nicht mehr an den ältesten Browsern zu orientieren und nur zu nutzen, was auch diese umsetzen, sondern Stück für Stück auch kleine Extras für moderne Browser einzubauen. Einen guten Artikel mit Beispielen dazu gibts bei Dieter.

PNG-Transparenz und hover einsetzen

Firefox Standardansicht
winkt mittels hover im Firefox
IE 6 graue Kästen statt Transparenz

In den Sonnenseiten der Webkrauts berichtet Nicolai Schwarz über eine Spielerei bei Qwitter mit den CSS-Sprites. Wie in den Abbildungen des Firefox zu sehen ist, winkt das Männchen. Realisiert wird das schlicht mittels eines Hover-Effekts durch CSS-Sprites, wie es beispielsweise im Artikel von Stefan David beschrieben wird.

Eine schöne und einfach ohne JavaScript umzusetzende Spielerei. Die Designer von Qwitter beschlossen, dass sie sich nicht die Mühe machen mit zusätzlichem Aufwand einen ähnlichen Effekt im IE6 zu erzielen. Wie auf dem Screenshot des IE 6 zu erkennen ist, haben die Bilder des Gesichts, des Arms und des Logos PNG-Transparenzanteile, die dieser nur als grauen Hintergrund darstellt. Der Hovereffekt klappt hier ebenfalls nicht, denn der IE 6 akzeptiert hover ausschließlich für Links.

Klar, kann man darüber diskutieren, dass die Nutzer des IE 6 hier nicht dasselbe geliefert bekommen. Allerdings wäre es in diesem alten Browser (so grade eben aus diesem Jahrtausend) nur mit sehr viel mehr Aufwand und nicht ohne JavaScript lösbar. Für einen netten, aber inhaltlich nicht notwendigen Effekt ist solch ein Aufwand wohl kaum gerechtfertigt.

Die meisten Webentwickler verwenden seit Jahren mehr Zeit für die Anpassungen an den IE 6, als für jeden anderen Browser. Fast alle anderen Browser orientieren sich an den Webstandards und benötigen nur selten einmal spezielle Anpassungen. Insbesondere der IE 6 ist jedoch deutlich aufwändiger von vielen Designideen zu überzeugen, siehe auch den Beitrag Webstandards oder Internet Explorer.

Webseiten für den IE 6

Manch eine Webseite für speziell für den IE 6 erstellt und funktioniert auf keinem anderen Browser richtig. Leider ist es je nach Webauftritt jedoch noch immer eine große Zahl an Besuchern, die den IE 6 nutzen.

Warum nutzen immernoch so viele den IE6?

Wie schon im Artikel über das Metatag für den IE 8 beschrieben, viele Entwickler schrieben ihre Webapplikationen lange Zeit ausschließlich für den Marktführer, also über einige Jahre speziell für den IE 6. Da dieser sicher kaum an Standards hält funktionieren viele Anwendungen ausschließlich mit dem IE 6 oder mit einem Nachfolger, der sich so verhält, als sei er ein IE 6. Applikationen sind teuer, daher benutzen noch viele Firmen den IE 6, um die darauf angepassten Programme nutzen zu können.

Hinzu kommen all die Besucher, die eine ältere Windowsversion, wie Windows 2000 nutzen, denn für dieses Betriebssystem wurde leider keine Version, des deutlich standardkonformeren IE 7 angeboten.

Warum sollte man den IE 6 überhaupt noch berücksichtigen?

Klare Sache, wegen seines Marktanteils. Inzwischen ist er zwar weit davon entfernt noch Marktführer zu sein, wie das lange der Fall war. Einen großen Teil hat der IE 7 übernommen, jedoch auch seit Einführung des Firefox (Hinweis an die Jüngeren: ja, es gab eine Zeit mit Internet und ohne den Firefox;-) ) verlor der Internet Explorer deutlich an Bedeutung.

Inzwischen werden viele Diskussionen geführt, was man tun könnte, um den IE 6 endlich loszuwerden. Manch einer hat die Nase voll und liefert zumindest bei eigenen Seiten für den IE 6 nur noch den reinen Text aus. Andere passen ihr Layout teilweise an und liefern an den IE 6 mit einem Hinweis auf den Firefox-Download aus. Für Kundenseiten bleibt den meisten bislang kaum etwas anderes übrig, als das jeweilige Layout weitgehend auch für den IE 6 anzupassen. Rund 20% Besucher, die nach wie vor den IE 6 nutzen, sind auf manchen Seiten keine Seltenheit.

Lösung durch Progressive Enhancement

Aus obigen Gründen, ist es meist nicht möglich völlig auf die Darstellung im IE 6 zu verzichten. Statt jedoch bei Layoutentwürfen nur darüber nachzudenken, wie etwas auch im IE 6 umgesetzt werden kann, bietet es sich an schrittweise vorzugehen. Schritt- oder stufenweise ist es wie im genannten Beispiel durchaus möglich bereits zusätzliche Verbesserungen und Erweiterungen einzuführen, ohne dass der IE 6 völlig vernachlässigt wird. In CSS 3 gibt es einige interessante Eigenschaften (runde Ecken usw.) und bezogen auf den IE 6 stehen auch in CSS 2 noch viele ungenutzte Möglichkeiten offen.

Meines Erachtens ist das der optimale Weg, um einerseits zusätzliche, neue und interessante Varianten zu nutzen, jedoch andererseits nicht diejenigen Besucher zu ignorieren, die halt einen sehr alten Browser nutzen. Wer mehr darüber wissen will, sollte sich das Buch Transcending CSS anschauen, besser beschreibt es zur Zeit meines Erachtens niemand, wie man auf diesem Weg neue Ideen umsetzen kann.

Spezialfälle: akzeptabler Verzicht auf valides CSS ::: was sagt der Validator?

ute — Wed, 03 Sep 2008 22:08:09 +0000

Dieser Artikel ist Teil 5 von 9 der Serie Webstandards und IE

Normalerweise bin ich ja der Meinung, dass Webstandards eingehalten werden sollen. Damit verbunden sind normalerweise auch Seiten, deren CSS valide ist. Ab und zu eine Ausnahme, ist für mich in einigen Situationen akzeptabel. In meiner Session beim Blogcamp in Zürich kam von einigen der Hinweis, dass die Meldungen des Validators teils unverständlich seien. Deshalb werde ich versuchen, ab sofort diese Meldungen mit zu erklären, wenn ich grad dabei bin.

-moz-border-radius

Wenn es um besondere Eigenschaften geht, die gerade noch nicht dem aktuellen Standard entsprechen, z.B:

-moz-border-radius: 5px;

statt der in CSS 3 kommenden Eigenschaft

border-radius: 5px;

führt zwangsläufig dazu, dass der Validator meldet: Diese Eigenschaft existiert nicht.

In diesem Fall ist das jedoch kein Problem, denn interpretiert wird die Eigenschaft nur von Mozilla-Browsern, die sie verstehen, alle anderen ignorieren die Definition.

Zuweilen nutze ich solche Spielereien daher ganz gern. Allerdings kann das natürlich zu Problemen führen, wie z.B. bei mir letztens mit radius und Firefox 3. Inzwischen habe ich nochmal ein bisschen damit experimentiert.

Bei relativ langen Seiten scheint Firefox 3 grundsätzlich dann Schwierigkeiten mit dieser Definition zu haben, wenn sie sich im gleichen div-Container befindet, wie eine größere Menge Text und ein Hintergrundbild. Nach wie vor konnte ich dieses Problem im Firefox 2 zumindest nicht in diesem Ausmaß feststellen, dort kann es mal etwas langsamer werden, aber kein Vergleich… Im Seamonkey gibt’s gar keine Probleme, da ruckelt und wackelt gar nichts.

Transparenzeffekte

Jegliche Transparenzen werden ebenfalls angemahnt, z.B:

-moz-opacity:0.75

Alle Eigenschaften, die mit sowas wie -moz oder -webkit (für Safari) beginnen, stammen aus CSS 3 und werden irgendwann kommen, zur Zeit ist jedoch noch CSS 2 oder CSS 2.1 aktuell. Ebenso wird natürlich die proprietäre Eigenschaft der Internet Explorer als Einlesefehler gewertet:

filter:alpha(opacity=75);

Hacks für den Internet Explorer

Weitere Hacks für den Internet Explorer, wie z.B. die Eigenschaften, die mittels expression eingebunden werden, versteht der Validator ebenfalls nicht:

height: expression(document.body.scrollHeight > document.body.offsetHeight ? document.body.scrollHeight : document.body.offsetHeight + ‘px’);

Hier meldet der Validator:

Ungültige Nummer: height Lexical error at line 149, column 81. Encountered: “?” (63), after : “” ? document.body.scrollHeight : document.body.offsetHeight + ‘px’);
Ungültige Nummer: height Parse error – Unrecognized }

Die erste Meldung bezieht sich darauf, dass nach height ein Wert stehen sollte, z.B:

height:150px;

Die zweite Meldung ist ein typischer Folgefehler, da der Wert für die Eigenschaft fehlt, versteht der Validator nicht, warum jetzt bereits die Klammer für die Deklaration geschlossen wird.

Bei speziellen Definitionen für den IE, bevorzuge ich Extra-Stylesheets für den jeweiligen IE, die per Conditional Comment eingebunden werden. Damit liest nur der betroffene Browser diese Definitionen ein, alle anderen ignorieren den Kommentar.

Das Beispiel hier stammt aus dem CSS der thickbox, die z.B. vom WordPress-Plugin Ajax-Edit-Comments genutzt wird. Dort wird es nicht per CC eingebunden, was jedoch nicht so schlimm ist, da durch die Transparenzeigenschaften das CSS thickbox.css sowieso nicht valide ist.

Validatormeldungen verstehen

Was man sich beim Korrigieren von Fehlern immer angewöhnen sollte:

immer zuerst den obersten Fehler reparieren
zwischendurch erneut prüfen

Häufig verschwinden mehrere Fehler, sobald ein Fehler korrigiert ist. Den ersten Fehler zunächst korrigieren, ist sinnvoll, um nicht etwaige Folgefehler zu suchen, die vielleicht schon gar nicht mehr existieren.

Hm, zu verstehen, was welche Meldung bedeutet, ist wohl Übungssache. Für mich ist meist klar, was gerade nicht passt, Beispiele:

Diese Eigenschaft existiert nicht.
- bedeutet genau das, so wie es im CSS steht, ist die Eigenschaft nicht zulässig, also z.B: -moz-border-radius
Einlese-Fehler opacity=75)
- Der Validator hat etwas nicht verstanden, in diesem Fall die Eigenschaft filter:alpha( deshalb meldet er einen Einlesefehler, weil der Wert nicht interpretiert werden kann.
Ungültige Nummer: margin-top Lexical error at line 60, column 105 Encountered: “&” (38), after : “” & &document.documentElement.scrollTop | document.body.scrollTop) + ‘px’);
- Lexical error bedeutet hier, dass ein Zeichen benutzt wurde, was da nicht hingehört, in diesem Fall ein “&”
Parse error – Unrecognized }
- Der Validator kann die Klammer an dieser Stelle nicht korrekt analysieren, da sie hier nicht hingehört. Mögliche Fehlerquellen
  - vorher war eine Definition nicht ok
  - es fehlt ein Semikolon nach einer Definition
- deshalb kommt die Klammer unerwartet.
Ungültige Nummer : display inline-block ist kein display-Wert : inline-block
- Die Eigenschaft gibt es in der geprüften Version nicht, zur Zeit wird im Standardfall auf CSS 2 geprüft, die meisten Browser verstehen jedoch auch CSS 2.1. Dort existiert inline-block, deshalb kann man es zwar verwenden, muss jedoch auf CSS 2.1 prüfen, um ein korrektes Ergebnis zu bekommen.

WordPress 2.6.1 wie die Galeriefunktion W3C-valide wird…

ute — Thu, 28 Aug 2008 13:52:11 +0000

Mistbiene! Blödes WordPress!

Erst dachte ich, ich hätte einen Fehler im Theme, weil ich es nicht glauben wollte, aber tatsächlich. Da schreibt mir diese dämliche Galerie doch irgendwo mitten in den Code die Anweisungen: