Web developer, writer, speaker. Co-founder of his company Algonquin Studios as well as evolt.org. Has co-written “Usability: The Site Speaks for Itself,” “Web Graphics for Non-Designers,” and “Web Professional's Handbook.”
Unlike other click-bait efforts that only speculated that perhaps Spartan was going to be WebKit-based, showing their own preference instead of any real understanding of the browser world, this one is filled with lots of great information. You should read it.
The first few comments, on the other hand, started off a mess (with many more on Twitter since the initial announcement). Two examples from the article:
So here was the opportunity to swallow their pride and join WebKit to make the internet a better place
…and they built *another* closed-source, proprietary rendering engine.
[Slow sarcastic clap]
« IE did shape the web in a positive way »
This made me laugh more than it should. You seem to forget why Internet Explorer has felt the need to change its name in the first place. And it’s not because it was «too good» or «too innovative»…
Many folks jumped in and corrected, down-voted, and generally balanced the insipid whining. Christian Heilmann, who has logged more years working for Firefox than most devs have logged using it, waded in to challengemany of theincorrect assertions.
Bruce Lawson, who happens to work for another browser vendor (Opera) noted all the things Internet Explorer did for the web in his five-year-old post In praise of Internet Explorer 6. It's also a cautionary tale about where reliance on a single rendering engine will take us.
What these two guys have in common, besides working for the competition, is that they have been on the web since its dawn. They've seen what happens when one browser gets too big (Internet Explorer) and how we spend the next decade-plus digging out from the mess.
How did we get into that mess? By people coding for one rendering engine.
Everyone who calls for WebKit in Internet Explorer is exactly the same kind of developer who would have coded to Internet Explorer 15 years ago (and probably happily displayed the best viewed in badge).
If you are that developer, then it will all be your fault when it happens again. When WebKit is no longer the hot engine. When Chrome loses its dominance. When Apple's market share falls to match the developing world. You will be to blame.
Depending on how much you spend staying up on web browsers, you've probably heard the cry of Opera did it first more than once (though the low-hanging fruit, browser tabs, wasn't technically Opera first). When Google announced that Chrome would offer a data compression mode, you may have figured you'd hear it again owing to Opera Mini.
Chrome for mobile devices has been climbing in use, partly because Android devices have started to move away from the default Android browser (though this doesn't affect all the Android 2.x devices and many of the 4.x devices that will be out there for a while). By adding support for data compression, Chrome is that much more appealing to users who have bandwidth caps, poor connections, or any other factor that limits how well they can see fat pages. Interestingly, some of the data compression comes from converting all the images to WebP (ol' Gil has finally found a way to make that format work). Chrome also automatically puts you into Safe Browsing mode as part of its compression process.
So I fired up both browsers, chose a list of web pages/sites that I haven't surfed using either of them, dropped into 3G and started my compressed surfing. These are the results:
Chrome requested 18.70Mb of data and compressed it to 4.83Mb, for a compression rate of 74%.Mini requested 12.9Mb of data and compressed it to 3.7Mb, for a compression rate of 72%.
This test was by no means rigorous or scientific. While Chrome compressed just a bit better overall, I felt like the experience was slower than on Mini. Chrome was also served much more data, perhaps owing to browser detection scripts offering more "features" to Chrome, or Mini's rendering engine just ignoring some of the elements it didn't know.
For those who have decided that Google is the great new evil, you may want to consider that Google proxies are between you and the web for every request when using Chrome's compression. For Mini users the same is true of Opera's servers, but far fewer people seem to be concerned about demonizing Opera Software. How much stock you put into Google's Safe Browsing technology behaving as some sort of censor is up to you and your own paranoia. I don't much care either way, but some folks might. As someone who's used Opera Mini for years when I travel outside the U.S., I'm very comfortable with it and doubt I'll switch — it's easier for me to just fire up Mini than it is to navigate Chrome's menus to enable compression.
Yesterday Opera announced the release of its newest browser, Coast, built specifically for iOS tablets (I would say just iPads, but if my fridge gets an iOS tablet UI then I'd be wrong and will have paid too much for a fridge).
Background
Recently Opera moved away from Presto as its rendering engine and hitched its future to Blink, the rendering engine born from WebKit that powers Chrome. Now instead of Opera worrying about the rendering engine, it is focusing on the user interface, the place where it can set itself apart from the other browsers.
Essentially Opera is removing the browser chrome (implying to the user that a web page is just an app) and adding gesture support. Given that Opera was the browser that introduced us to mouse gestures well over a decade ago, and given that a touch screen is an inherently gesture-based UI, this seems like a natural fit.
Bits for Developers
Sadly, my office wifi was down and I couldn't play with the browser immediately (my crusty iPad 2 is wifi only). So instead I took some time to read through the developer notes.
Tablet First
Overall Opera recommends general responsive design current best practices, though it promotes a tablet-first approach. Opera offers some CSS you can use to specifically target iPads Mini, 2, 3 and 4 (Retina and non-Retina), though it leans on vendor prefixes with only a brief note to also use other prefixes and unprefixed rules.
Responsive Images
It's also clear that Coast supports the new srcset option for responsive images. It even offers a code example: <img src="image.jpg" srcset="retina.jpg 2x">
Note: As Bruce was kind enough to inform me (because I missed it in the dev notes), responsive images will be supported only in iOS7 and up.
Update as of September 20, 2013
According to Opera, iOS7 did not come with a WebKit update. That means Coast cannot support responsive images via the srcset attribute without a polyfill. Nor can Safari, of course.
TileSpeed Dial Web App Image
Instead of "Speed Dial" icons/images, Coast now looks for a "web app image." If you don't have one, Coast will first look for a Windows 8 tile image, then an Apple touch icon, then a shortcut image, then just a favicon. You can, however, create your own 228 × 288 pixel image and stuff it into your site with the following HTML:
<link rel="icon" href="$URL" sizes="228x228">
User Agent String
Don't use this to do any browser sniffing. Browser sniffing bad. This is instead handy for recognizing it in your logs:
Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Coast/1.0.2.62956 Mobile/10B329 Safari/7534.48.3.
General Review
Getting going is pretty easy, just start typing into the only field on the screen. As you type you can see a Google preview on the left, which you can tap at any time to go to Google, or a list of icons on the right which correspond to sites you might mean. The icons start out just displaying the first letter of the site, and then identify the site's tile or shortcut image.
Note the handy ".com" and ".net" options that appear above the right end of the text box.
Once you are on a page, you can go back by swiping from the left, forward by swiping from the right, or reload the page by pulling down from the top — but not too far or you get the iOS menu instead.
Vine of me playing with back, forward and reload in Opera Coast.
Opera Coast skips tabs and windows altogether and, frankly, feels a lot more like Internet Explorer for Metro than other current tablet browsers. It's pretty easy to see the open "tabs," flip through them, get more details, and discard them. It's also incredibly easy to forget you have so many tabs open. I regularly found myself littered with tabs because of all the links opening new windows.
Testing Opera Coast window/tab management.
While in that tab view, you can also see how "safe" the page is and can get to options to share it, email it, print it, and so on.
The arrow on the right gives you all the share options.I don't have a printer installed, so I'd love to hear feedback on how Coast honors print styles.
Adding and removing a bookmark, tile, whatever, is pretty easy. It took a few swipe-fails, but I got the hang of it well enough to show the whole process in one uninterrupted Vine:
It takes a little getting used to, but it's not too hard
Gotchas
There were a few things that threw me off. Perhaps because I am a power user, perhaps because I only played with it for one evening.
Swipe History
The swipe for back/forth is handy, but conflicts with behavior I have already learned. In Chrome for Android, swiping left or right has the infuriating feature of bringing me to the next or previous tab in the stack order. For those rare sites that implement a slide that is swipe-friendly, imprecise swipes will move me back and forth in the history instead.
Web App Images
Using the browser in portrait view, the additional screens of tiles (speed dial icons if you are already familiar with Opera) aren't immediately apparent. It wasn't until I turned to landscape that I saw them. The tiny dots under the Coast icon weren't enough for me to intuit that. They also aren't nearly large enough to tap to jump to a specific screenful of tiles.
Hit Sizes
The 9-box grid at the center bottom as well as the three rectangles at the bottom right are the only real browser chrome in play as you surf. They are also maddeningly small to tap. And I have dainty, lady-like fingers, so I suspect it may cause consternation for others.
Address Bar
If I am on a site and I want to change the address of the current page (maybe I fat-fingered and got to a 404, or I know a super-secret URL), I could not find a way to bring up the address bar and change it. It also made it impossible to know the current page address at any time. As someone who regularly looks at the URL for familiar addresses, indications of scam sites, quick commitment to memory, and so on, this alone takes it out of the running as an everyday browser for me.
Email a Page
I did not care for the email feature one bit. Not only does it embed a screen shot of the page (with a Coast watermark), the screen shot won't display on other devices. Outlook blocked the image because the attachment ended in .com (not .png or .jpg). Had it not come from me, I wonder if Outlook would have blocked it as spam. My Android email client couldn't display it because there was no file extension to give it a clue.
What you see when you choose to email a web page from Opera Coast.Best case scenario of what the email recipient sees, though the attachment was blocked in Outlook and unusable in my Android email client.
Tweet a Page
Tweeting a page left me similarly dissatisfied. By default it includes a Twitpic screen shot of the current page with an Opera Coast watermark. When composing the tweet, I tapped the paperclip icon to see if it would do anything, but nothing happened. I opted not to tweet again.
Overall, I like the browser. I like what it's trying to do for consumers. As a power user, however, It's not a fit for me though I'd be interested in bringing it in front of some other members of my family.
I also didn't get to try out unsafe sites, printing pages, responsive images (need iOS7), or poorly-built sites. My opinion might change as I continue to play with the browser.
Open Question
There are a lot of Android tablets out there, not just the four screen size offerings from Apple. So how long before we can see Coast on my Nexus 7, if ever?
Updates
I'm adding notes throughout the day as they come up.
Surprising no one, the following reviews from more mainstream sources completely fail to include any screen shots or videos that weren't pilfered from Opera. I only say that to remind you that by reading this post you have gotten the most in-depth review currently on the web and you should be excited and send me a thank you note and maybe read all my other posts and high-five me on the street.
These articles are, however, worth visiting just to see the comments and how others are reacting to it.
This post isn't proposing any solutions (although I do toss out a hack). This post is a rant that I hope helps influence browser makers.
Background
Much of my web work isn't for public facing web sites. Often it's for enterprise-level software that is deployed via the web and used in a web browser. I think any web developer who does anything beyond standard brochure-ware is ultimately in the same boat. Usually we need stylistic control over elements on the page that aren't typically considered exciting.
Once again I find myself working on a reporting feature for a large piece of software. Reports are typically grids (a table) made up of columns & rows with numbers, letters, icons, colors and so on. Clients are used to seeing these reports the same way they might see them in Excel, Crystal Reports, and similar tools.
These reports are formatted for quick visual scans to identify outliers and exceptions, so control over formatting is key to their effectiveness.
Example
Often these grids contain numbers of various lengths that include decimals. Often these decimal values aren't the same number of (significant) digits. Let me offer an example of wildly divergent numbers (I cannot show real client data):
Name
Number
Units
George
1,984.0
years
Arthur
42.000
?
Ray
451.0
degrees
Marie
13.51
g·cm−3
Isaac
6.67384
(× 10-11) m3 kg-1 s-2
Sergei
289.8001
billions of dollars
It's standard practice to align numbers to the right. The problem is that some numbers have decimals lengths that don't match other numbers, thereby throwing off the formatting and making the entire column harder to read than necessary. Note that the biggest number is the same length as the smallest number.
CSS to the Rescue
CSS3 has a solution. The property text-align has an option to solve our problem. It can accept a one character string as the character on which to align the text.
Not just a decimal, but a string. This is great news for languages that use a comma instead of a period for decimals. It's great news for very large or very small values where perhaps you want to align on the multiplication sign instead.
This style will allow me to align on the decimals in my example table: text-align: "." right; (the keyword after the string still keeps my numbers aligned to the right, after the decimal is factored in)
Browser Support
Now the question comes down to browser support. What browsers support it? None.
A Hack
To achieve the effect I want, I would have to split my numbers into two columns, one for the whole number and one for the decimal value. Like in this hack:
Name
Number
Units
George
1,984
.0
years
Arthur
42
.000
?
Ray
451
.0
degrees
Marie
13
.51
g·cm−3
Isaac
6
.67384
(× 10-11) m3 kg-1 s-2
Sergei
289
.8001
billions of dollars
This table isn't ideal. I have to clear out padding values, remove borders, and accept that my numbers are split. It is unnecessary work that could be avoided if the browser makers would just fully support an aspect of CSS3 that has been around for years and whose related styles already have seen support for even more years across prior CSS versions.
The extra styles, whether inline or with per-cell classes, also add to the overall page weight. HTML tables aren't exactly examples of slim mark-up to begin with, but this can bloat them even more.
This table is also an accessibility gotcha. Users with screen readers are used to a particular way tabular data is read, so this variation may not come across so clearly. Users who scale text may see odd baseline text alignment as text wrapping in other columns can throw off everything else.
It is likely that others who have needed to represent data with alignment on specific characters have just used images instead. That solution is far worse than even this hack, particularly from an accessibility perspective.
My Request to You
If you work for a browser maker, please bring this to someone's attention.
If you don't work for a browser maker, please share this (or your own examples) so that perhaps the browser makers will see there is a need, even if it's not as sexy as animations, transitions, WebGL, and so on.
Related
Even in the modern international web, the specification is sometimes too Anglo-centric, as in the case of the input type="number", which isn't as universal as hoped. You can read about the request to allow developers to set a pattern attribute on input type="number" to specify the thousand separator, decimal separator, decimal precision and if any special characters should be allowed.
There are also people calling for Mozilla to drop support for MathML, suggesting that people who don't use numbers in financial and scientific applications on a daily basis may not see the value in stronger support for number formatting.
A combination of people who are far smarter, far more well connected, and in timezones that allow them to write about this sooner, along with all the Twitter chatter, has already hashed out the major details. As such, I will link to them below. I would be a terrible blogger if I didn't offer my opinion, however.
Any developer who is complaining that this means there is another browser/engine against which they will need to test has been doing it wrong.
Web developers should always test against different browsers, regardless of their engine. In particular, WebKit has so many nuanced implementations that not independently testing against each browser that uses WebKit belies either a lack of understanding of how WebKit is implemented or laziness.
If you aren't sure what is different between each WebKit implementation (Chrome, Safari, Android browser, Opera, etc.), I encourage you to read my post "WebKit Will and Won't Be the New IE," where I provide a high-level overview of these variances.
For Users
At this point it doesn't mean a whole lot.
Google will argue this is better for users. Apple will argue that Google took its ball and left. Opera won't be arguing. None of that impacts users because we have mostly done a good job of promoting standards-based development. I again refer you to "WebKit Will and Won't Be the New IE" for how poor testing can impact users, but that's not a function of the engines.
Because Apple only allows WebKit on iOS devices, and even then it restricts those browsers to a different JavaScript engine and thus a lesser experience, Chrome and Opera for iOS may still stay on WebKit. Over time as its harder to incorporate features from Blink back into the WebKit core, there may be feature divergence which may affect users.
That's just speculation on my part.
For Standards
For a specification to become a W3C recommendation, there must be two 100% complete and fully interoperable implementations, which basically means two browsers need to support it. When Opera announced the shuttering of Presto, that left Trident (Internet Explorer), Gecko (Mozilla), and WebKit (Safari and Chrome) as the remaining engines (of measurable size). Essentially, two out of the three of them had to agree to implement a feature.
With Blink, provided the W3C recognizes it as a stand-alone engine, there is now one more engine back in the mix, essentially returning the count to where it was in February before Presto's wind-down (to be fair to Presto, it's expected to exist in the wild until 2020, but with no new feature development).
I am hoping that this is a good thing for standards.
Blink won't be using vendor prefixes (even though it will have inherited some), so I consider that a step in the right direction. While I think this matters to developers, I think it matters even more to standards.
Technical Aside
From Peter-Paul Koch:
Chrome 28 will be the first stable release to use Blink; earlier versions will use WebKit. Opera and Yandex will start using Blink whenever they start using Chromium 28.
Related
First some bits from The Twitters:
Let's bring back the Netscape engine and call it Spacer! RT @codepo8: After blink Microsoft might bring out a new engine called marquee
Unlike Trident (Internet Explorer's rendering engine), WebKit can be wielded in many different ways by many different browsers. It's less a singular rendering engine and more a collection of pieces and parts that can be assembled in different ways. The tweet above demonstrates that there can be different WebKit implementations.
You may argue that the example above is just a case of the first implementation of an update that will make it into all browsers that use WebKit. That may very well be true (we don't know yet), but there are many more examples of differences as Paul Irish painstakingly details in his post WebKit for Developers. I encourage you to read it because it's an almost hilarious dive into the rabbit hole of WebKit. The most salient and clear point is the bullet list of what is not shared in WebKit ports:
Far too many developers are always looking for ways to justify testing less. It could be laziness, it could be lack of access to enough device configurations, it could be … well, frankly, I think it's the first one. My IE10 tweet above was based on watching people thrilled as much at taking a shot at Internet Explorer as they were at feeling they could test on one fewer browser.
Developers may use the common engine in one browser as justification for not testing on all the WebKit browsers, or they just may not know about the potential for dramatic differences between implementations. What happens when everyone builds for one awesome browser engine (or one perceived common engine)? We end up with a browser monoculture, devoid of testing for other variations.
As a web developer since the dawn of the web, I've seen it happen before. I remember surfing on Netscape only to find a site didn't take into account my screen colors or resolution, or on Internet Explorer only to find a site didn't take into account my laptop pixels-per-inch default. I was using the popular rendering engine of the day, but the assumption that all users on that engine would all have the same experience was wrong then, and it will be even more wrong now.
WebKit will become the new IE if web developers continue these false assumptions and fail to test other WebKit implementations. Developers will build for one implementation, test for it and maybe a couple variations, and call it a day.
Conclusion
My fear is that all the gains we've made in the last few years toward a more inter-operable standards-based web (leaving behind the Internet Explorer monoculture) will fall away as we unwittingly move toward a WebKit-tweaked yet non-multi-WebKit-inter-operable web.
In short, we'll test for one WebKit, not realize (or care) about all the other variations, and end up breaking the web all over again.
WebKit won't be the new IE, but WebKit will be the new IE.
I feel most web developers already ignored Opera. For those developers they can continue to be lazy and ignore Opera.
For Users
The short term impact on users will be minimal. Users will upgrade, users will surf, users may notice some sites work or look a little better.
For users trapped on old Android devices with the Android stock browser (that never seems to upgrade), this could result in a better experience — assuming these users know about and download the Chromium-powered Opera.
For Standards
Opera has an impressive place in the mobile world, being at the top of the pile globally. Opera's participation in the standards process has been valuable, partly because its rendering engine has been used to help move the process forward thanks to early implementations, differences in implementations, and arguments over implementations.
While the standards evangelists at Opera may do a great job of contributing back to Chromium, Google may be the block from those changes being committed. Even when changes get to Chromium, there is no guarantee that they'll make it back into WebKit, which might involve getting past Apple. Only if those changes get into WebKit do they stand a chance of making it Apple's Safari.
From the co-chairman of the W3C CSS Working Group, Daniel Glazman:
For the CSS Working Group, that's an earthquake. One less testing environment, one less opportunity to discover bugs and issues. Let me summarize the new situation of the main contributors to the CSS Working Group:
Microsoft: Trident
Apple: WebKit
Google: WebKit
Opera: WebKit
Adobe: WebKit and their own Adobe Digital Editions rendering engine found in many ebook readers
Mozilla: Gecko
Disruptive Innovations: Gecko
HP: has delivered WebKit-based products in the past but is pretty browser-agnostic IMO
Rakuten: ADE and probably WebKit
Kozea: WeasyPrint
Qihoo 360 Technology Co: both Trident and WebKit
other Members of the Group: I don't know
Suddenly I feel like the US political term lead from behind is apt.
Some other reactions from the Twitters:
It’s becoming clear that WebKit:browsers::MS Word:word processors.
Since I posted this, some folks have asked just what Opera did that was so useful? This quote from David Storey's post outlines some of it pretty well:
Moving from HTML to CSS based layouts? Opera was perhaps the first to have a useable CSS engine. Håkon (father of CSS, and Opera CTO) often says it was the reason he started to believe a browser could be made in Norway, not just the USA, and joined Opera. AJAX? Opera reverse engineered this from MS’ ActiveX based approach and were the spec editors through Anne van Kesteren. HTML5? Started at Opera with Ian Hickson and others. Responsive web design? Media Queries came from Opera, and were implemented for years before showing up in other browsers. What about native video on the Web? Opera again.
On Wednesday news broke that Opera was going to support some Webkit CSS vendor prefixes. On its surface I thought this wasn't exactly big news. There was a good deal of hubbub about this back in February (Browser Makers Caving to Vendor Prefix Misuse) when word got out that Mozilla, Opera and Microsoft were all considering supporting the -webkit prefix.
I think it's fair to say that the first two tactics haven't worked. In light of that, it was just a matter of time before the browser makers would start supporting the dominant codebase — even if it's only dominant because of developer misuse.
Now Opera is catching a lot of heat from people for caving. Some are pointing to Microsoft's statement that it won't support the -webkit prefix as an example of how not to play the game. Others feel betrayed that Opera, often the most standards-compliant of all the browsers, would now make such a move. Few of these people consider the business case for Opera. Opera has dominated the mobile market, and when web sites don't render properly — because of a developer who is either not coding to standards or is not including the -o prefix alongside the -webkit prefix — users may move to the browser that doesn't look broken. Opera is making a business decision to protect itself.
Wednesday on Twitter I placed the blame at the feet of lazy web developers. I still feel that way. My previous posts on this topic have been clear on this. If web developers took the time to learn the specifications, look at code generated by editors (if they use them), tested in other browsers, and shed their myopic view of how people surf, we would not be in this position. Developers can fix the code, see errors when testing, and otherwise not cut corners. I suspect there are lots of developers who know this and lots more who can be educated by the names and voices on the web now.
And then I saw this, retweeted by Zeldman, possibly in a show of support:
I don't include the -o- prefix because I don't test in Opera because it accounts for 0.3% of our visitors. Not because I'm lazy or inept.
If her percentage is not hyperbole and applies to all the sites she manages, then the time it took her to see those numbers and produce that tweet is about how long it takes to open Opera and paste in a web address.
This is why the browser makers are caving. This attitude is pervasive. Hers is just one example. I have seen similar comments around the web, ranging from those who have no idea what browsers visit their sites to those who just don't care. Telling someone they are wrong, myopic, and definitely not serving the needs of their users, clients, or even the rest of the web, just causes that person to ignore you or lash out.
You can run the math yourself using the percentage in the tweet. Take a site with a million visitors and you'll see that 0.3% is 3,000 users. In accessibility circles, that's an unacceptable number of users to shut out. Imagine 0.3% is an acceptable number to ignore on a larger site, perhaps even as big as Facebook with 800 million users. At 0.3% that's 2.4 million users. At what number of users is 0.3% acceptable? How many developers of large sites feel bolstered by such an attitude, reinforcing their own poor habits?
The question to web developers really should be, how many users are you willing to sacrifice because you are too lazy to open a browser and at least look?
This example of webs.com shows that just opening the home page in Opera would have shown it's broken, meaning either they didn't look or they don't care. In Opera it looks like this (as compared to Safari), hiding its main sales pitch (the issue starts at line 86 of the webs.com CSS file):
There just isn't an excuse. Stop blaming the browsers and the editors and instead review your code and test in browsers.
Related
Opera confirms WebKit prefix usage at .net Magazine. Read the comments, they include an Opera employee explaining the reasoning behind the -webkit support.
Opera has posted the announcement about the vendor prefix changes: Opera Mobile Emulator build with experimental WebKit prefix support. If you read through it, you will see only 13 -webkit properties (shadow, transform, border, transition) which are just being aliased to existing -o prefixes. It looks like Opera is not trying to mimic how Webkit renders the styles, only map the prefixes to Opera's existing support.
Update April 30, 2012
More posts and articles have surfaced over the weekend and today. I link them here:
CAFBank and Server Side User Agent Sniffing from Opera, showing how a bank ignores a 5-year-old request from users and Opera to stop explicitly blocking Opera. An example of blocking for no good (presented) reason.
Update July 6, 2012
Thiemo Mättig tried to comment below, but had trouble with the form. He let me know that he reached out to Webs.com to notify them of the bad CSS I mention above. All Webs.com did was add a solid background color, no -o- prefix and no unprefixed version.
Amazon's long-awaited tablet/e-reader was formally announced today, and the conversations about whether or not it will compete the iPad are underway. I don't much care about that. I am far more interested in the web browser that it includes.
Amazon Silk is a new web browser, built on Webkit, and that is really the news of interest here. Add to that Amazon's super-proxy approach to help users get content more quickly and efficiently and you've now got a new pile of potential chaos as a web developer. It's far too early to tell how this will shake out, but in a client meeting today I already had to address it, so I think it warrants a little context for the current state of browsers so we can consider potential developer impact.
The 400+ comments raise some questions that tend toward a common theme — in the absence of a technical explanation, when can we get our hands on an emulator? Granted, there are plenty of comments about privacy, security, and some wild speculation, but the theme is clear.
As a web developer, I can tell you that we all feel overburdened with the assault of browsers we have out there already. We can champion the ideal of targeting the specs, not the browser, but when the clients call to complain about a rendering difference, not even a problem, on another browser it can get pretty draining. As Silk comes to market we'll need to account for it, its hardware configurations, and its coming release versions (within reason, of course).
For some context about the burden we already have, yesterday Google Chrome developer Paul Irish wrote that, only taking into consideration Internet Explorer for desktop, we're already on track to need to support 76 versions of just Internet Explorer (including version 8) through 2020. There are some broad assumptions in his article regarding how people will use the IE document modes, but the potential is still there. Add to that the new release schedule of many browsers (Firefox has gone from version 5 to 7 in ~90 days), and then pile on the browsers available for mobile devices, and we're already at well beyond the number of variations of browsers that we had to support even in the heyday of the browser wars.
But Silk isn't just a web browser — it's got a super-charged proxy server that will compress images, compile JavaScript into its own machine-readable format, and batch files into a singular, smaller download. While this is nothing new (Opera Mini has done this for some time on mobile devices), Amazon's implementation raises the hairs on the back of my neck when I think about all the years I've had to troubleshoot web applications because proxy servers are caching files, munging JavaScript, brutalizing images, and generally gutting the real-time features that the web had been moving toward more and more. I don't know if this will happen with Amazon Silk, but given my experience with Opera, proxy servers, and users in general, I am filled with apprehension.
Related
Opera responded to the Amazon Silk announcement with its own explanation of how its own "cloud-compression" technology works:
Earlier this week CBS News ran the above image on its site in the Tech Talk section (within the topic Wired for Women, which doesn't seem to have anything to do with women) under the article An infographic! If web browsers were wrestlers... As is common nowadays, any illustration with numbers and witty (or not-so-witty) accompanying images is being called an infographic, and this is no exception. I do think the title is a bit tongue-in-cheek and CBS knows that this image isn't exactly fact-based.
The firm CBS hired to develop the graphic ranked each browser by market share, innovation, flexibility and speed — all the important factors. I disagree, however, that these are the important factors. Innovation means different things to different users, for example. As a web developer, I might like new HTML5 support, but my dad might prefer bigger buttons and less clutter. I have a different set of factors that I think are far more important:
Performance: How well the browser can render a page without choking, whether by slowing down or introducing image artifacts, or just crashing.
Standards Support: With the constant revisions to the still-in-development CSS3 and HTML5 specifications, along with related specs, this is even more important given the moving targets.
Ease of Use: This includes accessibility and usability. Can my mom use the browser without having to call me? On top of that, how about a power user, how easy to use is it for that audience?
Install Base: This is more than just who has chosen to download it, but should include who is forced to use it by corporate policy, lack of technical knowledge, hardware limitations, or public access.
I found another image that I think more accurately reflects the state of the battle between browsers (it rightly ignores Rockmelt and portrays Internet Explorer appropriately):
Bit Rebels took an old illustration of browsers as celebrities, posted it, and claimed it as an infographic: If Web Browsers Were Celebrities [Infographic]. It may be time for a web-wide infographic intervention.
Today Opera Software released data about how users of its Opera Mini mobile web browser use the web. Opera does this periodically to give some insight into how its users may be surfing, but what we don't know is how much Opera Mini users correspond to the web in general. Opera is certainly motivated to capture as much of the mobile market as it can given its low appearance numbers on desktops. Regardless, the title of the report really distills down Opera's findings: Generation Y chooses the mobile Web. You can get all the details from this and prior surveys at Opera's State of the Mobile Web site. Some of the highlights:
Almost 90% of respondents in the United States aged 18-27 have used their phones to share pictures. Of the profiled countries, Vietnam &8212; at 67% &7212; had the lowest use of mobile phones to share pictures.
Respondents in the United States are least likely to have asked someone out on a date via SMS (44%). Respondents in China (84%), Germany (84%) and Vietnam (83%) are most likely to have used SMS texts to ask someone out on a date.
Generation Y in both China and the United States share a disdain for printed newspapers. 53% of respondents in the United States and 57% of respondents in China rarely or never read physical newspapers.
Watch your privacy policies. Respondents in South Africa (49%) and the United States (44%) were somewhat to very uncomfortable sharing their personal information online.
Last week ReadWriteWeb reported that YouTube use on mobile devices has been on the rise — 75% of surveyed mobile YouTube users saying that their mobile device is the primary way of accessing YouTube (YouTube Mobile Use Exploding: 75% Report Mobile is Primary Way of Watching YouTube). This number, however, should be considered in context. Only users of the mobile version of YouTube (typically the YouTube app installed on a phone) were surveyed, so you can expect a far larger percentage of respondents relying on the mobile version as opposed to the general public. This doesn't, for example, track the users who might come across a page on your site with your corporate YouTube video. Since YouTube is often used for casual surfing, not so much business use, it makes sense that a meme discussed over beers with friends might result in a smartphone popping out to track down the video everyone is referencing.
Brian Solis was kind enough to take the data from the Ad-ology report, Twitter Users in the United States, and distill it down to some manageable chunks of data in his post Who are All of These Tweeple? In short, Twitter users tend to range between 18 and 34 (which is a big range) are white and have at least some college education. Again, cross-referencing with the data we've gathered from other surveys, we see a continuation of some trends toward younger more savvy users. There aren't lots of surprises in the report, but there are some numbers that can at least provide a little more detail to what we already expect. For example:
57.7% of Twitter users use the Internet more than three hours per day for personal use (outside of school or work) and are considered "heavy Internet users."
Back in June Nielsen released a report with a telling title: Social Networks/Blogs Now Account for One in Every Four and a Half Minutes Online. Four of the most popular destinations on the web are Google, Facebook, Youtube and Wikipedia. All of these enjoy a lot of use from users on mobile devices (well, perhaps not so much Wikipedia, but people are still looking things up in bars after tracking down the YouTube video). While the article is silent on mobile use, a skilled reader can apply mobile trends to the overall traffic and begin to see part of the reason mobile has been climbing.
If you believe this article from June, Social Media is the 3rd Era of the Web, then you can expect to see the numbers of social media sites to continue to climb and ages of users continue to stay young, even as older users get on board. As part of that, mobile use will continue to climb as people want to stay socially connected wherever they are.
The trick among reports and studies is to figure out how the data was gathered, who performed the gathering, why they did it and who participated. If you can validate that a study has any merit, then you can start to cross-reference it with other reports and piles of data to tease out some meaning.
It seems the day after Thanksgiving is a good day for people to post more details about Internet use. I won't distill them here (I haven't had a chance to read them in detail), but here are a couple more chunks of stats and data to review while you digest.
I'm going to make the assumption that if you are reading this you have at least a passing interest in typography on the web and have heard about Google's new font preview tool. There are already plenty of articles talking about how easy it is, how Google hosts the typefaces, how licensing isn't an issue, and so on. Some of them are linked at the end of this article, so go read up. As such, let me just dive right into the piece I find most interesting — the implementation.
I started to play around with Google Font Previewer by dropping code samples onto my development site. I tried to see how many typefaces I could embed, how I could mesh the code into my site, how easy it would be, and how it would look in different browsers. The screen shot below (from Google Chrome) shows my site with three of the typefaces in place: Molengo for the overall copy, IM Fell DW Pica SC for the headlines, and Reenie Beanie for the banner text with my name. You won't see this on my live site because this is, after all, only a test and I am not writing a ransom note.
In order to use these typefaces I needed to drop three references to the Google typefaces into the head of my document (one for each typeface):
From there I simply found the appropriate selectors in my CSS file and added the following styles (you'll note that I edited them heavily from what the tool provides):
You can see that I played around with font sizes (switching between using ems and pixels), font weight, drop shadows, and even adding an alternate font in case the user cannot see the selected typeface. I then loaded up my most current browsers on my Windows machine (my Mac and Ubuntu machines are hiding) and ran the site through each, comparing and contrasting. The image below shows a representative slice of the page with all three typefaces loaded in each browser. Click the image (or use whatever input device you prefer, such as your meatstick) to see the full-size screen shot. Browsers used in the test:
Internet Explorer 8
Chrome 5.0.375.99
Safari 5.0 (7533.16)
Firefox 3.6.7
Opera 10.6
I noticed the browsers were generally consistent on the font scaling and weight, with minor differences in anti-aliasing and line-height. Shadows showed greater variance among the browsers. Opera seemed to have a whole different idea of font weight, size, and anti-aliasing, but wasn't so far out of the park that it was unusable. Most interesting was how punctuation was treated. Note how only Internet Explorer and Opera show the commas in the tag-line under my name, or after the word "project" in the first sentence. Chrome, Safari, and Firefox each lost the commas altogether. While I am comfortable with the other display differences, losing punctuation is a deal killer for me.
Overall, the Google Font Previewer is a great way to quickly select and style type, drop it into your pages, and get it done quickly enough to go get an ice cream before your Dallas reruns. However, take some time to clean up the CSS it provides so that it matches your site coding style and isn't full of unnecessary declarations (do you really need to define word-spacing if you aren't changing the browser defaults?). Consider adding other, standard typefaces into the list as back-ups. Once you've done that, make sure you fire up your newly-typographized page in a few different browsers and are comfortable with the results. Those punctuation marks can be a killer, so check those. Don't limit yourself to your own browsers, either. Go find some variety and give the page a spin in alternative browsers, older browsers, and even mobile devices. You just might find that you added a style that works well with current browsers, but blows up the version of Netscape 4.x sitting on your grandmama's old Centris 610.
Yesterday 
It's old news by this Thursday morning, but in case you had not heard, 
Web developers have been looking to call 
On Wednesday news broke that Opera was going to support some Webkit CSS vendor prefixes. On its surface I thought this wasn't exactly big news. There was a good deal of hubbub about this back in February (
