&lt;p&gt;The &lt;a href="http://www.w3.org/2002/mmi/"&gt;Multimodal Interaction Working Group.&lt;/a&gt; has published a Candidate Recommendation of &lt;a href="http://www.w3.org/TR/2012/CR-emotionml-20120510/"&gt;Emotion Markup Language (EmotionML) 1.0&lt;/a&gt;. As the web is becoming ubiquitous, interactive, and multimodal, technology needs to deal increasingly with human factors, including emotions. The specification of Emotion Markup Language 1.0 aims to strike a balance between practical applicability and scientific well-foundedness. The language is conceived as a "plug-in" language suitable for use in three different areas: (1) manual annotation of data; (2) automatic recognition of emotion-related states from user behavior; and (3) generation of emotion-related system behavior.&lt;/p&gt; &lt;p&gt;The group also published &lt;a href="http://www.w3.org/TR/2012/NOTE-emotion-voc-20120510/"&gt;Vocabularies for EmotionML&lt;/a&gt;, a Working Group Note.&lt;/p&gt; &lt;p&gt;Learn more about the &lt;a href="http://www.w3.org/2002/mmi/Activity.html"&gt;Multimodal Interaction Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt;W3C is pleased to announce that &lt;a href="http://www.w3techcourses.com/course/view.php?id=21"&gt;registration&lt;/a&gt; is open for a new edition of the W3C online course &lt;a href="http://www.w3devcampus.com/writing-great-web-applications-for-mobile/"&gt;"Mobile Web 2: Programming Web Applications"&lt;/a&gt;. Developed by the &lt;a href="http://www.mobiwebapp.eu/"&gt;W3C/MobiWebApp&lt;/a&gt; team and taught by &lt;a href="http://www.w3devcampus.com/marcos-caceres/"&gt;Marcos Caceres&lt;/a&gt;, this course gives developers all the tools and knowledge necessary to write mobile Web applications that can ship both online and in application stores, using today's advanced technologies. The 6-week course begins 11 June. An early bird rate of 195 Euros is available until 25 May; after that date the full price is 225 Euros so &lt;a href="http://www.w3techcourses.com/course/view.php?id=21"&gt;register now&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt;The &lt;a href="http://www.w3.org/2008/geolocation/"&gt;Geolocation Working Group&lt;/a&gt; has published a Proposed Recommendation of &lt;a href="http://www.w3.org/TR/2012/PR-geolocation-API-20120510/"&gt;Geolocation API Specification&lt;/a&gt;. This specification defines an API that provides scripted access to geographical location information associated with the hosting device. Comments are welcome through 10 June. Learn more about the &lt;a href="http://www.w3.org/2007/uwa/"&gt;Ubiquitous Web Applications Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt; &lt;a class='imageLink' href="http://www.w3.org/2012/ldp/"&gt;&lt;img src="http://www.w3.org/Icons/SW/sw-cube.png" alt="Semantic Web Cube"/&gt;&lt;/a&gt; Today W3C launched the new &lt;a href="http://www.w3.org/2012/ldp/"&gt;Linked Data Platform (LDP) Working Group&lt;/a&gt; to promote the use of linked data on the Web. Per its &lt;a href="http://www.w3.org/2012/ldp/charter.html"&gt;charter&lt;/a&gt;, the group will explain how to use a core set of services and technologies to build powerful applications capable of integrating public data, secured enterprise data, and personal data. The platform will be based on proven Web technologies including HTTP for transport, and RDF and other Semantic Web standards for data integration and reuse. The group will produce supporting materials, such as a description of uses cases, a list of requirements, and a test suite and/or validation tools to help ensure interoperability and correct implementation. Learn more about the &lt;a href="http://www.w3.org/2001/sw/"&gt;Semantic Web&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt; &lt;a class="imageLink" href="/community/"&gt;&lt;img style="width: 55px; height: 71px;" src="http://www.w3.org/community/src/img/community-group-logo.png" alt="Community and Business Groups" height="71" width="55"/&gt;&lt;/a&gt; W3C announced today that eight months after the &lt;a href="http://www.w3.org/2011/08/cg-pr.html"&gt;launch&lt;/a&gt; of &lt;a href="/community/"&gt;Community Groups&lt;/a&gt; to speed Web innovation, more than 1200 people are participating in &lt;a href="/community/groups/"&gt;80 groups&lt;/a&gt; with wide-ranging interests, including mobile profiles, Web games, and big data. "We wanted to encourage richer and more diverse conversations about Web technology at W3C, and we are off to a great start," said &lt;a href="/People/Jeff/"&gt;Jeff Jaffe&lt;/a&gt;, W3C CEO. "A number of design choices (such as the &lt;a href="http://www.w3.org/community/about/agreements/summary/"&gt;permissive copyright license&lt;/a&gt;) have made this an appealing work environment to important stakeholders. The program is young but promising, and will continue to improve as we learn from our community."&lt;/p&gt; &lt;p&gt;The W3C Membership, which convenes next week at its semi-annual meeting, plays a preeminent role both in Community Groups and in turning innovations into interoperable, Royalty-Free Web standards through an open consensus process. Open Web Platform traction has resulted in more than 80 organizations becoming &lt;a href="/Consortium/Member/List"&gt;W3C Members&lt;/a&gt; in the past year. Read the full &lt;a href="http://www.w3.org/2012/04/membership2012.html.en"&gt;press release&lt;/a&gt; and &lt;a href="http://www.w3.org/2012/04/membership2012-testimonials"&gt;testimonials from some new W3C Members&lt;/a&gt; and learn &lt;a href="/community/about/"&gt;more about W3C Community and Business Groups&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt;The &lt;a href="http://www.w3.org/2009/dap/"&gt;Device APIs Working Group&lt;/a&gt; invites implementation of the Candidate Recommendations of &lt;a href="http://www.w3.org/TR/2012/CR-battery-status-20120508/"&gt;Battery Status API&lt;/a&gt; and &lt;a href="http://www.w3.org/TR/2012/CR-vibration-20120508/"&gt;Vibration API&lt;/a&gt;. The first defines an API that provides information about the battery status of the hosting device. The second defines an API that provides access to the vibration mechanism of the hosting device. W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. Learn more about the &lt;a href="http://www.w3.org/2007/uwa/"&gt;Ubiquitous Web Applications Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt;The &lt;a href="http://www.w3.org/2010/webperf/"&gt;Web Performance Working Group&lt;/a&gt; has published two Last Call Working Drafts: &lt;a href="http://www.w3.org/TR/2012/WD-performance-timeline-20120508/"&gt;Performance Timeline&lt;/a&gt; and &lt;a href="http://www.w3.org/TR/2012/WD-user-timing-20120508/"&gt;User Timing&lt;/a&gt;. The first defines an unified interface to store and retrieve performance metric data. The second defines an interface to help web developers measure the performance of their applications by giving them access to high precision timestamps. Comments are welcome through 07 June. Learn more about the &lt;a href="http://www.w3.org/2006/rwc/"&gt;Rich Web Client Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt;The &lt;a href="http://www.w3.org/2010/02/rdfa/"&gt;RDF Web Applications Working Group&lt;/a&gt; has published three Proposed Recommendations for &lt;a href="http://www.w3.org/TR/2012/PR-rdfa-core-20120508/"&gt;RDFa Core 1.1&lt;/a&gt;, &lt;a href="http://www.w3.org/TR/2012/PR-rdfa-lite-20120508/"&gt;RDFa Lite 1.1&lt;/a&gt; and &lt;a href="http://www.w3.org/TR/2012/PR-xhtml-rdfa-20120508/"&gt;XHTML+RDFa 1.1&lt;/a&gt;.&lt;/p&gt; &lt;p&gt;Together, these documents outline the vision for RDFa in a variety of XML and HTML-based Web markup languages. RDFa Core 1.1 specifies the core syntax and processing rules for RDFa 1.1 and how the language is intended to be used in XML documents. RDFa Lite 1.1 provides a simple subset of RDFa for novice web authors. XHTML+RDFa 1.1 specifies the usage of RDFa in the XHTML markup language. The group also published a draft of the &lt;a href="http://www.w3.org/TR/2012/WD-rdfa-primer-20120508/"&gt;RDFa 1.1 Primer&lt;/a&gt; today.&lt;/p&gt; &lt;p&gt;Learn more about the &lt;a href="http://www.w3.org/2001/sw/"&gt;Semantic Web Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt;The &lt;a href="http://www.w3.org/Style/CSS/members"&gt;Cascading Style Sheets (CSS) Working Group&lt;/a&gt; published Working Drafts of &lt;a href="http://www.w3.org/TR/2012/WD-css3-exclusions-20120503/"&gt;CSS Exclusions and Shapes Module Level 3&lt;/a&gt; and &lt;a href="http://www.w3.org/TR/2012/WD-css3-regions-20120503/"&gt;CSS Regions Module Level 3&lt;/a&gt;. Exclusions and Shapes lets people define arbitrary areas around which inline content content can flow. CSS Exclusions extend the notion of content wrapping previously limited to floats. The CSS regions module allows content to flow across multiple areas called regions. The regions are not necessarily contiguous in the document order. Learn more about the &lt;a href="http://www.w3.org/Style/"&gt;Style Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt;The &lt;a href="http://www.w3.org/2011/prov/"&gt;Provenance Working Group&lt;/a&gt; published 5 Working Drafts today related to the PROV data model. Provenance information can be used for many purposes, such as understanding how data was collected so it can be meaningfully used, determining ownership and rights over an object, making judgments about information to determine whether to trust it, verifying that the process and steps used to obtain a result complies with given requirements, and reproducing how something was generated. The PROV model is used to represent provenance records, which contain descriptions of the entities and activities involved in producing and delivering or otherwise influencing a given object.&lt;/p&gt; &lt;ul class="show_items"&gt; &lt;li&gt;&lt;a href="http://www.w3.org/TR/2012/WD-prov-dm-20120503/"&gt;PROV-DM: The PROV Data Model&lt;/a&gt; introduces the provenance concepts found in PROV and defines PROV-DM types and relations. &lt;/li&gt; &lt;li&gt;&lt;a href="http://www.w3.org/TR/2012/WD-prov-constraints-20120503/"&gt;Constraints of the Provenance Data Model&lt;/a&gt; introduces a further set of concepts useful for understanding the PROV data model and defines inferences that are allowed on provenance statements and validity constraints that PROV instances should follow. These inferences and constraints are useful for readers who develop applications that generate provenance or reason over provenance. (First Public Working Draft)&lt;/li&gt; &lt;li&gt;&lt;a href="http://www.w3.org/TR/2012/WD-prov-n-20120503/"&gt;PROV-N: The Provenance Notation&lt;/a&gt; allows serializations of PROV instances to be created in a compact manner. (First Public Working Draft)&lt;/li&gt; &lt;li&gt;&lt;a href="http://www.w3.org/TR/2012/WD-prov-o-20120503/"&gt;PROV-O: The PROV Ontology&lt;/a&gt; expresses the PROV Data Model using the OWL2 Web Ontology Language (OWL2).&lt;/li&gt; &lt;li&gt;&lt;a href="http://www.w3.org/TR/2012/WD-prov-primer-20120503/"&gt;PROV Model Primer&lt;/a&gt; provides an intuitive introduction and guide to the PROV specification for provenance on the Web.&lt;/li&gt; &lt;/ul&gt; &lt;p&gt;Learn more about the &lt;a href="http://www.w3.org/2001/sw/"&gt;Semantic Web Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt;The W3C Advisory Committee has filled six open seats on the &lt;a href="/2002/ab/"&gt;W3C Advisory Board&lt;/a&gt;. Created in 1998, the Advisory Board provides guidance to the Team on issues of strategy, management, legal matters, process, and conflict resolution. Beginning 1 July 2012, the nine Advisory Board participants are Ann Bassetti (Boeing), Jim Bell (HP), Michael Champion (Microsoft), Steve Holbrook (IBM), Qiuling Pan (Huawei), Jean-Charles Verdié (MStar Semiconductor), Ora Lassila (Nokia), Charles McCathieNevile (Opera), and Takeshi Natsuno (Keio University). Steve Zilles continues as interim Advisory Board Chair. Read more about the &lt;a href="/2002/ab/"&gt;Advisory Board&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt;The &lt;a href="http://www.w3.org/2008/webapps/"&gt;Web Applications Working Group&lt;/a&gt; invites implementation of two Candidate Recommendations:&lt;/p&gt; &lt;ul class="show_items"&gt; &lt;li&gt;&lt;a href="http://www.w3.org/TR/2012/CR-workers-20120501/"&gt;Web Workers&lt;/a&gt;, which defines an API that allows Web application authors to spawn background workers running scripts in parallel to their main page. This allows for thread-like operation with message-passing as the coordination mechanism.&lt;/li&gt; &lt;li&gt;&lt;a href="http://www.w3.org/TR/2012/CR-webmessaging-20120501/"&gt;HTML5 Web Messaging&lt;/a&gt;, which defines two mechanisms for communicating between browsing contexts in HTML documents.&lt;/li&gt; &lt;/ul&gt; &lt;p&gt;Learn more about the &lt;a href="http://www.w3.org/2006/rwc/"&gt;Rich Web Client Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt;The &lt;a href="http://www.w3.org/2001/sw/DataAccess/"&gt;SPARQL Working Group&lt;/a&gt; published three Last Call Working Drafts today:&lt;/p&gt; &lt;ul class="show_items"&gt; &lt;li&gt;&lt;a href="http://www.w3.org/TR/2012/WD-sparql11-overview-20120501/"&gt;SPARQL 1.1 Overview&lt;/a&gt;, which provides an introduction to a set of W3C specifications that facilitate querying and manipulating RDF graph content on the Web or in an RDF store.&lt;/li&gt; &lt;li&gt;&lt;a href="http://www.w3.org/TR/2012/WD-sparql11-http-rdf-update-20120501/"&gt;SPARQL 1.1 Graph Store HTTP Protocol&lt;/a&gt;, which describes the use of HTTP operations for the purpose of managing a collection of RDF graphs in the REST architectural style.&lt;/li&gt; &lt;li&gt;&lt;a href="http://www.w3.org/TR/2012/WD-sparql11-results-csv-tsv-20120501/"&gt;SPARQL 1.1 Query Results CSV and TSV Formats&lt;/a&gt;, which describes the use of CSV(comma separated values) and TSV (tab separated values) for expressing SPARQL query results from SELECT queries.&lt;/li&gt; &lt;/ul&gt; &lt;p&gt;Comments are welcome through 01 June.&lt;/p&gt; &lt;p&gt;The group is further planning to shortly release a 2nd Last Call working draft of the SPARQL 1.1 Query Language, after which we plan to advance all Recommendation track drafts in the next iteration to Proposed Recommendation directly. To this end, the group is currently gathering implementation reports and would appreciate reports from the community of implementations of any of the SPARQL1.1 specifications. Learn more about the &lt;a href="http://www.w3.org/2001/sw/"&gt;Semantic Web Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt;The &lt;a href="http://www.w3.org/Style/CSS/members"&gt;Cascading Style Sheets (CSS) Working Group&lt;/a&gt; has published a Working Draft of &lt;a href="http://www.w3.org/TR/2012/WD-css3-writing-modes-20120501/"&gt;CSS Writing Modes Module Level 3&lt;/a&gt;. CSS Writing Modes Level 3 defines CSS features to support for various international writing modes, such as left-to-right (e.g. Latin or Indic), right-to-left (e.g. Hebrew or Arabic), bidirectional (e.g. mixed Latin and Arabic) and vertical (e.g. Asian scripts). Learn more about the &lt;a href="http://www.w3.org/Style/"&gt;Style Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

&lt;p&gt;The &lt;a href="http://www.w3.org/International/core/"&gt;Internationalization Core Working Group&lt;/a&gt; has published a Working Draft of &lt;a href="http://www.w3.org/TR/2012/WD-charmod-norm-20120501/"&gt;Character Model for the World Wide Web 1.0: Normalization&lt;/a&gt;. This Architectural Specification provides authors of specifications, software developers, and content developers with a common reference on the use of normalization of text and string identity matching on the Web. The goal of this specification is to improve interoperable text manipulation on the World Wide Web. Learn more about the &lt;a href="http://www.w3.org/International/"&gt;Internationalization Activity&lt;/a&gt;.&lt;/p&gt; </content>

by W3C Staff at May 20, 2012 03:00 AM

With the debut of Vert.x, the asynchronous framework is reaching an inflection point, suggests Andrew Cholakian. With Vert.x, the software is packaged together in such a way as to be extremely practical, he states. For some JVM zealots, Vert.x may meet needs recently and apparently addressed by node.js.

Vert.x is an asynchronous application server – which may prove useful as architects rethink the server’s role in a world of powerful clients. Does the JVM have a role going forward? Some might say ‘no’ to the JVM. Many say ‘Yes’. Some of these might say: “Vert. x could be described as Node.js+ for the JVM.”

But let us view some from the Cholakian post:

One might say that if all Vert.x consists of is Netty+Hazelcast, that it’s nothing revolutionary. The reality is that Vert.x gets the API right, which most of the existing JVM tools get very…. very… wrong. Even simple services in Netty takes large amounts of code, an inordinate of factories, providers, and threadpools must be created just to do simple things. Mixing all this up with languages like jruby is just prohibitively painful. APIs can be as hard to design as implementations are to write!

On top of the API, the other half of the secret sauce is in Vert.x’s leveraging of high performance implementations of Ruby, Javascript, and Groovy. By integrating them into a single Vert.x executable, they’ve given developers the ability to write high-performance code on the JVM without knowing much about the JVM or its ecosystem at all. Vert.x can run any of those languages directly. Furthermore, since Vert.x is just a library, any JVM language can leverage it. On top of that, the entire universe of JVM libraries, concurrency APIs, and tooling is available to developers.

Like all things, your mileage may differ. The blogger notes : This model is great for large numbers of sockets and file descriptors, where it makes the best use of resources. However, it’s very confusing and complicated when it comes to day to day business logic, where simple, blocking, threaded code is a welcome comfort.  Read all about it as Andrew VC goes through the Vert.X/Node.js ropes.

by jvaughan at May 19, 2012 02:00 AM

In the course of expanding my documentation of color values, I failed to find a table that listed all 147 SVG-and-CSS3-defined keywords along with the equivalent RGB decimal, RGB percent, HSL, hexadecimal, and (when valid) short-hex values. There were some tables that listed some but not all of those value types, and one that listed all the value types (plus CMYK) along with a few hundred other keywords, but none that listed all of the CSS keywords and value types. And none that I saw used precise values for the RGB percent and HSL types, preferring instead to round off at the expense of some subtle differences in color.

So I created my own table, which you can now find in the CSS area of meyerweb. Most of it is dynamically generated, taking a list of keywords and RGB decimal equivalents and then calculating the rest of the values from there. The presentation is still a work in progress, and may change a little or a lot. In particular, if I can't find a better algorithm for determining which rows should have white text instead of black, I'll probably shift away from the full-row background colors to some other presentation. (Update: it's been greatly improved, so I'm sticking with the full-row backgrounds. For now, anyway.)

My thanks to Tab Atkins for his donation of the RGB-to-HSL routine I adapted as well as help improving the pick-light-or-dark-text algorithm; and to the people who responded positively on Twitter when I mused about the idea there.

As always: share and enjoy!

by Eric Meyer at May 18, 2012 08:26 PM

As all widely used web browsers (unless you still consider IE7 as being widely used) now support the :before and :after pseudo-elements along with the content property, using those pseduo-elements has become more and more common.

There are many clever CSS tricks they can be used for, like implementing a particular design without having to insert extra markup into your HTML. There is one catch though, and many developers seem unaware of this: several screen readers will speak content that is created this way. VoiceOver does (in both OS X and iOS). NVDA does when used with Firefox, though not with IE. I made a CSS generated content demo page so you can try it yourself.

Read full post

Posted in Accessibility, CSS.

Copyright © Roger Johansson

by Roger Johansson at May 18, 2012 09:25 AM

The fact that this:

h1 {color: red;}
h1 {color: green;}

"¦results in green h1 text, but this:

h1 {background:
	url(red-wave.gif) repeat,
	url(green-wave.gif) repeat;}

"¦results in a red wavy h1 background does my head in every single time. And it's the same with text and box shadows, too! In cases where backgrounds or shadows overlap, the first one you write "wins"�, by virtue of being "in front of"� the background images that are listed after it.

I know that font stacks are also done in order of most-to-least preferred, but I don't see them as being equivalent. The reason is that a font stack is a list of fallbacks"”use this face unless it can't render the glyph or doesn't exist, in which case try the next one in the list, etc., etc. Multiple background images and multiple shadows, on the other hand, are not a series of fallbacks. I expect to see them all, unless I made a mistake of some kind; and I do, constantly, because of this disconnect. Sure, one could use the multiple background image syntax to create a series of fallbacks"”first an SVG file, second a PNG, third a GIF"”but that's not its primary purpose, and I certainly wouldn't teach multiple background images that way. That's not what they're designed to do.

Maybe writing the problem down here will purge this daemon, but in all honesty, my hopes are not terribly high.

by Eric Meyer at May 16, 2012 02:11 PM

I'm working my way through a rewrite of Two Salmon (more on that anon), and I just recently came to the ch unit. Its definition in the latest CSS Values and Units module is as follows:

ch unit

Equal to the advance measure of the “0″ (ZERO, U+0030) glyph found in the font used to render it.

"¦and that's it. I had never heard the term "advance measure"� before, and a bit of Googling for font "advance measure" only led me to copies of the CSS Values and Units module and some configuration files for the Panda 3D game engine. So I asked the editor and it turns out that "advance measure"� is a CSS-ism that corresponds to the term "advance width"�, which I had also never heard before but which yielded way more Google results. Wikipedia's entry for "Font"� has this definition:

Glyph-level metrics include "¦ the advance width (the proper distance between the glyph’s initial pen position and the next glyph’s initial pen position)"¦

My question for the font geeks in the room is this: is that the generally accepted definition for "advance width"�? If not, is there a better definition out there; and if so, where? I'd like to be able to recommend the best known definition for inclusion in the specification; or, if there's no agreement as to the best, then at least a good one. The Wikipedia definition certainly sounds good, assuming it's accurate. Is it?

In CSS terms, if I've understood things correctly, 1ch is equal to the width of the character box for the glyph for "0"�. In other words, if I were to create a floated element with just a "0"� and no whitespace between it and the element's open and close tags, then the float's width would be precisely 1ch. But that's if I've understood things correctly. If I haven't, I hope I'll be corrected soon!

by Eric Meyer at May 15, 2012 01:37 PM

Wow. Mobilism 2012 is done, and it was a lot more awesome than I thought. Not that I thought it would be a dud, but it’s always pleasant when your expectations are exceeded.

We have worked with this particular venue, A/V, catering, and wifi crew before, during Fronteers 2011, so we knew what to expect: good service all along, with a few moments of sheer brilliance.

Even better, the conference topic also resonated with the support crew. We already knew a few A/V technicians were web developers, and they paid rapt attention. One of the catering crew turned out to be fascinated, too, and even the security guy gave me his regarded opinion on the future of BlackBerry. You can’t lose when absolutely everybody is involved in this way.

The wifi, in particular, was excellent: Event Engineers once again made sure that there was a network that catered to the voracious bandwidth tastes of 350 mobile web developers forced into one building for two days. Their best moment came during Seb Lee-Delisle’s session, when his application connected to about 200 mobile devices in the audience while his session was simultaneously live-streamed over the wifi network. It all worked without a hitch.

And our speakers were awesome. All of them had something useful, interesting, and beautiful to share, and all of them kept the audience in a state of rapt attention. Time flies when you’re having fun; it hardly felt like two days. More like a few hours.

The free beer, too, was excellent. We found a new beer provider, and we’re very happy with it.

That’s not to say nothing went wrong: there were various hitches along the way. Fortunately nobody noticed.

So all in all Mobilism 2012 was a smashing success. So smashing, in fact, that halfway through day 2 I felt myself becoming more and more nervous — not because I was afraid that anything would go terribly wrong, but because I was uncertain whether we could keep up the very high quality until the very end. Fortunately we could, and our attendees were very happy.

We’re currently working on the coverage page, where you’ll eventually find all presentations, all videos, and a lot of blog posts.

And we will return. In May 2013. In Amsterdam. Besides, on 14th of September we’ll organise PhoneGap Day EU, a day full of PhoneGappy awesome. If you want to stay in the loop, subscribe to our newsletter, and we’ll send you Mobilism and PhoneGap Day news as soon as it becomes available.

Thanks to all who attended; and I hope those who didn’t attend kick themselves for missing an awesome conference.

May 15, 2012 01:19 PM

In about two hours, at 16:50 CET, Mobilism will live-stream the mobile browser panel.

Moderated by Jeremy Keith, the panel features representatives of BlackBerry, Opera, Nokia, and Google. Just like last year they will discuss the state of the mobile browsers.

So follow our live-stream for an update on the mobile browser world.

Incidentally, tomorrow we will live-stream our entire programme from 13:00-16:00, including the device/network API panel, Seb Lee-Delisle, and Jake Archibald. So tune in if you want to know what Mobilism is like.

May 10, 2012 01:39 PM

Most web developers who have viewed their work in an iOS device know that Safari for iOS likes to zoom in on the page and do weird things to font size when you change the device's orientation from portrait to landscape. A too common way to prevent that is to completely disable the user's ability to zoom, which you really do not want to do.

Luckily there is A Fix for the iOS Orientationchange Zoom Bug, a very clever one too. I've been using this in a few projects and have found it to work well. I have however run into a couple of issues (that in hindsight are pretty obvious) that I want to note here as a reminder to my future self.

Read full post

Posted in CSS, JavaScript, iOS.

Copyright © Roger Johansson

by Roger Johansson at May 09, 2012 06:49 PM

It may be that from the ashes of vendor prefixes will arise a new way forward. As proposed by François Remy, vendor tokens would serve the same basic purpose as prefixes with a different syntactical approach, and with at east a couple of extra benefits. Instead of prefixing properties, you'd instead add vendor tokens to the end of a single declaration, much as you do !important (which of course we never ever use, amirite?).

For example, you might write:

border-radius: 1em !webkit-draft !moz-draft !o-draft;

That's it. The prefixed alternative, of course, runs to multiple lines and has spawned a whole subindustry of framework plugins and mixins and what-all just to take the repetitive authoring burden off our shoulders.

I've been contemplating this proposal all morning, and perhaps not too surprisingly I've come down in favor of the idea. I'm on record as being a fan of vendor prefixes, but what I was truly a fan of was the capabilities they offer. The syntax was never a core interest for me, and the ugliness was pretty apparent. Vendor tokens are less tortuous, and even make it much simpler to build in versioning, like so:

border-radius: 1em !webkit-draft-2 !moz-draft !o-draft;

Not that I'm saying this proposal will or even should get to that point, but the ability is there and it feels cleaner than trying to do the same thing with prefixes. I feel they ought to drop the -draft part of the tokens; just saying !webkit !moz !o or possibly !x-webkit !x-moz !x-o should be sufficient. I'm also not a fan of the bang, but then I never have been, and I figure any token marker would suffice. As before, it's not the syntax I care about so much as the capabilities.

There is a discussion ongoing at www-style, if you're interested in adding your perspective or even just following along as various stakeholders thrash at the idea. I'm cautiously optimistic. It's kind of a nice feeling!

by Eric Meyer at May 08, 2012 05:55 PM

This is just a short reminder of something I wrote about in On using h1 for all heading levels in HTML5: make sure your HTML5 document outline is backwards compatible.

The reason is simple. Browsers and assistive technology haven't implemented the HTML5 outline algorithm yet (the only exception I'm aware of is JAWS, which gets it wrong, as Jason Kiss explains in JAWS, IE and Headings in HTML5).

Read full post

Posted in Accessibility, HTML 5.

Copyright © Roger Johansson

by Roger Johansson at May 02, 2012 06:43 PM

In eight days the Mobilism workshops will take place, and in nine days the main conference will start. If you plan on coming, now would be a good time to buy your ticket.

So far we have about 320 attendees who have decided our programme is good enough to come to Amsterdam for. And let’s face it, if your job involves the mobile web in any way you cannot afford to miss the sessions by Horace Dediu, Remy Sharp, Jason Grigsby, Stephen Hay, Scott Jenson, the browser panel and device/network API panels moderated by Jeremy Keith, and many more sessions that focus exclusively on the mobile web.

Also, you cannot afford to miss the mobile social event of the year: our beer-to-beer networking event on Thursday night, which is completely free for attendees. You'll also have a chance to chat with 300 other attendees about the mobile web, free beer, or anything in between.

Ticket sales will close in a week, next Tuesday, so that our administration has a chance to catch up on Wednesday. So you still have seven days and a bit to buy your ticket.

See you in eight days.

May 01, 2012 11:01 AM

Michael Mahemoff writes: To be effective, Rails cache sweepers need to be more fully understood.  They know no standard, so you must employ art. He goes on: Sweepers observe both your models and your controllers, but most workarounds focus on their controller nature.  Importantly: the sweeper must be explicitly added as an observer. Even more important is redux. Read all about [Rails cache sweeper redux] it.

by jvaughan at April 28, 2012 03:03 AM

I get asked from time to time for my number one tip for new parents. My answer is always a single word.

"Earplugs."�

Seriously. Get some earplugs. They don't have to be fancy; the squishy yellow foam plugs you can get in a cardboard holder for a dollar work just fine. If you already have some fancier in-ear jobs for rock concerts or woodworking or whatever, those are good too.

Because as much as you love your new baby, and as much as you will work to keep them calm and happy, there will almost certainly be times when they are hurting or uncomfortable or just generally upset and unable to be soothed. No matter how much you cuddle and sing and swaddle, they will scream and cry. Some kids will do this rarely. Others will do it all the time. (A friend of ours tells how her eldest child screamed more or less non-stop from the day she was born until the day she walked.) I don't honestly know which is harder to handle, but I do know that the screaming worked its way through my eardrums and into my brain to induce a panicked pseudo-flight-or-flight response. It was cumulatively, enormously stressful.

Earplugs do not shut out the cries completely. You will not be denying your baby's distress or placing unwarranted distance between you and your child. Earplugs simply take the raw, serrated edge off their cry, giving you some mental space to cope with it and be a calmer and therefore better parent. It lets you hang in there longer, putting off the point where you have to put the baby in the crib and walk away for a few minutes. (And that's okay too; the baby won't die if you take five to regroup.) That means more direct contact with your baby, and possibly a shorter time to a calm baby due to longer, more continuous periods of parental contact.

So: earplugs. Probably the highest-ROI parental purchase I ever made.

by Eric Meyer at April 27, 2012 02:02 PM

Linear gradients in CSS can lead to all kinds of wacky, wacky results"”some of them, it sometimes seems, in the syntax itself.

Let me note right up front that some of what I'm talking about here isn't widely deployed yet, nor for that matter even truly set in stone. Close, maybe, but there could still be changes. Even if nothing actually does change, this isn't a "news you can use RIGHT NOW"� article. Like so much of what I produce, it's more of a stroll through a small corner of CSS, just to see what we might see.

For all their apparent complexity, linear gradients are pretty simple. You define a direction along which the gradient progresses, and then list as many color stops as you like. In doing so, you describe an image with text, sort of like SVG does. That's an important point to keep in mind: a linear (or radial) gradient is an image, just as much as any GIF or PNG. That means, among other things, that you can mix raster images and gradient images in the background of an element using the multiple background syntax.

But back to gradients. Here's a very simple gradient image:

linear-gradient(45deg, red, blue)

The 45deg defines the gradient line, which is the line that defines how the gradient progresses. The gradient line always passes through the center of the background area, and its specific direction is declared by you, the author. In this case, it's been declared to point toward the 45-degree angle. red and blue are the color stops. Since the colors don't have stop distances defined, the distances are assumed to be 0% and 100%, respectively, which means you get a gradient blend from red to blue that progresses along the gradient line.

You can create hard stops, too:

linear-gradient(45deg, green 50%, lightblue 50%)

That gets you the result shown in Figure 1, to which I've added (in Photoshop) an arrow showing the direction of the gradient line, as well as the centerpoint of the background area. Each individual "stripe"� in the gradient is perpendicular to the gradient line; that's why the boundary between the two colors at the 50% point is perpendicular to the gradient line. This perpendicularness is always the case.

Now, degrees are cool and all (and they'll be changing from math angles to compass angles in order to harmonize with animations, but that's a subject for another time), but you can also use directional keywords. Two different kinds, as it happens.

The first way to use keywords is to just declare a direction, mixing and matching from the terms top, bottom, right, and left. The funky part is that in this case, you're declaring the direction the gradient line comes from, not that toward which it's going; that is, you specify its origin instead of its destination. So if you want your gradient to progress from the bottom left corner to the top right corner, you actually say bottom left:

linear-gradient(bottom left, green 50%, lightblue 50%)

But bottom left does not equal 45deg, unless the background area is exactly square. If the area is not square, then the gradient line goes from one corner to another, with the boundary lines perpendicular to that, as shown in Figure 2. Again, I added a gradient line and centerpoint in Photoshop for clarity.

Of course, this means that if the background area resizes in either direction, then the angle of the gradient line will also change. Make the element taller or more narrow, and the line will rotate counter-clockwise (UK: anti-clockwise); go shorter or wider and it will rotate clockwise (UK: clockwise). This might well be exactly what you want. It's certainly different than an degree angle value, which will never rotate due to changes in the background's size.

The second way to use keywords looks similar, but has quite different results. You use the same top/bottom/left/right terms, but in addition you prepend the to keyword, like so:

linear-gradient(to top right, green 50%, lightblue 50%)

In this case, it's clear that you're declaring the gradient line's destination and not its origin; after all, you're saying to top right. However, when you do it this way, you are not specifying the top right corner of the background area. You're specifying a general topward-and-rightward direction. You can see the result of the previous sample in Figure 3; once more, Photoshop was used to add the gradient line.

Notice the hard-stop boundary line. It's actually stretching from top left to bottom right (neither of which is top right). That's because with the to keyword in front, you're triggering what's been referred to as "magic corners"� behavior. When you do this, no matter how the background area is (re)sized, that boundary line will always stretch from top left to bottom right. Those are the magic corners. The gradient line thus doesn't point into the top right corner, unless the background area is perfectly square"”it points into the top right quadrant (quarter) of the background area. Apparently the term "magic quadrants"� was not considered better than "magic corners"�.

The effect of changing the background area's size is the same as before; decreasing the height or increasing the width of the background area will deflect the gradient line clockwise, and the opposite change to either axis will produce the opposite deflection. The only difference is the starting condition.

Beyond all this, if you want to use keywords that always point toward a corner, as in Figure 2 except specifying the destination instead of the origin, that doesn't appear to be an option. Similarly, neither can you declare an origin quadrant. Having the gradient line always traverse from corner to corner means declaring the origin of the gradient line (Figure 2). If you want the "magic corners"� effect where the 50% color-stop line points from corner to corner, with the gradient line's destination flexible, then you declare a destination quadrant (Figure 3).

As for actual support: as of this writing, only Firefox and Opera support "magic corners"�. All current browsers"”in Explorer's case, that means IE10"”support angles and non-magic keywords, which means Opera and Firefox support both keyword behaviors. Nobody has yet switched from math angles to compass angles. (I used 45deg very intentionally, as it's the same direction in either system.)

That's the state of things with linear gradients right now. I'm interested to know what you think of the various keyword patterns and behaviors"”I know I had some initial trouble grasping them, and having rather different effects for the two patterns seems like it will be confusing. What say you?

by Eric Meyer at April 26, 2012 06:54 PM

I recently stumbled over a subtle interaction between cookie policies and localStorage in Firefox. Herewith, I document it for anyone who might run into the same problem (all four of you) as well as for you JS developers who are using, or thinking about using, locally stored data. Also, there's a Bugzilla report, so either it'll get fixed and then this won't be a problem or else it will get resolved WONTFIX and I'll have to figure out what to do next.

The basic problem is, every newfangled "try code out for yourself"� site I hit is just failing in Firefox 11 and 12. Dabblet, for example, just returns a big blank page with the toolbar across the top, and none of the top-right buttons work except for the Help ("?"�) button. And I write all that in the present tense because the problem still exists as I write this.

What's happening is that any attempt to access localStorage, whether writing or reading, returns a security error. Here's an anonymized example from Firefox's error console:

Error: uncaught exception: [Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "http://example.com/code.js Line: 666"]

When you go to line 666, you discover it refers to localStorage. Usually it's a write attempt, but reading gets you the same error.

But here's the thing: it only does this if your browser preferences are set so that, when it comes to accepting cookies, the "Keep until:"� option is set to "ask me every time"�. If you change that to either of the other two options, then localStorage can be written and read without incident. No security errors. Switch it back to "ask me every time"�, and the security errors come back.

Just to cover all the bases regarding my configuration:

1. Firefox is not in Private Browsing mode.
2. dom.storage.default_quota is 5120.
3. dom.storage.enabled is true.

Also: yes, I have my cookie policy set that way on purpose. It might not work for you, but it definitely works for me. "Just change your cookie policy"� is the new "use a different browser"� (which is the new "get a better OS"�) and it ain't gonna fly here.

To my way of thinking, this behavior doesn't conform to step one of 4.3 The localStorage attribute, which states:

The user agent may throw a SecurityError exception instead of returning a Storage object if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to persist data).

I haven't configured anything to not persist data"”quite the opposite"”and my policy decision is not to refuse cookies, it's to ask me about expiration times so I can decide how I want a given cookie handled. It seems to me that, given my current preferences, Firefox ought to ask me if I want to accept local storage of data whenever a script tries to write to localStorage. If that's somehow impossible, then there should at least be a global preference for how I want to handle localStorage actions.

Of course, that's all true only if localStorage data has expiration times. If it doesn't, then I've already said I'll accept cookies, even from third-party sites. I just want a say on their expiration times (or, if I choose, to deny the cookie through the dialog box; it's an option). I'm not entirely clear on this, so if someone can point to hard information on whether localStorage does or doesn't time out, that would be fantastic. I did see:

User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.

"¦from the same section, which to me sounds like localStorage doesn't have expiration times, but maybe there's another bit I haven't seen that casts a new light on things. As always, tender application of the Clue-by-Four of Enlightenment is welcome.

Okay, so the point of all this: if you're getting localStorage failures in Firefox, check your cookies expiration policy. If that's the problem, then at least you know how to fix it"”or, as in my case, why you'll continue to have localStorage problems for the next little while. Furthermore, if you're writing JS that interacts with localStorage or a similar local-data technology, please make sure you're looking for security exceptions and other errors, and planning appropriate fallbacks.

by Eric Meyer at April 25, 2012 02:07 PM