I finally moved the public side of this blog over to HTTPS last weekend. Traditionally I’ve preferred to put public info on HTTP and save HTTPS for things that need it – passwords, payment info, login tokens, anything that should be kept private — but between the movement to protect more and more of the web from eavesdropping and the fact that tools are making it harder to split content between open and encrypted sides (the WordPress app sometimes gets confused when you run the admin over HTTPS but keep the public blog on HTTP), I decided it was time.

The last sticking point was putting HTTPS on my CDN, and I’d decided to try getting Let’s Encrypt and CloudFront working together over the weekend. Then Amazon announced their Certificate Manager for AWS, which took care of the hard part. All I had to do was request and approve the (domain-validated) certificate, then attach it. Done!

Downside: Because I opted for the SNI option on the CDN, rather than pay the premium to get unique IP addresses on every CloudFront endpoint, the images won’t work with older browsers like IE6. (Server Name Indication is a way to put more than one HTTPS site on the same IP address.)

On the other hand, the cert I have on the site itself is SHA2-signed (as it should be, now that SHA-1 is no longer sufficient), so it wouldn’t work with older browsers even if I turned off the CDN and kept the images on the server.

It’s the first time I’ve actually broken the ability of older browsers to see any of my personal sites. I’ve broken layouts, sure, but not completely cut them off. In general I’d rather not, but I think I’m OK with it this time because

  1. SHA1 really does have to go, SHA2 is well-established, and it’s not like I’m providing downloads of modern browsers or a critical communications forum for people who are stuck with ancient hardware/software because that’s all that’s available to them.
  2. SNI has been around for TEN YEARS.

And as it turns out, DreamHost’s ModSecurity rules block IE6 to begin with, so the whole site’s already broken in that browser.

So I guess next time I redesign I can finally drop any IE6 workarounds. :shrug:

A lot of web developers have forgotten the lessons of IE6, and just as they used to build desktop websites coded only for one engine, now they’re coding mobile sites specifically for Webkit, even when other browsers would be perfectly capable of rendering the designs they want.

This is exactly the sort of thing that gave IE6 such a stranglehold on the web for so many years (and as much as we’d like it to be, it’s not dead yet), with Netscape/Mozilla and Opera completely marginalized until Firefox managed to break through. It’s not quite so bad because two companies are driving WebKit (Apple & Google) rather than just one (Microsoft), but let’s try to learn from history this time around instead of repeating it.

Call for action on Vendor Prefixes – The Web Standards Project

The Web Standards Project is a grassroots coalition fighting for standards which ensure simple, affordable access to web technologies for all.

Originally posted on Google+

From time to time the idea is put forth that Opera (and Firefox, for that matter) needs to start dealing with bad code. There are two problems with that view:

  1. Opera already deals with quite a bit of “bad code” (but there’s always room for improvement)
  2. Just dealing with bad code isn’t enough: you have to deal with it the same way someone else does.

#2 is the tough part.

The rules for dealing with good code are, for the most part, specific. If you encounter well-formed HTML, you can be reasonably sure you know what the author meant. But there are very few rules for dealing with bad code. Trying to "deal with it" means trying to guess what the author meant, and sometimes different assumptions are equally as likely.

Example:


<p><b>Here's some text</i> and here's some more.</p>

Did the author close the non-existent italics by mistake, meaning to close the bold? Or did he open bold by mistake, intending to open italics? Or is the closing italics tag left over from copy-and-paste? Depending on what assumptions the browser makes, it should display it as:

Here’s some text and here’s some more.

Here’s some text and here’s some more.

Here’s some text and here’s some more.

And that’s just a simple example. It gets wilder when you throw in issues like inline vs. block elements. A paragraph should never appear inside a tag for text formatting, like bold or italic. By all rights, starting a new paragraph (or more precisely, ending the previous one) should also revert to plain formatting. But a lot of old pages expect the formatting to continue into the next paragraph, because way back when, a P tag was a double-line break, not a container.

Now, suppose that Browser A always makes the first assumption, and Browser B always makes the second. If someone tests their code in Browser A, and it happens to be what they want it to do, they won’t necessarily notice that their code is broken. The result: the site looks wrong in Browser B, and the page author — who thinks the page is fine, since he tested it in Browser A — blames Browser B.

Multiply that scenario by millions of pages and you have a large chunk of the web as we know it today.

So the solution isn’t just to “handle bad code.” It’s to handle that bad code in the same way that the dominant browser handles it. And since there’s no document you can look to for guidance, that means taking every possible chunk of bad code, running it through the other browser, and seeing what it does to it.

And there are a lot of ways to break code!

Even Microsoft did this back when IE was new. At the time, lots of people were writing broken code and testing it by seeing whether it looked right in Netscape. So IE had to make the same assumptions Netscape did on certain things. Once IE became established, they diverged.

Some relevant articles:

This post originally appeared on Confessions of a Web Developer, my blog at the My Opera community.

OK, so you want a web anyone can use, whether they’ve picked Windows, Macintosh, Linux, or whatever came on their cell phone or PDA. What can you do? Here are some ideas:

Web Users

Try an alternative browser. Use it exclusively for several days. Get used to what it can do, and how it differs from Internet Explorer or the browser you’ve been using.

Better yet, try two. If you already use Firefox, try Opera. If you already use Opera, try Firefox or Chrome. You can always switch back if you like the other one better. The goal is to see what’s out there.

If you find a web browser you like, tell your friends and family. Get them to try it out, or give them a demo.

If you really like the browser, and would like to spread awareness, consider joining a promotional group like Firefox Affiliates or Choose Opera.

Bloggers and Content Providers

Write about your favorite web browser. Encourage your visitors to try it out. Post links or buttons pointing to the download site.

If you agree with the Alternative Browser Alliance‘s goals, feel free to link to us.

Web Developers

Base your design on web standards whenever possible. Take a look at sites like the CSS Zen Garden and A List Apart for ideas. The Mozilla Developer Center and Opera Developer Community are also good resources.

Validate your code. Learn which rules are safe to break. Where you have to use proprietary features, use graceful degradation so that other browsers at least get a usable experience. Some tools for validation include:

Try not to make assumptions based on browser detection, which is often wrong by the time the next version of a program rolls around. Where you have to check, detect capabilities, not browsers.

Start a collection of web browsers. When designing a site, check the layout with as many browsers as you can early in the process. Check critical parts of the site before you go live. Sites like Browsershots or BrowserStack can help you with browsers and platforms you don’t actually have.

Do your development on Chrome or Firefox. Both have extensive tools to help you test and debug your websites.

Conclusion

These are just suggestions. You can do as much or as little as you want, as much or as little as you can!

This article originally appeared on the Alternative Browser Alliance in 2005. This is the latest version before I retooled the site a decade later.