Forum: Weblog comments

Way to go stealing my idea http://home.kairo.at/blog/2007-06/the_fight_for_the_suckiest_ua_string#p4155
I don't mind. I think that what you are proposing should be more generally handled, otherwise you may need to add more and more info bars for each type of growing incompatibility.

Sites that are incompatible, in any way, with Firefox (and standards in general) could be managed, with various user-provided shims to fix them. These could be in the form of the most basic - a User-Agent spoof, all the way up to GreaseMonkey like scripts to patch bad behaviour.

The UI would be similar to what you have shown - "This website is known to not yet be fully compatible with Firefox. Firefox has taken some measures to correct the issue automatically, but cannot guaruntee this website will function correcty. Please click the button for more info"

The button would take you to a tab in the page-info dialog to show what shims have been used, and a notice to state that the user could consider contacting the website owner to improve compatibity with Firefox.

Opera lets users configure site-specific preferences (cookies, user-agent spoofing, and more), and it automatically downloads an override_downloaded.ini file that configures things (all user-agent fixes (and one "CompatMode Override") at the moment). It even auto-downloads a browser.js file that uses JavaScript to fix broken websites.

The problem is that it doesn't warn users when it does this. Your infobar idea is great.

I assume Opera's files are maintained completely by Opera, with no user-control except for reporting things. A Web 2.0-ish website sounds pretty neat, except that you have to remember there are stupid and malicious people out there. Let users submit and vote on problems and solutions, but someone has to be there to review things.

Well, if you guys create such a thing, I think it should be RDF. Create an RDF Seq with the items being links to the browsers' sites and contents being the UA string. Then you create a list of sites and rdf:about to which browser string to use (Firefox, Netscape, IE, etc.). Well that's my idea of a good way to do it.

Also, make it public domain. That would help the other browsers more than anything.

If I was you guys I would be encouraging Web Developers to stop testing and building websites with Firefox.

Instead they should be using GeckoDeveloperFox (okay terrible name), which is basically Firefox with all the useful web testing tools and extensions baked in and a new UA (adopted immediately by small-fry like Camino and Epiphany and later by Firefox) of Gecko/version/build (or whatever).

This means I can avoid wondering why the internet is so slow every time I turn caching off for testing. It means the web developer stuff won't be fighting for space with my Google toolbar. My personal surfing History/Bookmarks etc. won't get messed up with my work.

Maybe it's just the websites I frequent but it seems an amazing amount of people use Firefox just because of the amazing web development tools. Having a special build for these people could make this better, while streamlining the main release and helping people test their sites properly against Gecko and not just Firefox.

It may not work on it's own, but I think it could have a noticeable impact. If you want to influence people, make their life easier, give them a good reason to do as you ask.

Maybe it could be done like the undetectable document.all support.

Check for common Firefox detection routines like indexOf("Firefox") and modify their behaviour, possibly notifying the user of the problem.

Last edited by KaiRo at 2007-06-28 16:31

FYI, Konqueror (as distributed with openSUSE Linux 10.2) does something similar but static: it comes with a user-settable list of "spoofable" sites, preloaded with the following (I'm not writing the UA strings in full but if you want them, email me):

computerworld.com: IE4 on W2K
fernuni-hagen.de: IE5 on Mac PPC
gmail.com: Safari on Mac PPC
google.com: Safari on Mac PPC
logitech.com: IE4 on W2K
merian.spiegel.de: Mozilla 1.7.3 on Linux x86_64
sco.com: IE4 on W2K

The dynamic solution you propose seems better in terms of flexibility and reaction time (if properly maintained), worse in terms of bandwidth and (I guess) manpower at some central site. I'd say: if it can be done, go for it. But should it be all centralised or should the user have some leeway (for edge cases not "yet" covered by the central database)?

Just have a look to the latest Jquery.js library :

var b = navigator.userAgent.toLowerCase();

// Figure out what browser is being used
jQuery.browser = {
version: (b.match(/.+(?:rv|it|ra|ie)[\/: ]([\d.]+)/) || [])[1],
safari: /webkit/.test(b),
opera: /opera/.test(b),
msie: /msie/.test(b) && !/opera/.test(b),
mozilla: /mozilla/.test(b) && !/(compatible|webkit)/.test(b)
};


Gniiiii ? and why not document.all ???


As I said in French (here http://dascritch.net/blog.php/2007/07/05/818-javascript-comme-un-dialecte ), too much work is to do in Dom support and so much "well known" javascript librairies to be rewritten first.

Sorry my bad French

this stupid page : http://www.mozilla.org/docs/web-developer/css1technote/css1tojs.html

very very very ugly practices