Slashdot Mirror

Except that they do share his concerns. Not the version fragmentation problem, but the "lack of hardware uniformity" problem. Software testing in android is already hard, because the same software can work differently depending on some subtle hardware difference, so you need to test in different devices. It's not the end of the world, windows programmers were able to make programs for the hardware nightmare that the PC world is, but it's not nice.

I use Adblock Plus in Firefox 1.1 on my Nokia N900. The Android port of Firefox is in progress:

http://blog.vlad1.com/2010/04/27/fennec-on-android-ground-zero/

To advantage which of it own Apps does Apple use its OS advantage ?

On the iPad, only Apple software can multitask (this article has a list: email client, SMS text client, and other apps). On any of their platforms, only Apple software may use the APIs that let you customize the way the UI widgets display. Only Apple software can use the full functionality of the accelerometer. Here is a blog post discussing some undocumented OS X features that made Safari much faster than Firefox 3. And here is a blog post discussing how several apps were rejected for using undocumented functionality. And here is a whole article discussing undocumented Apple APIs, with examples of cool stuff that only Apple's own software is allowed to do. And here is an article discussing cool things that Safari can do, that Firefox isn't allowed to do. And here is a column that claims that Apple inserts undocumented APIs and uses them in its own code for years, without ever documenting them (but presumably without breaking them because it would break Apple's own code). Even the APIs for the WiFi are undocumented.

I understand the argument that Apple doesn't want to commit to supporting these APIs forever, like Microsoft has had to do with even obscure APIs in Windows. If you use these undocumented APIs to do cool things, and Apple revises the OS, your app may break. And Apple doesn't want the customer to think it's Apple's fault that your app broke.

But I also understand the argument that some of these APIs allow for really cool stuff, which is currently reserved only for Apple. People don't like this.

As for me, give me Linux anyway. No such thing as an "undocumented" API, and there is no entity that has an unfair advantage over everyone else, and I can install any software I want.

steveha

Because the full featured Firefox browser is coming to Android.

http://blog.vlad1.com/2010/02/02/android-progress-more-pixels-edition/

that's exactly why i posted links to the GWTCanvas and the GChart demos, as they show that it is in fact possible to do "graphics" using DOM manipulation. also, with WebGL coming in HTML5 to both webkit and firefox, it will be a simple matter of having a framework that creates the relevant DOM elements.

voila - instant control over 3D graphics code (written in c), from python or javascript.

There's no easy workaround that will both allow you to have a history, and allow web pages to display something different (e.g. link colour / style) for pages that you have visited already.

Sure there is. Have your browser always pull the visited and unvisited styles, then just display the relevant one. Problem solved.

Exactly, if the visited/unvisited pseudoclasses are pulled/suppressed when the textcolor is being read, this particular site would no longer be able to read people's history. This should be easy to implement in a Firefox extension.

There would be no loss of usability, although some "pretty" scripts might not function correctly, eg, a script that fades a link colour to a different colour triggered by an onmouseover event.

This may not cover the security hole, because there are probably other ways of getting the text colour, perhaps using Canvas in Firefox.

I'm guessing every hole in this solution could be covered, but I don't work on Firefox.

The other browsers should be able to be "fixed" too.

I am honestly torn on the idea of CSS sprites. While yes, they do decrease the number of HTTP requests, they increase the complexity of maintaining the site. Recently, Vladimir VukiÄeviÄ pointed out how a CSS sprite could use up to 75MB of RAM to display. One could argue that a 1299x15,000 PNG is quite a pain, but in my experience sprites end up being pretty damned wide (or long) if you have images that will need to be repeated or are using a faux columns technique.

Some times it gets to be a better idea to make a few extra initial requests, then configure your server to send out those images with a far future expires header (which you should do for the sprite anyway). At that point you're just talking about the initial page request, and then subsequent visits get the smaller sized. With one site I am working on the initial page view is hitting 265 KB on the initial view, 4.75 KB for the next month.

I don't see this mentioned anywhere, but Google has already switched to the HTML5 Doctype. It is much shorter the other flavors.

The publicly available WebKit source includes binary blobs, without which it is (AIUI) unusable. They're also deeply tied in to the internals of Mac OS X. What do they do? Things that are impossible using the published APIs - basically, like a more evil equivalent of Microsoft's supposed secret APIs. (At least those were actually APIs.)

These aren't just for minor things - fundamental stuff like text rendering is (still) done through the binary blobs. What's more, the binary blobs aren't compatible across Mac OS X releases - potentially making it impossible to use a version of WebKit on any Mac OS X release other than the one it's intended for, even if you compile from source.

You mean the canvas element? Firefox and Opera are already working on 3D drawing contexts.

Opera build, Opera Code example
Firefox Addon

Another advantage to giving web apps this power- it makes learning programming (especially the flashy bits) easier. Elementry-schoolers needn't worry about configuring compilers, managing imports, window handles, etc; the browser does it all. HTML and parts of Javascript are simple enough to explain with a good teacher; gloss over the trickier bits at first with a voodoo var artist = getElementById('canvas').getContext('2d'); line, and drawing becomes much more accessable.

The ZSNES developers for one prefer how Qt works and R. Belmont (of MAMEdev fame) also stated that the only reason he used GTK+ on the Linux port of Audio Overload was because various portions of the code weren't compatible with the GPL. If they had been, he'd have used Qt instead. I also prefer Qt, hence why I use KDE in preference to anything else and why I view the possibility of Mozilla using Qt with some excitement.

I'd go as far as to say that GTK+'s 'killer feature' these days is the licence. The fact that it uses the LGPL as opposed to the GPL and was open sourced well before Qt is why it's remained so popular. In most other respects, Qt is the better toolkit.

It's more accurate to say that WebKit is mostly open source. Apparently, it uses closed-source binary blobs based around private APIs and OS internals for various functionality under Mac OS X. (This used to include such vital things as font rendering.) Personally, I think this is probably a violation of the LGPL - it only allows you to use the library from closed-source code, and modifying the library so that it's dependent on closed-source code (other than the OS libraries) is still forbidden.

That doesn't solve the problem. Also from the fucking comments:


> For this case, there is a public way of doing what we needed to do, and it works well.

It actually doesn't work all that well because all our embedders (Prism, Songbird, etc) have to add this option to their plists. If they forget, they'll just mysteriously get crappy performance.


Firefox runs into the same problem that caused WebKit to use the undocumented API. Anybody embedding it will get crappy performance unless they add the option to their plists.

Eh. Vladimir (this post) seems pretty civil about it. I'd focus my attention on the internet community for yet again blowing something out of proportion.

His finding is that there is a beamsync synchronization, which can possible cause rapidly updating displays to slow down. There are some yet undocumented calls in the Webkit library that allows software to deal with beamsync.

If instead of conspiracy theories you are interested in an answer from one of the co-creators of Firefox and who is currently working at Apple's WebKit team, here it is: http://blog.vlad1.com/2008/02/28/finding-the-os-x-turbo-button/#comment-573

From David Hyatt's reply, it seems that the webkit team as a whole somehow doesn't like this practice too. David Hyatt was one of the original developers of Firefox and now he is working for Apple.

http://blog.vlad1.com/archives/2006/10/01/120/ http://blog.vlad1.com/archives/2006/10/02/121/ http://blog.vlad1.com/archives/2006/10/04/122/ http://blog.vlad1.com/archives/2006/10/04/123/ http://blog.vlad1.com/archives/2006/10/05/124/ These posts, in order, are about the visit and what they learned.

http://blog.vlad1.com/archives/2006/10/01/120/ http://blog.vlad1.com/archives/2006/10/02/121/ http://blog.vlad1.com/archives/2006/10/04/122/ http://blog.vlad1.com/archives/2006/10/04/123/ http://blog.vlad1.com/archives/2006/10/05/124/ These posts, in order, are about the visit and what they learned.

http://blog.vlad1.com/archives/2006/10/01/120/ http://blog.vlad1.com/archives/2006/10/02/121/ http://blog.vlad1.com/archives/2006/10/04/122/ http://blog.vlad1.com/archives/2006/10/04/123/ http://blog.vlad1.com/archives/2006/10/05/124/ These posts, in order, are about the visit and what they learned.

http://blog.vlad1.com/archives/2006/10/01/120/ http://blog.vlad1.com/archives/2006/10/02/121/ http://blog.vlad1.com/archives/2006/10/04/122/ http://blog.vlad1.com/archives/2006/10/04/123/ http://blog.vlad1.com/archives/2006/10/05/124/ These posts, in order, are about the visit and what they learned.

http://blog.vlad1.com/archives/2006/10/01/120/ http://blog.vlad1.com/archives/2006/10/02/121/ http://blog.vlad1.com/archives/2006/10/04/122/ http://blog.vlad1.com/archives/2006/10/04/123/ http://blog.vlad1.com/archives/2006/10/05/124/ These posts, in order, are about the visit and what they learned.

Full SVG support, integrated and sorted (should have been done before)

"Full SVG" doesn't make it entirely clear what you want, given the different versions and profiles. Most web browser developers seem to dislike the recent SVG Tiny 1.2, because its design is unsuitable for the web. Mozilla already has bloat problems with their SVG implementation (partly their fault, partly because the spec is large and complex), and some developers want a simpler SVG because most people don't actually need SVG - they just want proper scalable images in web pages. (The same applies for wanting animated PNGs, but not needing MNG). None of that is an excuse for bugs or missing features in what they've already decided to try to implement, though.

Whole page zoom seems to be an area where Firefox is falling behind at the moment - as far as I can see, the plan is to do that for Firefox 3 (which has a new graphics system) some time next year. I believe that new graphics system will let them do nicer image resizing too.

Geez, what happened to FF being a lightweight alternative to the suite?

A fucking SQL engine ...

... and more bloat for JS!

What next, OpenGL, ...

Personally I'd like to see APNG gain support to the point it becomes worthwhile to add it into the code.