PixelscheucherWahrscheinlich war es bisher noch nie so leicht, Webseiten auf ihre Kompabilität in verschiedenen Internet Explorer-Versionen zu testen. Tredosoft bietet zur Zeit den IE7 als Standalone-Variante (ohne Installation) und die IE-Versionen 3-6 in einem Paket an.
Anstatt den IE7 als Standalone-Variante laufen zu lassen, kann er auch einfach installiert werden. Dazu noch das Multiple IE-Paket dazu und das testen kann beginnen. Und für Linux-User gibt es den IE auch.
Danke Dr. Web für diesen Hinweis.
Das, was sich damals Microsoft bei Windows 98 mit dem Active Desktop gedacht hat, hat Apple mit den aktuellen Mac OS X Widgets wohl nahezu perfektioniert. Windows Vista wird auf diesen Zug aufspringen, wann auch immer es nun veröffentlicht wird. Wer jetzt schon welche haben möchte, schaut bei Yahoo! Widgets oder im oben erwähnten Wikipedia-Artikel nach. Ich nutz sowas derzeit nicht, aber das Kommentar-Widget von Martin Labuschin find ich recht bemerkenswert. Hätte ich einen Apfel, würde ich mir als allererstes die Designer’s Toolbox von Michael Preidel installieren.
Ein kleiner Gedanke am Samstag Mittag. Schönes Wochenende :)
Webseiten-Validät zu testen war bisher immer sehr klickreich. Zum HTML testen musste der HTML-Validator genutzt werden, für CSS-Überpfungen der CSS-Validator. Das W3C hat bestimmt gemerkt, dass das auf Dauer etwas mühselig ist, und stellt nun alles auf einmal zur Verfügung. Es nennt sich Unicorn und testet das CSS und HTML gleichzeitig. Warum man dafür derzeit JavaScript benötigt, wird mir nicht ganz klar, aber es ist ja auch noch eine Alpha-Version.
A clear, simple, concise and complete assessment of the quality of a web page. Being able to get results of validation of HTML, checking of the style sheets, finding broken links, and more, much more, without having to visit ten different pages and services. That would be a rare sight, but it’s not a fantasy. We give you: The unicorn (public preview)
Auf auf, testet eure Webseiten!
(Dieser Artikel benötigt eine Aktulisierung, die ich bald vornehmen werde, da sich bei diesem Thema einiges getan hat. Wer sich mal anschauen möchte, wie das mit dem iPhone funktioniert: hier entlang )
Jeder, der mit seinem Handy im Internet unterwegs war, wird sich manchmal gefragt haben, ob es nicht spezielle Versionen »für unterwegs« von seinen Lieblings-Webseiten gibt. Natürlich gibt es da einige, beispielsweise die Fahrplanauskunft der Deutschen Bahn, Google und eBay Unterwegs. Diese Versionen sind speziell an den Zugang per Handy angepasst, das heißt kleinere Dateien, weniger Grafiken und sehr schlichte Gestaltung. Mehr Beispiele bei MarcTV: Internet auf dem Handy.
Natürlich könnte man einfach hingehen und die Webseite so gut nach Webstandards umbauen, dass man sie auch im Handybrowser benutzen kann. Einfach ein paar passende HTML– und CSS-Anweisungen – Stichwort Medienangaben – und fertig ist das ganze. Super, braucht man sich keine weitere Subdomain merken, einfach so wie zu Hause. Leider weiß man nur nicht so genau, welcher Handybrowser wieviel CSS versteht und was er daraus gemacht. Außerdem braucht’s ja auch nicht jede Funktion auf einer Website, die man unterwegs abrufen möchte.
Deswegen werden weiterhin spezielle Versionen für Handys oder den Handheld/Palm/etc. entwickelt. Ein Dilemma dabei ist, dass jedes Angebot eine andere Art wählt, wie man diese angepasste Webseite aufrufen kann, das wurde ja schon in den 3 Beispielen deutlich: Subdomain mobile. bei der Deutschen Bahn, Unterverzeichniss /xhtml bei Google und nochmal eine andere Subdomain wap. bei eBay.
Hey, blöd, da herrscht kein bisschen Einigkeit. Welcher normale Google-Nutzer vermutet denn unter /xhtml ein angepasstes Google, wer zuckt bei dem Begriff WAP (oder auch W@P; was ist eigentlich mit i-mode?) (eBay) nicht automatisch zusammen (langsam, teuer, nicht bunt genug) und warum benutzt die Deutsche(!) Bahn bitte den englischen Begriff mobile?
Schluss damit, ein passender Standard muss her, zwei stehen zur Auswahl.
.mobi ist der Versuch von ICANN, Vodafone, Microsoft und sonstigen hohen Tieren bekannten großen Firmen in der Computer- und Telekommunikationsbranche, eine neue Top-Level-Domain für mobile Webseiten zu etablieren, also Domains wie bahn.mobi, karten.mobi oder restaurants.mobi
m. oder auch moburl, die Alternative, spart uns 3 Zeichen zum tippen und setzt einfach auf die Subdomain m., also m.fahrplan.de, m.dailyquote.com, und so weiter.
Persönlich find ich die m./moburl-Alternative besser, vor allem, weil man sich 3 Buchstaben schenken kann. Jeder, der die ein oder andere Kurznachricht getippt hat, weiß was das heißt und ist froh über jede Tipperei weniger. Und wozu eine neue Internet-Domain? Eine weitere Alternative wären Browser-Weichen, aber es gibt höchstwahrscheinlich so viele verschiedene Handybrowser, dass man das niemanden in der Web-Abteilung antun möchte. Mit GMail oder hier in Deutschland GoogleMail hat diese Aktion auch schon einen prominenten Vorreiter, wie die Internetseite von moburl stolz verkündet:
So let’s just make mobile life a bit easier and establish a new address-standard for mobile content: pull up a m.dot moburl like Google just did with m.gmail.com. mobURL
Egal, wofür die Internetwelt sich entscheiden wird, ein einheitlicher Standards ist von Nöten und längst überfällig.
Derzeit teste ich den Umstieg von WordPress auf textpattern, dabei hab ich bisher 2 Probleme feststellen können:
Hat man in WordPress zuvor Bilder hochgeladen und passende Beschreibungen vergeben, werden diese Beschreibungen als eigener Beitrag importiert. Folge ist, dass man nun erstmal diese Beiträge aussortieren und löschen muss. Nervige Angelegenheit ;)
Anscheinend kommt Textile nicht damit klar, wenn man zuvor die Überschriften direkt über den nachfolgenden Absatz geschrieben hat, also so:
<h2>Überschrift</h2>
Nachfolgender Absatz
In der HTML-Ausgabe kommt dann sowas heraus:
<p></p><h2>Überschrift</h2><br>
Nachfolgender Absatz
Steckt zwischen h2-Element und nachfolgendem Absatz eine Leerzeile, klappt es wie am Schnürchen und die Ausgabe ist korrekt:
<h2>Überschrift</h2>
nachfolgender Absatz
Mit einer entsprechenden Datenbankabfrage könnte man nun natürlich hinter jedem abschließenden h2-Element eine neue Zeile hinzufügen, aber was ist, wenn dieser schon existiert? Bekommt dann das nachfolgende (durch Textile erzeugte) p-Element noch ein br verpasst?
Der Umstieg von WordPress auf textpattern bringt einiges an Überraschungen mit. Dies dürfte auch erst der Anfang sein, mal sehen was da noch so auf mich zukommt.