I put my physicist training to use. As a scientist, you are supposed to approach problems using a simple process:
Form a hypothesis that matches everything you know so far.
Make some testable predictions using this hypothesis.
Test reality to see if your predictions can be disproved.
Repeat those steps until you can no longer find
anything in reality that disagrees with what your hypothesis predicts.
Publish your findings, along with all the data you collected,
and the hypothesis you ended up with.
Wait for someone to find a prediction that your hypothesis makes and which doesn’t match reality.
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.
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.
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,
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.
I’ve recently been working on the draft of a new CSS specification:
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:
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 invoice number,
a coupon code,
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
Here’s an example:
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?
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:
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.
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.
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,
and I’ll update this post.