I'm curious if anyone can help explain the trouble I am currently having with Firefox - the memory leak problem seems to be fairly well-known, but setting the browser.cache.memory.capacity lower seems to have absolutely no effect. Once it hits 280-300k, it hangs. Is there anything else I can try? Failing that, what are some acceptable Firefox alternatives?
Yeah I also noticed that setting the cache size doesn't really work. Too big and they are problems. Too small and it's a waste. My solution is to empty the cache regularly. But sometimes you click the Empty button and nothing happens, the cache is still there. In those cases I go to the \cache directory and delete all files myself.
Another source of problem is that file that grows very fast in Mozilla\Firefox\Profiles\[number]\downloads.rdf.
When it goes over around the 1,500,000 bytes mark then Firefox gets slower and slower to display.
To empty it: Tools > Downloads > Clean up.
One file you can safely delete is XUL.mfl, Firefox will recreate it on its next run. Sometimes deleting it solve problems.
Thanks for the advice >>2!
Also, Opera http://www.opera.com/ is now ads and license free, tho it doesn't have the same large array of extension plug-ins as Firefox.
Okay, thanks. I'll give it a look.
>>4
opera is faster and uses less memory than firefox, but it has lousy css support...
It's a good idea to regularly clear your download list in Firefox.
I set it to clear whenever I close the browser but I guess there should be extensions out there that do it on automated schedules for you.
> it has lousy css support
Really? http://nanobox.chipx86.com/browser_support.php
Opera also employs several people who helped create the CSS specs.
Opera's main problem at the moment is its half-assed XMLHttpRequest implementation.
Yeah, indeed.
Except that XMLHttpRequest is actually used for things. How many websites do XSLT processing client-side?
Not many, because we have to remember that silly Opera users couldn't use the page.
Firefox is also quite horrid with its file system dialog boxes. Best to have your default save location somewhere with not a lot of files, and not a lot of directories (even recursively). Not really going to help with memory usage though =(
>>11
Less than 1% of surfers use Opera. The vast majority of surfers use IE6 or a gecko-powered browser.
If there are people are willing to build their entire websites around Internet Explorer alone, you can be certain there also people who are willing to build websites that will exclude an even tinier population by using XSLT.
So I don't buy it. Something else is going on.
XSLT is black magic to a lot of people. It's much more complex to master than (X)HTML, and for most people static HTML does fine for their needs.
I've hardly ever seen on-the-fly XML->XHTML transitions being done on the client end, and know of very few sites who do it server-side.
Gentoo's docs are one example of server-side XML in action, they use some axkit magic -- I've never managed to fathom it out. I also have a little wrapper script around xsltproc, which works quite nicely for my needs:
XHTML: http://www.longlandclan.hopto.org/~stuartl/gentoo/docs/index.php/gentoo-doc/en/handbook/handbook-mips.xml
XML: http://www.longlandclan.hopto.org/~stuartl/gentoo/docs/gentoo-doc/en/handbook/handbook-mips.xml
(Which reminds me, I'll have to cvs-sync that site one of these days... Ahh well, I'll do it next time I update the MIPS handbook.)
Anyways... we're getting offtopic.
On the suggestion from >>2. I'm not sure if this is an extension somewhere, but Firefox 1.0.6 allows for the download manager to be cleared on exit.
In the Preferences (Tools -> Preferences on Windows, Edit -> Preferences on Unix/Linux, don't ask me why it's different) in Privacy, expand out the Download Manager History section, and select "When Firefox exits" from the drop down menu you see.
This should keep the downloads list in check. :-)
I think of XSLT as glue for different pieces of software. As such, I'm not certain how much use there is for it in a browser. It just adds another layer of complexity.
Can someone more knowledgable shed light?
Well, theorertically, it would be easier to design an application that just outputs data in a structured XML format, and lets the browser and XSLT transform it on the fly... In practice, I'm sure there are complications.
One that comes to mind is that my friends who've worked with it complain that XSLT is utterly horrid, syntax-wise.
It is...
The following monstrousity is similar to what Gentoo uses for their entire site. Utterly hideous voodoo.
http://www.longlandclan.hopto.org/~stuartl/gentoo/docs/gentoo-doc/stylesheet/live-guide.xsl
That said, it's damn fine voodoo. ;-)
>>13
1%? Not here at 4-ch. Try 18%. IE and Mozilla are neck and neck for first place. Mozilla usually wins, but not by much.
>>15
Using XSLT you can make the browser render a XML page into HTML. The plus side is that whilst the page looks like it was made in HTML, has tables, has styles etc the actual code is pure XML. So generating and parsing the data is significatly easier. The negative is that only very recent, non-opera browsers can use it. And of course, the bit I hate about XML, if one fucking thing is incorrect, you get a XML parsing error, and don't even get to see what the page looks like.
Ah, I see.
I'm still not convinced though. If you're going to output XML, why not just use XHTML in the first place? Why go to all the trouble of producing XML and then using XSLT? If you're going to be munging around in XSLT code to create changes in the output, how is that much different than doing it the other way?
Can someone give me an example where there's a clear advantage for using XML + XSLT in a browser instead of producing XHTML in the first place? The only uses I can think of are esoteric.
In a browser? No advantage. But having the same XML file used between a browser, an application, etc that's the advantage.
There's no clear advantage, it's a very subtle advantage. For instance:
Automated tools that want structured data can use the exact same data source as people viewing things in a browser. You don't need separate data streams.
Bandwidth may be less with a structured data format that doesn't include all the HTML markup needed to produce a pretty page.
Your programmers can focus entirely on handling and outputting data, without ever having to think of how it is displayed - that work is offloaded onto those making the XSLT.
It's much the same as the question "Why would I want to use CSS and semantic HTML when I can just use HTML 4 and a table-based layout to get the exact same result?"
What an interesting derailment this has been. XSLT for the win!