Vendor Prefixes: Blink, and You’ll Miss Them

October 25th, 2013

Google has announced that they will be forking WebKit to create a new rendering engine for Chrome called Blink.[1][2] Google will be able to remove millions of lines of code from Blink that isn’t needed for Chrome, and will be able to work more aggressively to develop Chrome-specific features into Blink.

This won’t unsettle things too much—at least not right away. The latest builds of Canary are already using Blink, and there is no perceptible difference. The CSS -webkit- prefixes even still work. So how long will it be until we have to switch over to using a -blink- or -chrome- prefix for our rounded corners? The answer to that question is: “wrong!” There will be no -chrome- prefix, or any other vendor prefixes at all, moving forward. Instead, you’ll have to change a setting in your browser to enable experimental CSS features.

Vendor prefixes seemed like a good idea. And maybe they would have worked, if developers had used them as intended. Eric Meyer wrote the seminal article advocating vendor prefixes, Prefix or Posthack. He explained that we could use vendor prefixes to escape the conflicting standards of the bad old days, when the same code was rendered differently by different browsers. Due to Internet Explorers broken box model, width meant one thing in Trident (IE’s layout engine) and something entirely different in Gecko (FireFox’s layout engine). Furthermore, because these differences were alive and living on the internet, there was no way for either browser to fix (or compromise) its definition to unify the web without breaking existing pages. Internet Explorer eventually fixed it’s box model, but it has been an arduous, difficult journey, one that has not yet reached it’s destination. Despite years of very clever attempts to fix things with the creation of quirks mode, doctype switching, and for IE, conditional comments and the problematic compatibility view (which still persists in IE10!).

With vendor prefixes, none of that would happen, because new CSS features would go through a vetting period, during which the feature could only be accessed by prefixing a code to the property name. After a time of testing, and when the standard was defined more definitively, the browser could begin supporting the property without the prefix, and nobody would have incompatible CSS anymore!

This quickly created a situation where the simple task of rounding some corners turned into this mess:

-ms-border-radius: 10px;
-moz-border-radius: 10px;
-webkit-border-radius: 10px;
-khtml-border-radius: 10px;
border-radius: 10px;

When it comes to background gradients, things are even worse:

background: -moz-linear-gradient(top,  rgba(255,255,255,1) 0%, rgba(255,255,255,0) 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,rgba(255,255,255,1)), color-stop(100%,rgba(255,255,255,0))); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top,  rgba(255,255,255,1) 0%,rgba(255,255,255,0) 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top,  rgba(255,255,255,1) 0%,rgba(255,255,255,0) 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top,  rgba(255,255,255,1) 0%,rgba(255,255,255,0) 100%); /* IE10+ */
background: linear-gradient(to bottom,  rgba(255,255,255,1) 0%,rgba(255,255,255,0) 100%); /* W3C */
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ffffff', endColorstr='#00ffffff',GradientType=0 ); /* IE6-9 */

Not only does each browser get its own line, the WebKit browsers actually use two lines, due to a change in syntax. The messiness of this is annoying, but it isn’t actually that huge of a problem, in terms of web compatibility. In fact, it saved us from having to write crazy javascript to detect the browser and version number in order to give one syntax to < Webkit 4 browsers and another syntax to all others. The real problem is that this is how most developers began coding their sites:

-webkit-border-radius: 10px;
border-radius: 10px;

or even just:

-webkit-border-radius: 10px;

You can see how this sort of abuse caused problems. Developers got used to Chrome being on the bleeding edge of CSS3 features, and began coding specifically for it without taking the time to check whether other browsers had supported the features yet. Effectively, vendor prefixes had become browser detection all over again, and developers were using this browser detection to block functionality from all browsers except WebKit. As you can imagine, this annoyed other browser vendors, like Opera, who were working hard to keep their browser up to date with CSS3, but which was blocked from applying the styles due to lazy coding. Developers had turned -webkit- into the very -beta- prefix which Eric Meyers dismissed in his article.

The -beta- prefix was proposed by Peter-Paul Koch as a compromise to his original proposition to abolish vendor prefixes. Koch’s vision was prophetic. In March 2010 he wrote:

Eventually Opera will discover that plenty of sites use -webkit-transition, but not -o-transition. Will Opera start to support -webkit-transition, too?

Despite a widely circulated call for action to web developers to change their ways and prevent “judgement day,” two years after Koch’s prediction, Opera announced it would support -webkit- prefixes. Mozilla had been planning to do the same. Microsoft’s massive attempt to change the bad behavior of developers had failed, and they too would follow suit.

It looked like things were going to get really messy. Then suddenly, Opera announced that it was abandoning its rendering engine Presto, and would instead use WebKit. While many saw this as a sad day for the web, the silver lining was that judgement day had been pushed back a little. Furthermore, Opera is adopting Blink with Google, and Mozilla is creating yet another rendering engine called Servo. So we aren’t looking at a rendering engine monoculture or a return to the “bad old days.”

So with all these new rendering engines, what will happen to vendor prefixes? They’re all going to go and live with the <blink> tag and IE’s broken box model. Mozilla is heading in the same direction as Chrome: “avoiding vendor prefixes by either turning things off before shipping or shipping them un-prefixed if they’re stable enough.” This is where all the vendors are headed, and the W3C working group on CSS has already put together a policy that rang the death knell of vendor prefixes.

This article originally appeared on the shoutleaf.com blog. It was cross posted by permission the owner of Shoutleaf (me) and the author of the article (me).

Two-liner

April 28th, 2012

I think of a Chef as a sensitive guy
Cutting onions makes him happy, but it also makes him cry.

HTML5 as a Brand

January 27th, 2012

If you’re in the web developer world, you’ve noticed by now that there isn’t a space before the ‘5’ in HTML5. This is different than HTML 4.01, HTML 4, HTML 3.2, and HTML 2.0. Why this new direction? Actually, it’s more in line with the old direction than most realize. The first version of HTML wasn’t called “HTML 1.0,” in fact there is no such thing as “HTML 1.” It all started out with a document called “HTML Tags,” which is, for all intents and purposes, the first version of HTML. Things were a little muddy there for a while as updates came in rapidly, but the next real version was called HTML+. Sure, you can go back and find the incremental numbered versions of HTML in some official specs, but in terms of reality and use, there was HTML Tags, then HTML+. These were real innovations and steps up in the language, but after that there was a drive to clean things up a bit, and the numbered versions dominated. I’m not saying that HTML 4 wasn’t groundbreaking and painfully needed (and it took way too long for developers and browsers to implement), but it was truly an incremental update, fixing and adding things that were obvious next steps.

Things changed with HTML5, which starts out with an awareness of the internet today. A search for “HTML 5” will find any page that mentions HTML and has some numbers on it–not very useful. But removing the space allows search engines to key in on just the term we need. This is just the first indication of what characterizes HTML5: an awareness of the world as it is today, and where it is going. We learned from HTML 4 that the internet is run by people, lots of people, and an official specification or update doesn’t do anything unless all those people–browser vendors, web developers, users–get on board. What if Tim Berners-Lee had submitted his “HTML Tags” document to the IEEE or some official organization, got it approved, registered, published, and then just waited for the world to adopt it? We wouldn’t have the internet we have today.

HTML5 BadgeTim Berners-Lee made something that worked, and he publicized it–created documents to help people use it, he facilitated it’s growth. The same with the market-minded naming of HTML+. It’s true that HTML was in deep need of regulation, but regulation was not enough to magically make HTML 3.2 or HTML 4.01 become a universal standard. That’s why HTML5 doesn’t have a space. And why it has it’s own logo. Have you noticed that people don’t really talk about “Web 2.0” anymore? HTML5 has completely encompassed both that term and that concept–HTML5 has come to mean not just the next version of HTML, but the next version of the web. It includes the newest version other languages, like CSS 3, dozens of little technologies like offline storage and location detection, it includes rapid-release browser schedules like Firefox and Chrome have, it stands for everything the internet has been waiting for.

html_can_not_do_that

Here’s something that I think is telling. The doctype for HTML 4 looked like this:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

Besides being messy, you notice the prominent versioning of it. 4.01. But here’s the HTML5 doctype:

<!DOCTYPE html>

No version number! HTML5 is the end of the idea that we can just release a new version of HTML and wait decades for people to update. From now on, the expectation is that you’re up to date–you’re using the latest browsers with the latest standards and the latest technologies. If you’re not, we’ll still display your content, but the internet is done pandering to the lowest common denominator. HTML5 is not the next version of HTML, but rather it’s a vision for the future of the internet, and it has a lot more in common with HTML Tags than with HTML 4.01 Strict.

strong passwords

August 18th, 2011

People are beginning to hear about this idea of using words and spaces to make strong passwords instead of crazy characters. Cases  in point: “fluffy is puffy” is more secure than “J4fS<2”, and “correct horse battery staple” is more secure than “Tr0ub4dor&3”, while the more secure passwords in both cases are easier to remember.

When people see stuff like this, they seem to make a few mistakes due to not really understanding the principles behind this. Using the word method is useless if your password ends up being short (less than 12 chars), or if you use a phrase (“happy go lucky”), or if you  draw from a limited set of words, (“five three two nine six four eight ten three two”) .  Using only common words is bad too.

Here is one way to think about why: the security of your password can be measured by the number of possibilities. Traditionally, this has been measured character-by-character. So in a lowercase letter only password, there are 26 possibilities per slot. A six slot password  has 308,915,776 possibilities (which is not very secure).

“hsufbe” = 6 chars, 6 slots
(26)^(6) = 308,915,776

The problem is that that is only true if password guessers work like this: aaaaaa, aaaaab, aaaaac, aaaaad… and so on. But if your password is “happy!” then it’s going to get guessed by a dictionary attack much much sooner.

Therefore, we need to make a more general rule:

(values in category) ^ (slots) = possibilities

If you’re working with characters on the keyboard (e.g., these: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 01234567890 `~!@#$%^&* ()_+-={}[]\|;’:”,./<>?) then you have 95 values in the category. A six character password is then 735,091,890,625 combinations.

“h&’8,}” = 6 chars, 6 slots
95 ^ 6 = 735,091,890,625

While this is better, it’s still not fantastic. But here’s where English words really come in handy. There are between 300,000 and a million English words, depending on your dictionary and how you define words. Let’s use the lower range and assume 300,000 possible values per slot (the slots are the WORDS now, not the characters).

“fluffy is puffy” = 15 chars, 3 slots
300,000 ^ 3 = 27,000,000,000,000,000

“correct horse battery staple” = 28 chars, 4 slots
300,000 ^ 4 = 8,100,000,000,000,000,000,000

The important thing to notice here is that we’re not calculating by characters anymore–a brute force cracker would have an impossibly hard time. But a dictionary attack cracker is going to have the best shot, so that’s what we’re looking at.

Even though you’re using words with 5 and 6 characters, you don’t get to count each character as a slot: they get chunked into one slot. Similarly, if you use a phrase, even though you’re using multiple words, you don’t get to count each word anymore: they get chunked into a single slot of phrases. I have no idea how many common phrases there are, but I’m sure there are password programs that take sentence fragments from the internet and try them as passwords. What is the probability that such a program will hit upon the phrase “jimmy crack corn?” Hard to say. If it’s drawing text from a transcript of Pinky and the Brain, then your odds might be pretty bad. But the big point is that your slots have now been reduced to 1. Let’s assume that the cracker is drawing from a trillion phrases.

“jimmy crack corn and i dont care” = 32 chars,  1 slot
( 1,000,000,000,000) ^ 1 = 1,000,000,000,000

Not very good. Barely better than a 6 char password, even though it’s 32 characters and 7 words long.

So: things to keep in mind. Draw your “chunks” or slots from categories with very large number of values. The more the better: drawing common English words is ok if you use a lot of them. Drawing from a larger range of English words (e.g. include scientific words, place names, proper nouns, stuff that would get you disqualified from Scrabble) means you can get away with using less slots. If you also use other languages, you’re even better off.

But also remember that you’re always limited by the less sophisticated password cracking algorithms. The following  words are all extremely uncommon words drawn from various languages and various technical terms: xi af ju . Let’s assume that for some strange reason you’re somewhat familiar with these words and so it’s easy for you to remember. So you might think:

“xi af ju”  = 3 slots
(~6 million )^ (3) = (absurdly large number)

but in fact

“xi af ju ”  = 8 slots
(27 )^ (12) = (282,429,536,481)

So you’ll beat the sophisticated dictionary attack but lose at a persistent brute force attack. Likewise, you may have several words that are all part of some similar category (e.g. numbers, as from the example above) in which case you now only have ten values per slot, even though each slot is multiple characters long. Similar story if you happen to choose all words that are in the 1,000 most common words, because the dictionary program may be using only those 1,000 common words, reducing your values per slot from 300k to 1k.

Lastly, and this should be obvious, but once a random assortment of words or characters goes on the internet or becomes famous, it effectively is the same as a word or a phrase. If you see an example of a secure password on the internet, (here you go: “D&hjd6G44@#46″;}{neh*(Jeheg$#@EfTGTgSYhs” ) it automatically ceases to be secure because some programs build their dictionaries from the internet. That means that that “secure” password back there is no longer secure. So you can’t use “fluffy is puffy” or “correct horse battery staple” anymore. And really, you can’t use any password that has any google results if you google it (in quotes).

This is just one small part of password security, especially compared to problems like people reusing passwords for more than one site. But if it’s learned correctly, it can help solve the problem by creating easier to remember passwords and encouraging people to create unique passwords for each site they visit.

Arguments and Confirmation Bias

May 5th, 2011

An article from wired that I was reading today pointed out an interesting connection between argumentation and confirmation bias. I never would have thought the two were so connected before now, but it actually makes sense.

The article begins by wondering at the phenomenon of confirmation bias. Why do we even have it? Why is it that we dumbly look only for evidence that supports the idea we already have in mind, and are blind to contrary evidence? The result is that people make tons of bad choices! But what they point out is that this ability to only see things that confirm an idea is helpful when it comes to being persuasive. If I’m encouraging you to do something for me, I only want to give reasons you should do it, not reasons you shouldn’t.

It makes sense, and it speaks to our being designed for community. We literally can’t think logically about things without another person to bounce ideas off of. The other person has their own confirmation bias and, hopefully, you’ll get someone with a different idea than you. The result is a debate, and you get different ideas going back and fourth in opposition to each other. So our confirmation bias actually does work towards logical conclusions, but only in the context of a somewhat diverse community.

I think that confirmation bias further functions to strengthen the community once the debate is over and a conclusion is reached: everyone agrees on the idea in the end, and then everyone’s confirmation bias kicks in to start seeing reasons that it was right, bonding the community in agreement. That’s why stores have liberal return policies. As much as you may be debating in your head and hesitant about a purchase, once you’ve got it, you start seeing all the reasons you should keep it, even if you thought you didn’t like it before.

Where debates don’t end in agreement, community tends to polarize more and more, splitting into factions that will probably separate. This seems unfortunate but is probably helpful in that it keeps a diversity of approaches to life alive. You have people making cars that run on gas, and people making cars that run on electricity (like we did at the turn of the 20th century). If both approaches are perused, then you have better options down the line. If only one is perused (e.g. gas) then it’s really hard to adapt when problems emerge with that approach.