All of This Has Happened Before and Will Happen Again

Jacob Rossi from Microsoft put together an article for Smashing Magazine that discusses Microsoft's Project Spartan web browser, Inside Microsoft’s New Rendering Engine For The “Project Spartan”.

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]

Jones

« 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»…

Erick G.

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 challenge many of the incorrect 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.

Do you think that won't happen? Just look to Android browser fragmentation, or WebKit failing to support a standard that Firefox and IE have nailed, or Chrome introducing its own proprietary features (can't find the link; it's coming), or failing to use best practices as it tries to carry the next big thing forward, or the complete lack of developer relations from Apple. We've had over half a decade of warning signs.

It's happening again, and every petulant, lazy developer who calls for a WebKit-only world is responsible.

Related

• The Return of “Best Viewed in…”
• Everything Will Be the New IE6

Update: February 3, 2015

My rant continues in my post Best Viewed in 1 of 11 Flavors of Chrome! It's built off PPK's Chrome continues to fall apart at brisk pace. Even I didn't know there are so many Chromium variants.

My Kingdom for Decimal Alignment on Numbers

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.

Three Browsers in One: Lunascape

I like to think I'm pretty smart about web browsers, sporting four on my mobile phone and six on my desktop computer in regular day-to-day use. Heck, I even started the evolt.org browser archive back in 1999 with 80 unique browsers at the time (which I am pimping to the W3C Web History Community Group).

But then this tweet came through my timeline:

Turns out there is a three-engine WebKit/Gecko/Trident browser en.wikipedia.org/wiki/Lunascape Uh.

— Sylvain Galineau (@sgalineau) May 24, 2012

How did I miss this?

So I went to the Lunascape Wikipedia article, and then to the Lunascape English site and promptly downloaded it.

It's too early for me to review it, but I did run a quick check to see how it reports itself in the user agent string as compared to the browsers whose core rendering engines it is using. My results...

Trident

Internet Explorer version 9 reports itself as:

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)

Lunascape, when using the Trident rendering engine, reports itself as:

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; BRI/2; InfoPath.3; Lunascape 6.7.1.25446)

Gecko

Firefox 12 reports itself as:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0

When using the Gecko rendering engine, Lunascape reports itself as:

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120410 Firefox/3.6.28 Lunascape/6.7.1.25446

Webkit

Chrome 19 reports itself as:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5

Safari 5.1.2 for Windows reports itself as:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7

Under the Webkit engine, Lunascape reports itself as:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.3 (KHTML, like Gecko) Lunascape/6.7.1.25446 Safari/535.3

Conclusions

It looks like Lunascape doesn't share the rendering engines for Gecko and Webkit with the browsers in which we've come to associate them.

Beyond that, I have no conclusions. I was just looking at the UA string and figured others might find it interesting and/or useful.

Amazon Silk, Yet Another Web Browser

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.

Amazon posted a video on its brand new blog to provide an overview of Silk (with an obligatory Geocities reference):

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:

• Amazon’s Silk Web Browser Adds New Twist to Old Idea at ars technica.
• Amazon Launches Silk Web Browser for Tablets at Mashable.
• Amazon Silk browser spins a faster mobile web, courtesy of cloud servers (video) at Engadget.
• Opera: Amazon's Silk Browser is Flattering, But Five Years Late at PCMag.
• Amazon's Silk Browser May Not Be Smooth When It Comes to Privacy at PCWorld.
• Amazon's Silk browser one-ups Opera's approach to the Web at InfoWorld.
• The Implications of Amazon's Silk Web Browser at ReadWriteWeb

Browsers as Wrestlers "Infographic"

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:

1. Performance: How well the browser can render a page without choking, whether by slowing down or introducing image artifacts, or just crashing.
2. 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.
3. 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?
4. 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.

CBS gave each browser a chance to respond/defend itself, specifically Firefox, Chrome, Internet Explorer, Opera, Rockmelt, and Safari. Opera even took it a step further and wrote up a response on its blog, Speed, Innovation, and Flexibility in the Ring.

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):

Credit for the above image goes to Galit Weisberg, from The Shoze Blog. Now go to TechCrunch and tell MG Siegler that he stole the image.

Update August 25, 2011

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.

Chrome and Mozilla Announce Tracking Blockers

Last month Microsoft announced that Internet Explorer will be adding a "tracking protection" feature to its browser, allowing users to prevent advertising sites from tracking their activity on the web (ad targeting, really). This move was partly to stay ahead of an FTC push to mandate that browser makers add that feature. If you spent that few days between Christmas and New Year's hiding from computers and family, then perhaps you missed my post, Browsers to Add Tracking Blockers.

In that post I mentioned how Firefox had started the work, pulled it, and then brought it back. Well now it's official. You can read up on how it works at the Mozilla Wiki, where they were kind enough to put together a DoNotTrack FAQ. The FAQ helps readers understand that this is not the solution that will ultimately be implemented, since it relies on an HTTP header.

Google is relying on a cookie-based approach via a browser add-on. The only real difference from the voluntary Network Advertising Initiative that allows users to opt-out, which relies on cookies, is that the Chrome add-on won't blow away those cookies when a user clears all other cookies on his/her browser. You can read up on the confusingly-named Keep My Opt-Outs on one of the Google blogs (there are so darn many).

I suggest that if you plan on using these new features, which are not enabled by default and require some level of configuration to be useful, that you take a few minutes to read up on them:

• Mozilla, Google take different approaches to ad tracking opt-out at ars technica.
• Mozilla & Google Announce Browser "Do Not Track" Features at Mashable.
• Firefox and Chrome Add "Do Not Track" Tools To Their Browsers at ReadWriteWeb.
• Web Tool On Firefox To Deter Tracking at Wall Street Journal.
• Protecting Consumer Privacy in an Era of Rapid Change, preliminary FTC staff report (PDF).
• Self-Regulatory Program for Online Behavioral Advertising
• Network Advertising Initiative
• chrome-opt-out-extension at Google code blog.
• Keep My Opt-Outs from the Chrome web store.
• More Choice and Control Over Online Tracking from the personal blog of the Global Privacy and Public Policy Leader at Mozilla.
• Thoughts on Do-Not-Track from Michael Hanson, Mozilla Labs.

Updates

• Big browsers hop aboard the 'Do Not Track' train at New Scientist, Jan. 27, 2011.

Browsers to Add Tracking Blockers

This may be somewhat old news by now, but given the hubbub last night that Apple and some makers of apps for the iPhone are getting sued over tracking users without consent, it seems that the struggle between privacy and features will never be old news.

Back at the dawn of the web, the notion of surfing anonymously was pretty compelling. Users in the early days had enough technical know-how to understand that privacy could not be guaranteed and at the very least a combination of IP logging and old-fashioned real-world tracking could often get an interested party the identity of someone engaging in nefarious activity. The key benefit to that process (for users) is that for most organizations it wasn't worth the bother (either time or money). Privacy was maintained simply for lack of effort.

Fast forward to today's world where online ads can track your habits and preferences, where Facebook is regularly lambasted for sharing too much information, where mobile devices can track where you are at any time, where people use social media with the curious expectation that they are guaranteed some privacy, and so on...

Microsoft sees this as an opportunity to push its coming web browser, Internet Explorer 9, to the fore by offering a new feature called Tracking Protection. Microsoft will be rolling this feature out in the next beta release due early in 2011. In Microsoft's words, the feature will do the following:

1. IE9 will offer consumers a new opt-in mechanism ("Tracking Protection") to identify and block many forms of undesired tracking.
2. "Tracking Protection Lists" will enable consumers to control what third-party site content can track them when they're online.

This is a little different from the Federal Trade Commission's request that browser makers implement a "do not track" feature. In the FTC's world, this feature sets a flag for all sites you visit asking the web site and/or ad service not to track you. The FTC cannot force anyone to honor that, however, so it's a mostly empty request. This is where the IE9 feature is so compelling — it's intended to just block the tracking outright.

Mozilla isn't missing the boat on this. Even though a similar feature was in development in June, it was pulled (for conflicting reasons) but made its reappearance just a few days ago. Mozilla's chief executive stated in an interview that [t]echnology that supports something like a 'Do Not Track' button is needed and we will deliver in the first part of next year. He was speaking about Firefox 4, which is still in beta. This puts Firefox's offering out there around the same time as IE9's.

Now that two major browsers will be developing a feature in parallel with a similar name and set of functionality, it will be interesting to see how it is implemented. While the features both Microsoft and Mozilla are discussing have mostly been in both browsers in some form since the last full release, activating those features isn't exactly intuitive for the novice user. Now comes the struggle of creating a user interface that is simple, still provides enough detail and control, and isn't so far removed from the other browser's interface that users who use both aren't horribly confused.

Whether these features are enough to satisfy the FTC, consumers, or even the ad networks is still up in the air. Whether these features will be easy to use, however, seems unlikely given browser configuration options over the years. If that happens, it may end up protecting ad networks for now.

Related

• Apple, App Makers Sued Over User-Tracking at Wired, December 27, 2010.
• 'Do Not Track' Coming to Firefox 4 at PCWorld, December 21, 2010.
• Firefox backs "Do Not Track" with online stealth at Google News, December 18, 2010.
• Privacy and the Web's 'signal-to-noise ratio' at CNN, December 15, 2010.
• Microsoft Builds Online Tracking Blocking Feature Into IE9 at Wired, December 7, 2010
• IE9 and Privacy: Introducing Tracking Protection at Microsoft's IE9 blog, December 7, 2010.
• IE9 "Do Not Track" Feature Prone to User Error at PCWorld, December 7, 2010.
• FTC Staff Issues Privacy Report Offers Framework for Consumers, Businesses, and Policymakers at FTC.gov, December 1, 2010.
• Hiding Online Footprints at Wall Street Journal, November 30, 2010.
• Question of the Day: Would you use an Internet “do-not-track” tool if it were included in your Web browser? at Wall Street Journal.

Related on this blog

• Google Analytics Opt-Out Add-On Is Out, May 26, 2010.
• Google to Let Users Opt Out of Analytics Tracking, March 19, 2010.
• Google Dashboard: What Google Knows about You, November 5, 2009.

Updated: January 24, 2011

• Firefox and Chrome Add "Do Not Track" Tools To Their Browsers

Trying Google Font Previewer

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):

<link href="//fonts.googleapis.com/css?family=Molengo:regular" rel="stylesheet" type="text/css">
<link href="//fonts.googleapis.com/css?family=Reenie+Beanie:regular" rel="stylesheet" type="text/css">
<link href="//fonts.googleapis.com/css?family=IM+Fell+DW+Pica+SC:regular" rel="stylesheet" type="text/css">

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):

body {
  font-family: 'Molengo', Trebuchet, sans-serif;
  font-size: .82em;
  font-weight: 400;
  word-spacing: -0.1em;
  line-height: 1.6em; }

h1 {
  font-family: 'IM Fell DW Pica SC', serif;
  font-size: 25px;
  text-shadow: 2px 2px 2px #333;
  line-height: 1em; }

#Banner p#Title {
  font-family: 'Reenie Beanie', serif;
  font-size: 100px;
  font-weight: 600;
  text-shadow: 4px 4px 4px #333;
  line-height: 1em; }

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.

Related

• New Google Font Previewer - Webfonts Easier and More Fun
• Google Font Previewer
• Test Drive Your Type With Google Font Preview
• HOW TO: Implement Google Font API on Your Website
• Google Makes Custom Web Typography Ridiculously Easy

Does Your Browser Really Support HTML5 and CSS3?

I like reading rants. And by rants, I mean well-thought, researched, articulate arguments that are the result of a festering pool of frustration finally shooting out and being channeled into something constructive. Not the rants you might find on bathroom stalls.

Thanks to the Twitters I came across a blog with a two-part rant about HTML5 and browsers. It echoes rants I've read or written 10 years ago, the result of chafing against browser makers and developers buying into standards too soon, chastising each other based on unfounded data, and blind faith in one option over another despite overwhelming data to the contrary.

I watched people say HotJava would save us from Mosaic, Netscape would save us from HotJava, NetShark from Netscape, Internet Explorer from the internet, Mozilla from Internet Explorer, Opera from everyone, Firefox from Mozilla, Safari from ourselves, Chrome from whatever is left, and so on. It's been done, we're looping back through. Examples other than browsers? HTML 3 from HTML 2, HTML 4 from HTML 3, ISO HTML from something, XHTML 1 from HTML 4; JSSS from font tags, CSS from font tags, CSS 2 from CSS 1, CSS 3 from communists; PNG from UNISYS; MNG from animated GIF; Flash from Shockwave, Silverlight from Flash, HTML5 (and CSS3 and JavaScript) from Flash; VRML from boring pages; Quicktime from AVI, Windows Media from Quicktime, YouTube from Windows Media, Ogg Theora from YouTube, H.264 from Theora, VP8 (WebM) from H.264. And on...

The point of all that comes down to the fact that things change. Quickly. Especially on the web. Relying on an unfinished spec (HTML5) to build your browser support and/or code your pages is full of risk, risk that is passed on to end users and clients. There is a tangible cost to go back and fix things that short-sighted developers implemented, whether by making corporate Help Desks do company-wide upgrades (or making the poor kid down the street do it for smaller companies) or by making clients pay to fix something on their sites that should never have been implemented to begin with.

Cue the rant. Lars Gunther has written a piece that breaks down actual browser support versus marketing statements of browser support, taking Webkit in particular to task (No browser supports HTML5 yet. Part 1. The rant.). His points ring true (even though he also discusses CSS3), especially if you have been in the web world long enough to witness the browser wars from the 90s. Some key statements:

...[O]nce someone has started to claim support for a feature, even though that support is half baked and incomplete, everyone else has to answer in kind, and claim support even when their implementations are equally half-baked. Or even worse, rush out such half baked implementations to the market to show everyone that they are also a leader.

We've seen this in the half-baked support for PNG images in Internet Explorer for years. We've already experienced this abrupt deployment of incomplete features for a decade, and now Apple happens to be the company doing this via Webkit. It was terrible when Microsoft did it, but somehow it's not raising any hackles this time out.

...[W]e tend to put up demos of new cool technologies that are not really examples of best practice, e.g. even though transformations and transitions work in the latest versions of Firefox and Opera, many demos use the webkit prefix only.

Given how many young and/or inexperienced developers still get by with the thieving of source code, add in some prior experience with IE-specific hacks, and we are running the risk of developers implementing features incorrectly, even when other browsers may have supported a spec for years.

In part 2 of the rant (No browser supports HTML5 yet. Part 2. Technology.), the author proceeds to back up his points with some data. He pulls out three aspects of HTML5 that Safari and Chrome (as examples) both claim to support but really do not.

The world of HTML forms has opened up a lot in HTML5, allowing many different types of input elements, for example. In addition, accessibility is built into the spec for these elements from the start:

At the moment neither Webkit nor Gecko (nor Opera) is nowhere near having a complete HTML5 web forms support. They all lack some features and they all lack accessibility.

Sectioning elements, such as the oft-confused section and article elements, need to be accessible via the DOM to more than just styling:

...[S]ectioning elements affect document outline and that should in turn be exposed to seeing users through varying sizes on the headings and to non-sighted users through their assistive technologies. [...] Being able to style a sectioning element is actually a bullshit claim. HTML5 mandates that one should be able to style any unknown element. That is, a browser vendor could claim that they support the , and elements, since according to HTML5, they should!

The hgroup and nav elements were designed to hide subtitles from the DOM outline and to provide greater accessibility for accessing navigation, respectively. Their functions are pretty clearly laid out in the specification.

There is no browser on the market that supports these behaviors. Indeed, to my knowledge, no browser even has begun working in earnest on this.

These are each examples that one or another browser vendor claims it supports, when it really does not.

As I have done for prior specifications over many years, all I can do is remind people not to get caught up in the marketing hype and the gee-whiz factor of the technology. Understanding your users, their available browser features, and the business cases for implementing a particular technology are the better methods for guiding how you should build for the web. If you want to play with the cool new gadgets and features, do it on your own time, don't make your users or clients pay for it.

Firefox 4: Planned Features

Mike Beltzner, Mozilla's Director of Firefox, yesterday presented an early product plan for Firefox 4 to the Mozilla community. He followed up with a blog post outlining the presentation and linking to some resources. He is careful to regularly state in his post and throughout his slide presentation that these are just plans, nothing is built and everything may change. He links to the OGG version of the presentation video and also embeds the slide presentation from SlideShare on his. Which I am reposting here:

To quote his primary goals for Firefox 4:

• Fast: making Firefox super-duper fast
• Powerful: enabling new open, standard Web technologies (HTML5 and beyond!),
• Empowering: putting users in full control of their browser, data, and Web experience.

His plan puts Firefox 4 arriving around October 2010 (with the beta arriving around June). Firefox 3.7 was going to include out-of-process plug-ins, but those are being moved into 3.6.4, essentially removing 3.7 from the lifecycle.

Today the Mozilla Hacks blog has a post on the new HTML5 parser coming in Firefox 4. Gecko's old (current) HTML parser dates back to 1998, well before HTML5 was even on the drawing board. There are four key improvements in the new parser, according to Mozilla:

1. You can now use SVG and MathML inline in HTML5 pages, without XML namespaces.
2. Parsing is now done off Firefox's main UI thread, improving overall browser responsiveness.
3. It's improved the speed of innerHTML calls by about 20%.
4. With the landing of the new parser we've fixed dozens of long-standing parser related bugs.

The rest of the post goes into detail with SVG and MathML examples. It's worth reading if you're... me, I suppose.

All of this is fine and dandy for developers, but not much of these new features interest end users. Unlike Internet Explorer and, to some extent, Safari, Firefox users tend to be a bit more savvy and are interested in upgrading the browser when new releases come out. Because of that, adoption of Firefox 4 should move along pretty well.

End users will benefit from planned security enhancements, stability improvements, and speed enhancements, and this should be enough to pull most users along into the upgrade path. There are also plans to add more personalization features into the browser. All of this, however, is up for grabs. The only certain item so far is the progress that has already been made on the HTML5 parser, which will be a boon to users if more companies move away from Flash, proprietary video, or just start to use HTML5 and CSS3 more on their sites. iPad and iPhone users, however, won't benefit from a browser they cannot install.

Mozilla to Modify How CSS :visited Works

If you know CSS, then you know that the :visited pseudo-class is a method to determine if a user has already been to the link it targets. For example, you may have styles for a:link and a:visited in your CSS file to help users see a difference between links they've clicked and links they haven't. Combine this with the getComputerStyle method in JavaScript and an author can conceivably figure out all the sites you've visited. This issue has prompted Mozilla to announce changes to how the :visited selector will work.

The Mozilla Hacks blog outlines how these changes will affect web sites and web developers. At the high level:

• getComputedStyle (and similar functions like querySelector) will lie. They will always return values as if a user has never visited a site.
• You will still be able to visually style visited links, but you're severely limited in what you can use. Mozilla is limiting the CSS properties that can be used to style visited links to color, background-color, border-*-color, and outline-color and the color parts of the fill and stroke properties. For any other parts of the style for visited links, the style for unvisited links is used instead. In addition, for the list of properties you can change above, you won't be able to set rgba() or hsla() colors or transparent on them.

They also note some subtle changes to how selectors will work. Mozilla acknowledges that these two items might be confusing and has promised some examples in the near future.

• If you use a sibling selector (combinator) like :visited + span then the span will be styled as if the link were unvisited.
• If you're using nested link elements (rare) and the element being matched is different than the link whose presence in history is being tested, then the element will be drawn as if the link were unvisited as well.

The blog post points out a couple of areas that will probably require changes to existing sites:

• If you're using background images to style links and indicate if they are visited, that will no longer work.
• Mozilla won't support CSS Transitions that related to visitedness (I think they made that word up). There isn't that much CSS Transition content on the web, so this is unlikely to affect very many people.

Right now Mozilla cannot say what version of Firefox will get this change, but the post is intended to get us all ready for the impact in advance of that release.

Mozilla does admit that this won't fix all the potential security leaks of your browsing history (see the bug report). They do offer an option for minimizing your exposure to the other leaks, or to minimize yourself in your current release of Firefox until they get the fixes out:

...[V]ersion 3.5 and newer versions of Firefox already allow you to disable all visited styling (immediately stops this attack) by setting the layout.css.visited_links_enabled option in about:config to false. While this will plug the history leak, you'll no longer see any visited styling anywhere.

Read more:

• privacy-related changes coming to CSS :vistited
• Plugging the CSS History Leak
• Preventing attacks on a user's history through CSS :visited selectors
• Bug 147777 - :visited support allows queries into global history
• What the Internet knows about you. This page checks your browser history and determines which of the 5000 most popular Internet websites you've recently visited.

January 2010 Browser Stats

Mashable has posted information about browser usage (Browser Usage Stats: Chrome Grows While IE and Firefox Shrink) stats from Net Applications. In short, Chrome continues its climb at the expense of Explorer and Firefox. The original data comes from January of 2010 and shows that Chrome has gained 0.57% to get to 5.20% of browser share. Firefox dropped (-0.20% to 24.41%) as did Internet Explorer (-0.51% to 62.18%). Opera and Safari hardly moved.

It's no surprise Chrome has climbed. It's a good browser for those who are technically inclined and don't need all the bloated features of the other browsers. It's speed (especially with JavaScript) and memory management have made it my default browser on my Ubuntu netbook, even though it still has issues rendering Facebook's message inbox and photo gallery management tools. Even though Firefox 3.6 was just released, the average user won't see a huge benefit from switching browsers and probably won't bother as a result (although I do like the new type support).

Internet Explorer is the troubling one in the mix. IE8 is now up to 22.31% of the market, but IE6 still beats out IE7 (20.07% and 14.58%, respectively). That equates to 1 in 5 users is still surfing on IE6, known for its security holes and buggy rendering.

Many people (web sites, developers, forums, etc.) have been calling for the demise of IE6 in some way for quite a while now. Google has just joined the list (Modern browsers for modern applications, from the Google blog), announcing that they will phase our support for IE6 in Google Docs and Google Sites as of March 1. You can see other sites (far smaller, for the most part) who are trying to push IE6 out to pasture, just visit ie6nomore.com. Whether or not this will speed the end of IE6's reign is to be seen. Catch up on some anti-IE6 articles at Mashable using their IE6 Must Die tag.

I am curious, though — am I the only one who still uses Lynx?

Firefox 3.6 Is Here

As you may have noticed in my warning tweet yesterday, Firefox 3.6 is out.

Firefox 3.6 was released today and is the very browser I am using to write this post. So far it hasn't blown up, and I abuse my browsers with tab counts around 70 or so. It's memory footprint isn't any smaller, but I am not terribly surprised by that. I am disappointed to find out that my HTML validator plug-in is not compatible, but it should be updated within a few days if prior experience is any guide. I would recommend against using the personas feature, the skins they put on your browser just make it harder to use when you have your toolbars full of buttons. You can grab your own copy from the Firefox 3.6 download page.

The Mozilla blog announced it today along with the following features and updates (copied from their post):

• New CSS3 features: Improve your style with support for gradients, multiple backgrounds, pointer-events and more.
• Drag and Drop: It has never been easier to move files from your desktop to the Web.  You can now drag content into the browser window and leverage the FileAPI for instant access to that content.
• File API: Support for the latest HTML5 specification allows Web applications to access local files and interact with them in new ways.
• Web Open Font Format (WOFF): Add a touch of typography to the Web with WOFF support, which makes even more possible than the existing support for OpenType and TrueType fonts.
• Device orientation: Discover new ways to manipulate and interact with Web content with access to the orientation of supported laptops and devices.
• XMLHttpRequest improvements and more…

Back in October I posted about coming support for Web Open Font Format (WOFF) in the post Firefox 3.6 to Support Web Open Font Format. In case it's not obvious by now, that is the feature I will be trying out the most in the next few days.

Firefox 3.6 to Support Web Open Font Format

Mozilla's developer blog today posted that they have added support for the Web Open Font Format (WOFF) to Firefox 3.6. Firefox 3.5 gave us support for linking to TrueType and OpenType fonts, but this takes it a step further to support a format that is more robust for two key reasons:

1. WOFF is a compressed format, resulting in files smaller than an equivalent TrueType or OpenType font.
2. It avoids DRM and domain labels by containing meta data about its source, garnering support from typeface designers and foundries.

If you want to see this in action, you'll need to grab a Firefox 3.6 nightly build until the full release is out the door. If you should feel compelled to do that, the nice folks at Mozilla have provided a sample block of CSS that uses the @font-face rule to link to a WOFF font:

@font-face {
  font-family: GentiumTest;
  src: url(fonts/GenR102.woff) format("woff"),
       url(fonts/GenR102.ttf) format("truetype");
}

body {
  font-family: GentiumTest, Times, Times New Roman, serif;
}

Structured this way, browsers that support the WOFF format will download the WOFF file. Other browsers that support @font-face but don’t yet support the WOFF format will use the TrueType version. (Note: IE support is a bit trickier, as discussed below). As WOFF is adopted more widely the need to include links to multiple font formats will diminish.

If you are fortunate enough to have a build of Firefox 3.6 already up and running on your machine, go to a test page using ff Meta set up by the nice folks at edenspiekermann (if part of the name is familiar, Erik Spiekerman is the designer of the Meta family, and if the typeface is familiar, it's what we use at Algonquin Studios). The image below shows how that page looks in Firefox 3.6 using ff Meta (left side) and how it looks rendered in Internet Explorer 8 (right side).

Because IE8 only supports the EOT format, the blog offers some code to account for IE8 in the CSS. Because IE8 doesn't understand the format hints, it will parse the hints as part of the URL, resulting in requests to the server for files that don't exist. The end user will see things just fine because of the EOT reference, but your logs will show some odd 404s as a result of this technique. The Mozilla post has more details on this and some other issues. The code to do this:

@font-face {
  font-family: GentiumTest;
  src: url(fonts/GenR102.eot);  /* for IE */
}
 
@font-face {
  font-family: GentiumTest;
  /* Works only in WOFF-enabled browsers */
  src: url(fonts/GenR102.woff) format("woff"); 
}

The main Mozilla blog has a post today listing the supporting organizations with the following endorsement:

We endorse the WOFF specification, with default same-origin loading restrictions, as a Web font format, and expect to license fonts for Web use in this format.

Updates

• font_dragr: a drag and drop preview tool for fonts
• after Firefox 3.6 – new font control features for designers

Current CSS3, HTML5 Support

The Tool

Last week saw the launch of FindMeByIp.com, a very handy web site that displays a user's current IP address (along with a geographic breakdown to city, if possible), user agent string (browser, version and operating system) and support for CSS3 and HTML5 (read the article about it). It accomplishes this last bit by using the Modernizr JavaScript library to test a series of features in your browser:

• @font-face
• Canvas
• Canvas Text
• HTML5 Audio
• HTML5 Video
• rgba()
• hsla()
• border-image
• border-radius
• box-shadow
• Multiple backgrounds
• opacity
• CSS Animations
• CSS Columns
• CSS Gradients
• CSS Reflections
• CSS 2D Transforms
• CSS 3D Transforms
• CSS Transitions
• Geolocation API

If you are running the Google Chrome for Internet Explorer plug-in, it will show up in your browser user agent string on this page. However, it will also report your Internet Explorer browser as Chrome.

The Results

The site developers ran their own browsers through this tool and that collection of information has been gathered up and posted to provide information on current browser support for the latest standards (or recommendations). Deep Blue Sky, one of the developers of this site, has written up the level of support in all the A-Grade browsers. Yahoo's model outlines A-Grade browsers as "... identified, capable, modern and common" and claims "approximately 96% of our audience enjoys an A-grade experience." This is their codified way of simply saying, "the latest common browsers." If you read my post, Browser Performance Chart, then you'll see the same browsers. The article, Browser support for CSS3 and HTML5, covers the following browsers (the author didn't test against anything other than Windows versions):

• Safari 4 (Win)
• Firefox 3.5 (Win)
• Google Chrome (Win)
• Opera 10 (Win)
• Internet Explorer 6, 7 & 8

The surprise in here is that Safari 4 outshone (outshined? outshinerified?) the others with Google Chrome coming up close behind. Firefox 3.5 was missing some key CSS3 support and Opera 10 was surprisingly lacking in support. As expected, Internet Explorer brings up the rear, lacking in everything but @font-face support (even in IE8) which has actually been there since version 6 (but only for the .eot format).

Browser Performance Chart

Jacob Gube has posted a handy chart over at Six Revisions titled "Performance Comparison of Major Web Browsers." He tests the current versions of five browsers:

• Mozilla Firefox 3.5
• Google Chrome 3.0
• Microsoft Internet Explorer 8.0
• Opera 10.0
• Apple Safari 4.0

In his tests he used the following performance indicators, tested three times each with an unprimed cache, and averaged the results:

• JavaScript speed
• average CPU usage under stress
• DOM selection
• CSS rendering speed
• page load time
• browser cache performance

When Google Chrome 3 was released in September, Google claimed a 150% increase in JavaScript performance from its previous version but didn't offer comparisons to other browsers. Opera also made improvement claims in its September release of Opera version 10, specifically a "40% faster engine." Those claims are also not made in comparison to other browsers. The overall performance ranking he assigns to the browsers isn't too much of a surprise, with Google Chrome as the best and Internet Explorer 8 as the worst. If he ran as many persistent tabs in Firefox as I do, it might not hold on to the #2 slot so easily. The ranking:

1. Google Chrome 3.0
2. Mozilla Firefox 3.5 (tied with Safari)
3. Safari (tied with Firefox)
4. Apple Safari 4.0
5. Microsoft Internet Explorer 8.0

Use the chart below to link to the full size version. You can also download the raw data in CSV format from the site in case you want to try your own hand at colorful charts.