the 200ok weblog

The second batch of articles has been released at the Opera Web Standards Curriculum. This update really gets the curriculum up to a full head of steam - students can now learn everything they need to know to create a valid, accessible, fully styled website. The next update will see the Javascript articles added.

I contributed two articles to this round... styling lists and links; and styling tables. They were chunkier topics than we originally imagined, as it turns out... :)

Anyway, if you haven't checked out the Opera Web Standards Curriculum already, head on over and take a look.

Labels: opera, tutorials, web standards

It's not every day a whole new browser comes out. It's even less common for that new browser to make lead story status in mainstream media outlets*. But today both happened as Google released their browser, Chrome.

Initial impressions are that its 'innovative features' are essentially an amalgam of other browsers; plus it uses bits of Safari, Firefox and IE (settings panel) so it's kind of Frankenstein's browser. But no matter what you think of its pedigree it does feel fast.

[*] Chrome's release was top story news at The Australian and news.com.au, for those of you playing at home. It might have been top story on other sites too, I didn't have time to look around. Standard disclaimer: I work for News Digital Media.

how fast is it?

Precisely how fast it is depends on who you ask. Naturally if you ask Google they'll tell you it's the fastest browser that has ever existed; although they tend to just talk about the Javascript engine rather than overall performance. Google's own Javascript benchmark yields the unsurprising result that Chrome is far quicker than the others.

Let's face facts, companies choose whichever benchmark makes their product look best. Other tests show different results:

• Slickspeed JS Test Results › drewrobinson.id.au. Short version: Opera and Safari win comfortably, Chrome and Firefox are runners up, IE7 loses a lot. I also get cited as an Opera fanboy (it's a long bow to draw).
• PannonRex » Shining Chrome: Browser Speed Tests. Short version: IE's really slow, Chrome narrowly beats the others.

So the only consistent result is that everything is faster than IE. I'm rather partial to Lifehacker: Speed Testing the Latest Web Browsers, where nobody won across the board :)

So, is Chrome fast? Forget the numbers, everyone says it feels fast and that's pretty much what counts at the end of the day. It's more of an emotional measurement. It's quick. Paint it red.

security and rendering flaws

Along with Webkit's benefits, Chrome also inherited its first security flaw: Serious Security Flaw in Google Chrome - ReadWriteWeb. It's not even listed as a product on Secunia yet..!

Interestingly there are also some rendering inconsistencies: Google Chrome vs Safari 3.1 on Flickr (some CSS properties not working, border-radius not anti-aliased...).

privacy controversy

It really was a big first day for Chrome, with the first privacy concerns blogged within hours: Does Google Have Rights to Everything You Send Through Chrome? - ReadWriteWeb. Matt Cutts responds that all is above board: Preventing paranoia: when does Google Chrome talk to Google.com?

Let's cut to the chase. Google can do whatever it wants with any information you enter or reveal while using their products. There is nothing to stop them. So the real question is not can they do it - yes, they can - but do you trust them not to?

Do you trust Google?

odd name

I have to say the name does seem like an odd choice to me. For anyone who didn't know, the interface elements of a browser are called the 'chrome'. So we could end up having to talk about Chrome's chrome at some point.

More to the point though, chrome is generally shiny but non-functional bling; and 'chroming' is another name for petrol or glue sniffing. Neither association seems like something you'd want with your new product. Interestingly, Wikipedia has already been updated to include a reference to 'chroming' meaning 'to browse with Google Chrome'. I didn't realise things like that became canonised in a day, but hey ;)

I guess it's not like Opera, Firefox or Mozilla are the most immediately obvious names anyway (compare that with Navigator, Explorer, Safari - all related to finding things and travelling around). So who's to judge? :)

Anyway, so far I haven't seen an explanation from Google for the name. No doubt it's out there somewhere. Maybe it was buried somewhere in that cartoon (I haven't been able to get through the whole thing, I have to admit).

a bit of fun

Google threw a lot of geeky fun into Chrome. Options are labelled with things like 'stats for nerds'; entering about:internets into the address bar reveals a fun easter egg; and some of the error messages are a bit... unconventional:

OK, so actually I could have lived without my browser saying 'Aw, snap' to me before I had my coffee ;) I do wonder if this sort of geekyness will put off mainstream users - time will tell I guess.

so why is google doing this?

There's heaps of speculation going around regarding Google's motivation for releasing a browser. After all they don't need to do it, since people are having no trouble finding Google as far as I can tell...

I think the explanation probably goes back to a message that was loud and clear at Google Developer Day (literally, they openly said this): Google wants to be synonymous with everything you do on the web.

They want all their services' names to become verbs, I guess ;) Google it. YouTube it.

Basically Google are in a position that's probably unique: the more people use the web, the more money they make (from their ads). Literally, that's as specific as it needs to get for Google. So long as we're online, they make money. I don't think there are any other companies that can say something quite so broad and still be serious.

the google gloss

We'd had the first 'do we support Chrome?' question before we'd had lunch; and it wasn't just the tech staff that were talking about Chrome. People certainly do notice Google products.

Personally, I don't think Chrome is about to sweep the world and take over the entire browser market (that said, anything's possible). There's a big novelty factor right now, but it's not so fundamentally different from any other browser that you simply can't live without it.

It's fast, it's multi-threaded, it has tabs. Umm, just like most other browsers. Even the Wikipedia entry for Chrome is littered with 'like Opera' and 'like Firefox' references. There's even a 'like IE8' in there.

So it's probably not going to cruel the other 'alternative' browsers from the market. I do think it's a legitimate danger to IE though. It's the only other browser from a company the average punter has actually heard of.

Think about that - a lot of alternative and open source products get smashed by FUD tactics. "They're too small", "how do you know it's made properly" and that sort of crap. But it's harder to get that sort of FUD going over a product from a company as widely recognised as Google.

last thoughts

Google might attract conspiracy theorists as fast as geeks, but nobody thinks they're a flash in the pan. People who wouldn't try an open source product like Firefox might just give Chrome a go (they probably won't even notice Chrome's open source). People who've never heard of Opera won't know where they can already get speed dial and top placement of tabs. Lots of things that geeks think about simply won't matter.

I can see a lot of people trying Chrome even though they've always used IE. Quite a few of them will probably like what they see, too. It's a pretty good browser and it'd certainly be new and shiny after years of IE. That, or people will just stick with whatever they're already using, since habits don't change easily.

One thing is for sure - it's going to be interesting to see what happens next.

...

Update 2008.09.07 - It has come to light that Chrome does not support even basic accessibility features in its first release: Google Chrome Accessibility - The Paciello Group Blog. Google has a terrible track record for accessibility, so it's discouraging to see Chrome start badly in this regard.

Obviously it remains to be seen whether accessibility features are incorporated as the browser progresses. A comment at the Paciello Group Blog post suggests that Google do plan to incorporate accessibility features, they just didn't put them into the initial release. Here's hoping that's true.

Labels: browsers, chrome, firefox, google, ie, opera, safari

Opera has some great features buried in its menus, so I make a couple of buttons to add them to the standard toolbars.

The first one I use is Reload From Cache, which does exactly what it says. It reloads the page entirely from cache, which is really useful when you combine it with the ability to view source in your choice of text editor. You can view source, make some test changes, reload from cache and see if it worked. It's less twitchy than inline editing since it only reloads when you're ready; and it's far less aggravating than trying to do serious edits in a tiny window with no syntax highlighting.

The second is bleeding obvious - a button on your toolbar to load Dragonfly. I'm sure they'll add one as standard once it's out of beta, but who's that patient? :)

So anyway, here are the buttons. Click the links and they'll get added to your custom buttons; then you can drag them onto whichever toolbar you like.

• Reload from cache
• Dragonfly

full instructions

Either click and drag the link to the toolbar of your choice, or...

1. Click the link and then ok to add it to your buttons

   

2. Right click a toolbar and select Customise

   

3. Go to the Buttons tab and select My Buttons at the bottom left

   

4. Drag the button to the toolbar of your choice

   

5. Click ok and you should have a new button on your toolbar

   

to make more buttons

If you want to make more buttons of your own, check out the Opera Custom Button & Command Creator.

Labels: dragonfly, opera

I've often been asked if I know of a good, comprehensive set of standards-based web development tutorials. Something to give a student or keen newbie so they can learn the right way to build websites from the ground up, instead of learning outdated techniques they'll just need to replace.

Sadly, I've often been at a bit of a loss. Most of the tutorials I could find out there either taught old methodologies or they jumped straight to an intermediate or advanced level. Or, they simply couldn't cover the entire topic of standards-based web development.

I've also been frustrated at the slow pace of change at many universities, where students are still being taught techniques that are well past their use-by date. Don't get me wrong here. I know academia is not the easy life that popular opinion would have you believe. So I think the industry should do its best to support academics, as they are training the next group of bright young developers.

So with all these things in mind, I was really happy to be one of the authors for the Opera Web Standards Curriculum (WSC). It's a comprehensive resource for students, teachers, corporate trainers and developers. The first 21 articles have just been released; and there are about 30 more in the pipeline to be released soon.

Check it out! I hope you find it useful. Head on over to the WSC homepage or jump straight to the WSC table of contents if you're keen to dive right in. If you have any feedback the best way to go is to get in touch with Chris Mills, the mastermind of the project. There's also a WSC forum if that is more your style.

Labels: curriculum, education, opera, tutorials, web standards

It has become more or less expected that browsers will release developer tools. Firefox really pushed this concept with its developer toolbar and, of course, Firebug.

Opera has been hinting at the release of developer tools for a while; and when dragonfly.opera.com went live, speculation was that we knew what they were going to be called. Well the release date is finally here and yes, Opera has released an alpha of their developer tools - Opera Dragonfly.

The name was chosen because "dragonflies are highly evolved predators". That is, dragonflies are fast as hell and eat bugs for breakfast :) The name also makes a nice nod to Firebug, which is an undeniable source of inspiration.

features

So what's in the first release? From Opera's official email:

The alpha release includes the initial implementation for the JavaScript Debugger, CSS Inspector, DOM Inspector, Command Line and the Error Console, as well as the Scope module, which allows Opera Dragonfly to communicate with the Opera browser. This will be followed with a second alpha in the coming weeks, which will add inline editing support, improved remote debugging, improved threading in the JavaScript Debugger and infrastructure for localisation. You can read about the current features at <http://www.opera.com/dragonfly/>

One of the key reasons for the alpha release is to collect feedback from developers, to gauge how Opera Dragonfly covers their needs. We will use this feedback to improve Opera Dragonfly as it moves into beta and then full release. Feedback can be given at <http://www.opera.com/products/dragonfly/feedback/>

The Opera Dragonfly team will be maintaining a blog at <http://my.opera.com/dragonfly/blog/> where you can follow the progress of the application.

A really significant feature will be the ability to debug content for devices on your computer - yes, debug mobiles with a real keyboard. That's a pretty cool feature.

reactions

So far common reactions are that people are really looking forward to the inline CSS editing/CSS inspector; and some users report that it's running quite slowly for them. It is an alpha release though, so it's not time to panic about the speed issue.

The first release runs as a separate window from the main browser; which is absolutely brilliant on a dual-monitor machine (like my work machine). However it's not quite so awesome on a single monitor or widescreen; but the single-window mode will take care of that.

Basically, every feature request I've seen so far has been for stuff already listed in the "coming soon" paragraph on the Dragonfly homepage. That's great news, really - the features are clearly well matched to the target audience.

Frankly I'm mostly excited that other developers will now be able to debug in Opera the way they do in Firefox. The lack of a Javascript console and CSS debugger has been a consistent complaint... :) Opera really isn't hard to build for, but the lack of a debugger did make it uncessarily difficult to bugfix existing sites.

notes on trying dragonfly

As it's not been 100% clear - Dragonfly is included in Opera 9.5 Beta 2 release. It's not like Firefox, where you go and find an extension; it's just included in the package. The required code is downloaded when you first run it; and updated automatically after that.

I do recommend you install the beta separately from the currently release; and later when Opera 9.5's official release arrives, you should uninstall the beta and upgrade the stable release. To put it another way, don't install stable releases over the top of beta releases, or vice versa.

Also, when you fire up Dragonfly, note that you need to click on the script you want to inspect; or click into the DOM tab for the CSS inspector. Check out Chris Mills' Introduction to Dragonfly for a full run-through.

No matter how you slice it, Dragonfly is a sweet new tool for web developers; and as more features get rolled in, it's just going to get better.

Labels: console, developer tools, dom inspector, dragonfly, firebug, opera, opera dragonfly

Doing the rounds at the moment is a Five Things I Want In Opera tag-meme. Chaals tagged the world of connected people so that's good enough for me. Besides, I don't really want to wait for this meme to work its way out of Europe ;)

Here are five things I want in Opera (no particular order):

• An auto-update feature so people are less likely to let their version lag. This feature alone determined whether I recommended Opera or Firefox to my mother-in-law.
• Web developer tools similar to Firefox's Web Developer Toolbar. There are some add-ons which are pretty good but I'd really push for Opera to integrate more of them into the base install.
• Slicker handling of Opera mods like user js - they sound too techy so the average user won't try them. I'd also like a neater way to add Bookmarkets to a toolbar, even if the only change was being able to set the favicon permanently.
• Let me synch my Opera preferences with my account at my.opera.
• Default toolbars which are more consistent with competitors. Out of the box, the buttons in Opera don't look like other browsers. I have long since thought this was a reason many users "don't get" Opera, leading them to ditch it in that all-important "just trying it out" phase.

Who am I tagging? Anyone who wants to join in - comment with the URL of your post.

Labels: meme, opera

For a long time I really couldn't get into widgets. I found them too clunky for the functionality they offered - a bad ROI. Konfabulator in particular was not kind to my aging PC's performance.

But then two things happened: I got a second monitor at work and installed some Opera widgets. So no I use a few widgets - some obvious stuff like the weather and the fuzzy clock; plus some very niche stuff like Stay Secure.

The extra monitor was a no-brainer - that just gave me extra room to have widgets in view. The real kicker was having the widgets piggyback my browser - something I'm running all day anyway.

With all the options out there for widgets, Opera has two big advantages going: first, it doesn't require a whole new platform on your computer. If you have Opera, you already have the platform. Second, they're cross-browser and from what I'm told will ultimately be cross-device as well courtesy of Opera Mobile.

Opera have put widgets right where you've already installed software - you can just hit widgets.opera.com and away you go. Of course, if you have OSX or Vista you might choose their widget offerings for much the same reason.

spoiled for choice

So anyway, I know I'm late to the widgets party. But there are an awful lot of users out there who haven't even heard about them yet, or just don't really know where to start.

It's a classic barrier to adoption: widgets sound techy and more than a little geeky; there are lots of competing options, with no clear differentiation for the casual observer; and you have to install stuff before you really know whether you want it.

I was trying to give someone a "quick overview" of widgets a couple of weeks back. I dashed off what was supposed to be a quick email. It took a whole screen just to list and describe the widget engines I could remember off the top of my head (don't look at me like that, they actually needed the info - I wasn't doing a misguided geek braindump!).

If you're an average user, you probably don't even modify your browser settings - much less install add-ons, widgets and customisations. There are plenty of users out there who haven't really got their heads around XML feeds. Can you imagine their confusion trying to figure out widgets?

Then from the publisher's perspective, with all these options how do you pick a widget to release?

don't look now, it's another cowpath thing

Realistically you have to offer widgets wherever people are already using them - even if it is still a wide range of options with small user bases. If someone's not using widgets yet, chances are they're not going to be starting just for you - they'll keep using whatever they're already comfortable with, even if that means visiting your site randomly via in-browser bookmarks.

About the best thing you can do is find all the widget engines you think have a decent user base and release a widget for all of them. With all the quirks and weirdness, you could be spending a lot of time making widgets.

it's like we need a standard or something

A standard format would definitely be useful here - something like the Netvibes Universal Widget API (hat tip to Lachlan for that one). It remains to be seen whether UWA will become a standard, or if everyone will just publish their own "standard" leaving us no better off than before (RSS anyone?).

people are tired of beige boxes

Perhaps widgets will encourage more average, non-geek users to customise their computer. I've observed over the years that a lot of people really are nervous about using computers, while others are simply disinterested. I have a vague theory that only fear could drive someone to put doilies on a computer monitor, but that's probably more about my view of doilies ;)

I don't think fear is too strong a word - people are still worried they could "break the computer" by pressing the wrong key. It doesn't help that current affairs TV spots regularly scream about privacy and security online.

So anyway - whether they're afraid or just ambivalent, a lot of people don't get much enjoyment out of the computer. Even so there's a good chance they're stuck using it all day at work anyway.

giving the humans a look in

Being able to whack the weather, traffic report and your favourite newsfeed right on the desktop gets people to engage with their computer a bit more. It lets them get useful information (or fun, useless information) and gives a simple opportunity to make the machine a bit less threatening (or boring). The computer might be forcing them through the agonies of spreadsheets, but it can also tell them they need an umbrella at lunchtime and to avoid the freeway on the way home because it's backed up for miles.

Sure you can get that info from websites, but widgets are right there already. They're little bite sized bits of web.

To think of it another way, widgets are about the user. They're generally free, most of them are still free of overt advertising. They just fun, or useful, but most of all personal. It's technology which actually does something nice for the humans. Which is a nice change.

So anyway, there's a lot of potential in widgets - if only users can be convinced to use them. Here's hoping a clear standard format emerges to make it easier to give the people what they want...

Labels: computers, konfabulator, netvibes, opera, opera widgets, personalisation, technofear, user engagement, uwa, widgets

This is one for the "if you fix a problem, blog it" files.

I've been having a problem with a particular feature on a page I'm building at the moment. Basically I need to position a small div over the top of an image. The image can then change without needing to edit the content in the div.

To do it, I set the size of the container div then used absolute positioning to place the small div where I wanted it within those boundaries. To get it all to work the container is set to position: relative; and the small div is set to position: absolute; - something which is pretty common.

the problem

Screenshot 1: Desired result (and before scrolling in Opera 9).

Screenshot 2: After scrolling down and back in Opera, content disappears. The exact result varies; with other combinations of positioning the example div may also disappear immediately after the page loads (that is, it renders then disappears).

The problem occurs in Opera 9 on both PC and Mac. To see this in action, check out the example page.

the scenario

The large image and the red example div are enclosed in a container div. Initially, the container div was set to position: relative;; the red example div was set to position: absolute; and the large image had no specific setting.

the fix

To fix the problem in Opera, apply position: relative; to the large image as well. Some more testing is required to be sure, but I think the principle is to make sure there aren't any elements without explicitly handled positioning.

Again, see the example page for the real thing.

Update 2008.08.13: This bug does seem to be fixed in Opera 9.5x. Hurrah! :)

Labels: bug, disappearing content, opera, opera 9, problem

It seems that Firefox 3 will include an option to treat meta refreshes much the same way as popups - blocking them and alerting the user what the page wants to do. It's another step forwards in letting the user take control.

Of course, Opera users already have this option; using opera:config#UserPrefs|ClientRefresh. Neat, although an alert would be good; as would site-specific settings. Hopefully the feature will be refined in future versions.

Really though, either way is good as it gives the user a little more control over their browser. Automatic refreshes and redirects break accessibility recommendations. They're one of those things which gets written up as "until browsers provide a way to control...".

As these features become more widespread, the importance of fallback options will become even more critical. Just like scripts need a <noscript>, meta refreshes need a link in the document. Many pages don't have them, though; so no accessibility or SEO juice for them!

It serves as a good reminder that we should provide alternatives any time we modify the behaviour of a page. I have had people say in the past that meta refresh was so simple nothing could go wrong. Well, that assumption will bite them on the arse...! :)

We should always assume that somehow, somewhere such features will be disabled. It's not hard to provide an alternative, so it should remain our habit to do so.

how to disable meta-refresh

• In Opera 9 (Win/Mac): browse to opera:config#UserPrefs|ClientRefresh, then deselect the option and restart Opera.
• Firefox 2 (Win/Mac): install the Web Developer's Toolbar and click Disable → Disable Meta Redirects.
• In Internet Explorer 6 and 7: go to Tools → Internet options → Security tab → Custom Level button → Miscellaneous category → set "Allow META REFRESH" to Disable.
• Safari 2: currently I don't know of a way to disable it in Safari.

Labels: accessibility, browsers, disable, firefox, ie, meta refresh, opera

Back in 2005 I compared the patch rates of IE, Firefox and Opera. In the past few days the subject of browser security has come up a few times, so I thought I'd revisit the topic to see what (if anything) has changed.

data source

I'm using Secunia advisories again, to keep the data source consistent. The product pages are:

• Internet Explorer 7, Internet Explorer 6
• Firefox 2, Firefox 1
• Opera 9, Opera 8
• Safari 2, Safari 1

Note that Secunia's data starts from February 2003, regardless of each product's release date. You can investigate Secunia's methodologies if you will; there are some quirks. However I'm not after a perfect scientific investigation, so much as a broad strokes impression.

what am i comparing here?

Since each browser has a different release date and lifespan, comparing raw numbers of problems isn't really useful. However we can compare the percentage of patches/fixes from the vendor - it's not how many security issues were identified, rather it's about how many were fixed.

I would have added in "time to patch" and "days vulnerable" and so on, but Secunia doesn't currently graph that information (as far as I know).

I thought about sorting out standardised timeframes and so on, but the bottom line here is how secure can a user's browser be today? I say "can" since we can't assume that all browsers are up to date with the latest patch (or even close), but we can at least evaluate the potential for a conscientious user to keep up. After all, we can only apply the patches that are available.

Having discussed the user acceptance issue in the previous article (to patch or not to patch?) I won't rehash it here. However I will mention that according to Secunia Opera users really need to update their browsers.

patch rates - july 2005

First, let's remind ourselves of the data from 2005:

* Firefox advisories start from August 2004.
** Opera 7 and 8 are combined to create a better comparison in terms of the number of advisories.

[Note - yes I know it didn't really make sense to combine Opera 7 and 8, but both had a 100% success rate so it didn't really change the outcome.]

patch rates - january 2007

First off, let's compare the patch rates of the same browsers (and we'll add Safari so people don't accuse me of forgetting Macs). Remember that these are all superceded versions now:

So, no change for the three browsers compared last time. Safari slots in at second, after Opera and before Firefox.

Now let's have a look at the latest versions of the four browsers:

This produces very clear results, but the low number of advisories exaggerates the margins. The previous versions all have a higher number of advisories, but actually the only change in ranking is that Safari drops from second to third. The sharp drop in patch rate between Safari 1.x and 2.x makes it hard to get any useful conclusions - has Apple really dropped the ball?

For the other three browsers, the rankings remain:

1. Opera (100% patched, no change)
2. Firefox (50% patched, down from 87%)
3. IE (25% patched, down from 67%)

It's worth noting that the patch rate for both Firefox 1.x and IE 6.x improved between 2005 and 2007. However both dropped noticeably between their previous and current versions (same as Safari). The proportion is exaggerated by the low number of advisories for the newest products.

conclusions?

Well, one clear thing is that Opera is the only vendor with a 100% patch record according to Secunia. Opera is also the only vendor that maintained its patch rate between versions - in fact you have to go back to Opera 6 to find an unpatched advisory (and there's only one).

It's also clear that IE has the worst patch rate of all the browsers compared. You could say that's a result of having a much bigger user base and a correspondingly higher incident rate. But then Microsoft has more resources than the other three vendors combined so it's a pretty weak excuse for leaving security issues unpatched.

Meanwhile Firefox does pretty well for an open-source product, consistently beating IE - even if not by much. Apple meanwhile needs to get Safari 2 sorted out; but we'll see what happens as more data becomes available (for all four browsers).

So at this time Opera wins the patch stakes. The argument can be made that Opera attracts fewer attacks due to small marketshare. That could be true - there's no way to truly know, since malicious hackers aren't polled - but when I'm doing my banking I don't care if it's true. I just care that my browser is secure; and Opera currently has the best record for fixing security issues.

Labels: browsers, comparison, firefox, ie, opera, safari, secunia, security

Computer lab only has IE? No problem! Bring your own browser. Most labs let you use USB drives, so use them to run software...

• Opera for USB drives
• mozdev.org - portablefirefox
• JAWS for USB Thumb Drives

So what software do you use on your thumb drive?

Labels: firefox, jaws, opera, software

It's likely that you've already caught this one, but just in case you didn't here's a quick rundown:

• Acid2 and Opera 9 Problems? - The Web Standards Project: We’ve received some reports here at WaSP that Opera 9 is not passing Acid2 under certain unique scenarios. We’d like to hear from you in comments if this is the case.
• Then Opera Watch mentioned it: Some questioning whether Opera 9 passes the Acid2 Test | Opera Watch
• Acid 2 in major browsers discusses the fact that some behaviours being called 'errors' are actually valid results for the test.
• Then people turned closer attention to Acid2: The Guided Tour - The Web Standards Project. Under close scrutiny it turns out that some wording is a little vague, eg. Acid2 assumes that the browser uses a default style sheet with common values ..."common values" is open to interpretation.
• Chaals explains the situation neatly: Acid burns - Out of the way - by Chaals (Charles McCathieNevile): Unfortunately, the people who have made these reports are wrong about us not passing the test. One of the limitations of Acid2 is that it relies on a 'normal' rendering setup. Scrolling, zooming, resizing, setting minimum font size, choosing your own styles for things that are important to you, and various other things, will all break the rendering of the test. It is written that way.

During the debate - make that 'comment wars' - things tended to dissolve into Opera vs. Firefox rather than actually discussing whether Opera 9 passes Acid2. For what it's worth, my opinion based on the Acid2 documentation is that Opera 9 does pass the test. The only remaining doubt is whether one or two lines should be left when you scroll the test. If the Acid2 page is scrolled, the scalp will stay fixed in place, becoming unstuck from the rest of the face, which will scroll. The documentation only discusses one line - that's an omission, not a failure condition.

Frankly, I think the intention of the test was to see if the smiling face would render in the first place. It does for me on all systems I've been able to test. My personal suspicion is that most of the failures are resulting from buggy installations (eg. final release installed over the top of a beta) or the page is zoomed or minimum text size is overriding the test - whether the user realises or not (it's easy to forget). Or possibly some other system glitch - there are lots of variables. If Opera 9 itself failed the test, I would have expected a more consistent result across the user base.

Labels: acid test, acid2, opera, opera 9

So, right now browser preview/beta releases are the new black. IE7b2 is doing the rounds, so I won't bother getting back into that circus. Let's have a look at Opera 9 Technology Preview 2 (on PC, since that's what I use).

what's good

There's a lot of polish going into this version, but I won't bore you with every single little detail which I like. The bigger points:

• I will mention that overall, a huge number of preference/options settings now have more flexibility.
• Add any search to the search dropdown, just by right-clicking it. You can define a search keyword while you're at it. I've since discovered Firefox lets you define your own search keywords, but it's not as easy and you still can't add it to the dropdown without writing an extension.
• opera:config ... the ability to deep link a preference setting is going to make life a lot easier when directing users to a particular setting.
• Tab/window nomenclature now matches other browsers. I'm sure a certain standardista will feel vindicated.
• BitTorrent. The cool kids tell me BitTorrent is a good thing. It wasn't included in previous versions since there were some bugs - gasp, I hear you say... a software company that didn't just slap the new feature in, bugs and all? That's right, they waited until it was good and ready for public consumption. That's a company that cares. Redmond this ain't.
• The ability to change a stack of settings for specific sites. So now you can disable flash but have it automatically re-enabled for those three sites where you actually wanted the flash.
• Content blocking - seems to be something similar to the popular "ad block" in Firefox, which is nice. I'm also thinking of blocking the boring photos posted by specific users in some photography groups...
• Tab thumbnails, making it easier to find that particular tab.
• "Insert personal"... it's form field autocomplete, but in a user-controlled manner. I really like this.

what's bad

Actually not a huge amount to complain about.

• Still doesn't have a "home" button on the toolbar, out of the box. Seriously, what the hell? I really don't like the default toolbar and I always change it immediately. It is my opinion that this one single issue causes the most trouble for potential new users.
• Tab selection order still bugs me, I'm sure a certain standardista would agree. It's that reading-through-the-blogroll thing.
• Some settings still don't have quite enough flexibility for my liking, eg. I'd like to be able to allow the tab bar to extend to a second row but no more.

what's... not sure

• Widgets. People who went nuts for Konfabulator (or whatever it was called) should get a kick out of widgets. Plus, they look the same as all the faux-plastic/glass widgets that I see plastered all over the Mac at work. People love those things. So anyway, I'll have to play with the widgets a bit more to see if they're useful for me.

conclusion

I'm looking forward to the final release. Although, actually the beta has been rock solid on my machine so far anyway.

link crazy

• Opera Labs | Opera 9 Technology Preview 2
• Opera 9 Preview 2 - Anne’s Weblog about Markup & Style
• wg:Opera 9 Preview 2 released
• Opera 9.0 Technology Preview 2 - Arve Bersvendsen - a good walkthrough, with screenshots.
• Content blocking in Opera 9 Technology Preview 2 | Innuendo and out the other

Labels: browsers, opera, opera 9

This feeling has been brewing for a while: Firefox is turning into Internet Explorer. The attitudes surrounding Firefox draw ever closer to those attitudes it was supposed to destroy. Things people hate about IE and Microsoft are appearing in Firefox and the Mozilla Project.

What am I talking about? It mostly boils down to these points:

• Using one browser's popularity to justify not supporting other browsers
• Treating users of other browsers as inferior - "just use the popular one"
• Making up proprietary code which is only supported in one browser

People weren't happy to let IE get away with that crap, so why are they taking it from Firefox?

popularity contest - what is this, high school?

I thought we were supposed to be getting away from the days where users with a small marketshare were told "too bad". Sadly an increasing number of sites are appearing which work in IE and Firefox, but not Opera or Safari. Users of these browsers can rant and rave but they are inreasingly being met with blank stares - why won't you just use Firefox and shut up?

Major players lament having to support "niche browsers" and even people who should know better are starting to go live with sites that only work in IE and Firefox:

• Flickr's "notes" feature only works in Firefox, despite being one of the key features they promote.
• Blogger actively pushes users into using Firefox since their interface sucks in anything other than IE and Firefox: AOL users, as well as those unaccounted for here (Netscape, Opera, etc.), would be wise to use Mozilla Firefox in order to have the best possible experience using Blogger.
• Technorati's method of increasing the size of popular tags only works in IE and Firefox (maybe Safari, but I don't have a Mac handy).
• 37 Signals may be the darlings of the life hacking fraternity, but their products generally don't work in Opera so guess what? I don't use them.

What makes it even more interesting is the way many applications add support for other browsers later on. This indicates that it was entirely possible to support all browsers at go-live, but instead they ran early without bothering to finalise the product. Who cares about a few idiots who don't use IE or Firefox?

Most of this is based on the flawed assumption that browser stats are gospel. For all anybody really knows, Firefox's real marketshare could be a third of that reported in most log files (what with all the pre-fetching).

"quit complaining and just use Firefox"

People ranted at length about being told to "go use IE", yet don't seem to blink when directed to Firefox. Just because Firefox has some open source cool points doesn't mean people should be forced to use it.

What happened to letting the user choose? Did we decide that Microsoft was right after all - everyone should use the exact same software?

Worse still, many people seem to think Firefox is the only alternative browser. Firefox has been pushed so hard, people are treating it like "the other browser" instead of "another browser". Gratingly, articles are appearing with titles like Why You Should Consider Budgeting a Site Redesign for Firefox 1.5 Now (Yes Firefox). Argh! No! Redesign with standards, not "for Firefox"!

proprietary code

There's been quite a bit of noise surrounding the <a ping> feature being proposed for Firefox. Actually, it's not a feature for Firefox so much as a bit of proprietary code for developers to add to their pages. Wow, there's a thought - let's code our pages for just one browser. Let's stick "Best viewed in Firefox!" buttons on our sites and get in the popcorn to watch Browser Wars 2.0 unfold.

Does one feature really mark an entire project? Not really, but have you ever had the feeling you've just seen the thin end of the wedge? The ping attribute isn't even being proposed for a good reason - the justification is that some sites do stupid redirection monkey business in order to track hits. Why a browser maker should get involved is beyond me. Let those sites break if their redirections fail, for all I care. Don't make up new code!

firefox is not perfect

No matter what people say, Firefox is not perfect. It has bugs (table padding problems, anyone?), it has security flaws, it has a memory problem. It may have a larger marketshare than a few other browsers, but it's still a minnow compared with IE.

People should stop acting like it's perfect. Firefox is just another choice. Its marketshare could slip tomorrow - IE7 could take back everything Firefox gained; taking the "it's popular" argument back off Firefox. I'm sure Firefox users would still like to be supported even if that happened.

Unless we want to replace IE with Firefox, the industry needs to remember the original point of web standards: support standards, not browsers. Build once, publish anywhere, let the users choose the UA that's right for them.

Labels: browsers, firefox, ie, opera, safari, web standards

A timely interview with the Opera CEO can at least stop a few rumours: Slashdot | Opera CEO Jon von Tetzchner Answers Your Questions. Although the questions could have been chosen a little more carefully, it's still an interesting read.

Meanwhile Opera Watch had some fun thinking up the next companies which might buy Opera; and the names they'd have for the browser. Opera Watch: Next company to acquire Opera? | Opera Browser Blog. Yahoopera? Appera? Actually I think Apple would call it iPera.

Labels: google, ie, opera

I don't remember who said it, but someone once pointed out that if you solve a tricky problem... blog it. You'll help out the next sucker who is trying to solve it.

Recently I ran into a background image positioning bug in Opera 7/8. Well, ok, I thought it was a bug; but actually it was user error. Basically, I had a background image positioned center center. In everything except Opera, it was sitting - as expected - bang in the center of the page.

In Opera, the image was sliding up off the top of the browser canvas. I eventually figured out that Opera was positioning the image according to the length of the content, not the visible canvas area. Throw in some really long content and you'll find the image way down in the middle.

The problem was I'd forgotten to set the background-attachment, despite the fact that I did want it to be fixed. Since I hadn't specified what I wanted, Opera defaulted to the vertical centre of the element. Which, when you think it through, is the right thing to do - I'd said it should be in the middle of the element and the element was as long as the content. The other browsers use for 'we think you wanted...' approach and default to the length of the viewport.

So I explicitly set the background attachment:

background-image: url("img/watermark.gif");
background-repeat: no-repeat;
background-position: center center;
background-attachment: fixed;

...and all is well.

In my defence, half the office had a look at the problem and they didn't spot it either :) The moral of the story: beware of default settings and the lazy habits they breed. It will catch you out eventually. In this case, the overly-forgiving defaults of IE and Firefox had let me slip into the bad habit of expecting a background setting that I hadn't actually specified.

Labels: opera