Source: http://www.edition-w3.de/DE/BMI/BITV/20020717/
Timestamp: 2013-05-24 09:17:24
Document Index: 390317448

Matched Legal Cases: ['§ 2', '§ 1', '§ 3', '§ 1', '§ 1', '§ 3', '§ 1', '§ 3', '§ 3', '§ 1', '§ 3']

BITV | Verordnung zur Schaffung barrierefreier Informationstechnik
nach dem Behindertengleichstellungsgesetz (Barrierefreie
Hinweis: Bei der hier zur Verfügung gestellten BITV handelt es sich um eine nichtamtliche Fassung,
die aufgrund ihrer thematischen Nähe zu Webstandards,
insbesondere den Zugänglichkeitsrichtlinien für Web-Inhalte, zu Informationszwecken hier angeboten wird.
Die amtliche Fassung entnehmen Sie bitte dem Bundesgesetzblatt oder anderen amtlichen
Die hier angebotene Fassung enthält Hyperlinks auf entsprechende Stellen der HTML-4- und
CSS-2-Spezifikation. Obwohl sich die BITV nicht
ausdrücklich auf diese Versionen bezieht, sollen die
Hyperlinks die Verständlichkeit der BITV verbessern,
da HTML 4 (bzw. das inhaltlich äquivalente XHTML 1) und
CSS 2 derzeit die verbreitetsten Versionen der jeweiligen
Technik darstellen.
Aufbereitung: Stefan
Mintert, Linkwerk
Informationstechnik-Verordnung - BITV)
Behindertengleichstellungsgesetzes vom 27. April 2002 (BGBl. I
S. 1467) verordnet das Bundesministerium des Innern im
Einvernehmen mit dem Bundesministerium für Arbeit und
Intranetauftritte und -angebote, die öffentlich
zugänglich sind, und
mittels Informationstechnik realisierte grafische
Programmoberflächen, die öffentlich
§ 2 Einzubeziehende Gruppen behinderter
Die Gestaltung von Angeboten der Informationstechnik (§ 1)
nach dieser Verordnung ist dazu bestimmt, behinderten Menschen
im Sinne des § 3 des Behindertengleichstellungsgesetzes,
denen ohne die Erfüllung zusätzlicher Bedingungen die
Nutzung der Informationstechnik nur eingeschränkt
möglich ist, den Zugang dazu zu eröffnen.
Die Angebote der Informationstechnik (§ 1) sind
gemäß der Anlage zu dieser Verordnung so zu
gestalten, dass
alle Angebote die unter Priorität I
aufgeführten Anforderungen und Bedingungen
zentrale Navigations- und Einstiegsangebote
zusätzlich die unter Priorität II
(1) Die in § 1 dieser Verordnung genannten Angebote, die
nach Inkrafttreten dieser Verordnung neu gestaltet oder in
wesentlichen Bestandteilen oder größerem Umfang
verändert oder angepasst werden, sind gemäß
§ 3 dieser Verordnung zu erstellen. Mindestens ein
Zugangspfad zu den genannten Angeboten soll mit der Freischaltung
dieser Angebote die Anforderungen und Bedingungen der
Priorität I der Anlage zu dieser Verordnung erfüllen.
Spätestens bis zum 31. Dezember 2005 müssen alle
Zugangspfade zu den genannten Angeboten die Anforderungen und
Bedingungen der Priorität I der Anlage dieser Verordnung
(2) Angebote, die vor Inkrafttreten dieser Verordnung im
Internet oder im Intranet (§ 1 Nr. 2) veröffentlicht
wurden, sind bis zum 31. Dezember 2003 gemäß § 3
dieser Verordnung zu gestalten, wenn diese Angebote sich speziell
an behinderte Menschen im Sinne des § 3 des
Behindertengleichstellungsgesetzes richten.
(3) Soweit nicht Absatz 2 gilt, sind die Angebote, die vor
Inkrafttreten dieser Verordnung im Internet oder im Intranet
(§ 1 Nr. 2) veröffentlicht wurden, bis zum 31. Dezember
2005 gemäß § 3 dieser Verordnung zu
Die Verordnung ist unter Berücksichtigung der technischen
Entwicklung regelmäßig zu überprüfen. Sie
wird spätestens nach Ablauf von drei Jahren nach ihrem
Inkrafttreten auf ihre Wirkung überprüft.
Fundstelle des Originaltextes: BGBl. I 2002, 2655 - 2662
Dieses Dokument enthält keine Vorgaben zur
grundlegenden Technik, die für die Bereitstellung
von elektronischen Inhalten und Informationen verwendet
wird (Server, Router, Netzwerkarchitekturen und
Protokolle, Betriebssysteme usw.) und hinsichtlich der
zu verwendenden Benutzeragenten. Die Anforderungen und
Bedingungen beziehen sich allein auf die der
Nutzerin/dem Nutzer angebotenen elektronischen Inhalte
Die Anforderungen und Bedingungen dieser Anlage
basieren grundsätzlich auf den
1.0 (Web Content Accessibility Guidelines 1.0) des
World Wide Web Consortiums vom 5. Mai 1999.
Die in Teil 1 dieser Anlage enthaltenen, bei ihrem
ersten Auftreten im Text durch Unterstreichung
kenntlich gemachten, grundlegenden technischen
Fachbegriffe sind in Teil 2 dieser Anlage (Glossar)
geeignete äquivalente Inhalte bereitzustellen, die
den gleichen Zweck oder die gleiche Funktion wie der
originäre Inhalt erfüllen.
Für jedes Nicht-Text-Element ist ein
äquivalenter Text bereitzustellen. Dies gilt
insbesondere für: Bilder,
graphisch dargestellten
Text einschließlich Symbolen, Regionen von
Animationen (z. B. animierte GIFs), Applets
und programmierte Objekte, Zeichnungen, die auf der
Verwendung von Zeichen und Symbolen des ASCII-Codes
basieren (ASCII-Zeichnungen), Frames,
Scripts, Bilder,
die als Punkte in Listen verwendet werden,
Platzhalter-Graphiken, graphische Buttons, Töne
(abgespielt mit oder ohne Einwirkung des Benutzers),
Audio-Dateien, die für sich allein stehen,
Tonspuren von Videos und Videos.
Für jede aktive Region einer serverseitigen
Imagemap sind redundante Texthyperlinks
Für Multimedia-Präsentationen ist eine
Audio-Beschreibung der wichtigen Informationen der
Videospur bereitzustellen.
Für jede zeitgesteuerte
Multimedia-Präsentation (insbesondere Film oder
Animation) sind äquivalente Alternativen (z. B.
Untertitel oder Audiobeschreibungen der Videospur) mit
verständlich sein, wenn sie ohne Farbe
Alle mit Farbe dargestellten Informationen müssen
auch ohne Farbe verfügbar sein, z. B. durch den
Kontext oder die hierfür vorgesehenen Elemente der
verwendeten Markup-Sprache.
Bilder sind so zu gestalten, dass die Kombinationen aus
Vordergrund- und Hintergrundfarbe auf einem
Schwarz-Weiß-Bildschirm und bei der Betrachtung
durch Menschen mit Farbfehlsichtigkeiten ausreichend
Markup-Sprachen (insbesondere HTML)
und Stylesheets
sind entsprechend ihrer Spezifikationen und formalen
Definitionen zu verwenden.
Soweit eine angemessene Markup-Sprache existiert, ist
diese anstelle von Bildern zu verwenden, um
Mittels Markup-Sprachen geschaffene Dokumente sind so
zu erstellen und zu deklarieren, dass sie gegen
veröffentliche formale Grammatiken
Es sind Stylesheets zu verwenden, um die Text- und
Bildgestaltung sowie die Präsentation von mittels
Markup-Sprachen geschaffener Dokumente zu
Es sind relative anstelle von absoluten Einheiten in
den Attributwerten der verwendeten Markup-Sprache und
den Stylesheet-Property-Werten zu verwenden.
Zur Darstellung der Struktur von mittels
Markup-Sprachen geschaffener Dokumente sind
Überschriften-Elemente
Zur Darstellung von Listen und Listenelementen sind die
hierfür vorgesehenen Elemente der verwendeten
Markup-Sprache zu verwenden.
sind mittels der hierfür vorgesehenen
Sprachliche Besonderheiten wie Wechsel der Sprache
sind erkennbar zu machen.
Wechsel und Änderungen der vorherrschend
verwendeten natürlichen Sprache
sind kenntlich zu
Tabellen sind mittels der vorgesehenen Elemente der
verwendeten Markup-Sprache zu beschreiben und in der
Regel nur zur Darstellung tabellarischer Daten zu
In Tabellen, die tabellarische Daten darstellen, sind
die Zeilen-
und Spaltenüberschriften mittels der
vorgesehenen Elemente der verwendeten Markup-Sprache zu
Soweit Tabellen, die tabellarische Daten darstellen,
zwei oder mehr Ebenen von Zeilen- und
Spaltenüberschriften aufweisen, sind mittels der
vorgesehenen Elemente der verwendeten Markup-Sprache
Datenzellen und Überschriftenzellen einander
Tabellen sind nicht für die Text- und
Bildgestaltung zu verwenden, soweit sie nicht auch in
linearisierter Form dargestellt werden
Soweit Tabellen zur Text- und Bildgestaltung genutzt
werden, sind keine der Strukturierung dienenden
Elemente der verwendeten Markup-Sprache zur visuellen
Formatierung zu verwenden.
Internetangebote müssen auch dann nutzbar sein,
wenn der verwendete Benutzeragent
nicht unterstützt oder diese deaktiviert
Es muss sichergestellt sein, dass mittels
Markup-Sprachen geschaffene Dokumente verwendbar sind,
wenn die zugeordneten Stylesheets deaktiviert
Es muss sichergestellt sein, dass Äquivalente
für dynamischen Inhalt aktualisiert werden, wenn
sich der dynamische Inhalt ändert.
wenn Scripts, Applets oder andere programmierte Objekte
Es muss sichergestellt sein, dass die Eingabebehandlung
von Scripts, Applets oder anderen programmierten
Objekten vom Eingabegerät unabhängig
Dynamische Inhalte müssen zugänglich sein.
Insoweit dies nur mit unverhältnismäßig
hohem Aufwand zu realisieren ist, sind gleichwertige
alternative Angebote unter Verzicht auf dynamische
Inhalte bereitzustellen.
durch die Nutzerin/den Nutzer kontrollierbar sein.
Bewegung in mittels Markup-Sprachen geschaffener
Dokumente ist entweder zu vermeiden oder es sind
Mechanismen bereitzustellen, die der Nutzerin/dem
Nutzer das Einfrieren der Bewegung oder die
Änderung des Inhalts ermöglichen.
Automatische periodische Aktualisierungen in mittels
Markup-Sprachen geschaffener Dokumente sind zu
Die Verwendung von Elementen der Markup-Sprache zur
Weiterleitung ist zu vermeiden. Insofern
auf eine automatische Weiterleitung nicht verzichtet
werden kann, ist der Server entsprechend zu
Internetangeboten eingebetteten Benutzerschnittstellen
Programmierte Elemente (insbesondere Scripts und
(Applets) sind so zu gestalten, dass sie entweder
direkt zugänglich oder kompatibel mit assistiven
Technologien sind.
Internetangebote sind so zu gestalten, dass Funktionen
unabhängig vom Eingabegerät oder
Es sind clientseitige
Imagemaps bereitzustellen, es sei
denn, die Regionen können mit den verfügbaren
geometrischen Formen nicht definiert werden.
Jedes über eine eigene Schnittstelle
verfügende Element muss in
geräteunabhängiger Weise bedient werden
In Scripts sind logische anstelle von
geräteabhängigen Event-Handlern
Die Verwendbarkeit von nicht mehr dem jeweils aktuellen
Stand der Technik entsprechenden assistiven
Technologien und Browsern ist sicherzustellen, soweit
der hiermit verbundene Aufwand nicht
Das Erscheinenlassen von Pop-Ups oder anderen Fenstern
ist zu vermeiden. Die Nutzerin/der Nutzer ist über
Wechsel der aktuellen Ansicht zu informieren.
Bei allen Formular-Kontrollelementen mit implizit
zugeordneten Beschriftungen ist dafür Sorge zu
tragen, dass die Beschriftungen korrekt positioniert
Die zur Erstellung des Internetangebots verwendeten
Technologien sollen öffentlich zugänglich und
vollständig dokumentiert sein, wie z. B. die vom
World Wide Web Consortium entwickelten
Es sind öffentlich zugängliche und
vollständig dokumentierte Technologien in ihrer
jeweils aktuellen Version zu verwenden, soweit dies
für die Erfüllung der angestrebten Aufgabe
Die Verwendung von Funktionen, die durch die Herausgabe
neuer Versionen überholt sind, ist zu
Soweit auch nach bestem Bemühen die Erstellung
eines barrierefreien Internetangebots nicht
möglich ist, ist ein alternatives, barrierefreies
Angebot zur Verfügung zu stellen, dass
äquivalente Funktionalitäten und
Informationen gleicher Aktualität enthält,
soweit es die technischen Möglichkeiten zulassen.
Bei Verwendung nicht barrierefreier Technologien sind
diese zu ersetzen, sobald aufgrund der technologischen
Entwicklung äquivalente, zugängliche
Lösungen verfügbar und einsetzbar sind.
Der Nutzerin/dem Nutzer sind Informationen zum Kontext
und zur Orientierung bereitzustellen.
Jeder Frame
ist mit einem Titel zu versehen, um
Navigation und Identifikation zu ermöglichen.
Der Zweck von Frames
und ihre Beziehung zueinander ist
zu beschreiben, soweit dies nicht aus den verwendeten
Titeln ersichtlich ist.
Große Informationsblöcke sind mittels
Elementen der verwendeten Markup-Sprache in leichter
handhabbare Gruppen zu unterteilen.
sind genau ihren Kontrollelementen
Navigationsmechanismen sind übersichtlich und
schlüssig zu gestalten.
Das Ziel jedes Hyperlinks
muss auf eindeutige Weise
Es sind Metadaten bereitzustellen, um semantische
Informationen zu Internetangeboten
Es sind Informationen zur allgemeinen Anordnung und
Konzeption eines Internetangebots, z. B. mittels eines
Inhaltsverzeichnisses oder einer Sitemap,
Navigationsmechanismen müssen schlüssig und
nachvollziehbar eingesetzt werden.
Das allgemeine Verständnis der angebotenen Inhalte
ist durch angemessene Maßnahmen zu
Für jegliche Inhalte ist die klarste und
einfachste Sprache zu verwenden, die angemessen
Für jede aktive Region einer clientseitigen
sind redundante Texthyperlinks
Texte und Graphiken müssen auch denn
verständlich sein, wenn sie ohne Farbe betrachtet
Texte sind so zu gestalten, dass die Kombinationen aus
Markup-Sprachen (insbesondere HTML) und Stylesheets
und Akronyme sind an der Stelle ihres
ersten Auftretens im Inhalt zu erläutern und durch
die hierfür vorgesehenen Elemente der verwendeten
Markup-Sprache kenntlich zu machen.
Die vorherrschend verwendete natürliche Sprache
ist durch die hierfür vorgesehenen Elemente der
verwendeten Markup-Sprache kenntlich zu machen.
sind mittels der vorgesehenen Elemente der
Für Tabellen sind unter Verwendung der
hierfür vorgesehenen Elemente der genutzten
Markup-Sprache Zusammenfassungen
Für Überschriftenzellen sind unter Verwendung
der hierfür vorgesehenen Elemente der genutzten
Markup-Sprache Abkürzungen
wenn der verwendete Benutzeragent neuere Technologien
Es ist eine mit der Tabulatortaste navigierbare,
nachvollziehbare und schlüssige Reihenfolge
Hyperlinks, Formularkontrollelementen und Objekten
Es sind Tastaturkurzbefehle
für Hyperlinks, die
für das Verständnis des Angebots von
entscheidender Bedeutung sind (einschließlich
solcher in clientseitigen Imagemaps),
Formularkontrollelemente und Gruppen von
Formularkontrollelementen bereitzustellen.
Für alle Tabellen, die Text in parallelen Spalten
mit Zeilenumbruch enthalten, ist alternativ linearer
Text bereitzustellen.
Leere Kontrollelemente in Eingabefeldern und
Textbereichen sind mit Platzhalterzeichen zu
Nebeneinander liegende Hyperlinks sind durch von
Leerzeichen umgebene, druckbare Zeichen zu
bereitzustellen, die es ihnen erlauben, Dokumente
entsprechend ihren Vorgaben (z. B. Sprache) zu
Es sind Navigationsleisten bereitzustellen, um den
verwendeten Navigationsmechanismus hervorzuheben und
einen Zugriff darauf zu ermöglichen.
Inhaltlich verwandte oder zusammenhängende
Hyperlinks sind zu gruppieren. Die Gruppen sind
eindeutig zu benennen und müssen einen Mechanismus
enthalten, der das Umgehen der Gruppe
Soweit Suchfunktionen angeboten werden, sind der
Nutzerin/dem Nutzer verschiedene Arten der Suche
Es sind aussagekräftige Informationen am Anfang
von inhaltlich zusammenhängenden
Informationsblöcken (z. B. Absätzen, Listen)
bereitzustellen, die eine Differenzierung
Soweit inhaltlich zusammenhängende Dokumente
getrennt angeboten werden, sind Zusammenstellungen
dieser Dokumente bereitzustellen.
Es sind Mechanismen zum Umgehen von ASCII-Zeichnungen
Text ist mit graphischen oder Audio-Präsentationen
zu ergänzen, sofern dies das Verständnis der
angebotenen Information fördert.
gewählte Präsentationsstil ist
durchgängig beizubehalten.
Anlage (Teil 2): Glossar
Kurz für "Application". Meist in der
Programmiersprache Java verfasstes, in ein
Internetangebot eingefügtes Programm.
"American Standard Code For Information Interchange";
ein Zeichensatz, der es erlaubt, nummerischen Werten
(Bytes) Zeichen der gebräuchlichen Schriftsprache
zuzuordnen. ASCII-Zeichnungen sind Bilder, die durch
die Kombination von Zeichen und Symbolen des
ASCII-Zeichensatzes entstehen (z. B. Emoticons).
Software oder Hardware, die speziell entwickelt wurde,
um behinderten Menschen bei ihren täglichen
Aktivitäten zu helfen. Assistive Technologien sind
z. B. Rollstühle, Lesegeräte, Geräte zum
Greifen usw. Gängige assistive Technologien im
Bereich der Vermittlung von Internetinhalten sind
Screenreader, Bildschirmlupen, Sprachgeneratoren und
Spracheingabe-Software, die in Verbindung mit
graphischen Desktop-Browsern (neben anderen
Benutzeragenten) eingesetzt werden. Assistive
Hardware-Technologien sind u. a. alternative Tastaturen
und Zeigegeräte.
Befehle in Programmiersprachen können
zusätzliche Angaben zur Beschreibung des Befehls
in Form von Attributen enthalten. Diese Attribute
können durch Wertangaben näher bestimmt
Stellt der Nutzerin/dem Nutzer die verarbeiteten Daten
zur Verfügung. Beispiele für
Ausgabegeräte sind Monitore, Drucker, Lautsprecher
oder Braille-Zeilen.
Software zum Zugriff auf Internetinhalte; dies umfasst
graphische Desktop-Browser, Text-Browser,
Sprach-Browser, Mobiltelefone, Multimedia-Player und
manche assistive Software-Technologien, die in
Verbindung mit Browsern verwendet werden, wie etwa
Screenreader, Bildschirmlupen und
Ermöglichen Eingaben der Nutzerin/des Nutzers und
legen deren Darstellung fest.
Programm, das den Zugriff auf und die Darstellung von
Angeboten im Internet erlaubt.
Mittels Graphiken dargestellte Schaltflächen.
Softwareprogramm in Netzwerken, in der Regel auf dem
lokalen Computer der Nutzerin/des Nutzers, das von
Servern bereitgestellte Dienste in Anspruch nimmt.
Clients fordern entweder Daten von Servern an (z. B.
Browser) oder versenden Daten an Server (z. B. E-Mail).
Clientseitig ist eine Funktionalität dann, wenn
sie auf dem Client ausgeführt wird.
Sammelbegriff für verschiedenartige Mechanismen,
Inhalte während ihrer Anzeige dynamisch zu
ändern, entweder automatisch oder durch Einwirken
der Nutzerin/des Nutzers.
Ermöglicht die Interaktion mit dem elektronischen
Medium. Beispiele für Eingabegeräte sind
Tastaturen, Computer-Mäuse,
Blindenschriftgeräte, Kopfstäbe oder
Mikrophone.
"Ereignis-Behandler", werden meist als Attribute in
Befehlen der HTML-Programmiersprache notiert und
lösen bei Aktivierung durch die Nutzerin/den
Nutzer eine vordefinierte Reaktion, in der Regel ein
Definierbare Segmente, die den Anzeigebereich eines
Browsers aufteilen. Jedes Anzeigesegment kann eigene
"Graphics Interchange Format"; ein Dateiformat zur
Darstellung von Graphiken. Animierte GIFs enthalten in
einer Datei mehrere Graphiken, die nacheinander
angezeigt werden und dadurch den Eindruck von Bewegung
Siehe "Markup-Sprache".
Verweis in einem elektronischen Dokument auf ein
beliebiges Verweisziel. Das Verweisziel kann sich in
jeder über den elektronischen Datenaustausch
erreichbaren Quelle befinden.
Verweis-sensitive Graphiken; Graphiken, die in Regionen
mit zugeordneten Aktionen unterteilt wurden. Die
Betätigung einer aktiven Region löst eine
Ein Verfahren der Tabellendarstellung, bei der die
Inhalte der Zellen zu einer Folge von Absätzen
werden. Die Absätze erscheinen in derselben
Reihenfolge, in der die Zellen im ursprünglichen
Dokument definiert sind.
"Auszeichnungssprachen"; Kategorie von
Programmiersprachen, die z. B. HTML (Hyper Text Markup
Language) oder XML (Extensible Markup Language)
umfasst. Auszeichnungssprachen basieren auf der in der
ISO-Norm 8879 festgelegten SGML (Standard Generalized
Markup Language). Sie dienen, in ihren spezifischen
Anwendungsgebieten, zur logischen Beschreibung von
Inhalten, zum Datenaustausch oder zur Definition
Informationen über die verwendeten Daten oder
Die Verbindung mehrerer Medien wie Text, Bild, Ton oder
dreidimensionaler Simulation zu einer geschlossenen
elektronischen Präsentation.
Gesprochene, geschriebene oder durch Zeichen
dargestellte Sprachen wie Deutsch, aber auch
Gebärdensprache oder Blindenschrift.
Neu erscheinender Anzeigebereich bzw. Fenster. Durch
die Nutzerin/den Nutzer in der Regel nicht zu
steuernder Prozess.
In einer speziellen Programmiersprache
("Script-Sprache" wie z. B. JavaScript) verfasstes
Softwareprogramm, das auf einem Hostrechner
ausgeführt wird und in Netzwerken anderen
Rechnern, auf denen Clientsoftware ausgeführt
wird, Dienste (z. B. Websites, E-Mail) zur
Verfügung stellt. Serverseitig ist eine
Funktionalität dann, wenn sie auf dem Server
Gesamtübersicht über den Aufbau eines
CSS (Cascading Stylesheets) ist eine
Ergänzungssprache zu HTML, die die Spezifizierung
der Präsentation eines Dokumentes ermöglicht.
Sie erlaubt das beliebige Formatieren einzelner
HTML-Elemente oder das Definieren zentraler Formate in
Dokumenten. Property-Werte enthalten Wertzuweisungen
für die festgelegten Formate.
die dazu verwendet werden, logische Beziehungen
zwischen Daten zu repräsentieren, enthalten
tabellarische Daten. Den Gegensatz hierzu bilden
Tabellen, die nur der Formatierung bzw. Text- und
Bildgestaltung von Dokumenten dienen.
Ein Linkwerk-Projekt
Die wichtigsten Webfeeds auf einem Blick - zusammengestellt von <edition W3.de>
The Web Application Security Working Group has published a Working Draft of User Interface Security Directives for Content Security Policy. This document defines directives for the Content Security Policy mechanism to declare a set of input protections for a web...[mehr]
(Quelle: W3C News)
The Device APIs Working Group and the Web Applications (WebApps) Working Group have published Working Group Note of Web Intents. This informative specification defines a service discovery and light-weight RPC mechanism for web apps called Web Intents. This document defines...[mehr]
The Device APIs Working Group has published a Last Call Working Draft of Vibration API. This specification defines an API that provides access to the vibration mechanism of the hosting device. Vibration is a form of tactile feedback. Comments are...[mehr]
The User Agent Accessibility Guidelines Working Group (UAWG) today published updated Working Drafts of User Agent Accessibility Guidelines (UAAG) 2.0 and Implementing UAAG 2.0, which define how browsers, media players, and other &quot;user agents&quot; should support accessibility for people with...[mehr]
W3C announced today a RDF Validation Workshop - Practical Assurances for Quality RDF Data, 10-11 September 2013, in Cambridge, USA. The Semantic Web has demonstrated considerable value for collaborative contributions to data. Adoption in many mission-critical environments requires data to...[mehr]
The XML Query Working Group and the XSLT Working Group have published a new version of the Candidate Recommendation of XPath and XQuery Functions and Operators 3.0. The new version reflects changes and clarifications that have been made during the...[mehr]
The MultilingualWeb-LT Working Group has published a Last Call Working Draft of Internationalization Tag Set (ITS) Version 2.0. The Internationalization Tag Set (ITS) 2.0 enhances the foundation to integrate automated processing of human language into core Web technologies. ITS 2.0...[mehr]
<p>Great design is a product of care and attention applied to areas that matter, resulting in a useful, understandable, and hopefully beautiful user interface. But don’t be fooled into thinking that design is left only for designers.</p>
<p>There is a lot of design in code, and I don’t mean code that builds the user interface—I mean the design <em>of</em> code.</p>
<p>Well-designed code is much easier to maintain, optimize, and extend, making for more efficient developers. That means more focus and energy can be spent on building great things, which makes everyone happy—users, developers, and stakeholders.</p>
<p>There are three high-level, language-agnostic aspects to code design that are particularly important.</p>
<li>System architecture—The basic layout of the codebase. Rules that govern how various components, such as models, views, and controllers, interact with each other.</li>
<li>Maintainability—How well can the code be improved and extended?</li>
<li>Reusability—How reusable are the application’s components? How easily can each implementation of a component be customized?</li>
<p>In looser languages, specifically JavaScript, it takes a bit of discipline to write well-designed code. The JavaScript environment is so forgiving that it’s easy to throw bits and pieces everywhere and still have things work. Establishing system architecture early (and sticking to it!) provides constraints to your codebase, ensuring consistency throughout.</p>
<p>One approach I’m fond of consists of a tried-and-true software design pattern, the module pattern, whose extensible structure lends itself to a solid system architecture and a maintainable codebase. I like building modules within a jQuery plugin, which makes for beautiful reusability, provides robust options, and exposes a well-crafted API.</p>
<p>Below, I’ll walk through how to craft your code into well-organized components that can be reused in projects to come.</p>
<h2>The module pattern</h2>
<p>There are a <em>lot</em> of design patterns out there, and equally as many resources on them. <a href="https://twitter.com/addyosmani">Addy Osmani</a> wrote an <a href="http://addyosmani.com/resources/essentialjsdesignpatterns/book/">amazing (free!) book</a> on design patterns in JavaScript, which I highly recommend to developers of all levels.</p>
<p>The <a href="http://addyosmani.com/resources/essentialjsdesignpatterns/book/#modulepatternjavascript">module pattern</a> is a simple structural foundation that can help keep your code clean and organized. A “module” is just a standard object literal containing methods and properties, and that simplicity is the best thing about this pattern: even someone unfamiliar with traditional software design patterns would be able to look at the code and instantly understand how it works.</p>
<p>In applications that use this pattern, each component gets its own distinct module. For example, to build autocomplete functionality, you’d create a module for the textfield and a module for the results list. These two modules would work together, but the textfield code wouldn’t touch the results list code, and vice versa.</p>
<p>That decoupling of components is why the module pattern is great for building solid system architecture. Relationships within the application are well-defined; anything related to the textfield is managed by the textfield module, not strewn throughout the codebase—resulting in clear code.</p>
<p>Another benefit of module-based organization is that it is inherently maintainable. Modules can be improved and optimized independently without affecting any other part of the application.</p>
<p>I used the module pattern for the basic structure of <a href="http://jpanelmenu.com/">jPanelMenu</a>, the jQuery plugin I built for off-canvas menu systems. I’ll use that as an example to illustrate the process of building a module.
<h2>Building a module</h2>
<p>To begin, I define three methods and a property that are used to manage the interactions of the menu system.</p>
<p>The idea is to break down code into the smallest, most reusable bits possible. I could have written just one <code>toggleMenu( )</code> method, but creating distinct <code>openMenu( )</code> and <code>closeMenu( )</code> methods provides more control and reusability within the module.</p>
<p>Notice that calls to module methods and properties from <em>within</em> the module itself (such as the calls to <code>setMenuStyle( )</code>) are prefixed with the <code>this</code> keyword—that’s how modules access their own members.</p>
<p>That’s the basic structure of a module. You can continue to add methods and properties as needed, but it doesn’t get any more complex than that. After the structural foundations are in place, the reusability layer—options and an exposed API—can be built on top.</p>
<h2>jQuery plugins</h2>
<p>The third aspect of well-designed code is probably the most crucial: reusability. This section comes with a caveat. While there are obviously ways to build and implement reusable components in raw JavaScript (we’re about 90 percent of the way there with our module above), I prefer to build jQuery plugins for more complex things, for a few reasons.</p>
<p>Most importantly, it’s a form of unobtrusive communication. If you used jQuery to build a component, you should make that obvious to those implementing it. Building the component as a jQuery plugin is a great way to say that jQuery is required.</p>
<p>In addition, the implementation code will be consistent with the rest of the jQuery-based project code. That’s good for aesthetic reasons, but it also means (to an extent) that developers can predict how to interact with the plugin without too much research. Just one more way to build a better developer interface.</p>
<p>Before you begin building a jQuery plugin, ensure that the plugin does not conflict with other JavaScript libraries using the <code>$</code> notation. That’s a lot simpler than it sounds—just wrap your plugin code like so:</p>
<p>Next, we set up our plugin and drop our previously built module code inside. A plugin is just a method defined on the jQuery <code>($)</code> object.</p>
<p>All it takes to use the plugin is a call to the function you just created.</p>
<p>Options are essential to any truly reusable plugin because they allow for customizations to each implementation. Every project brings with it a slew of design styles, interaction types, and content structures. Customizable options help ensure that you can adapt the plugin to fit within those project constraints.</p>
<p>It’s best practice to provide good default values for your options. The easiest way to do that is to use jQuery’s <code>$.extend( )</code> method, which accepts (at least) two arguments.</p>
<p>As the first argument of <code>$.extend( )</code>, define an object with all available options and their default values. As the second argument, pass through the passed-in options. This will merge the two objects, overriding the defaults with any passed-in options.</p>
<p>Beyond providing good defaults, options become almost self-documenting—someone can look at the code and see all of the available options immediately.</p>
<p>Expose as many options as is feasible. The customization will help in future implementations, and flexibility never hurts.</p>
<p>Options are terrific ways to customize how a plugin works. An API, on the other hand, enables extensions to the plugin’s functionality by exposing methods and properties for the implementation code to take advantage of.</p>
<p>While it’s great to expose as much as possible through an API, the outside world shouldn’t have access to all internal methods and properties. Ideally, you should expose only the elements that will be used.</p>
<p>In our example, the exposed API should include calls to open and close the menu, but nothing else. The internal <code>setMenuStyle( )</code> method runs when the menu opens and closes, but the public doesn’t need access to it.</p>
<p>To expose an API, return an object with any desired methods and properties at the end of the plugin code. You can even map returned methods and properties to those within the module code—this is where the beautiful organization of the module pattern really shines.</p>
<p>API methods and properties will be available through the object returned from the plugin initialization.</p>
<h2>Polishing developer interfaces</h2>
<p>With just a few simple constructs and guidelines, we’ve built ourselves a reusable, extensible plugin that will help make our lives easier. Like any part of what we do, experiment with this structure to see if it works for you, your team, and your workflow.</p>
<p>Whenever I find myself building something with a potential for reuse, I break it out into a module-based jQuery plugin. The best part about this approach is that it forces you to use—and test—the code you write. By using something as you build it, you’ll quickly identify strengths, discover shortcomings, and plan changes.</p>
<p>This process leads to battle-tested code ready for open-source contributions, or to be sold and distributed. I’ve released my (mostly) polished plugins as open-source projects on <a href="https://github.com/acolangelo">GitHub</a>.</p>
<p>Even if you aren’t building something to be released in the wild, it’s still important to think about the design of your code. Your future self will thank you.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/x0nEW66nHaE" height="1" width="1"/>[mehr]
(Quelle: A List Apart: The Full Feed)
<p>We’ve all been there: that bit of JavaScript functionality that started out as just a handful of lines grows to a dozen, then two dozen, then more. Along the way, a function picks up a few more arguments; a conditional picks up a few more conditions. And then one day, the bug report comes in: something’s broken, and it’s up to us to untangle the mess.</p>
<p>As we ask our client-side code to take on more and more responsibilities—indeed, whole applications are living largely in the browser these days—two things are becoming clear. One, we can’t just point and click our way through testing that things are working as we expect; automated tests are key to having confidence in our code. Two, we’re probably going to have to change how we write our code in order to make it possible to write tests.</p>
<p>Really, we need to change how we code? Yes—because even if we know that automated tests are a good thing, most of us are probably only able to write integration tests right now. Integration tests are valuable because they focus on how the pieces of an application work together, but what they don’t do is tell us whether individual <em>units of functionality</em> are behaving as expected.</p>
<p>That’s where unit testing comes in. And we’ll have a very hard time <em>writing unit tests</em> until we start <em>writing testable JavaScript</em>.</p>
<h2>Unit vs. integration: what’s the difference?</h2>
<p>Writing integration tests is usually fairly straightforward: we simply write code that describes how a user interacts with our app, and what the user should expect to see as she does. <a href="http://docs.seleniumhq.org/">Selenium</a> is a popular tool for automating browsers. <a href="https://github.com/jnicklas/capybara">Capybara</a> for Ruby makes it easy to talk to Selenium, and there are plenty of tools for other languages, too.</p>
<p>Here’s an integration test for a portion of a search app:</p>
<pre><code class="ruby">def test_search
<p>Whereas an integration test is interested in a user’s interaction with an app, a unit test is narrowly focused on a small piece of code:</p>
<blockquote>When I call a function with a certain input, do I receive the expected output? </blockquote>
<p>Apps that are written in a traditional procedural style can be very difficult to unit test—and difficult to maintain, debug, and extend, too. But if we write our code with our future unit testing needs in mind, we will not only find that writing the tests becomes more straightforward than we might have expected, but also that we’ll simply <em>write better code</em>, too.</p>
<p>To see what I’m talking about, let’s take a look at a simple search app:</p>
<p><img src="http://d.alistapart.com/375/app.png" alt="Srchr"></p>
<p>When a user enters a search term, the app sends an XHR to the server for the corresponding data. When the server responds with the data, formatted as JSON, the app takes that data and displays it on the page, using client-side templating. A user can click on a search result to indicate that he “likes” it; when this happens, the name of the person he liked is added to the “Liked” list on the right-hand side.</p>
<p>A “traditional” JavaScript implementation of this app might look like this:</p>
<pre><code class="javascript">var tmplCache = {};
<p>My friend <a href="https://twitter.com/ajpiano">Adam Sontag</a> calls this <cite>Choose Your Own Adventure</cite> code—on any given line, we might be dealing with presentation, or data, or user interaction, or application state. Who knows! It’s easy enough to write integration tests for this kind of code, but it’s hard to test individual <em>units of functionality</em>.</p>
<p>What makes it hard? Four things:</p>
<li>A general lack of structure; almost everything happens in a <code>$(document).ready()</code> callback, and then in anonymous functions that can’t be tested because they aren’t exposed.</li>
<li>Complex functions; if a function is more than 10 lines, like the submit handler, it’s highly likely that it’s doing too much.</li>
<li>Hidden or shared state; for example, since <code>pending</code> is in a closure, there’s no way to test whether the pending state is set correctly.</li>
<li>Tight coupling; for example, a <code>$.ajax</code> success handler shouldn’t need direct access to the DOM.</li>
<h2>Organizing our code</h2>
<p>The first step toward solving this is to take a less tangled approach to our code, breaking it up into a few different areas of responsibility:</p>
<li>Presentation and interaction</li>
<li>Data management and persistence</li>
<li>Overall application state</li>
<li>Setup and glue code to make the pieces work together</li>
<p>In the “traditional” implementation shown above, these four categories are intermingled—on one line we’re dealing with presentation, and two lines later we might be communicating with the server.</p>
<p><img src="http://d.alistapart.com/375/code-lines.png" alt="Code Lines"></p>
<p>While we can absolutely write integration tests for this code—and we should!—writing unit tests for it is pretty difficult. In our functional tests, we can make assertions such as “when a user searches for something, she should see the appropriate results,” but we can’t get much more specific. If something goes wrong, we’ll have to track down exactly where it went wrong, and our functional tests won’t help much with that.</p>
<p>If we rethink how we write our code, though, we can write unit tests that will give us better insight into where things went wrong, and also help us end up with code that’s easier to reuse, maintain, and extend.</p>
<p>Our new code will follow a few guiding principles:</p>
<li>Represent each distinct piece of behavior as a separate object that falls into one of the four areas of responsibility and doesn’t need to know about other objects. This will help us avoid creating tangled code.</li>
<li>Support configurability, rather than hard-coding things. This will prevent us from replicating our entire HTML environment in order to write our tests.</li>
<li>Keep our objects’ methods simple and brief. This will help us keep our tests simple and our code easy to read.</li>
<li>Use constructor functions to create instances of objects. This will make it possible to create “clean” copies of each piece of code for the sake of testing.</li>
<p>To start with, we need to figure out how we’ll break our application into different pieces. We’ll have three pieces dedicated to presentation and interaction: the Search Form, the Search Results, and the Likes Box.</p>
<p><img src="http://d.alistapart.com/375/app-views.png" alt="Application Views"></p>
<p>We’ll also have a piece dedicated to fetching data from the server and a piece dedicated to gluing everything together.</p>
<p>Let’s start by looking at one of the simplest pieces of our application: the Likes Box. In the original version of the app, this code was responsible for updating the Likes Box:</p>
<pre><code class="javascript">var liked = $(&#39;#liked&#39;); var resultsList = $(&#39;#results&#39;); // ...
e.preventDefault(); var name = $(this).closest(&#39;li&#39;).find(&#39;h2&#39;).text(); liked.find( &#39;.no-results&#39; ).remove(); $(&#39;&lt;li&gt;&#39;, { text: name }).appendTo(liked); });
<p>The Search Results piece is completely intertwined with the Likes Box piece and needs to know a lot about its markup. A much better and more testable approach would be to create a Likes Box object that’s responsible for manipulating the DOM related to the Likes Box:</p>
<pre><code class="javascript">var Likes = function (el) {
<p>This code provides a constructor function that creates a new instance of a Likes Box. The instance that’s created has an <code>.add()</code> method, which we can use to add new results. We can write a couple of tests to prove that it works:</p>
<pre><code class="javascript">var ul;
<p>Not so hard, is it? Here we’re using <a href="http://visionmedia.github.io/mocha/">Mocha</a> as the test <em>framework</em>, and <a href="http://chaijs.com/">Chai</a> as the <em>assertion library</em>. Mocha provides the <code>test</code> and <code>setup</code> functions; Chai provides <code>assert</code>. There are plenty of other test frameworks and assertion libraries to choose from, but for the sake of an introduction, I find these two work well. You should find the one that works best for you and your project—aside from Mocha, <a href="http://qunitjs.com/">QUnit</a> is popular, and <a href="http://theintern.io/">Intern</a> is a new framework that shows a lot of promise.</p>
<p>Our test code starts out by creating an element that we’ll use as the container for our Likes Box. Then, it runs two tests: one is a sanity check to make sure we can make a Likes Box; the other is a test to ensure that our <code>.add()</code> method has the desired effect. With these tests in place, we can safely refactor the code for our Likes Box, and be confident that we’ll know if we break anything.</p>
<p>Our new application code can now look like this:</p>
<pre><code class="javascript">var liked = new Likes(&#39;#liked&#39;);
var resultsList = $(&#39;#results&#39;); // ...
e.preventDefault(); var name = $(this).closest(&#39;li&#39;).find(&#39;h2&#39;).text(); liked.add(name);
<p>The Search Results piece is more complex than the Likes Box, but let’s take a stab at refactoring that, too. Just as we created an <code>.add()</code> method on the Likes Box, we also want to create methods for interacting with the Search Results. We’ll want a way to add new results, as well as a way to &#8220;broadcast&#8221; to the rest of the app when things happen within the Search Results—for example, when someone likes a result.</p>
<pre><code class="javascript">var SearchResults = function (el) {
<p>Now, our old app code for managing the interaction between Search Results and the Likes Box could look like this:</p>
var resultsList = new SearchResults(&#39;#results&#39;); // ...
<p>It’s much simpler and less entangled, because we’re using the <code>document</code> as a global message bus, and passing messages through it so individual components don’t need to know about each other. (Note that in a real app, we’d use something like <a href="http://backbonejs.org">Backbone</a> or the <a href="https://github.com/tildeio/rsvp.js">RSVP</a> library to manage events. We’re just triggering on <code>document</code> to keep things simple here.) We’re also hiding all the dirty work—such as finding the name of the person who was liked—inside the Search Results object, rather than having it muddy up our application code. The best part: we can now write tests to prove that our Search Results object works as we expect:</p>
<p>The interaction with the server is another interesting piece to consider. The original code included a direct <code>$.ajax()</code> request, and the callback interacted directly with the DOM:</p>
<pre><code class="javascript">$.ajax(&#39;/data/search.json&#39;, {
<p>Again, this is difficult to write a unit test for, because so many different things are happening in just a few lines of code. We can restructure the data portion of our application as an object of its own:</p>
<pre><code class="javascript">var SearchData = function () { };
<p>Now, we can change our code for getting the results onto the page:</p>
<pre><code class="javascript">var resultsList = new SearchResults(&#39;#results&#39;); var searchData = new SearchData();
<p>Again, we’ve dramatically simplified our application code, and isolated the complexity within the Search Data object, rather than having it live in our main application code. We’ve also made our search interface testable, though there are a couple caveats to bear in mind when testing code that interacts with the server.</p>
<p>The first is that we don’t want to <em>actually</em> interact with the server—to do so would be to reenter the world of integration tests, and because we’re responsible developers, we already have tests that ensure the server does the right thing, right? Instead, we want to &#8220;mock&#8221; the interaction with the server, which we can do using the <a href="http://sinonjs.org/">Sinon</a> library. The second caveat is that we should also test non-ideal paths, such as an empty query.</p>
<pre><code class="javascript">test(&#39;constructor&#39;, function () {
<p>For the sake of brevity, I’ve left out the refactoring of the Search Form, and also simplified some of the other refactorings and tests, but you can see a finished version of the app <a href="https://github.com/rmurphey/testable-javascript">here</a> if you’re interested.</p>
<p>When we’re done rewriting our application using testable JavaScript patterns, we end up with something much cleaner than what we started with:</p>
<pre><code class="javascript">$(function() {
<p>Even more important than our much cleaner application code, though, is the fact that we end up with a codebase that is thoroughly tested. That means we can safely refactor it and add to it without the fear of breaking things. We can even write new tests as we find new issues, and then write the code that makes those tests pass.</p>
<h2>Testing makes life easier in the long run</h2>
<p>It’s easy to look at all of this and say, &#8220;Wait, you want me to write more code to do the same job?&#8221;</p>
<p>The thing is, there are a few inescapable facts of life about Making Things On The Internet. You will spend time designing an approach to a problem. You will test your solution, whether by clicking around in a browser, writing automated tests, or—<em>shudder</em>—letting your users do your testing for you in production. You will make changes to your code, and other people will use your code. Finally: there will be bugs, no matter how many tests you write.</p>
<p>The thing about testing is that while it might require a bit more time at the outset, it really does save time in the long run. You’ll be patting yourself on the back the first time a test you wrote catches a bug before it finds its way into production. You’ll be grateful, too, when you have a system in place that can prove that your bug fix really does fix a bug that slips through.</p>
<p>This article just scratches the surface of JavaScript testing, but if you’d like to learn more, check out:</p><ul>
<li><a href="http://lanyrd.com/2012/full-frontal/sztqh/">My presentation</a> from the 2012 Full Frontal conference in Brighton, UK.</li>
<li><a href="http://gruntjs.com/">Grunt</a>, a tool that helps automate the testing process and lots of other things.</li>
<li><cite><a href="http://www.amazon.com/Test-Driven-JavaScript-Development-Developers-Library/dp/0321683919/ref=sr_1_1?ie=UTF8&amp;qid=1366506174&amp;sr=8-1&amp;keywords=test+driven+javascript+development">Test-Driven JavaScript Development</a></cite> by Christian Johansen, the creator of the Sinon library. It is a dense but informative examination of the practice of testing JavaScript.</li>
</ul><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/EcxNHDRHkTM" height="1" width="1"/>[mehr]
<p>If SharePoint and Facebook had a baby, it would look a lot like <a href="http://www.igloosoftware.com/campaigns/alistapart">Igloo</a> (without the recessive balding or oversharing tendencies). Hosted, managed and with a major release every 90 days, Igloo is <a href="http://www.igloosoftware.com/campaigns/alistapart">a whitelabel content platform</a> built for today&#8217;s needs. We also have Sandwich Video.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/mMOKelnXCko" height="1" width="1"/>[mehr]
<a href="http://ma.tt/2013/05/yahooblr/" style="font-size: 18px;">» Matt Mullenweg on Yahoo-Tumblr</a><br><br>“We’re at the cusp of understanding the ultimate value of web publishing platforms, particularly ones that work cross-domain.”–Matt Mullenweg of WordPress.<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/mtIeSUFNVF0" height="1" width="1"/>[mehr]
W3C announced today a Workshop on Social Standards: The Future of Business, 7-8 August 2013, in San Francisco, USA. The event is hosted by AppFusions, sponsored by IBM, and jointly organized with the OpenSocial Foundation. The goal of this workshop...[mehr]
A report summarizing the MultilingualWeb workshop in Rome is now available from the MultilingualWeb site. It contains a summary of each session with links to presentation slides and minutes taken during the workshop in Rome. The workshop was a huge...[mehr]
The RDF Working Group has published a Last Call Working Draft of JSON-LD 1.0 Processing Algorithms and API. This specification defines an Application Programming Interface (API) and a set of algorithms for programmatic transformations of JSON-LD documents. Restructuring data according...[mehr]
The Web Applications Working Group has published a Last Call Working Draft of Indexed Database API. This document defines APIs for a database of records holding simple values and hierarchical objects. Each record consists of a key and some value....[mehr]
The System Applications Working Group has published two Working Drafts today: The app: URI scheme. This specification defines the app: URI scheme and rules for dereferencing an app: URI, which can be used to address resources inside a package (e.g.,...[mehr]
The Web Real-Time Communication Working Group and the Device APIs Working Group have published a Working Draft of Media Capture and Streams. This document defines a set of JavaScript APIs that allow local media, including audio and video, to be...[mehr]
The Research and Development Working Group (RDWG) will hold an online symposium to explore user modeling for accessibility, an approach for generating and adapting user interfaces to address particular user needs and preferences. The Call for Papers is open until...[mehr]
The Site Redesign Task Force invites the community to take a short site redesign survey. As discussed in the A List Apart Column "W3C is Getting Some Work Done" W3C is developing a plan to refresh its Web presence for...[mehr]
<a href="http://mapbox.com/blog/vector-tiles/" style="font-size: 18px;">» MapBox Develops an Open Source Vector Format for Maps</a><br><br>MapBox's new vector-based map tiles are more stable, more scalable, and customizable to an amazing degree.<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/6RkzuwjWbwM" height="1" width="1"/>[mehr]
<p class="question"><b>I know you’ve been asked this plenty of times already, but: no new vendor prefixes, right? <em>Right?</em></b></p>
<p>Nope, none! They’re great in theory but turns out they fail in practice, so we’re joining <a href="http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0731.html">Mozilla</a> and the <a href="http://www.w3.org/blog/CSS/2012/08/30/resolutions-53/">W3C CSS WG</a> and moving away them. There’s a few parts to this.</p>
<p>Firstly, we won’t be migrating the existing <code>-webkit-</code> prefixed properties to a <code>-chrome-</code> or <code>-blink-</code> prefix, that’d just make extra work for everyone. Secondly, we inherited some existing properties that are prefixed. Some, like <code>-webkit-transform</code>, are standards track and we work with the CSS WG to move ahead those standards while we fix any remaining issues in our implementation and we’ll unprefix them when they’re ready. Others, like <code>-webkit-box-reflect</code> are not standards track and we’ll bring them to standards bodies or responsibly deprecate these on a case-by-case basis. Lastly, we’re not introducing any new CSS properties behind a prefix.</p>
<p class="question"><b>Pinky swear?</b></p>
<p>Totes. New stuff will be available to experiment with behind a flag you can turn on in <code>about:flags</code> called &#8220;Experimental Web Platform Features&#8221;. When the feature is ready, it’ll graduate to Canary, and then follow its ~12 week path down through Dev Channel, Beta to all users at Stable.</p>
<p>The <a href="http://www.chromium.org/blink#vendor-prefixes">Blink prefix policy</a> is documented and, in fact, WebKit just nailed down their <a href="https://lists.webkit.org/pipermail/webkit-dev/2013-May/024850.html">prefix policy</a> going forward. If you’re really into prefix drama (and who isn’t!) Chris Wilson and I discussed this a lot more on <a href="http://5by5.tv/webahead/51">the Web Ahead podcast</a> [37:20].</p>
<p class="question"><b>How long before we can try Blink out in Chrome?</b></p>
<p>Blink’s been in Chrome Canary as of the day we announced it. The codebase was 99.9% the same when Blink launched, so no need to rush out and check everything. All your sites should be pretty much the same. </p>
<p>Chrome 27 has the Blink engine, and that’s available on the beta channel for Win, Mac, Linux, ChromeOS and Android. (See the <a href="https://googledrive.com/host/0B8R1QvA3x5IbWll3M0hIYXVLZlk/">full beta/stable/dev/canary view</a>).</p>
<p class="question"><b>While the internals are apt to be fairly different, will there be any radical changes to the rendering side of things in the near future?</b></p>
<p>Nothing too alarming, layout and CSS stuff is all staying the same. Grid layout is still in development, though, and our Windows text rendering has been getting a new backend that we can hook up soon, greatly boosting the quality of webfont rendering there.</p>
<p>We’re also interested in better taking advantage of multiple cores on machines, so the more we can move painting, layout (aka reflow), and style recalculation to a separate thread, but the faster everyone’s sites will render. We’re already doing multi-threaded painting on ChromeOS and Android, and looking into doing it on Mac &amp; Windows. If you’re interested in these <a href="http://www.chromium.org/blink/developer-faq#TOC-What-sorts-of-things-should-I-expect-from-Chrome-">experimental efforts</a> or watching new feature proposals, take a look at the <a href="https://groups.google.com/a/chromium.org/forum/?fromgroups#!forum/blink-dev">blink-dev mailing list</a>. A recent proposed experiment is called <a href="https://groups.google.com/a/chromium.org/d/topic/blink-dev/V1vJmirHUGE/discussion">Oilpan</a>, where we’ll look into the advantages of moving the implementation of Chrome’s DOM into JavaScript.</p>
<p class="question"><b>Will features added to Blink be contributed back to the WebKit project? Short term; long term?</b></p>
<p>Since Blink launched there’s been a few patches that have been landed in both Blink and WebKit, though this is expected to decline in the long-term, as the code bases will diverge.</p>
<p class="question"><b>When are we likely to start seeing Blink-powered versions of Chrome on Android? Is it even possible on iOS, or is iOS Chrome still stuck with a Safari webview due to Apple’s policies?</b></p>
<p>Blink is now in the <a href="https://play.google.com/store/apps/details?id=com.chrome.beta&amp;hl=en">Chrome Beta for Android</a>. Chrome for iOS, due to platform limitations, is based on the WebKit-based WebView that’s provided by iOS. </p>
<p class="question"><b>Part of this move seems to be giving Google the freedom to remove old or disused features that have been collecting dust in WebKit for ages. There must be a few things high on that list—what are some of those things, and how can we be certain their removal won’t lead to the occasional broken website?</b></p>
<p>A few old ’n crusty things that we’re looking at removing: the <a href="http://www.w3.org/wiki/HTML/Elements/isindex">isindex attribute</a>, <a href="https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/blink-dev/5mNHirgyOzM">RangeException</a>, and <a href="https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/blink-dev/JoerJvQlWFY">XMLHttpRequestException</a>. Old things that have little use in the wild and just haven’t gotten a spring cleaning from the web platform for ages. </p>
<p>Now, we don’t want to break the web, and that’s something that web browser engineers have always been kept very aware of. We carefully gauge real-world usage of things like CSS and DOM features before deprecating anything. At Google we have a copy of the web that we run queries against, so we have a pretty OK idea of what CSS and JavaScript out there is using. </p>
<p>Blink also has over 32,000 tests in its test suite, and manual confirmation that over 100 sites work great before every release ships. And we’re working closely with the W3C and Adobe to share tests and testing infrastructure across browsers, with the goals of reducing maintenance burden, improving interoperability, and increasing test coverage. Eventually we’d like all new features to ship with shared conformance tests, ensuring interoperability even as we add cutting-edge stuff.</p>
<p>Still, any deprecation has to be done responsibly. There’s now a draft Blink <a href="https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/blink-dev/nmIDo1w9dwg">process for deprecating features</a> which includes:</p>
<li>Anonymous metrics to understand how much any specific feature is used “in the wild”</li>
<li>”Intent to deprecate” emails that hit blink-dev months before anything is removed</li>
<li>Warnings that you’ll find in your DevTools console if you’re using anything deprecated</li>
<li>Mentions on the Chromium blog like <a href="http://blog.chromium.org/2013/04/chrome-27-beta-speedier-web-and-new.html">this Chrome 27 wrap-up</a>.</li>
<p class="question"><b>Did part of the decision to branch away from WebKit involve resistance to adding a Dart VM? WebKit’s goals <a href="http://www.webkit.org/projects/goals.html">explicitly mention JavaScript</a>, and Apple representatives have been <a href="https://lists.webkit.org/pipermail/webkit-dev/2011-December/018806.html](https://lists.webkit.org/pipermail/webkit-dev/2011-December/018806.html">fairly vocal</a> about <a href="https://lists.webkit.org/pipermail/webkit-dev/2011-December/018822.html](https://lists.webkit.org/pipermail/webkit-dev/2011-December/018822.html">not seeing a need</a>.</b></p>
<p>Nope, not at all. The decision was made by the core web platform engineers. Introducing a new VM to a browser introduces considerable maintenance cost (we saw this with V8 and JavaScriptCore both in WebKit) and right now Dart isn’t yet ready to be considered for an integration with Blink. (more on that in a sec). Blink’s got strong <a href="http://www.chromium.org/blink#compatibility">principles around compatibility risk</a> and this guides a lot of the decisions around our commitments to potential features as they are proposed. You can hear a more <a href="https://www.youtube.com/watch?feature=player_embedded&amp;v=TlJob8K_OwE#at=1046">complete answer here from Darin Fisher</a>, one of the Chrome web platform leads.</p>
<p class="question"><b>Have any non-WebKit browsers recently expressed an interest in Dart? A scripting language that <a href="https://gist.github.com/paulmillr/1208618#file-dart-txt-L320">only stands to work in one browser</a> sounds a little VBScript-y.</em></b></p>
<p>Not yet, but since Dart compiles to JavaScript and runs across the modern web, it’s not gated by other browsers integrating the VM. But it’s still early days, Dart has not yet reached a stable 1.0 milestone and that there are still technical challenges with the Dart VM around performance and memory management. Still, It’s important to point out that Dart is an open source project, with a bunch of external contributors and committers.</p>
<p>Let me take a moment to provide my own perspective on Dart. :) Now, as you know, I’m a JavaScript guy, so early on, I took a side and and considered Dart an enemy. JavaScript should win; Dart is bad! But then I came to realize the Dart guys aren’t just setting out to improve the authoring and scalability of web application development. They also really want the web to win.&nbsp; Now I’ve recently spoke about how <a href="http://www.lukew.com/ff/entry.asp?1716">The Mobile Web Is In Trouble</a>, and clarified that my priorities are seeing it provide a fantastic user experience to everyone. For me, seeing the mobile web be successful trumps language wars and certainly quibbling over syntax. So I’m happy to see developers embrace the authoring advantages of Coffeescript, the smart subset of JavaScript strict mode, the legendary Emscripten &amp; asm.js combo, the compiler feedback of TypeScript and the performance ambitions of Dart. It’s worth trying out technologies that can leapfrog the current expectations of the user experience that we can deliver. Our web is worth it.</p>
<p class="question"><b>Will Opera be using the Chromium version of Blink wholesale, as far as you know? Are we likely to see some divergence between Opera and Chrome?</b></p>
<p>As I understand it, Opera Mobile, Opera Desktop, and Opera Mini will all be based on Chromium. This means that they’ll not only share the exact version of Blink that Chrome uses, but also the same graphics stack, JavaScript engine, and networking stack. Already, Opera has contributed some great things to Blink and we’re excited about what’s next.</p>
<p class="question"><b>Why the name “Blink,” anyway?</b></p>
<p>Haha. Well&hellip; it’s a two parter. First, Blink evokes a certain feeling of speed and simplicity—two core principles of Chrome. Then, Chrome has a little tradition of slightly ironic names. Chrome itself is all about minimizing the browser chrome, and the Chromebook Pixel is all about not seeing any pixels at all. So naturally, it fits that Blink will never support the infamous <code>&lt;blink&gt;</code> tag. ;)</p>
<p>&lt;3z</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/_FjSLm1-zBM" height="1" width="1"/>[mehr]
<a href="http://www.w3.org/QA/2013/05/perspectives_on_encrypted_medi.html" style="font-size: 18px;">» W3C to Publish Encrypted Media Extensions Specification</a><br><br>The W3C announced today that it intends to publish the controversial Encrypted Media Extensions extension specification despite highly outspoken resistance, paving the way for native web DRM.
<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/f7uMGgccqS4" height="1" width="1"/>[mehr]
<a href="http://cognition.happycog.com/article/better-stakeholder-interviews" style="font-size: 18px;">» Research Tips For Designers and Developers</a><br><br>How is the waterfall web design process like the childhood game of "Telephone," and how can we fix it? Bringing designers and developers into the discovery and research phase is a good start, says Happy Cog creative director Chris Cashdollar, who shares stakeholder interviewing tips in this helpful Cognition post.<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/Qq8IuA20lkY" height="1" width="1"/>[mehr]
<p>In any given day I can find myself reading up on a new W3C proposal, fixing an issue with our tax return, coding an add-on for our product, writing a conference presentation, building a server, creating a video tutorial, and doing front end development for one of our sites. Without clients dictating my workload I’m in the enviable position of being able to choose where to focus my efforts. However, I can’t physically do everything.</p>
<p>I’m one half of a two-person web development business—the team behind the little CMS, Perch. I’m also an author and speaker on subjects that range from CSS to technical support, and I enjoy all of it.</p>
<p>When we were a service business, what I was actually working on was largely dictated by the requirements of our clients. Whether they wanted to pay me to build servers, manage projects, or write code didn’t really matter. I was exchanging my time for money, doing a range of things I enjoyed. Now that we’re a product company, my greatest challenge is working out where I am best spending my time, while avoiding falling down a rabbit hole of interesting things I have discovered while performing some other task.</p>
<p>The quote that I opened this column with reflects the dilemma I seem to face daily. I can choose to place my attention anywhere. But if I dart around between tasks, none of them get my full attention. At the very least, progress on everything becomes painfuly slow as I spend an hour on one thing and two on another, inching them all forward. I can’t claim to have the perfect solution to managing this problem, but I have started to develop a process for deciding what needs to be done, and whether I am the best person to be doing it.</p>
<p>First and foremost you need to identify what needs doing. I am a great fan of <a href="http://en.wikipedia.org/wiki/Getting_Things_Done">Getting Things Done</a> and regularly review our business and my personal goals, and the tasks that will go into meeting them. Once I have a list of tasks, I can assess them against the following criteria:</p>
<li>Am I the only person who can do this?</li>
<li>Does the business or product benefit from me in particular doing this?</li>
<li>Is this a task I really enjoy doing?</li>
<li>Will I learn anything new by doing this?</li>
<li>What am I not doing if I choose to do this?</li>
<h2>Am I the only person who can do this?</h2>
<p>Things that fall into group one, the things that only I can do, need investigating. It isn’t ideal for any business to have things that only one person can do. It might be that I need to deal with that task <em>today</em>, but how can I make it so that in the future someone else could? Until the middle of last year, our accounts were a case in point. Although we had an accountant do our end of year tax returns, I was the only person who fully understood the complex processes developed to deal with the many incoming small payments for Perch licenses. Taking on a bookkeeper meant I had to formalize and document all of those processes. As a result I don’t have to do the day-to-day books, but perhaps more importantly the business isn’t reliant on knowledge that is only in my head.</p>
<h2>Does the business or product benefit from me in particular doing this?</h2>
<p>It can make sense to keep some tasks internal. I wouldn’t completely outsource our technical support, or our social media activity, or even our marketing. The public face of our product is very much about us being a small, friendly business. Our customers get to talk to us, the product developers; we share their frustrations and they help us decide on where to put time into new features. There may well be real reasons to keep certain tasks as a role of the core person or team, even if they would seem straightforward to outsource.</p>
<h2>Is this a task I really enjoy doing?</h2>
<p>Running a business can involve hard work and long hours. If you feel you have to outsource bits of your job that you love doing because it makes most sense as a business, you may end up pretty miserable. For those of us running small software companies, it’s likely we have ended up here because we like to code. So it’s important to me that I spend some of my time actually writing code—even if it might be more sensible from a business perspective for me to just manage other people who are writing code.</p>
<p>I believe that our products and businesses are better when we love being involved with them. To have a successful business, it’s likely that you will always have important things to do that you find less enjoyable than designing or writing code, however I don’t think we should be beating ourselves over the head. Doing what we love is really what has been behind the success of our product. It is completely ok to hang onto some tasks because you simply enjoy doing them.</p>
<h2>Will I learn anything new by doing this?</h2>
<p>I might really enjoy a particular project, but I find a helpful way to decide if I should do something or contract it out is to see whether I will learn anything new by doing it myself. For example, I have just sent out a sizeable chunk of front-end development. It is a rebuild of an existing site, and I think there are lots of practical and performance gains to be had by rebuilding it. It would have been nice to have done that work myself, but I wouldn’t have learned anything by doing it. Therefore I made the decision that this would be a good piece of work to outsource to a contractor. I can manage that project and make sure that I’m happy with the end result, but I don’t need to actually write the code.</p>
<p>Our business benefits by us having knowledge and understanding. I’m currently spending quite a lot of time learning about automation (using <a href="https://puppetlabs.com/">Puppet</a>) and modern ways of managing systems while rebuilding our infrastructure. I could have brought someone in to do this work for me, and may well do so in future. Yet by updating my systems administration skills, I’m ensuring that within the business we maintain a good level of knowledge about our infrastructure.</p>
<h2>What am I not doing if I choose to do this?</h2>
<p>As part of a tiny team of two, I’ll always have a number of tasks on the go. Ultimately, choosing to take on one task means not doing something else. It might be another task in the business that gets pushed back. It might be personal things like exercise, or spending time with family and friends. To be able to understand the implications of selecting one thing to work on over another, you need to have a really good overview of all the things that are trying to get your attention.</p>
<p>Having clear business goals and objectives in the first place can make this decision-making so much easier. When you find yourself in the position of being able to do anything, it is so easy to run around picking up tasks and trying to do everything. The trick is to take that step back; to see where you can be more strategic with which tasks you tackle and which you delegate. This approach can help you be far more productive and give you space to enjoy the work you are doing while meeting your business goals.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/yiLQQ29l58s" height="1" width="1"/>[mehr]
<p>Ilya Grigorik discusses in detail how to construct a mobile website that loads as quickly as possible. A site that not only renders in 1 second, but one that is also visible in 1 second. With hard statistics as evidence to show why this matters, Ilya discusses techniques to deliver a 1000 millisecond experience.</p>
<iframe width="696" height="392" src="http://www.youtube.com/embed/Il4swGfTOSM?rel=0" frameborder="0" allowfullscreen></iframe>
</figure><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/VpCuD_mMqCU" height="1" width="1"/>[mehr]
<p>Arguing for “separation of content from presentation” implies a neat division between the two. The reality, of course, is that content and form, structure and style, can never be fully separated. Anyone who’s ever written a document and played around to see the impact of different fonts, heading weights, and whitespace on the way the writing flows knows this is true. Anyone who’s ever squinted at HTML code, trying to parse text from tags, knows it too.</p>
<p>On one hand, the division of labor between writing and presentation can be seen at every point in our history. Ancient scribes chiseling stone tablets, medieval monks copying illuminated manuscripts, printers placing movable type—we’ve never assumed that the person who produces the document and the person who comes up with the ideas must be one and the same.</p>
<p>And yet, we know that medium and message are intertwined so tightly, they can’t be easily split apart. Graphic designers rail against the notion that “look and feel” can be painted on at the end of the process, because design influences meaning. The more skilled we are as communicators, the more we realize that the separation of content from presentation is an industrial-age feint, an attempt to standardize and segment tasks that are deeply connected.</p>
<p>Today, we try to enforce the separation of content and form because it’s good for the web. It’s what makes web standards possible. It enables social sharing and flexible reuse of content. It supports accessibility. It’s what will keep us sane as we try to get content onto hundreds of new devices and form factors.</p>
<p>When talking about how best to separate content from presentation, designers and developers tend to focus on front-end code—which makes sense, because that’s what we have the most control over. But, as with so many challenges we have with content on the web, the real issue lies in the tools we give content creators to help them structure, manage, and publish their content. The form that content takes depends as much on CMS as it does on CSS.</p>
<p>How should content management tools guide content creators to focus on meaning and structure? What’s the right amount of control over presentation and styling in the CMS? And how should these tools evolve as we break out of the web page metaphor and publish content flexibly to multiple platforms? Let’s look at three tools that sit at the intersection of content and form.</p>
<h2>Preview button</h2>
<p>Even the most die-hard structured content editors still like seeing what their work is going to look like. Writers print out documents for editing to give them a different view from what they see on the screen. Bloggers instinctively hit the preview button to look at their work the way a user will see it.</p>
<p>Whoops. Decades of work refining the emulators between desktop publishing programs and laser printers means that writers can feel confident that their document will look virtually identical, regardless of where it’s printed. We’ve carried that assumption over to the web, where it’s categorically untrue. Different browsers render content in their own vexingly special way. Users can change the font size—even add their own custom style sheet. Today, the same document will render differently on desktops, tablets, and mobile devices. The preview button is a lie.</p>
<p>Yet we can’t just throw the baby out with the bathwater. In fact, seeing content in context becomes even <em>more</em> important as our content now lives across devices and platforms. Instead of throwing up our hands and saying “preview is broken,” it’s time to invent a better preview button.</p>
<p>One publishing company I know of has built its own custom preview rendering interface, which shows content producers an example of how each story will appear on the desktop web, the mobile web, and an app. Is it perfect? Far from it. Content will appear in many more contexts than just those three. Is it better than nothing? Absolutely.</p>
<h2>WYSIWYG</h2>
<p>The desktop publishing revolution ushered in by the Macintosh allowed the user to see a document on screen in a form that closely mirrored the printed version. The toolbar at the top of the screen enabled the user to add formatting—change the font, insert an image, add typographic effects like headings and bullets, and much more.</p>
<p>In an effort to carry over this ease of use to the web, we allow content creators to embed layout and styling information directly into their content. Unfortunately, the code added by content creators can be at odds with the style sheet, and it’s difficult for developers to parse what’s style and what’s substance. When it comes time to put that content on other platforms, we wind up with a muddled mess.</p>
<p>What is the right amount of formatting control to give content creators? That’s a difficult question to answer, because it pierces right to the heart of what’s stylistic and what’s semantic. Even something as simple as adding bold and italic text forces us to ask if we’re really just styling the text, or adding semantic meaning (say, a book title or a warning message.)</p>
<p>Better content modeling can solve some of these problems, encouraging content creators to appropriately “chunk” their text. By banishing blobs of text with formatting embedded and replacing them with chunks of clean, presentation-independent content, we’re building in the distinction between content and form right from the start.</p>
<p>But imagining that each “chunk” of content is a field in the database (with its own input field) rapidly devolves into the absurd. That way lies madness. The real solution isn’t necessarily to “banish blobs,” but to replace the WYSIWYG toolbar with semantic markup. Rather than entering all text into discrete fields, content authors wrap text that describes what it is. Our book title doesn’t need to be a separate field if we can wrap it in the proper tags.</p>
<p>Defining what goes in a field and what goes in a tag requires a tighter collaboration between content authors, CMS architects, and front-end developers. It’s time we started having these conversations.</p>
<h2>Inline editing</h2>
<p>We’re evolving. Not satisfied to rely just on tools that are vestiges of the desktop publishing era, we’re developing new and innovative ways to mix up content and formatting that are unique to the way the web works. There’s no better example of this than inline editing.</p>
<p>Inline editing allows content creators to directly manipulate content in the interface, with no separation between the editing screen and the display. Medium offers an editing interface that’s <a href="https://medium.com/about/df8eac9f4a5e">identical to the desktop display</a> and in-place editing is being <a href="http://drupal.org/project/spark">added to Drupal 8 core</a>.</p>
<p>One of the questions I get asked most frequently is “how can I get my content creators to understand why it’s so important to add structure and metadata to their content?” This, I believe, is one of the fundamental challenges we’re facing on the web, particularly as we adapt to a multi-channel future. Inline editing encourages content creators to focus on the visual presentation of the desktop interface. Just at the moment when we need content creators to think about the underlying structure, we’re investing in tools that obscure the “connective tissue.”</p>
<p>Jeff Eaton sums up this problem nicely in a post called <a href="https://www.lullabot.com/articles/inline-editing-and-cost-leaky-abstractions">Inline Editing and the Cost of Leaky Abstractions</a>:</p>
<figure class="quote"><blockquote><p>The editing interfaces we offer to users send them important messages, whether we intend it or not. They are affordances, like knobs on doors and buttons on telephones. If the primary editing interface we present is also the visual design seen by site visitors, we are saying: “This page is what you manage! The things you see on it are the true form of your content.”</p>
<p>The best solution isn’t to build tools that hide that complexity from the user, that make them think that the styling they’re adding to the desktop site is the “real” version of the content. Instead, our goal should be to communicate the appropriate complexity of the interface, and help guide users to add the right structure and styling.</p>
<p>The era of “desktop publishing” is over. Same goes for the era where we privilege the desktop web interface above all others. The tools we create to manage our content are vestiges of the desktop publishing revolution, where we tried to enable as much direct manipulation of content as possible. In a world where we have infinite possible outputs for our content, it’s time to move beyond tools that rely on visual styling to convey semantic meaning. If we want true separation of content from form, it has to start in the CMS.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/8MK6ULY0bLI" height="1" width="1"/>[mehr]
<p>Chris Coyier explains <a href="http://css-tricks.com/magic-numbers-in-css/">Magic Numbers</a>:</p>
<blockquote>Magic numbers in CSS refer to values which “work” under some circumstances but are frail and prone to break when those circumstances change. They are usually always related to fonts.</blockquote>
<p>Many good examples in that post, and in the comments, but the one that stood out for me was Chris&#8217; attempt to flank a heading with horizontal lines:</p>
<blockquote>In a recent post <a href="http://css-tricks.com/line-on-sides-headers/">Line-On-Sides Headers</a>, I used a line-height value that was a magic number. Let’s say you used the technique around text with a fancy @font-face font. Let’s say that font doesn’t load or the user overrides it or the page is being viewed in a browser that don’t support @font-face. The fallback font will load, and that fallback font might have drastically different sizing than the custom font. The lines on the outside of the fallback font are now awkwardly placed, not centered like we wanted.</blockquote>
<p>Of course, I don&#8217;t need to tell Chris (he was only trying to illustrate a technique and its shortcomings), but it bears mentioning whenever I get the chance: progressive enhancement is <a href="https://readmill.com/vasilis/reads/a-pocket-guide-to-combining-typefaces/highlights/x3ywfw">part of typography now</a>. First, style text in a generic way (like, without flanking horizontal lines). Then, if the fonts you intend are active, use <a href="https://github.com/typekit/webfontloader">WebFont Loader</a> (or <a href="http://help.typekit.com/customer/portal/articles/6787-Font-events">Typekit font events</a>) to follow up with rules that depend on the presence (and the dimensions) of those fonts.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/MCz34tjVTp0" height="1" width="1"/>[mehr]
<p>In my first article, “<a href="http://alistapart.com/article/even-better-in-browser-mockups-with-node.js">Even Better In-Browser Mockups with Node.js</a>,” I explained why Node.js makes designing applications easier and more efficient, and how to get started. Now it’s time to see your new design process in action.</p>
<p>Rather than figuring out all your requirements and API schemas just to design your comps with mockup content hard-coded and server interactions faked—only to throw it all away when you go back and implement things “for real”—you can use Node.js to skip the hard-coding and produce client-side code that’s ready for beta at the end of the design stage.</p>
<p>The process looks a lot like good ol’ <a href="/article/responsive-comping-obtaining-signoff-with-mockups">designing in the browser</a>, but with more JavaScript and an additional layer:</p>
<li>Design the layout and styling</li>
<li>Convert the markup to a JavaScript template</li>
<li>Create an initialization function</li>
<li>Create a simple Node.js server</li>
<li>Add a mockup data object to the server</li>
<li>Add server functions to serve static pages and JSON</li>
<li>Request and consume the JSON on the client</li>
<p>Sound daunting? Don’t worry. The first step takes approximately a zillion times longer than any of the others. So if you’ve already mastered the design, you’ll find the rest of these steps more than manageable.</p>
<p>In this walkthrough, we’ll build a feature for a mock art store. If you want to follow along at home, you can clone my <a href="https://github.com/garann/coolartstore">GitHub repository</a>. (If you need help installing, see the <a href="https://github.com/garann/coolartstore/blob/master/README.md">README</a>, or just take a peek at the <a href="http://coolartstore.rs.af.cm/">live demo</a>—I’ll cover all the steps and code below.)</p>
<h2>Creating templates</h2>
<p>Once you have a solid design and the markup to accompany it, converting it to a template you can use for all examples is more efficient than creating duplicate markup for each one. The hard part’s over; you already thought about where data points would be used in the design when you created it. With those choices fresh in your mind, go back and mark up your HTML with data in whatever template language you prefer.</p>
<p>For my example, I’m using a store selling art prints. Here’s a snippet of my initial markup:</p>
<pre><code>&lt;h2&gt;Two Acrobats with a Dog&lt;/h2&gt;
&lt;span class=&quot;price&quot;&gt;$49.99&lt;/span&gt;</code></pre>
<p>Think of your templates as places to define your requirements for both data and its formatting on the client side. If you can also reuse it for client-side rendering, that’s awesome—but that may not be relevant to your application. As long as you have good data, converting from one template language to another is trivial, so don’t agonize over which template engine to use.</p>
<p>You do need a template engine that will work in both the browser and Node.js, however. If you’re unsure, search for your template engine on <a href="https://github.com/">GitHub</a> and verify that there’s a guide to installing it via <a href="https://npmjs.org/">npm</a> in the manual, as well as a minified script for use on the client. I prefer <a href="http://olado.github.io/doT/index.html">doT.js</a>, so here’s that snippet again marked up to add data using doT:</p>
<pre><code>&lt;h2&gt;{{=it.title}}&lt;/h2&gt;
&lt;span class=&quot;price&quot;&gt;{{=it.price}}&lt;/span&gt;</code></pre>
<p>I like to save my templates in their own directory at the same level as my JavaScript directory, so now I store that as <code>tmpl/detail.dot</code>.</p>
<h2>Initializing the client</h2>
<p>Since we want to be able to use our templates in both Node and the browser, they need to be stored outside of the HTML and loaded and compiled when we open the page. To start, save the minified version of your template engine and add a script tag to your page to include it. Once that’s done, you can fetch the template, compile it, and then continue on with any other initialization work in your main JavaScript file. I’m using jQuery in my example, so my code looks like this:</p>
<pre><code>var detailTmpl;
$.when( $.get( &quot;tmpl/detail.dot&quot;, function( tmpl ) {
}, &quot;text&quot; ) ).then( init );</code></pre>
<p>That mysterious <code>init</code> function? That’s where I’ll put any interactivity I want to add to my currently static mockup. For the moment I’m only creating one interaction, so my <code>init</code> function is pretty simple:</p>
<pre><code>function init() {
<p>This code can be made much more elegant using <a href="http://requirejs.org/">Require.js</a> with its text plugin. That’s beyond the scope of this demo, but I highly encourage it for production.</p>
<p>We’ll handle template rendering in <code>showDetail()</code>, but we have to add a server and data store before writing that function, since right now we lack any data <em>to</em> render.</p>
<h2>Creating a server</h2>
<p>If I reload my page now and open the browser console, I get a JavaScript error. That’s because I’m trying to load my template via an XMLHttpRequest (XHR) on a page being served from the file system, in violation of the <a href="http://en.wikipedia.org/wiki/Same_origin_policy">same origin policy</a>. I can’t even check that my template works until the page is served properly (i.e., from a server).</p>
<p>To whip up a simple Node server that allows me to run my XHRs, I do a few things:</p>
<li>Move all my existing assets into a new subdirectory called <code>public</code></li>
<li>Open my terminal or command line to my working directory and run <code>npm install express</code></li>
<li>Add a server.js file to the working directory</li>
<p>We could write everything from scratch, of course, but it’s more work than is necessary for a basic server. The <a href="http://expressjs.com/">Express</a> framework provides a number of abstractions of server and application concepts. For the initial version of the server, the only one we’ll need is its ability to serve static resources. We can use it by adding four lines of code to <code>server.js</code>:</p>
<pre><code>var express = require( &quot;express&quot; ),
app.listen( 3000 );</code></pre>
<p>Once you start your server by typing <code>node server.js</code> in your open terminal or command line, you can view your page at http://localhost:3000 (adding a filename if necessary), and the error related to loading the template ought to disappear.</p>
<h2>Adding server-side data</h2>
<p>While it’s certainly nice to be able to use XHRs, we&#8217;re creating the Node server to use it as a representation of the real server—and real servers store data. Though it’s not hard to create a data store that works with a Node server, it’s even less difficult to create one big <a href="https://developer.mozilla.org/en-US/docs/JavaScript/Guide/Values,_variables,_and_literals?redirectlocale=en-US&amp;redirectslug=Core_JavaScript_1.5_Guide/Values,_Variables,_and_Literals%23Object_literals">object literal</a>. For a mockup, that’s all we really need. One of the goals here is to define the data objects we need to support in our new design, so the format of this object can be determined by the template we just added. For my example, I need an object structured something like this:</p>
<pre><code>var products = {
<p>Note that <code>products</code> could just as easily be an array, but I want to be able to quickly find my products—once I have more than one in my fake data store—by ID. Aside from that little twist, the data look exactly like the content hard-coded in my original HTML. If I want to add more data, including things that might break the layout in unpredictable ways, I can just copy this structure and make substitutions. Well, almost.</p>
<h2>Returning data from the server</h2>
<p>If you’ve dealt with other server-side frameworks, creating endpoints for XHRs might seem intimidating, but Express makes it really easy. We don’t need any special setup to define a server endpoint as a target for asynchronous requests. All we have to do is define the path on the server where we want to accept requests and a callback. The callback receives a request object (for doing things like getting passed-in data) and a response object (for defining what we return to the client). To return the data in my products object, I add a few lines of code at the bottom of server.js:</p>
<pre><code>app.get( &quot;/detail/:id&quot;, function( req, res ) {
<p>See? Easy. If I restart my server and go to http://localhost:3000/detail/102, I should see my object data. To break down what’s going on with the ID in the path, we’ve named the data at that position in the path &quot;id&quot; with the <code>:id</code> bit, and it then becomes available as a property of <code>req.params</code>.</p>
<p>The names and positions of parameters are up to us, and if our path were super complex, we could also use regular expressions to split out multiple pieces of data. Express also gives us the option of accepting data from the query string or from a POST. Of all the pieces we’re creating, however, the paths are the most likely to change in production, so it’s to our advantage to keep them as readable as possible.</p>
<p>Besides sending pure data to the client, we also want to be able to send rendered HTML, in case a user is linked directly to a product detail or doesn’t have JavaScript available. We might also want HTML for our own consumption via XHR, if we find that client-side rendering is slowing us down. So we add a second endpoint below the one we just created to do that:</p>
<pre><code>app.get( &quot;/product/:id&quot;, function( req, res ) {
<p>For simplicity’s sake, and because the first path served JSON for an overlay while this provides a full page, I’ve used a different pathname, but kept the same pattern. This time, instead of the response’s send function, I use <code>render()</code>. Express provides some magic to make template rendering work out of the box, but since I’m using doT instead of Jade (the default template engine of Express), I have to do some additional setup.</p>
<p>First I have to go back to the terminal or command line, stop my Node server, and install my template engine using <code>npm install doT</code> and the consolidate module (which provides Express compatibility for a number of popular template engines) using <code>npm install consolidate</code>. Now I’ve got both of those in my <code>node_modules</code> directory and can use them in <code>server.js</code>.</p>
<p>Since doT (and probably your template engine of choice, as well) is accessed through consolidate, consolidate is the only additional module I need to require at the top of <code>server.js</code>:</p>
cons = require( &quot;consolidate&quot; );</code></pre>
<p>I want to continue serving some of my other pages statically, so I add my template configuration stuff below the existing <code>app.use</code> line in my code:</p>
<pre><code>app.use( express.static( _dirname + &quot;/public&quot; ) );
app.set( &quot;views&quot;, _dirname + &quot;/public/tmpl&quot; );</code></pre>
<p>Those three new lines set doT (as exposed by consolidate) as the view engine, register files ending in <code>.dot</code> as templates, and tell Express to look in <code>/public/tmpl</code> for templates to use. So when Node sees <code>res.render( &quot;detail&quot;, { ... } )</code>, it knows to expand <code>&quot;detail&quot;</code> to <code>/public/tmpl/detail.dot</code> and render it as a doT template. Now I can restart my server, go to http://localhost:3000/product/102, and see my template rendered statically, without creating a separate server-side file.</p>
<h2>Fetching dynamic data</h2>
<p>Our template now works as a static page, but there’s still one more step to get our mockup populated with the data from the server. Remember the <code>showDetail</code> function from our main client-side script? It’s time to flesh that out.</p>
<p>In my simple example, the overlay my template will populate already exists as a hidden <code>div</code> on the main page, and it appears when the user clicks a <code>div</code> containing a summary of the content. This div has a data attribute storing the ID of the product that corresponds to the key and id property in my server-side data object. Once that click event happens and <code>showDetail()</code> is called, I just need to do this: </p>
<pre><code>function showDetail( e ) {
<p>The path above is the same one I defined in <code>server.js</code>. If you chose a different name for yours, use that name here on the client. When I receive the data object from the server, I pass it to <code>detailTmpl()</code>, the compiled version of my template. The result of the <code>detailTmpl</code> function is the HTML to populate my overlay.</p>
<h2>Onward</h2>
<p>So there you have it! A mockup that mimics the interactions it will have with its production server precisely on the client, without the need for hard-coded data or temporary workarounds. Despite the simple exercise, the process I’ve outlined accomplishes a good deal of the setup necessary to create other workflows that require server interactions. For instance, I can fill my fake data store with more products and use that to render the initial page that triggers my overlay without having to revisit my mockup data, and my application will show the correct values in any view I add to it.</p>
<p>If you’d like to explore beyond just serving HTML and JSON, consider adding in <a href="http://socket.io">Socket.io</a> to allow real-time interaction for multiple clients or Require.js to manage your assets on the client. You could also move your CSS into templates and serve different builds of your site for different browsers or devices. Your mockup can be as sophisticated and reflect as many of its production requirements as you choose. At the end, the lion’s share of your client-side code is done and ready to use.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/1XsqLkwaSO8" height="1" width="1"/>[mehr]
<p>Designing in the browser has all sorts of benefits, like producing more accurate, comprehensive results and removing the extra step of converting from image file to markup and CSS. But even sites designed in a browser still require pasting in content, faking interactions with the server, and creating placeholder JavaScript that isn’t usable on the live site.</p>
<p>Wouldn’t it be nice if we could go from just designing layouts and interactions to designing the whole client side of the application during the same process?</p>
<p>This is where Node comes in.</p>
<p>Node.js is a server-side JavaScript platform. It isn’t a web server, but it allows you to easily create one. It also lets you create utilities that run on web servers, like setup and minification utilities and general-purpose command line tools.</p>
<p>Node started in 2009 and generated considerable interest, probably because it gave JavaScript developers an opportunity to write server-side code even if they lacked a server-side background. It didn’t hurt that Chrome had established a reputation for being solid and fast, and Node used its V8 engine.</p>
<p>Today, it’s possible to run production servers on Node, and many people are doing so successfully. Taking it that far, however, is an investment. The Node project, and all the community-created modules that make it so awesome, is still a moving target. But even if you’re not ready to write and launch entire sites with Node, it’s plenty stable enough to use as a development tool.</p>
<p>It’s JavaScript, so if you can wire up a jQuery event handler, you can write a web server. It’s lightweight, so you can run it on your laptop and keep streaming music in the background. It’s dead simple to download, set up, and build in, so you don’t need the esoteric knowledge of an IT support person to get going with it. And the payoff is that instead of mockups and hard-coded data, you can design a set of client-side assets, page templates, and data schemas that are ready to launch to production.</p>
<p>Installing Node locally for the most common environments is a piece of cake. You can download <a href="http://nodejs.org/download/">installers</a> that include Node as well as npm, its package manager, from the project’s site. Installing it on a remote server is not quite that easy, but <a href="https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager">good documentation</a> is available to help you out. After running through the installation process, you should be able to go to your terminal or command line and test it out.</p>
<p>If you don’t tell Node to run a specific file, you get a Read-Eval-Print Loop, or REPL. If you type <code>node</code> in your terminal or command prompt, you can begin to execute arbitrary JavaScript. For example, after starting the REPL, type <code>var a = 9;</code>. The REPL will respond with undefined. Now type <code>a * 3</code> (or any other number) and it will respond with the correct result. You can make things more interesting by defining a function and then calling it:</p>
<pre><code>> function sayHello( name ) { return “Hello, “ + name; }
‘Hello, A List Apart’</code></pre>
<p>To break out of the REPL, or end any other Node execution (like a running web server), press Ctrl+C. In the case of the REPL, you’ll need to press it twice to confirm.</p>
<p>While it’s nice to know Node can perform basic arithmetic and string concatenation, its value to us as developers is in running programs. You can see an example of one such program, a basic web server, on the project’s homepage. They suggest creating a file called <code>example.js</code> with this code:</p>
<pre><code>var http = require(’http’);
console.log(’Server running at http://127.0.0.1:1337/’);</code></pre>
<p>This makes use of only one module, the core module <code>http</code>. As you can probably guess, the <code>http</code> module contains all the basic stuff you need to serve a site over HTTP. Node contains a tightly edited collection of <a href="http://nodejs.org/api/">core modules</a> that provide things like event handlers, file system access, and abstractions for various network protocols. But just as you probably use a JavaScript library or framework to speed up and bulletproof development on the client side, for Node development beyond a simple &quot;Hello World&quot; you generally add other non-core modules using npm.</p>
<p>The <code>http</code> module does contain a <code>createServer</code> function, though, which is all you need to create a bare-bones web server. In the code above, once the server has been created, it listens to port 1337 on your local machine. When it receives a request, it sends back a text response.</p>
<p>One thing to note is that the work here is done in event handlers, as are most things in Node. The callback in <code>createServer()</code> handles a connection event, which occurs every time a new client contacts the server. To start this server, type <code>node example.js</code> in your terminal, and then open a browser to http://127.0.0.1:1337. This triggers the connection event, and you should see the message in the callback.</p>
<p>To obtain any serious value from a Node server—even one not intended to ever go to production—it’s best to get familiar with the modules in npm. There are thousands available, but those you’d need to create a basic web application are some of the oldest and most stable, so don’t feel obligated to research them all before getting started. One that definitely comes in handy for designing an application is <a href="http://expressjs.com/">Express</a>, an uncomplicated web application framework.</p>
<p>If you’re accustomed to installing open source projects by cloning a GitHub repository or downloading a zip file, you’ll probably enjoy npm. To install Express with npm, for example, go to your terminal or command line and type <code>npm install express</code>. As long as you’re online and have permission to write to your machine, this fetches all the code and assets Express needs to run, as well as any modules it has as dependencies. The first time you run npm from your working directory, all these elements will end up in a new <code>node_modules</code> subdirectory. Now the module is ready to be used in Node programs the same way we used <code>http</code>, via the <code>require</code> function.</p>
<h2>Designing applications</h2>
<p>The ideal use case for designing your application with Node is a single-page application in which the server mostly provides data, but Node is still useful for a more traditional site. Of course, you want to begin development with requirements defined as precisely as possible, but implementation tends to expose requirements you hadn’t considered, and some of those can have a considerable impact on your timeline. Even in a server-driven application where it may not be possible to reuse data structures and templates as-is, creating client-only versions helps test your assumptions about the data you need and how you’ll use it.</p>
<p>If you’re developing a single-page app, the justification is much easier. You’ll need to think about optimizing your communication with the server to require as few requests as possible, which means knowing how data should be packaged up by each server endpoint and how you’ll cache the data on receipt (if at all).</p>
<p>An advantage of having JavaScript on the server is that templates can be rendered by the same template engine on either the client or server side. This allows you to experiment on both sides and optimize for your situation. It’s also a timesaver to render the templates with JavaScript objects and consider only the way data must eventually be grouped (not how it&#8217;s stored in a database). Designing these groupings of data is the bulk of the work we can do with Node toward the end of what we traditionally consider application design.</p>
<p>Piecing together each page from disparate parts from all over the server is messy for an application in any language. Instead, whatever renders a page should have clear dependencies, and the result of each page or data request should combine those dependencies into a cohesive and sensibly organized unit.</p>
<p>If you’ve worked in a server-side framework in which a page or view is tied to a single object or model, and where additional data is imported and exposed in a different way, you probably understand how the alternative gets to be a nuisance. You’re probably also aware that the solution is a good view-model whose data is defined by each view, not the models that feed it. With this exercise, we aim to map out what goes in those view-models.</p>
<p>There’s a strong likelihood that your production server does not run JavaScript, so you may end up converting templates you produce in this design phase. You could attempt to mitigate this by choosing a template engine like <a href="http://mustache.github.io/">Mustache</a> with existing parsers for a huge list of languages. Or you might choose one with minimal logic available (I find that the only things I want for a truly flexible template are conditionals, loops, and partials) and the option of changing the delimiters around the template tags to agree with your server template language. I’d argue that the process of getting all the data correctly placed in your HTML is a lot more difficult than doing a find and replace on the end result, so creating a template in JavaScript that you can use easily is time well spent even if it can’t be parsed by your production server.</p>
<p>You could choose to design the UI of your pages using hard-coded mockup data first and add the template tags afterward, or you could start with a template and some mockup data ready to go in your Node server. Even though it’s an extra step, I find the former easier, because the latter tends to require extra shifting of the mockup data. Starting with hard-coded data lets me examine the finished mockup and see what kinds of &quot;objects&quot; are present (e.g., a user, an item for sale, or a status update). That helps me create a flexible object hierarchy in my data more easily. But you may be naturally amazing at creating object hierarchies, so, by all means, do what you feel.</p>
<p>Wherever you begin, hammering out your templates should give you an indication of which parts of each page are dynamic and which data each requires. If subsections of your pages are rendered separately because they’re reused on different parent pages or because they’re also rendered by the client, converting your markup to templates also allows you to find the right balance between never repeating code and having absurdly tiny templates.</p>
<h2>Real fake server interactions</h2>
<p>If you’ve created high-fidelity wireframes that run in a browser, you know the annoyance of having only parts of a page be interactive, since every click means having to create a new view (even if you have a series of items that share the same behavior when clicked). You also know about copying and pasting the same data into multiple places, and updating each of them separately if the manner of presenting data should change. Designing your app with a server behind it removes those frustrations.</p>
<p>With the support of a server, it’s not a problem if the same data shows up in different displays all over the workflow you’re designing. Since the data lives on your Node server, you can write it once and reuse it as many ways as you like. You still have to consider how you’ll move it from server to client, though. When a user clicks on one of many items in a list, will she be taken to a new page, or will more data appear inline? Is the former the non-JavaScript fallback for the latter? Working that out for your app will tell you which endpoints the server needs, and which parameters need to be sent to it in query strings, form posts, or URLs. It’ll also help define the API for those requests, telling anyone who might work on your production server which keys you expect to correspond to which pieces of data.</p>
<p>Having a server to work with is especially nice if you’re in the business of making asynchronous requests. Obviously, you can get your mockup data, which is excellent, but you can also lazy-load assets like templates or stylesheets to consume that data. Testing the process of getting data and assets to the client validates your assumptions about not only the way you’re packaging them, but how you’re storing and structuring them. And, of course, it means a lot less wasted client-side JavaScript.</p>
<h2>A mockup you can use</h2>
<p>The end result of all this should be that you’ve moved all the mockup pieces out of your client-side JavaScript and HTML. You have a Node server that might not match your production framework, but does have clear definitions of everything the client side expects to exist—possibly even all viewable in a single file. You have templates and client-side requests that may require substitutions, but also separate your data from everything else and are at minimum easily convertible to whatever format is needed for production.</p>
<p>Could you do the same with any other server under the sun? Absolutely. But if you already know JavaScript and aren’t aiming to become a server-side developer, it makes sense to use the skills you already have. Node makes that pretty easy, while also letting you dig as deeply as you want into more complex servers, should your ambitions change. It’s simple to get going and flexible to extend, making Node an awesome tool for designing applications.</p>
<p>Ready to take your new Node skills for a spin? In &ldquo;<a href="http://alistapart.com/article/node-at-work-a-walkthrough/">Node at Work: A Walkthrough</a>,&rdquo; I’ll take you through a live demo, and get specific about how to refine your own mockups.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/JIuRksQbUN4" height="1" width="1"/>[mehr]
<a href="https://github.com/rwldrn/idiomatic.js/" style="font-size: 18px;">» Principles of Writing Consistent, Idiomatic JavaScript</a><br><br>If you’re looking for a thorough JavaScript style guide for your team, <a href="https://twitter.com/rwaldron">Rick Waldron</a>’s <i>Principles of Writing Consistent, Idiomatic JavaScript</i> is a great place to start.<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/5CfpcP1kjcE" height="1" width="1"/>[mehr]
<a href="http://breakpoint-sass.com" style="font-size: 18px;">» Breakpoint: Really Simple, Organized, Media Queries with Sass</a><br><br>Breakpoint is a Compass extension designed to simplify the creation and management of media queries.<br><br><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/ztKNstcFdzo" height="1" width="1"/>[mehr]
<a href="http://www.unheap.com" style="font-size: 18px;">» Unheap: A Tidy Repository of jQuery Plugins</a><br><br>A nice-to-look-at, easy-to-use reference library of jQuery plugins.<br><br>℅ <a class="attribution-link" href="https://twitter.com/candicodeit/status/327429516530159617">@candicodeit</a><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/bR70__8AKxI" height="1" width="1"/>[mehr]
<p>Electronic books are on the rise everywhere. For some this threatens centuries-old traditions; for others it opens up new possibilities in the way we think about information exchange in general, and about books in particular. Hate it or love it: electronic books are with us to stay.</p>
<p>A <a href="http://libraries.pewinternet.org/2012/12/27/e-book-reading-jumps-print-book-reading-declines/">press release</a> issued by the <a href="http://www.pewinternet.org/">Pew Research Center’s Internet &amp; American Life Project</a> in December 2012 describes an upward trend in the consumption of electronic books. The trends are similar in the UK, China, Brazil, Japan, and other countries.</p><figure class="quote">
“…the number of Americans over age 16 reading eBooks rose in 2012 from 16 to 23 percent, while those reading printed books fell from 72 percent to 67. …the number of owners of either a tablet computer or e-book reading device such as a Kindle or Nook grew from 18% in late 2011 to 33% in late 2012. …in late 2012 19% of Americans ages 16 and older own e-book reading devices such as Kindles and Nooks, compared with 10% who owned such devices at the same time last year.” </blockquote>
<p>What does this mean for web professionals? Electronic books represent a market that&#8217;s powered by core web technologies such as HTML, CSS, and SVG. When you use EPUB, one of the primary standards for electronic books, you are creating a packaged website or application. <a href="http://www.idpf.org/epub/30/spec/epub30-overview.html">EPUB3</a> is at the bleeding edge of current web standards: it is based on HTML5, CSS2.1 with some CSS3 modules, SVG, OpenType, and WOFF. EPUB3’s embrace of scripting is sure to encourage the development of more interactivity, which is sought after in education materials and children’s books.</p>
<p>Recently W3C has been <a href="http://www.w3.org/2012/08/electronic-books/">working more closely</a> with digital publishers to find out what else the Open Web Platform must do to meet that industry’s needs.</p>
<p>One comment we’ve heard loud and clear is that people care deeply about centuries-old print traditions. For example, Japanese and Korean users have accepted that many websites display text horizontally, from left to right. While that may be ok for the web, when these users read a novel, they expect traditional layout: characters rendered vertically and from right to left. Japanese readers often find it more tiring to read a long text in any other way. To address these requirements, W3C is looking at the challenges that vertical layout poses for HTML, CSS, and other technologies; see for example <a href="http://www.w3.org/TR/css3-writing-modes/">CSS Writing Modes Module Level 3</a>.</p>
<p><a href="http://www.w3.org/TR/jlreq/">Requirement of Japanese Text Layout</a> summarizes the typesetting traditions and resulting requirements for Japanese. These traditions should eventually be reproduced on the web as well as in electronic books. In June, W3C will hold a digital publishing workshop in Tokyo on the specific issues surrounding <a href="https://www.w3.org/2013/06/ebooks/">internationalization and electronic books</a>.</p>
<p>We have also heard that the “page” paradigm—including notions of headers, footnotes, indexes, glossaries, and detailed tables of contents—is important when people read books of hundreds or thousands of pages. Web technology will need to reintegrate these UI elements smoothly; see for example the <a href="http://www.w3.org/TR/css3-page/">CSS Paged Media Module Level 3</a> (Joe Clark talked about <a href="http://alistapart.com/article/ebookstandards">paged media and the production of ebooks</a> in 2010, and Nellie McKesson <a href="http://alistapart.com/article/building-books-with-css3">gave us an update</a> in 2012). In September in Paris, W3C will hold a workshop on the <a href="http://www.w3.org/2012/12/global-publisher/"><i>creation</i> of electronic books</a> using web technologies. Note that both this and the Writing Modes Module are still drafts and need further work. That means now is the right time for the digital publishing community to have its voice heard!</p>
<p>In the realm of metadata, important to publishers, librarians, and archivists, the challenge is to agree on vocabulary (and there are many: Harvard&#8217;s <a href="http://hul.harvard.edu/ois/digproj/metadata-standards.html">reference to metadata standards</a> is only the tip of the iceberg). Pearson Publishing recently launched the <a href="http://www.w3.org/community/opened/">Open Linked Education Community Group</a> to examine creating a curated subset of Wikipedia data that can be used for tagging educational content.</p>
<p>Here are a few other places to look for activity and convergence:</p><ul>
<li>People take notes in books and highlight text. Most ebook readers these days have built-in support for these features, but they are not widely deployed on the web.</li>
<li>Today search engines tend to ignore electronic books; I expect that will not remain the case for long.</li>
<li>“Offline mode” in web technology is still difficult to use if you try to access more than a single page of a site. Since an ebook is quite often a packaged website, ebook offline mode will need to improve to support browsing.</li>
<li>ebooks business models are likely to drive new approaches to monetization, some of which may be found in native mobile environments but not yet on the web.</li>
<p>Although publishing has some specific requirements not common to the web generally, I think that the distinction between a website (or app) and an ebook will disappear with time. As I have <a href="http://ivan-herman.name/2013/02/22/browsers-and-ebook-readers/">written before</a>, both will demand high-quality typography and layout, interactivity, linking, multimedia, offline access, annotations, metadata, and so on. Digital publishers’ interest in the Open Web Platform is a natural progression of their embrace of the early web.<br /></p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/9z7R6z4TcQk" height="1" width="1"/>[mehr]
<a href="http://fourkitchens.com/blog/2013/04/24/one-less-jpg" style="font-size: 18px;">» One Less JPG</a><br><br>Before you go worrying about how to minify every last library or shave tests out of Modernizr, try and see if you can remove just one photo from your design. It will make a bigger difference.<br><br>℅ <a class="attribution-link" href="https://twitter.com/rupl/status/327129473927479297">@rupl</a><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/QnwiFbhSAyQ" height="1" width="1"/>[mehr]
<p>In this 60-minute video from An Event Apart Boston, Scott Berkun tackles designer disempowerment. He discusses how power actually works, and why developing salesmanship skills is a must, even if your job isn&#8217;t public-facing.</p>
<iframe src="http://player.vimeo.com/video/63902503?title=0&amp;byline=0&amp;portrait=0" style="width: 696px; height: 391px;" frameborder="0" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>
</figure><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/qzM5KtOqHhM" height="1" width="1"/>[mehr]
<p>Last month, a U.S. District Court handed down a decision that’s pretty awful if you care about consumer rights and digital content.</p>
<p>It all started in 2011, when a company called ReDigi launched a service to let folks resell their unwanted iTunes purchases—the digital equivalent of unloading your old vinyl at a swap meet. This annoyed the legal department at Capitol Records enough that they sued ReDigi in federal court to stop it. Unfortunately for consumers, Capitol Records succeeded. This isn’t just bad news for ReDigi though. What’s really troubling is the court’s take on current copyright protections.</p>
<h2>The ReDigi case</h2>
<p>When it comes to the CDs, DVDs, and paper books you own, U.S. law is clear. A legal concept called the <a href="http://en.wikipedia.org/wiki/First-sale_doctrine">first-sale doctrine</a> establishes your right to sell them to another person, provided you&#8217;re handing over the item you originally bought, and that you didn’t make any copies. That&#8217;s the idea behind garage sales, swap meets, and Craigslist. As repeated by <a href="http://www.scribd.com/doc/133450332/Capitol-Records-v-ReDigi-Judgment">the court’s own decision</a> in the ReDigi case, first-sale doctrine states:</p>
<figure class="quote"><blockquote><p>“The owner of a particular copy or phonorecord lawfully made&#x2026;, or any person authorized by such owner, is entitled, without the authority of the copyright owner, to sell or otherwise dispose of the possession of that copy or phonorecord.”</p>
<p>That “owner” is you. The “copyright owner” is the record label, movie studio, or publisher. They make it. You buy it. You can sell it to somebody else if you don’t want it anymore. Simple. But according to this court, you don’t have that right if you send that movie, song, or book over an electronic network when you resell it.</p>
<p>Wait a minute. How’d that happen?</p>
<p>In the district court’s view, any transfer that takes place via the internet creates a reproduction of the work on the receiving machine, a new physical object that is “embodied” on the buyer’s hard drive. And that constitutes an illegal copy. In the judge’s own words:&nbsp; <br />
<!-- CMOS 13.16 In some legal writing, textual commentary, and other contexts, it is considered obligatory to indicate any change in capitalization by brackets. This is the reason David used brackets; no doubt it's not obligatory for ALA, but... --></p><figure class="quote"><blockquote><p>[W]hen a user downloads a digital music file or “digital sequence” to his “hard disk,” the file is “reproduce[d]” on a new phonorecord within the meaning of the Copyright Act. Id.</p>
<p>This understanding is, of course, confirmed by the laws of physics. It is simply impossible that the same “material object” can be transferred over the Internet. Thus, logically,&#x2026; the Internet transfer of a file results in a material object being “created elsewhere at its finish.”</p>
</blockquote></figure><!-- Escaped ellipsis because I wasn't sure if the key combo I knew (opt-semicolon) was creating a French suspension point or an ellipsis. -->
<p>Yeah, you read that right. According to this decision, electronic transfers generate a new “material object” on the receiving device. In legal terms, that’s a copy, and a violation of copyright law.</p>
<p>Even when products like ReDigi’s take reasonable measures to remove the file from the seller’s hard drive as it’s transferred, the court says it doesn’t count. Because I can’t physically hand you the original item over an electronic network, they say all bets are off.</p>
<h2>The implications</h2>
<p>This creates a world where we’re barred from ever transferring digital goods we own to another person if we use an electronic network. Insert internet, lose first-sale rights. The <a href="http://www.techdirt.com/articles/20080508/1119441065.shtml">jury is still out</a> on whether this interpretation really works from a legal standpoint. The scope of court decisions on copyright are typically papercut-narrow and excruciatingly literal. But the U.S. District Court for the Southern District of New York isn’t really the one causing all the trouble here. The main culprit is the law itself.</p>
<p>The copyright law at play in <i>Capitol Records v ReDigi</i> <!-- Should it be a cite? --> predates the digital world by decades, and still talks about usage rights strictly in terms of “material objects.” It doesn’t recognize a difference between photocopying a printed book and reconstructing one from a set of bit-flipping instructions. The letter of the law hasn’t caught up with the reality we live in. Right now it’s Zoolander smashing a tangerine iMac, hoping a bunch of paper files spill out.</p>
<p>That might not seem like a big deal now. But outdated laws aren’t just discordant with the times, they’re minefields filled with unintended consequences. Just think about your web browser. Anyone want to chat with the district court about the “material objects” a typical browser cache leaves on your hard drive? Unless you feel like upending some of the basic mechanics of the internet, I’d rather you didn&#8217;t.</p>
<p>And what happens as we shift to a future where the majority of our access to content is digital? Will we see the shuttering of all secondary resale markets? Who gains and who loses from that? If I can’t transfer the digital goods I own over the network, what happens when I die? Will my executor have to ship my hard drive to my next of kin because she couldn’t transmit its contents to them without risking legal action?</p>
<h2>Fixing this mess</h2>
<p>So far we’ve largely ducked these questions by letting content companies push us toward rental/lease models online, where we constantly pay and repay for content without enjoying full rights of ownership. That’s okay for some things. But by ignoring the bigger picture on ownership, we leave ourselves open to even further reductions in the consumer rights we’ve enjoyed for decades on movies, music, and books. We need to avoid a world where the only right we have left is the right of refusal.</p>
<p>Fixing the language of creaky old laws takes legislators, not courts. But we can do better than just petition Congress to drag copyright into the current century. We can set the standard ourselves. As entrepreneurs, developers, and technologists building products around digital content, we can incorporate progressive terms into our services. We can choose to grant users better rights than current law permits by default. We don’t have to sit around waiting for the next ReDigi case to tell us how to treat our customers. We can, and should, do better than that.</p>
<p>The first-sale doctrine needs to be defended in the digital space. We need acceptable, liveable standards for ownership of digital goods, and we can start building them now.</p><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/zFA4cDzzVJY" height="1" width="1"/>[mehr]
<a href="http://blog.forecast.io/its-not-a-web-app-its-an-app-you-install-from-the-web/" style="font-size: 18px;">» It’s not a web app. It’s an app you install from the web</a><br><br>The makers of Forecast.io struggle to explain the concept of "installing" web apps. (Spoiler: They succeed.)<br><br>℅ <a class="attribution-link" href="https://twitter.com/paul_irish/status/322762200466989056">@paul_irish</a><img src="http://feeds.feedburner.com/~r/alistapart/main/~4/LU3yUq7Uwoo" height="1" width="1"/>[mehr]
In an email to the WHATWG mailing list Ian Hickson explained how the relationship between the WHATWG and W3C effort around HTML has evolved. It is recommended reading if you want to know the details. In summary, we will remain focused on improving HTML and related technologies to address the needs of users, developers, and [...][mehr]
(Quelle: The WHATWG Blog)
A new release of the Validator.nu HTML Parser is available. The new version 1.4 contains minor adjustments to spec compliance and fixes for notable Java-specific problems (of the crash and infinite loop sort). Also, the parser is again available from the Maven Central Repository (groupId: nu.validator.htmlparser, artifactId: htmlparser, version: 1.4). Upgrading to the newest version [...][mehr]
I apologize for the longer than expected wait for this article, but now, we may continue. The article below will pick up where Part 1 left off. Article 1: Websites and SectioningPart 2: Styling &#60;warning&#62;Warning: This article discusses the topic of &#60;semantics&#62;semantics&#60;/semantics&#62;&#60;/warning&#62; As we began with previously, we now have the basics down as to [...][mehr]
Like probably many others who read this blog, I am a web design enthusiast, web standards advocate, and web designer by trade. I have been working with HTML since the early 2000s, and have enjoyed it ever since. Over the years, the web has evolved around me. I have watched it grow and adapt. And [...][mehr]
The WHATWG now has a patent policy, the WHATCG. We will keep using the same mailing list, the same IRC channel, the same web sites, but now sometimes we will publish through the WHATCG as well for patent policy purposes per the W3C Community Final Specification Agreement. If you could previously not join the WHATWG [...][mehr]
WHATWG Weekly: Fullscreen dialog
Ian Hickson made a proposal to unify Web Intents with registerProtocolHandler() and registerContentHandler(). The Encoding Standard now has all its decoders defined. This is the WHATWG Weekly. The big news this week is the new dialog element. Introduced in revision 7050, along with a new global attribute called inert, a new form element method attribute [...][mehr]
The StringEncoding proposal is getting closer to consensus. It now consists of a TextEncoder and a TextDecoder object that can be used both for streaming and non-streaming use cases. This is the WHATWG Weekly. Some bad news for a change. It may turn out that the web platform will only work on little-endian devices, as [...][mehr]
Jonas Sicking proposed an API for decoding ArrayBuffer objects as strings, and encoding strings as ArrayBuffer objects. The thread also touched on a proposal mentioned here earlier, StringEncoding. This is the mid-March WHATWG Weekly. Revision 7023 added the Path object to HTML for use with the canvas element, and the next revision made it possible [...][mehr]
Apple's Safari team provided feedback to the Web Notifications Working Group. That group, incidentally, is looking for an active editor to address that and other feedback. Opera Mobile shipped with WebGL support. This is March's first WHATWG Weekly. Simon Pieters overhauled much of HTML5 differences from HTML4 and the document now provides information on added/changed [...][mehr]
A draft for the SPDY protocol has been submitted, the W3C HTML WG mailing list goes crazy over media DRM. This is the WHATWG Weekly. In response to feedback Adam Barth changed the getRandomValues() method to return the array the method modifies. The method is part of the window.crypto proposal. Ian Hickson has been busy [...][mehr]
Die Barrierefreiheit von Webseiten wird in Deutschland durch die &#8220;Barrierefreie Informationstechnik-Verordnung&#8221;, kurz BITV geregelt. Wenngleich sich der Wirkungsbereich nur auf Seiten von Behörden erstreckt, hat die BITV auch eine große Bedeutung für Unternehmensseiten bekommen. Die BITV ist naturgemäß stellenweise abstrakt, ähnlich wie die verwandten englischen Texte des W3C. Um die Verständlichkeit zu erhöhen, haben wir [...][mehr]
(Quelle: blog.linkwerk.com » edition W3.de)
BITV auf <edition W3.de>
Als Ergänzung zu den Zugänglichkeitsrichtlinien für Web-Inhalte
steht ab heute auch die BITV
(Quelle: <edition W3.de> Neuigkeiten)
Dem im März 2009 erschienenen Internet Explorer 8 wurde von Anfang an eine bessere Unterstützung von Webstandards bescheinigt. Wer Websites macht, wird das bestätigen können. Wer allerdings Javascript-Bibliotheken entwickelt, die von anderen auf ihren Seiten eingesetzt werden sollen, kann ein anderes Bild bekommen. Mit dem IE6 hat Microsoft die Unterscheidung in &#8220;Quirks Mode&#8221; und &#8220;Standard [...][mehr]
Am 3. Dezember hat die Ecma die Verabschiedung von ECMAScript5 bekanntgegeben. Im Gegensatz zu manch anderem Standardisierungsgremium, bietet die Ecma ihre Standards kostenfrei zum Download auf der Webseite an: Für ECMAScript siehe Ecma-262. ECMAScript ist die standardisierte Form von Javascript und damit ein wichtiger Baustein für die Weiterentwicklung des Web. Über die wichtigsten neuen Features [...][mehr]
Einmal mehr dürfen wir uns über Bestnoten für unseren XSLT-Workshop freuen. In der vergangenen Woche haben wir eine XSLT-Schulung für einen neuen Kunden durchgeführt. Die Kundenbewertungen auf den Feedbackbögen zeichnet uns und unsere Leistung aus. In allen Punkten, von &#8220;Inhalt&#8221; über &#8220;Präsentation&#8221; und &#8220;Übungen&#8221; bis zur &#8220;Gesamtbewertung&#8221; bekommen wir sehr gute Noten. Darüber hinaus sagen [...][mehr]
Relaunch von <edition W3.de>
Heute geht eine überarbeitete Version der <edition W3.de> online.
Zum Jahresende wird die Verabschiedung von EcmaScript 5 erwartet. In der aktuellen Ausgabe der iX schreibe ich über die wichtigsten neuen Features. Für alle Leser des Artikels oder diejenigen, die sich selbst einen Eindruck verschaffen möchten, stelle ich im Folgenden die Quellen zusammen. Wikipedia: ECMAScript Allen Wirfs-Brock: Steps Toward Creating Compatible ECMAScript 5 Implementations Allen [...][mehr]
Heute habe ich bei der Arbeit mit einer XSLT-Engine an meinem Verstand gezweifelt. Die Aufgabe war einfach: Ein kleines Verarbeitungsskript für eine Webseite. Doch leider brach die Verarbeitung immer ab, weil der XSLT-Interpreter die DTD nicht vom Server des W3C laden konnte. Natürlich sollte man besser eine lokale DTD verwenden, dennoch war es überraschend, dass [...][mehr]
Die ursprüngliche Idee der Adressen im Web beinhaltet auch, dass man über eine Adressangabe eine Seite finden kann. Schließlich heißt der Fachbegriff nicht umsonst URI &#8212; Uniform Resource Identifier. Es gibt aber zahlreiche Beispiele, bei denen das nicht der Fall ist. Oft sind Session-IDs, Query-Parameter oder andere temporäre Informationen in der Adresse enthalten. Die machen [...][mehr]
Es ist schön zu sehen, dass Semantic Web Technologien zunehmend zum Thema werden. Jüngster Zuwachs im Bereich der Semantic Web Community ist wohl semanticoverflow.com, eine Seite die sich ganz im stile ihres grossen Bruders stackoverflow.com der Aufgabe widmet Fragen rund um das Thema Semantic Web Community-basiert zu beantworten. Ich wünsche der Seite zumindest vergleichbaren Erfolg [...][mehr]
Na ja, ganz so weit ist es noch nicht. Aber sollte ich mal einen persönlichen, autonomen und wirklich intelligenten Software-Agenten mein Eigen nennen, könnte er ja auch mal Angst haben, sich überlastet oder ausgebrannt fühlen. Das W3C arbeitet jedenfalls schon mal an der passenden Auszeichnungssprache: EmotionML. Wer jetzt glaubt, die Initiative sei genauso sinnvoll wie [...][mehr]
&#8230;und der ein oder andere mag sich fragen, was ist &#8220;GeoCities&#8221;? In der Frage ist zumindest die Antwort auf die Frage zu finden, weshalb Yahoo die Site dicht macht. &#8220;Wow, eine geschlossene Website, das ist&#8217;n Blogartikel wert!&#8221; &#8212; Die Tatsache ist wohl nicht bemerkenswert, allerdings ist der Artikel der L.A. Times lesenswert für alle, die [...][mehr]