This looks cool: Mozilla has released a translation tool as an add-on for Firefox that can do web page translation locally instead of sending data to the cloud! It’s based on Project Bergamot and implemented in WebAssembly.
IMO translation is one of those things like speech recognition that ideally should have always have been local (for obvious privacy reasons), but the processing and data just wasn’t there yet when Google Translate and similar services launched.
I never thought I’d see Microsoft throw in the towel on their browser engine. Or that, by the time it happened, I’d see that as a bad thing.
But it’s true: like Opera did a few years ago, Microsoft is dropping not only the old Internet Explorer engine, but the newer Edge engine, and will be building Edge on Chromium going forward. That means Edge, Chrome, Opera and Safari are all built on the same codebase. (Chromium split from Apple’s WebKit a while back, but they still have a lot in common.)
Monoculture is still a problem, no matter who runs it. We’re already at the point where webdevs are treating Chrome like the defacto standard, the way they did IE6 back in the day.
Firefox is going to be even more important in the future, ensuring that the web continues to be built on interoperable standards instead of one stakeholder’s goals.
Mozilla is a non-profit organization, and like many, they’re running a year-end donation drive. Now is a good time to contribute to their mission to keep the internet and the web open. (I’ve already made my annual donation to them.)
I think I may want to finally shut down or retool that old Alternative Browser Alliance site I ran during the Second Browser War. The last time I made a significant update to it, Chrome was the new upstart.
If you’ve been following the Firefox 4 betas, you’ve probably noticed that they’re dumping the status bar. OK, a lot of people didn’t use it, but here’s the thing:
When you hover over a link, the status bar tells you where it will take you.
This is important (especially for security) — important enough that they’ve moved the functionality elsewhere…but in a broken manner. They’ve put it into the location bar — you know, the field where you type in a URL, or look to see where you are.
The problem is that there isn’t room in the location bar to show the full URL of a hovered link except for very short links. The status bar has the entire width of the browser. The location bar has to share that space with the navigation buttons, the search box, the feedback button (during the beta), any custom toolbar buttons, the site name on secure websites, etc.
Just about every link I hover over ends up with critical information cut off in the “…” between the start of the hostname and the parameters at the end. That’s almost useless. (Almost, because at least the hostname is visibla, but it would help to see the page name as well.)
Displaying the target URL in some way is core functionality for a web browser, and you shouldn’t remove or break core functionality. In some ways this is worse than the proposal a few years ago to remove “View Source,” because that at least isn’t core functionality for a browser (though it is core functionality for the web, because it encourages people to explore and tinker and learn how to make their own websites — which is exactly why that was put back in). It’s crazy that I need to install an add-on to get back something as basic as a working preview for links.
Firefox has been testing a new release that detects and closes crashed plugins (instead of letting them crash Firefox entirely) for several months, carefully making sure everything was working before they released Firefox 3.6.4 last week.
Within days, they released an update. I couldn’t imagine what they might have missed in all the beta testing. Katie wondered if the beta testers hadn’t been testing the limits.
You want to know what convinced Mozilla to issue an update so quickly?
Farmville.
Apparently Firefox was detecting Farmville as frozen and closing it. It turns out that on many computers, Farmville regularly freezes up the browser for longer than 10 seconds, and its players just deal with it and wait for it to come back. Mozilla decided that the simplest thing to do would be to increase the time limit.
What this tells me is that the type of person willing to beta-test a web browser these days is not likely to be playing Farmville — or if they are, it’s likely to be on a bleeding-edge computer that can handle it without 10-second freezes.
In more practical terms: Mozilla needs to convince a wider variety of users to help test their software!
I recently tried to retrofit a mobile layout onto an old table-based site using CSS. It was a fairly simple layout: A banner across the top, two columns, and a footer. I figured I’d use CSS to “unwrap” the table and make the sidebar and main content area into full-width sections instead of side-by-side columns.
In theory this should be simple: CSS handles tables by using the display property and assigning it table, table-row and table-cell for the <table>, <tr> and <td> elements. You can assign these properties to other elements and make them act as tables, or you can assign block or inline to these elements and make the table act like a series of paragraphs.
Initial testing worked perfectly in Firefox 3.6 and Opera 10.5x. Internet Explorer 8, as expected, ignored the changes entirely. Chrome, however, did something very strange, and Safari reacted the same way: The banner shrank, and the columns changed from a narrow sidebar to a 50/50 split…making it actually worse for small screens.
Clearly WebKit didn’t like something I was doing. Unfortunately, WebKit powers the exact platforms I was targeting: the iPhone and Android!
I dug around with the developer tools a bit to see if I could figure out what was going on. Was the browser not applying the property? Were the table cells inheriting the “original” property from somewhere else? Did I need to change properties on thead and tbody as well?
What I found was that WebKit did recognize the display:block I had added, but somehow the computed style was reverting to display:table-cell. This only applied to table and td, though. Table rows actually did what I told them to, which was why the result ended up looking bizarre.
If it hadn’t changed anything, I probably would have chalked it up to the capability just not being implemented yet. But since it worked on table rows, but not on cells, I decided to treat it as a bug in WebKit and went looking for the best way to report it. I ended up creating a WebKit Bugzilla account and reporting it as bug 38527.
Check out the testcase in Firefox 3.6 or Opera 10.5 to see what it should look like, then take a look in Chrome 4 or 5 or Safari 4.
A good tech support one-liner from (The customer is) Not Always Right: A Flock Of Explorers On A Safari Singing Opera.
Me: “Alright, so what browser are you using to view your websites?”
Customer: “Mozzarella Firefox!”
I don’t know how I missed this easter egg before: In Firefox, type about:robots into the location bar. (via @Aeire & @IsobelWren) If you’re a science fiction fan, you’ll get a kick out of it!
