Check XML and XHTML documents for Well-Formedness and Validity while editing them in TextMate with support for DTD, W3C XML Schema, RELAX NG, Schematron, XInclude, XML Catalog, and XPath 2.0 Visualizer.
[tags]textmate, editor, tools, plugin[/tags]
Check XML and XHTML documents for Well-Formedness and Validity while editing them in TextMate with support for DTD, W3C XML Schema, RELAX NG, Schematron, XInclude, XML Catalog, and XPath 2.0 Visualizer.
[tags]textmate, editor, tools, plugin[/tags]
Gerade ging mir durch den Kopf, dass man ja, wenn man einen Link schreibt, in den Attributen durchaus mit angeben kann, in welcher Sprache das Ziel dieses Links gehalten ist. Dazu gibt es das Attribut hreflang
. Ein Link auf das US-Google würde dann so aussehen:
<a href="http://google.de" hreflang="en-us">US-Google</a>
Der Sprachcode richtet sich dabei nach ISO 639-1. Die Frage nach dem Sinn liegt natürlich auf der Hand: das W3C schreibt dazu:
If you add some text or graphic to a link indicating that the target document is in another language, it may allow the reader to decide in advance whether or not to follow the link, according to their language skill. If the user has to waste time following the link to find out that they cannot read the target document, this introduces fatigue, and they may lack confidence when faced with links that actually do go to readable pages.
Das würde natürlich nur Sinn machen, täte der Webbrowser anzeigen, welche Sprache den geneigten Leser denn nun erwartet. Macht aber kein mir bekannter Browser von alleine. Mit ein wenig CSS kann man ihn aber dazu überreden. Beispielsweise so:
[syntax,flaghover.css,css]
Links mit den Sprachcodes von englisch, amerikanisches englisch, französisch und holländisch bekommen nun beim hovern ein nettes Fähnchen angezeigt. Die Fahnen gibt’s für lau bei FamFamFam zu laden, freundlicherweise. Natürlich passen die Landesfahnen nicht immer zur Sprache und umgekehrt, aber der Benutzer versteht’s sicherlich trotzdem…
BTW: Man sollte natürlich seinen Content insgesamt sprachlich identifizieren, bspw. durch die Angabe der Spache im <html>-Tag, ungefähr so <html lang="de">
. Und wenn man dann fremdsprachlich Texte verwendet identifiziert man diese widerum, bspw. mit einem lang-Attribut in einem Absatz: <p lang="en">This is englisch</p>
. Der eine oder andere Screenreader soll diese Auszeichnugen tatsächlich beachten können und beim Vorlesen den richtigen Akzent auswählen.
[tags]css, code, html, xhtml[/tags]
Ralf Eggert arbeitet in seinem Weblog an einem sehr umfangreichen Zend Framework Tutorial. 11 von 17 Kapiteln sind schon fertig, da kann man sich mal schon ans Lesen machen, während die letzten Kapitel nachgeliefert werden. Über das Tutorial hinweg wird eine komplette Anwendung entwickelt, was ich für einen guten Weg des Einstiegs halte: so kommt am Ende wenigstens etwas dabei heraus. Das Tutorial umfasst folgende Themen:
Das Zend-Framework ist ein MVC– und Webapplication-Framework, von (na?) Zend (schon wieder…).
[tags]PHP, MVC, Framework[/tags]
Ich geb’s zu, darauf warte ich jetzt schon ein paar Tage: Apple BootCamp 1.2beta [via]. And the killa-feature is: Support für Windows Vista (32-bit). Damit und mit Parallels ist die Browser-Engine-Front-End-Testing-Suite komplett. Great.
[tags]Apple, BootCamp, Windows Vista[/tags]
Apollo heisst ein, nein vielleicht das neue Produkt für’s Web aus dem Hause Adobe und es ist das erste echte Kind der Ehe mit Macromedia. Was Apollo macht bzw. machen soll: es fasst die aus dem Netz bekannten Techniken, also HTML, Javascript, Flash und später auch PDF unter einer virtuellen Maschine zusammen und ermöglicht dem geneigten Webentwickler Desktopanwendungen zu erstellen, mit den schon vorhandenen Skills.
Das kann man schon einen Trend nennen: Offlinefunktionalität. Da passen Dojos Offline Toolkit genau so rein, wie Firefox 3, der mit solchen Features aufwarten wird. Eigentlich witzig, denn durch die komplette Zeit meiner Onlineerfahrung habe ich (und sicherlich viele andere) es immer als höchstes Ziel empfunden, irgendwann letztendlich always on zu sein, also immer Verbindung zum Netz zu haben. Nun verkehrt sich diese Idee, das Netz geht sozusagen offline weiter.
Adobe greift zur Herstellung Desktop- und Offlinefähigkeiten auf viele eigene Technolgien zurück (Flash/Flex, PDF), nutzt bekannte Sprachen (HTML, JS/AJAX) und fügt das alles in einer Anzeigeengine zusammen, die auf (man höre und staune) Safari basiert.
Funktionieren kann das schon, denn im Grunde ist Apollo von unten betrachtet, nichts anderes als ein plugingeschwängerter Webbrowser mit Offlinefunktionalität, soll heissen, einSafari, dass zwei zusätzliche Fähigkeiten besitzt:
Simple Idee eigentlich. Die Anwendungen sind dabei genauso zu schreiben wie im Netz, widerum erweitert um ein paar nötige Fähigkeiten:
Im Grunde wars das schon. Nochmal: simple Idee eigentlich. Nun stellt sich trotzdem die Frage, inwieweit sich soetwas durchsetzen wird. Dem User von Flash (viele, viele…) wird man die Apollo-Runtime wohl als Flash-Uodate unterschieben können (oder zumindest anbieten), somit könnten auf Userseite die nötigen Kapazitäten wohl erreicht werden. Aber anders als Flash verlangt Apollo die Verlagerung der eigentlichen Online-Arbeit in eine andere Applikation, heraus aus dem Webbrowser. Das könnte für den Benutzer etwas unsinnig wirken: schätzen wir nicht beispielsweise Gmail, weil es im Browser läuft? Und wollten wir offline damit arbeiten, würden wir dann zur Gmail-Offline-Anwendung wechseln? Oder Gmail immer dort nutzen? Und: wenn ich doch wirklich Offlinefunktionalitäten brauche, benutze ich dann nicht eher Firefox3, der dieses Feature mitbringen wird?
[tags]Adobe, Desktop, Offline, Flash, Javascript[/tags]
Nach so einem Tag ist es vielleicht ratsam, sich einfach mal hinzusetzen, auszuspannen, fünfe gerade und den zu zu lassen und ein wenig zu meditieren… O.K., klappt nicht! Also Rechner wieder auf und schnell das neue Release des Ambient Collective (MySpace) aus dem Internetarchiv herunterladen. So, jetzt ein wenig Feng Shui… ach wunderbar.
Wer seine Webanwendung mal so richtig unter Dampf setzen möchte, der kann dazu 1000 Beta-Tester heranziehen, die in düsteren Kellerräumen eingepfercht, stundenlang auf der neuen Site herumklicken. Das haben wir früher so gemacht. Bis uns ein paar nette Jungs von der Firma Zend heute gezeigt haben, dass es für solche Sachen natürlich auch Tools gibt (… eh, das war ein Scherz).
Microsoft bietet das Web Application Stress Tool für lau, bei der Firma Paessler gibt’s das wesentlich umfangreichere Webserver Stress Tool ab $249.95. Die kostenlose Demo lässt vermuten, dass sich die Investition wohl lohnen wird.
Was die Programme machen: sie gehen mit aller Gewalt, also einer einstellbaren Menge von virtuellen Usern auf die nächste URL los und klicken sich einen mittleren Wolf durch die Webseite. Das »Webserver Stress Tool« kann dabei bis zu 10.000 User simulieren: da ist dann schon etwas los auf dem Server.
Und wie komme ich nun darauf? Nun, irgendwie habe ich die Kollegen im Verdacht, meinen RSS-Feed da in den Stress-Test mit eingeschmuggelt zu haben: woher zum Teufel kommen mit einem Male 440 Abonnenten? 😀
Hab gerade keinen Wein zur Hand: vielleicht hilft auch ein Link. Lieber Designer am Mac, ohne das Widget »Designers Toolbox« des Herrn Preidel geht gar nichts in Sachen Schrift- und Dateigrössen- und Punktberechnung, Blindtexterzeugung und HTML-Entitätenvernachschlagung… oder so. Spitzentool, dass hier im Moment vor allem für die em-Berechnung verwendet wird.
Ich hatte mich ja schon einmal echauffiert, dass es WordPress-Themes in der Hauptsache eher in Quantiät, als in Qualität gibt. Kopfkribbeln versucht das Gegenteil zu beweisen und präsentiert 20 echt gut aussehende WordPress-Design-Templates. Da ist tatsächlich einiges interessantes dabei, aber auch ein paar Sachen zum Nase rümpfen. [Via pixelgraphix].