the 200ok weblog

[Or, When Minutiae Attack!]

There's a perennial question that pops up on email lists and from other developers. The question goes something like this:

"This page works fine in everything except Firefox and I can't tell why... it's showing an HTML comment as raw code..."

the problem

This problem usually boils down to a quirk in the way Firefox handles HTML comments. Most browsers only treat --> as a closing comment in HTML. However, Firefox also treats any instance of -- as a closing comment.

So, if you have a comment with two or more adjacent hyphens, you're in trouble. Both of these are out:

<!-- --------------- Blah --------------- -->

<!--
<p>
Blah blah blah -- then blah.</p>
-->

Firefox will display the comment as raw code, instead of hiding the comment and its contents. The late Netscape Navigator did this too - in fact I first saw the problem in NN4, back in 2000.

the solution

The solution is simple, even if it's not always convenient: don't put adjacent hyphens inside an HTML comment. That's fine and dandy unless you have content authors who have a habit of using two hyphens instead of an em dash!

In any case, you either need to remove the adjacent hyphens, or if it's appropriate you can convert them to more correct characters.

If your page's content includes double hyphens and you're not allowed to modify it, then you're not going to be able to comment blocks of it out. Yes, that is indeed annoying.

is firefox wrong?

Technically, very technically, Firefox is right. The HTML 4 specification defines "--" as the comment delimiters; while "<!" and ">" are the markup declaration delimiters. From the spec:

White space is not permitted between the markup declaration open delimiter("<!") and the comment open delimiter ("--"), but is permitted between the comment close delimiter ("--") and the markup declaration close delimiter (">"). A common error is to include a string of hyphens ("---") within a comment. Authors should avoid putting two or more adjacent hyphens inside comments.

Information that appears between comments has no special meaning (e.g., character references are not interpreted as such).

Note that comments are markup.

...so, Firefox is not "wrong". It's just following the spec to the letter (or hyphen, as the case may be). The other browsers have gone with a more human-friendly interpretation of the spec.

so are all the other browsers wrong?

I don't think the other browsers are definitively wrong either. They still comply with a different interpretation. Personally I read the specification the same way: "any instance of -- followed by > or whitespace and > is a closing comment".

According to this interpretation, "-->" and "--  >" are valid closing comments, but "-- blah" is not. It's also a reasonably logical approach to say that since a closing comment should be "-->", then the browser should ignore anything which is not "-->". That's pretty much what a comment is there for, after all - to ignore stuff.

is the spec wrong?

Well the spec can't really be "wrong" I guess. It is what it is. But in this case I think the specification is a bit illogical:

• I don't see the sense in random exceptions to rules - why specify vagueness? "this is the closing comment tag, except when it's not".
• Why allow whitespace in the closing comment, when it's not allowed in the opening comment? If whitespace was prohibited the only valid interpretation would have been the complete "-->" and the whole problem goes away.
• The "common error" note just confuses the issue. It does not say why including adjacent hyphens is an error, nor does it define any specific error handling method.
• The double-hyphen approach can't be a technical requirement for producing a rendering engine, since the other browsers are able to restrict closing comments specifically to "-->".
• It's impractical to expect that commented content will never contain multiple adjacent hyphens. Sure, we can live without hyphens in comments; but we shouldn't dictate content based on markup (no matter how small a detail it is).
• And finally... it's irritating, so I'm going to be cranky at the spec ;)

Besides that, as the HTML5 spec notes, HTML has always been implemented by browsers as a language in its own right. There's no need to slavishly follow anything else. The more human interpretation could just as easily have been specified.

But then, comments appear to be a blind spot in W3C specs - how I curse the lack of a single-line comment in CSS... but I digress.

will html5 clear it up?

No. HTML5 actually makes things a little harder to remember, by addingdocumenting (hat tip zcorpan) the restriction that a comment can't end with a hyphen either:

Comments must start with the four character sequence U+003C LESS-THAN SIGN, U+0021 EXCLAMATION MARK, U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS (<!--). Following this sequence, the comment may have text, with the additional restriction that the text must not contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a U+002D HYPHEN-MINUS (-) character. Finally, the comment must be ended by the three character sequence U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN (-->).

What's the saying about laws and sausages?

conclusion

Perhaps there's some deep-seated syntactical reason for the double hyphen approach. The HTML4 spec's warning about "a common error" hints at some underlying logic without actually revealing it. Maybe it's related to the formatting of DTD comments. Maybe it was just a Netscape quirk which got turned into a standard. Maybe it's totally random.

It seems unlikely that Mozilla is going to change this particular detail, particularly as it's not a "bug" to follow the specifications; and besides, Firefox 3 Beta 2 still has the quirk.

Still, Firefox does correct omitted background colours by defaulting to white - so they're not above "helpful" rendering tricks. So maybe there's some hope on that front.

But in the meantime, no matter what we think we just have to live with it. It's yet another bit of web development minutiae to file away in your head, for the day you see it happen.

Labels: bug, comments, firefox, html, interpretation, netscape, problem, specifications, w3c

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

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