Sure. It would just plummet even more if it were an oil heater.

Also about your heating source. Burning natural gas or using steam radiators puts a lot more water in the air than burning oil does.

Mozilla is actively implementing the Web Audio API, for what it's worth.

SSL by default for Google since Firefox 14, back in July 2012. See https://bugzilla.mozilla.org/show_bug.cgi?id=633773

For other search engines it depends. For example, Wikipedia has asked that the search through their search plugin keep happening over HTTP for now (see https://bugzilla.mozilla.org/show_bug.cgi?id=758857 ).

I've been using Firefox on Android too, in the "eat my own dogfood" way, and while a lot of sites are fine, some are just completely broken because of all the WebKit-isms. :(

> I'm betting they would get some people in the team of
> maintainers.

Possibly. It's hard to say with these sorts of things. The question I'd be asking as a Microsoft executive is how risky a play this would be...

You mean Trident?

There's a nonzero chance that they don't own all the rights to all the pieces of it, if they licensed them from somewhere.

But past that, who knows. They might just not be ready for that sort of thing at all on an organizational level yet.

> People ought to know that the prefixed attributes
> are in beta and may change.

That would be true if WebKit didn't explicitly promise to never remove or change them. Which they do. So people assume they can use them with no fear.

> Fortunately none of the vendor-specific extensions
> are anything but minor enhancements,

That's just not true for transforms, where not supporting them makes a page done entirely using positioning via transforms totally unreadable.

Or for animations where an element is display:none or off-screen and then animated in: no CSS animations means you never see the element at all.

Seriously, I suggest using a non-WebKit mobile UA for a bit and seeing just how broken some sites are.

Actually, in a very real sense the engine _does_ belong to the competition. To actually get your code landed in WebKit you have to convince the current project maintainers (mostly Google and Apple) to accept it.

Which means that if you want to do something that Google and Apple don't (both, often!) approve of, you have to maintain it as a separate branch and deal with the merge pain. No different from other projects where you have to collaborate with others, but a lot different from having control over the code as Microsoft does with Trident right now.

Firefox 10 ESR is out of support 6 weeks from now, for what it's worth, with ESR 17 taking over.

Very true what you say about IE, though. It's trying to handle IE8 and lower that people run into problems with.

Everyone and their mother designing "mobile" sites. For some big names, Google, Disney, Comcast, DirecTV, Flickr will all sniff whether you're on "mobile" and either serve you WebKit-only sites or detect that you're not using WebKit and serve you totally different, mostly unusable, sites than they do to WebKit-based browsers.

You should really try using a non-WebKit browser on Android. It's worse than trying to use a non-IE browser in 2000-2001 or so.

A lot of people have problems with this setup, precisely because people end up shipping sites that only work in only one browser.

There is no exposed way to disable updates in Chrome that I know of.

Most applications are not automatically launched when you visit random websites.

In fact, that's the change Mozilla made: they turned on click to play for Java so that it is no longer launched automatically when you visit a site with a java plug-in.

> For the Mozilla team to say there will "never" be a
> 64-bit build for Windows

Which is something no one at Mozilla ever said. But don't bother reading what they actually said, just read the lies lazy reporters spouted instead.

What Benjamin said is that there are no plans to ship a final 64-bit product in the next several months.