Florian’s Blog

Specifying Legacy Features

I ran into an old article from Hixie that describes how he worked when specifying the drag and drop part of HTML. As I am working on specifying some legacy css features (like the user-select property or the appearance property), this felt really familiar.

Here’s how Hixie describes his approach:

I put my physicist training to use. As a scientist, you are supposed to approach problems using a simple process:

  1. Form a hypothesis that matches everything you know so far.
  2. Make some testable predictions using this hypothesis.
  3. Test reality to see if your predictions can be disproved.
  4. Repeat those steps until you can no longer find anything in reality that disagrees with what your hypothesis predicts.
  5. Publish your findings, along with all the data you collected, and the hypothesis you ended up with.
  6. Wait for someone to find a prediction that your hypothesis makes and which doesn’t match reality.
  7. Repeat the entire process.

When reverse-engineering a single implementation, this is a very sound way to proceed, and the number of times you have to run through step 3 is why is love jsbin so much these days.

However, there’s one important complication when what you’re trying to reverse-engineer and specify has not one, but several implementations. As you run steps 1–4, occasionally you find that some implementations match your predictions but that some others do not. Even though it shows that there not yet complete interoperability, the interesting thing is that this can sometimes be a good news.

If something has been in the market for a while with multiple implementations behaving interoperably, there’s a very good chance the web at large now depends on that specific behavior. That does not necessarily means web developers like the way it works. Maybe they do, or maybe the feature is terribly designed and they have to resolve to elaborate workarounds to get it to do what they want. But these workarounds are written, deployed, and depend on the behavior every browser agrees about and would likely break if they were to change.

When browsers do behave differently — assuming the difference is not limited to browsers with negligible market share — authors generally cannot rely on any particular behavior. So they don’t, and hardly any web site depends on browsers staying the same. This means we have an opportunity for making improvements.

If it’s some obscure detail of the feature that doesn’t really matter, it is sometimes just as well to document it as undefined behavior and move on. Getting every vendor to align on something is costly; it’s important to pick the right battles and not waste time on insignificant things. We can alway come back to it later anyway.

If it is some aspect of the feature that does matter, I get to take off my scientist hat and put on a more judgemental one: which the variants I’ve uncovered makes the most sense? Is there one that solves the problem better, or solves more problems, or fits better with how everything else works? Which one do I like best?

Occasionally, none of these disagreeing implementations is particularly good. Browser engineers are generally capable people but sometimes they’re in a hurry. Or maybe they came up with this years before other features which now conflict with their design were added. With the benefit of being able to learn from their mistakes, maybe I’ll be able to come up with something better.

Regardless of whether what I want to go with what one of the browsers did or something I made up, I still have to try to convince all the implementers that will need to change that this is the right thing to do. Although browser vendors can sometimes be uncooperative and just drag feet until others agree to match their implementations, they generally do want the best for the web and will try to accommodate each other.

It is also fairly common that these discussion will uncovered some aspect of the problem I had not yet noticed and throw me back either at the science lab to find out what is really happening or at the drawing board to come up with a better solution.

Having gone through many such cycles, the user-select property is now a hybrid that matches different browsers on different aspects. The lack of inheritance and behavior auto value are in line with Microsoft’s implementation. The none value on the other hand was superficially the same in all browsers but where they differed the specification now rules in favor of Firefox’s approach… And so on for various other parts of the feature.

Lettre ouverte à Axelle Lemaire sur le projet de loi Renseignement

Note to my non-French speaking readers: This is an open letter to the French Secretary of State for Digital Affairs Axelle Lemaire about a law facilitating mass surveillance.

Madame la Secrétaire d’État

J’ai voté pour vous lors des précédentes législatives. Votre action parlementaire m’avait conforté dans mon choix, et je me suis félicité de votre entrée au gouvernement. Le numérique est un enjeu sociétal et économique majeur, et vous me semblez avoir les compétences et les convictions idéales pour mener à bien cette mission.

Alors que le projet de loi renseignement vient de passer à l’assemblée nationale, je vous écrit aujourd’hui pour vous faire part de ma profonde déception. Déçu par la majorité qui soutient cette aberration. Déçu par l’Assemblée Nationale dont je ne sais si l’absentéisme s’explique par le manque de courage politique, ou par le manque de compréhension des enjeux. Déçu par le gouvernement, qui profite des tragiques événements de janvier pour justifier cette entorse à la liberté.

Déçu par vous: élue députée de ma circonscription en 2012, secrétaire nationale aux droits de l’homme du parti socialiste jusqu’à récemment, membre du gouvernement, vous incarnez les trois. Sur un sujet combinant numérique et liberté, on pouvait beaucoup attendre de vous. En vain.

Ce qu’Edward Snowden a révélé aurait dut être un avertissement, pas une source d’inspiration.

Je ne sais pas si vous vous êtes opposée à cette loi et avez échoué à faire valoir la raison, ou si défendiez vous-même cette loi liberticide, néfaste économiquement et inefficace en matière de sécurité. Peut-être est-ce dans l’esprit de la célèbre phrase de monsieur Chevènement que l’on ne vous a pas entendu vous opposer à ce projet, et que vous avez agi à l’interieur du gouvernement. Même si c’était le cas, je ne trouverais pas grand réconfort à voir le peu d’effet sur un dossier qui devrait être au cœur même de votre action.

Il n’est jamais trop tard pour bien faire, et j’espère que vous aurez la sagesse et la capacité de remettre le gouvernement dans le droit chemin, pour épargner à la France cette loi, qui bien au contraire de protéger notre république, lui donne plutôt de reflets orwelliens.

Improving Usability with the user-select Property

I’ve recently been working on the draft of a new CSS specification: CSS-UI-4. One of the features specified there is the user-select property. This isn’t really a new feature: it first appeared in User Interface for CSS3 back in 1999, before being rejected and therefore not included it the specification that replaced it, CSS-UI-3.

However, despite the initial rejection, browser vendors have experimented with it, and over the years, it has found a public. There are still many interoperability problems, but hopefully the specification will help resolve them.

Quite a few people have written about this property, usually to speak about user-select: none, and occasionally about user-select: element. Here is a good and recent article (Update: the domain has expired redirects to some spam, so I’ve removed the link) by Alex Muir written in celebration of user-select support reaching 90% of browsers according to caniuse.com.

I’d like to introduce a lesser-known ability of this property that is a small but easy win for usability: user-select: all. After applying it to a piece of content, if a user tries to select any part of that content, all of it will be selected.

What is that good for? Assume you have a piece of content in your document which is mainly used by being copy and pasted around, and needs to be kept in one piece. Typical examples could be an ID, an invoice number, a coupon code, a checksum…

If you do nothing, occasionally users trying to select it for copy and pasting will aim poorly, and for example start their selection on the second character of the string, rather than the first. You can make their life easier by using user-select: all. Here’s an example:

Get <strong>50% off</strong> on all our products by using the <span class="coupon">XYZ-SUPER-SAVER-1234567</span> discount code during checkout.
.coupon {
	/* Webkit only, not Blink */
	-webkit-user-select: all;
	-moz-user-select: all;
	/*no other vendor prefix is supported */
	user-select: all;

	/* overkill coupon styling */
	white-space: nowrap;
	padding: 2px 5px 0px;
	border: dashed goldenrod 1px; border-radius: 5px;
	box-shadow: lightgray 5px 5px 10px;
	background: radial-gradient(white, gold);
	color: darkgoldenrod;
}

Unfortunately, this currently only works in Firefox and Safari, but since it causes no harm to users of other browsers, why not include it anyway?

Controlling Spatial Navigation

While working on the CSS directional navigation properties, the question of how to activate spacial navigation has come up a few times, so I thought I’d just put it out there to have something to point to.

While this is a common feature in TV browsers or feature phone browsers, it is less well known that several desktop browsers (and desktop emulators of non-desktop browsers) support spatial navigation. This allows the user to move the focus between elements of the web page in 2D, which is often more convenient that the linear keyboard navigation enabled by the Tab key.

The aforementioned directional navigation properties give the author extra control over how this works. You can read more about it in this article by Daniel Davis. But even if the author does nothing, spatial navigation is still a big usability boost for keyboard users.

Here is a list of browsers that support spatial navigation, and how to turn it on in each of them:

Chrome
Opera (Blink based)
Yandex Browser
The Blink based browsers come with spatial navigation built-in, but turned off by default. Launch from the command-line with the --enable-spatial-navigation argument to activate it (on OS X, use open path/to/browser.app --args --enable-spatial-navigation), then use the arrow keys. This does not include support for the directional navigation properties.
Classic Opera (Presto based, version ≤ 12.x)
This is probably the most mature implementation of spatial navigation, and includes support for the directional navigation properties. Hold down the Shift key and press the arrow keys.
Vivaldi
Vivaldi is a new feature rich browser, that aims to become the spiritual heir to what Opera used to be before the switch to Blink and the UI rewrite. It is the only actively developed desktop browser I know of to offer spatial navigation out of the box. As in Opera, hold down the Shift key and press the arrow keys. At the time of writing, this is still very fragile, and does not include support for the directional navigation properties.
Opera TV emulator
Being based on Presto, this works well and includes support for the directional navigation properties. Use the arrow keys. Alternatively, you can connect to a simulated remote control on http://localhost:5555 (See the Opera TV Emulator User Guide for details).

If you know of other browsers running on desktop and supporting spatnav, let me know, and I’ll update this post.