When writing CSS3 properties, the modern wisdom is to list the “real” property last and the vendor prefixes first:

.not-a-square { -webkit-border-radius: 10px; -moz-border-radius: 10px; border-radius: 10px; }

Why is this method of ordering properties so commonly taught? Here is what it would look like “the wrong way”:

.not-a-square { border-radius: 10px; -moz-border-radius: 10px; -webkit-border-radius: 10px; }

Even doing it “the wrong way”, won’t the border radius be the same no matter what, forever? A quick investigation might lead you to conclude that it will, and this ordering of properties is rather nonsense.

1. The Long Long Ago: None of the properties are supported, order doesn’t matter.
2. The Past: Only vendor prefixes are supported, order doesn’t matter.
3. The Now: Both vendor prefixes and actual property are supported. If prefix is last, it will override actual property, but both are the same anyway.
4. The Future: Only actual property is supported, order doesn’t matter.

Here’s a simple chart with this concept at work.

Woah there, Cowboy

The fact is, the ordering of CSS3 properties is important, and the above is fundamentally flawed. “The Now” is exactly the problem. We are at a crucial juncture in browser history where some browsers are supporting both the vendor prefixed version and the actual CSS3 property. Right now it’s specifically WebKit that is doing this, and the way they have implemented it is that if you list the vendor prefix after the actual property, the vendor prefix will override and be the property that renders.

Why does that matter? In the simple border-radius example we saw above, either way, the corners on that element will have a border-radius of 10px. There is no difference in how the vendor prefix and “real” property handle rounded corners when you set only one value. The problem is that there is a difference between the implementations of the properties when passing more than one value.

.not-a-square { /* These do totally different things */ border-radius: 30px 10px; -webkit-border-radius: 30px 10px; }

The spec or “real” version will render the top left and bottom right corners at 30px and the top right and bottom left corners at 10px. The vendor prefix will render all four corners with elliptical corners 30px wide and 10px tall.

So if you’ve been blinding including the real border-radius at the end of your property lists using identical values, and then switch from Safari 4 to Safari 5, you’d see a dramatic change in how the above code was styling your boxes.

See here

You could fix this up by fiddling with the values to make sure they do the same thing… but if you are going to fiddle with anything, you might as well fiddle with the real property as that will be supported version in the future. Listing the real property last is definitely the way to go. Because it will be based entirely on the spec, it will match other browsers implementations, and will be the only supported version as time goes on and vendor prefixes are removed.

Border radius isn’t the only example here. Note the dramaticly different syntaxes for background-image gradients. Now there is no “real” spec version of these values yet, but when there is, the implementation will be different than what we are using now. That should be listed last in the ordering of the properties to future proof that as well.

Thanks to @mattwiebe and @snookca for helping me understand this better.

There are all kinds of reasons IPs get banned. A forums manager might ban an IP because the user at it is spamming. An admin of an email server might also ban IPs for spamming. A web service might ban an IP for using an API in an unapproved way.

On this site, we used to ban IP’s in the forums all the time (the new forums have been much better in spam prevention). I also sometimes ban IPs from inside WordPress. There is a setting to “blacklist” IP’s in the admin area on the Settings > Discussion page. There are few in there from spammers, and a variety of people I thought just shouldn’t come ’round here no more. In looking at this list now, some of these IP’s have been in here for years. Is that acceptable?

At the time of blockage, and IP address might belong to Danny Doucher, but after sometime, the IP address might be reassigned and now belong to Susie Supercool. I certainly wouldn’t want to punish Susie for Danny’s crimes.

So, how long should we ban IP’s for? Wikipedia, who certainly needs to deal with IP blocking on a regular basis, has a few choice words:

Most IP addresses should not be blocked more than a few hours, since the malicious user will probably move on by the time the block expires.

IP addresses should almost never be indefinitely blocked. Many IP addresses are dynamically assigned and change frequently from one person to the next, and even static IP addresses are periodically re-assigned or have different users. In cases of long-term vandalism from an IP address, consider blocks over a period of months or years instead. Long-term blocks should never be used for isolated incidents, regardless of the nature of their policy violation.

I can get on board with that. IP blocks should only last a limited time, since all IPs eventually change. Most blocks should be short, but if you experience long-term bad activity, make the ban longer. In the case of this site and WordPress, the Discussion Settings also offer a Moderation list, so you don’t actually have straight blacklist IP’s at all if you don’t want, and even if you do, you can move them from the blacklist to the moderation list after a while and be fine.

Anyone else have any theories or research to share?

These are way above and beyond the level of any other “CSS3 buttons” I’ve seen. Multiple backgrounds combining gradients and images, uneven border-radius, pseudo elements, HSL coloring, @font-face icons, transitions, box shadows, text shadows, hover and active states… the list goes on. Every trick in the book masterfully employed.

They make my button maker look dull and flat.

Direct Link to Article — Permalink

I saw that Andy Clarke had added a fluid width YouTube video to a particular page on one of his sites. His code relies upon a wrapping div and then images and video within this wrapper are set to the width of the wrapper:

.img img, .img object, img embed { width: 100%; }

I love the idea. It’s essentially the classic technique for dealing with images in fluid width designs. Andy’s code sets max-width to 100% here too, but since the width is already 100% that doesn’t matter. Max-width works best by itself. So it can scale down images which could be larger than the wrapper, but not scale them up if they are smaller. For video, scaling up is probably fine. I’d suggest this change:

.img img { max-width: 100%; } .img object, .img embed { width: 100%; }

That will scales images only down if needed, and videos up or down.

Keeping Aspect Ratios

With images, as long as there isn’t an inline “height” setting, the aspect radio will be maintained in a fluid width environment even when you only alter the width. With video (flash or otherwise) this is not the case. If we want to maintain aspect ratio while the video grows and shrinks in width, we’re going to need JavaScript.

Example YouTube Provided Code:

<object width="640" height="385"> <param name="movie" value="http://www.youtube.com/v/EWsWFjO9MlE?fs=1&amp;hl=en_US"></param> <param name="allowFullScreen" value="true"></param> <param name="allowscriptaccess" value="always"></param> <embed src="http://www.youtube.com/v/EWsWFjO9MlE?fs=1&amp;hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed> </object>

This is the plan:

1. Find original aspect ratio by dividing original height by width
2. When window is resized…
3. Measure width of parent
4. Set width of video to width of parent
5. Set height of video to width multiplied by aspect ratio
6. Trigger a fake resize on pageload to ensure video fits right away

Here, we’re using jQuery. Take note that we are target both the class name of .youtube and the embed within that class name. This is presupposing that we are adding a classname of .youtube to the object in the copy-and-paste code YouTube provides. Feel free to adjust the selectors as you wish. You may wish to target all objects themselves, or use a special wrapper. Here we’re using the #page-wrap of all the content to measure width.

<script src='http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js'></script> <script> var $origVideo = $(".youtube, .youtube embed"); var aspectRatio = $origVideo.attr("height") / $origVideo.attr("width"); $(window).resize(function() { var wrapWidth = $("#page-wrap").width(); $origVideo .width(wrapWidth) .height(wrapWidth * aspectRatio); }).trigger("resize"); </script>

Also of note here is that we are targeting the <object>s and the <embed>s within them with this JavaScript. Targeting the objects alone will work in modern browsers. Including the embed is fine for modern browsers and makes it work with Internet Explorer as well.

Bonus Trick

You can get rounded corners on your YouTube videos! The only luck I’ve had so far is in Google Chrome (7.0.503.0 dev).

1. Add this param to your embed (within the object) <embed wmode="opaque" ...
2. Then you can add border radius to the objectobject { border-radius: 10px; }

Credit to ubahnverleih on Forrst for the idea.

Demo & Download

View Demo   Download Files

UR DOIN IT WRG

This worked in all browsers I tried, including Internet Explorer (tested 7 & 8), but not Opera. The best I can tell is that Opera respects in the inline width and height attributes over those set via inline styling. If anyone knows of a way to fix that, or if you think my whole method here is stupid and you have something better, please let me know and I’ll update things here.

I’ve done my own The VERY Basics screencast, but this full series from Google, targeted at just-starting-out beginners, would be a good place to go directly after my intro, to take things further along.

Direct Link to Article — Permalink

When we first released the book Digging Into WordPress, we thought of some reasons why people might not want to buy it. A big reason is because tech books can go out of date quickly, especially when the subject is a fast-developing technology like WordPress. So, we fixed that. When you buy this book, you get PDF updates to it for life.

Today is just such an event. WordPress 3.0 has been out for a while now, and so it’s time for our second major update. This is the biggest one yet. We’ve combed through the entire book updating anything that was out of date or stale. We’ve also added a new Chapter 12, which is specific to the 3.0 update. The book is also sportin a brand new front and back cover!

If you already own our book in any form, this is old news, because we’ve already sent out an update email containing your new download. If you didn’t get it (spam filters happen), email sales@digwp.com with your original receipt and we’ll make sure you get it.

If you are considering it, but want to know more, you should check out the PDF sample of the book.

Regarding print version of the book, yes, they are coming back! It’s going to take us about a month to have them ready. If you’d rather not wait, you can buy the PDF now, and when the print version is ready forward us your receipt. We’ll send you a coupon code for exactly what you paid for the PDF to use in purchasing the print version. I’m sorry I spoke to soon on this issue. We are NOT offering any discounts on the printed version.

There is no shortage of documentation on WordPress’ famous content-spewing structure, but I still feel like there is more confusion and mystery surrounding “The Loop” than there should be. In this screencast I try and explain what it is, how it works, related parts, and then demonstrate some alterations and various tricks. Things like running multiple loops, writing your own custom queries, and handling pagination with your own custom loops.

View Screencast

Using percentage values for certain things can have slightly unexpected results in WebKit based browsers. For instance, if you have a series of columns set in percentage widths with percentage padding, WebKit can calculate their sizing rather strangely.

The red lines indicate the column as rendered with WebKit. The background shades of gray are accurate placement of those columns in percentage widths.

It’s percentages in general that seem to be the issue. I haven’t been able to dig up a ton of information on it, although I do seem to remember reading something about it quite a while ago. I think it’s related to how subpixel values are calculated. For example, if a container is 657px wide currently, and has four columns at 25% each, they would be 164.25px each wide, and WebKit doesn’t handle that well (rounding issues?) Other browsers handle the “subpixel” value OK.

Firefox, IE, and Opera are fine.

Thanks to Nicolas Gallagher for pointing this out to me. If I’m way behind the times on this, feel free to yell at me, but throw me some links and information so I can update this post with the most accurate information I can. This link seems to indicate the issue has been around a while.

Remember this is only really an issue if you are doing something like shown in these examples with solid color columns. If you didn’t have any visual separators, it might not be a big deal, just a slight cross browser difference very few people would ever notice.

This is a direct link to a PowerPoint file by Steve Souders (in April 2009). Of particular interest is pages 19-33 with all the information on CSS selectors. Evidence points to yes, there are efficiency differences in how you write selectors. But efficient CSS can sometimes come at the cost of larger CSS (bad) and that a “real world” levels even “costly” selectors aren’t that big of a deal.

Direct Link to Article — Permalink

From the desk of important beginner concepts:

You have a website with 100 pages on it. All 100 pages use the same style.css file. You’d like to change the background color of every single page. You make one adjustment in the CSS file, and that background color adjustment will be reflected across all 100 pages. You don’t need to edit each of those pages individually. That’s the core benefit behind CSS: abstracting the design away from the markup.

Now you want to make another change to those 100 pages. You’d like to include the publication date underneath the title of each of the pages. That is something you’ll need to edit the HTML to do. If those 100 pages are based on a template, as they would be when using a CMS (Content Management System), you can make one adjustment to the template file and the date adjustment will be reflected across all 100 pages. That’s the core benefit behind a CMS: abstracting the content away from the markup.

The point is that once a website is any more than one page, there are going to be shared resources and it’s time to use a CMS. Just as the zen garden taught us that using CSS is vital to allow design freedom and make redesigns easier, the ultimate freedom comes from also using a CMS where we also aren’t locked to any specific HTML. HTML isn’t for content these days, it’s for describing content. Databases are for content.

I have made this scientific chart to drive home the awesomeness of this all.

One of the new types of inputs in HTML5 is search.

<input type=search name=s>

It does absolutely nothing in most browsers. It just behaves like a text input. This isn’t a problem. The spec doesn’t require it to do anything special. WebKit browsers do treat it a bit differently though, primarily with styling.

A search input in WebKit by default has an inset border, rounded corners, and strict typographic control.

The Styling Limitations

WebKit has big time restrictions on what you can change on a search input. I would guess the idea is consistency. In Safari particularly, search fields look just like the search box in the upper right of the browser. The following CSS will be ignored in WebKit “no matter what”, as in, you can’t even fight against it with !important rules.

input[type=search] { padding: 30px; /* Overridden by padding: 1px; */ font-family: Georgia; /* Overridden by font: -webkit-small-control; */ border: 5px solid black; /* Overridden by border: 2px inset; */ background: red; /* Overridden by background-color: white; */ line-height: 3; /* Irrelevant, I guess */ }

In other words, be extremely cautious about using any of those CSS properties on a search input unless you are OK with the search input looking very different in other browsers.

Allowed styling

The following CSS works as expected. The last three, in my opinion, should probably locked in like the properties above as styling those properties almost always looks worse than if you didn’t.

input[type=search] { color: red; text-align: right; cursor: pointer; display: block; width: 100%; letter-spacing: 4px; text-shadow: 0 0 2px black; word-spacing: 20px; }Busted styling

Be careful not to use text-indent on search inputs. The results are quite weird an inconsistent. Here is one example:

Sometimes the text is below like this. Sometimes it’s not visible at all. It appears to be related to elements around it as well as how much indent it has (low values sometimes work fine).

Show Previous Searches

This isn’t documented anywhere that I know of nor is it in the spec, but you if you add a results parameter on the input, WebKit will apply a little magnifying glass with a dropdown arrow showing previous results. (Thanks to Mike Taylor)

<input type=search results=5 name=s>

The integer value you give the results attribute is how many recent searches will appear in this dropdown, if there are that many.

I really like the little magnifying glass. It drive home the searchyness of the field, but I’m calling the functionality itself rather janky. On a page reload recent searches clears, so that dropdown will almost always say “No recent searches”, unless you have implemented some kind of Ajax search (and even that I haven’t really tested).

Size Restrictions

There are only three different “sizes” that WebKit search inputs can be, and it is determined by the font-size you declare on them.

Resulting SizeCSS font-sizeSmall<= 10pxMedium11px – 15pxLarge>= 16px

Small, Medium, and Large. That’s all you get!

This small, medium, and large business can be extremely frustrating, as even setting identical font values, at the minimum for a “bump”, you’ll see font size difference across browsers.

Identical font sizings not idential.

Notice the (x) on the right hand side of the search inputs on the WebKit side. That is an additional feature of these search inputs in WebKit. If the input has any value (not a placeholder, a real value) the (x) will be present which is a functional UI control for clearing the input.

Speaking of placeholder text, search inputs are a great candiate for that.

<input type=search results=5 placeholder=Search... name=s>

And in case light gray isn’t your cup of tea, you can style the placeholder text:

::-webkit-input-placeholder { color: orangered; }

View Demo

Chrome users and CSS wranglers, check this out. It’s an extension which adds a “css” link on the right in your URL bar. Click it to open a CSS Edit-like pane on any website where you can click elements and adjust their CSS on the fly. The CSS that you edit will automatically be applied any time you visit that domain, allowing you to make persisting changes to the sites you visit.

Direct Link to Article — Permalink

The Oscars of web nerdery. I’m nominated for a flatteringly high number of categories! Web personality of the year? You know it.

Direct Link to Article — Permalink

Have you ever tried to debug a site where a beginner web designer has loaded the page with scripts? There’s a couple copies of jQuery in various versions, maybe a little Prototype or MooTools thrown in. We can laugh a bit, but many of us went through that stage where we just didn’t really understand things well enough to know there was any problem with that. And is there? Aside from the bandwidth concerns, most libraries have steps you can take to ensure they play well with other libraries if need be. So what’s the scoop? Do you ever use multiple libraries? Poll is in the sidebar.

This is a very cool extension for Firebug (add-on for an add-on?) that expands Firebug’s capabilities with jQuery. For instance, a built in jQueryify button, showing attached event handlers in the Content / DOM tree view, and highlighting all elements in a jQuery collection. I don’t think it’s new but I hadn’t seen it until I finally watched Remy Sharp’s debugging tools screencast from last month.

Direct Link to Article — Permalink

Here’s some food for thought.

When designing something that you are reasonably certain the user is willing (or forced) to invest time in learning to use proficiently, is it beneficial to intentionally make some tasks just slightly more difficult than they could be?

Not incredibly hard, not convoluted, not outright counter-intuitive. But perhaps making some information a little more buried, or placing an action in a slightly strange place. If the user is really looking, they’ll be able to find it.

Frustrating a user is never good, doubly so when you have competition a few clicks away. But forcing a user to do a little discovery and learn the specifics of this product/application/website might make them feel closer to it or more attached to it because they’ve already learned it.

I’m not advocating this, I’m just throwing it out there because I think it’s interesting. It’s certainly no excuse for bad design.

The latest poll was all about picking the best sentence to a user to perform a specific action on a website. The choices are listed below, sorted from most popular to least:

• 39% – Select a user and then click the Update button.
• 37% – Select a user and then click Update.
• 8% – Select a user and Update.
• 7% – Select a user and then press the Update button.
• 5% – Select a user and then press Update.
• 3% – Select a user and then choose Update.
• 1% – Select a user and then choose the Update button.

Clearly, the action verb of “click” is the most popular. I don’t think that’s much of a surprise as that verb has been around and working for us for a long time. In the opening article, I suggested that “click” might be misleading since links and buttons can be used without having to use a mouse. Several people chimed in that, while that is true, those people still know what “click” means and can apply it to themselves. “Choose” was an device-agnostic alternative, but the least popular in this poll. “Press” only slightly more popular alternative. Surprisingly, the third most popular was to use the action verb from the button itself (since “Update” is already a verb).

New poll soon.

Mike Harding with a desperately needed fix for when backgrounds “leak” out of elements with borders and border-radius.

Direct Link to Article — Permalink

Quick public service announcement: The CSS-Tricks forums will be unavailable starting now as the undergo awesomeness upgrades. I’ll update this post when they are back!

And they are back! Might be a bug here and there. Definitely let me know if you see one.

If you asked me right now, Hey Chris, what’s your favorite browser? I wouldn’t know what to tell you! I’ve been a Firefox user primarily over the past few years, but over the last several months my allegiance is no longer to any one browser. I’m a browser jumper. I feel like it’s only fairly recently that the tools are finally there that I can do that without too much trouble.

Firefox, Chrome, & Safari

When I say I’m a browser jumper, I really only mean those three. I’d love for Opera to join the party. It’s nice and fast. Its Dragonfly developer tool is fully capable, but it doesn’t support two of my crutch tools: XMarks and 1Password. When that day comes, I’ll switch to it at least for a while. I feel like for obvious reasons I don’t use Internet Explorer. It’s just not as good of a browser and I’m not willing to use it other than for testing. Not to mention, I’m on a Mac. Although I do test on it, using VMWare Fusion and a bunch of “Snapshots” where I keep Windows XP and Vista in different states of having native versions of IE 6/7/8/9.

The Major Enablers

My browser jumping is largely enabled by a couple of tools that keep the browser environments synced up for me.

Xmarks

If I had to export and import bookmarks every time, I’d probably never switch. I don’t use the bookmarks menu itself much, but I do like having my bookmarks bar consistent in all browsers (and across computers). I keep it pretty curated so if I make a switch, I want to see it in all my browsers across all my computers. XMarks makes that easy, for free.

Mmmm, consistency.

1Password

I was a little late to the game on 1Password, but I’m playing hard now. Why do you need a password tool? I used to think. My browser already remembers my passwords. Yes, most of them do, but not nearly as nicely as 1Password. 1Password keeps all your usernames/passwords in its database, and through browser extensions, allows you to submit them into sites. It makes having multiple logins for the same site much easier. It also deals with auto-filling forms. It also stores your credit cards in your “wallet” making online purchasing way easier. Not to mention other things like your Driver’s License. It’s very handy not to have to go around digging for that when the situation comes up you need to have that information.

The real advantage though, is that it keeps this information synced across browsers and across computers (using Dropbox sync). Change a password in Firefox on your laptop, go home and use Safari on your desktop and you won’t have any problems.

Delicious

I like marking things on Delicious for reading later, further reference, just to share, or whatever. It just bugs me when I’m in an environment where I can mark something I’m looking at in Delicious, so I always look for that ability.

1Password is full powered in Safari, meaning it can fill and submit forms as well as access all your form prefilling data. 1Password is equally full powered in Firefox. 1Password is pretty crippled in Chrome (it’s only alpha), allowing only the submission of logins. It’s better than nothing though, as I wouldn’t be able to use Chrome without it and I love me some Chrome.Development Tools

One of the things that kept me in Firefox for so long was Firebug. OK, the only thing. Firebug is amazing and I believe is still the best developer tool out there. But now the Web Inspector that comes in both Safari and Chrome is nearly as awesome, functionally. It’s actually much prettier, but I debate a few of the UI decisions. Dragonfly in Opera is also very nice, but as I said, I don’t use Opera much. Now that all these browsers have great Developer Tools, it’s not a major determining factor on which I use.

The original king of dev tools, Firebug.

The Web Inspector is much prettier than Firebug (especially in panels like the Resource panel) and just as powerful as Firebug.

My one big gripe with Web Inspector is the folding areas on the right. If you inspect properties a lot, the Metrics is always buried way down. The tabs of Firebug are much easier.

Browser NotesFirefox

The URL bar handling in Firefox is my favorite of all browsers. When you start typing, it matches what you’ve typed so far by URL and by page titles, which typically yields really smart and useful results. If you type an incomplete web address, the bar will behave like the “Feelin’ lucky” button in Google, where it will take you to the first result for that search term in Google. For example, typing “firebug” will get you to “http://getfirebug.com”. I use this to lazily get to destinations all the time.

The Firefox URL bar is the most helpful

Other quick notes on Firefox:

• Firebug is still the best dev tool in my opinion. Other people swear by it in combination with the Web Developer Toolbar. I just never got into the WDT thing.
• The Open With add-on is nice for browser jumpers. It provides a contextual menu for opening the page you are currently viewing in other browsers.

  This would be a good time to mention Choosy as well. Non-Firefox specific, but allows for browser choice in opening links.

• Multifirefox is a great tool for having around multiple version of Firefox (for testing). Simply download old versions of Firefox and rename the Application file (like “Firefox 2.app”). Then launch this application to start any version of Firefox, and you’ll be able to pick a particular profile and particular version. That way you can keep multiple versions open simultaneously which you cannot otherwise.
• Screengrab is a great extension for Firefox that can take a snap shot of the entire length of a webpage. I haven’t found an alternative (other than Paparazzi, which is super old) in other browsers.
• Firefox has an official Delicious add-on.

Safari

The URL bar handling in Safari is my least favorite of the three. It matches what you start typing by both URL and page title, but the dropdown results are more generic and less helpful than Firefox. Also remember how Firefox allows entering a keyword with the “Feelin Lucky” like results, if you try and put a generic search string in Safari you’ll likely just get an error page.

I feel like Safari should step it up in this department. Although it’s likely just because I’m so used to Firefox.

Other notes about Safari:

• Safari has an annoying default where, when it is the default browser and another application tells it to open a link, it will default to opening in a new window. I doubt very many people prefer that behavior, preferring instead to have new links open in tabs. Thankfully there is a fix for that.
• Viewing source in Safari yields non-highlighted, non-linked, non-line-numbered, lifeless code. You can fix that with the BetterSource extension.
• This is what I use for Delicious in Safari, but there is also a native extension now as well.
• You can re-open a closed tab in Safari with Command-Z, but that re-opened tab does not retain it’s history, which is awful.

Chrome

Noteable about Chrome is that it doesn’t have a separate URL bar and search bar, it is combined. This is clever as a space-saving UI feature, but takes a bit of getting used to. For example, in Firefox or Safari typing “getfirebug” will instantly get you to “http://getfirebug.com”, but Chrome, in seeing that as not a full URL, will do a Google search for it, and require you an additional click to get to where you want to get. I feel like if any browser should have “Feelin’ Lucky” type behavior, it’s Chrome, but I can also understand that without a dedicated search field, this is impossible.

Other notes about Chrome:

• Chrome has very nice View Source
• Chrome has a neat search feature where it shows you the scroll positions of the matches it finds.
  
• There is now an official extension for Delicious in Chrome.
• Chrome shows page titles in the tab, but has no dedicated area at the top to show full page titles, which can feel weird.

Results

Even after typing all that up, I couldn’t pick a winner. I quite like them all. Their little positives and negatives cancel each other out as far as I’m concerned. Noticed I didn’t mention speed. You can feel subtle speed difference between them on different sites but nothing to write home about. I also find that all three of them crash from time to time, and that none at any noticeably higher rate.

Is this what they want?

If we could attend secret strategy meetings for these browser vendors, would we discover that this easy interchangeability is what they were going for? Or would we hear planning for future strategies to differentiate themselves more firmly? We web workers are always fighting for the web to behave the same in all browsers, but do we want that fight to be brought to the browsers UI and functionality themselves?

I really don’t know. In some ways I appreciate how easy it has become to switch around, but at the same time have to wonder what is happening in competition and innovation if the final products have become so similar.

 

I’m sure you all have favorite browsers, favorite tools, and favorite techniques for browser jumping. Feel free to share!