Annoying Firefox problems when surfing sgforums
-
i guess this is sgf coding problem .. i might be wrong
-
From the CSS file:Originally posted by FireIce:yeah is a ff thing
big pictures oso cannot see full pic
admin tried to fix liao but cannot.
i think i can oni say, too bad
.msg-body {
font-family: Arial;
font-size: 13px;
padding: 1em 0.3em 2em 0.3em;
overflow: hidden;
}
Full pic problem:
I think FF hide stuff that is overflow, that's why the picture cannot display in full if too big. IE is OK because the css didn't specify a fixed size which IE needs to be able to overflow. -
that is very rude. some poeple never change.Originally posted by FireIce:problem between keyboard and chair
-
Please note that those buttons use JavaScript... what works for IE will not work in Firefox and some other browsers...
Don't believe, disable JavaScript, click on those buttons and see where it brings you. -
Originally posted by ndmmxiaomayi:Please note that those buttons use JavaScript... what works for IE will not work in Firefox and some other browsers...
Don't believe, disable JavaScript, click on those buttons and see where it brings you. -
Originally posted by turbo_drift:
-
It's not an issue with Firefox. When this forum was started 9 years ago, Firefox was still a sperm and egg. The (quirky) JS code used for the posting page is targeted at IE users only since it monopolized the browser market then. If you're expecting features that you see on other forums, you should write to Jason about upgrading the entire forum backend instead.Originally posted by Gordonator:i'll write to firefox to fix this problem. -
Cannot create one. If got liao Opera users will jump ship de, then I will be all alone.Originally posted by Y_Shun:pay PEE etc etc ya da ya da...
aiya juz bear with it.
budden i think FF, with greasemonkey thingy, can fix these things(if someoen creates for sgF)
-
Originally posted by LatecomerX:Cannot create one. If got liao Opera users will jump ship de, then I will be all alone.
-
Actually thats a problem I faced working on my recent project. How to get Firefox and IE to work the same way. Some stuff works for IE, and doesnt work for Firefox, and vice versa.
Some of these problems may not have solutions at all. So sometimes the only option is to remove those implementations or look for alternatives. Some of the teething problems includes scrolling and sizing.
I was wondering, whether all web applications like forums n stuff would move to Adobe Air application versions? It'd be interesting to see a forum exist as a desktop application. Air Technology's cross platform compatibility would resolve a lot of these "browser differences." -
It will be easier to get everyone onto Firefox than to some "cutting-edge" Adobe applications. But no, everyone, please come to the big red "o".Originally posted by Shotgun:Actually thats a problem I faced working on my recent project. How to get Firefox and IE to work the same way. Some stuff works for IE, and doesnt work for Firefox, and vice versa.
Some of these problems may not have solutions at all. So sometimes the only option is to remove those implementations or look for alternatives. Some of the teething problems includes scrolling and sizing.
I was wondering, whether all web applications like forums n stuff would move to Adobe Air application versions? It'd be interesting to see a forum exist as a desktop application. Air Technology's cross platform compatibility would resolve a lot of these "browser differences."
And I don't see your point of having a forum to be ran as a desktop application. Firstly, it becomes less accessible since users will need to download the application before it is usable. Secondly, coding the GUI for a desktop application is much more complicated than cooking up a set of HTML and CSS code. Next, you have the OS platform compatibility issue. I think it's best to just leave it as a web application.
Besides, everything else is moving online as well. Now you already have the online clone of Microsoft Word. Once we reach the age where processors are measured in Terahertz and bandwidth by Gbps, I'm sure you'll see young kids playing Doom XI without downloading any client application for game installation.
To make your web application to be cross-browser, there are two ways to go about it. Either use a well-developed framework that handles all those tweeny-weeny browser issues, or do your own browser checking and serve different code to each browser. -
LOL!
These problems so common to me.. -
dun worry, i oso opera usersOriginally posted by LatecomerX:Cannot create one. If got liao Opera users will jump ship de, then I will be all alone.
-
So if someone writes the GM script, will you jump ship?Originally posted by Y_Shun:dun worry, i oso opera users 
-
Thats where Adobe Air comes in. You can create cross platform desktop applications using familiar HTML, scripting languages, CSS and javascript. Of course, it can still at the same time run on web browsers, but you just have an added advantage of having it on the desktop.Originally posted by LatecomerX:It will be easier to get everyone onto Firefox than to some "cutting-edge" Adobe applications. But no, everyone, please come to the big red "o".
And I don't see your point of having a forum to be ran as a desktop application. Firstly, it becomes less accessible since users will need to download the application before it is usable. Secondly, coding the GUI for a desktop application is much more complicated than cooking up a set of HTML and CSS code. Next, you have the OS platform compatibility issue. I think it's best to just leave it as a web application.
Besides, everything else is moving online as well. Now you already have the online clone of Microsoft Word. Once we reach the age where processors are measured in Terahertz and bandwidth by Gbps, I'm sure you'll see young kids playing Doom XI without downloading any client application for game installation.
To make your web application to be cross-browser, there are two ways to go about it. Either use a well-developed framework that handles all those tweeny-weeny browser issues, or do your own browser checking and serve different code to each browser.
Theres quite a large potential for doing this as well. Desktop Web Apps, can be used to create virtual offices, where secure connections are required, and cross platform operations are a necessity. Go check out Adobe Air. I feel that its gonna be a big thing. -
I have just spent about 30 minutes looking up on it. It definitely looks promising, but it will only make an impact similar to Flash during the pre-DHTML era, in my opinion.Originally posted by Shotgun:Thats where Adobe Air comes in. You can create cross platform desktop applications using familiar HTML, scripting languages, CSS and javascript. Of course, it can still at the same time run on web browsers, but you just have an added advantage of having it on the desktop.
Theres quite a large potential for doing this as well. Desktop Web Apps, can be used to create virtual offices, where secure connections are required, and cross platform operations are a necessity. Go check out Adobe Air. I feel that its gonna be a big thing.
Indeed, it's easier on the web developers as they don't have to pick up another few more languages to code a desktop application, and Adobe solves the OS platform compatiblity issues for them as well. But the barrier of having to download and to install the application for the users remains. The HTML and JS code may not be rendered in the exact same way as on web browsers unless it's WebKit-based such as Safari. So it's just as good as pushing everyone to use Safari to surf the web. And even if this AIR thing gets popular, Microshyt is simply going to come out with a clone and replaces the technologies within with its own proprietary ones (say, instead of WebKit, they use their own IE rendering engine), just like Flash and Silverlight. So at the end of the day, the web developers are simply getting more headaches with all these new, emerging technologies.
To add on, due to the difference how security issues are handled by web browsers and AIR, a moderate to large-scale web application will probably not be able to fit into both platforms without major editing required to adapt to one of them.
Furthermore, if a programmer only needs to create a cross-platform desktop application, that dear old coffee-flavoured Java will always be there. -
My only concern is lag. Seriously, take a look around Ajax websites like Yahoo! Mail, Live Hotmail. Ajax lags badly on a computer with just 256MB of RAM. And to top it off, it's a barebones system with no extra programs, tweaked to improve performance.
If Ajax websites can lag so badly on such a system, desktop applications will kill it.
I've trialed one website which uses Adobe Air. Webbie loads fast, but in less than half hour of usage, it caused browsers to start leaking memory and caused huge lags. The only way is to kill it and restart the computer.
What Adobe needs - an efficient coding team. Notice that all products of Adobe lags very badly. -
Fair enough. Thats the penalty for having XML providing instantaneous updates to a low end system. Then again, 256MB Ram machines aren't gonna be around much longer are they?Originally posted by ndmmxiaomayi:My only concern is lag. Seriously, take a look around Ajax websites like Yahoo! Mail, Live Hotmail. Ajax lags badly on a computer with just 256MB of RAM. And to top it off, it's a barebones system with no extra programs, tweaked to improve performance.
If Ajax websites can lag so badly on such a system, desktop applications will kill it.
I've trialed one website which uses Adobe Air. Webbie loads fast, but in less than half hour of usage, it caused browsers to start leaking memory and caused huge lags. The only way is to kill it and restart the computer.
What Adobe needs - an efficient coding team. Notice that all products of Adobe lags very badly.
I use a wide line of Adobe Products. Stuff like Photoshop, Flash, Fireworks, Dreamweaver, Acrobat Pro, Illustrator... Only photoshop and illustrator gives me problems with "lag" once in a while. But I figured that was due to my 915 chipset than anything else.
IMO, Ajax sites face the same performance penalties as web services using WSDL. It takes time for an xml, to trave back and form, recompiled etc. That one can't be helped until they somehow find a better way to compile XML. I mean you look at an xml document, you'll see more header/tags than data. There's inefficiency in the way it works already.
If they improve the xml efficiency issue, I think Ajax, and Air apps should become a lil more responsive as well. Maybe instead of sending one huge xml chunk, they should break up their applications to chew on smaller chunks. -
Actually XML is not the only thing AJAX can send and receive during requests, despite the fact that the "X" in AJAX refers to XML. Text and comma-separated values are some of the alternatives used to reduce bandwidth usage in AJAX requests. Of course, if the main usage of AJAX is to insert/replace existing HTML elements on the page or delivering random chunks of data, it's still the best to use XML. I mean, XML data such as:Originally posted by Shotgun:Fair enough. Thats the penalty for having XML providing instantaneous updates to a low end system. Then again, 256MB Ram machines aren't gonna be around much longer are they?
I use a wide line of Adobe Products. Stuff like Photoshop, Flash, Fireworks, Dreamweaver, Acrobat Pro, Illustrator... Only photoshop and illustrator gives me problems with "lag" once in a while. But I figured that was due to my 915 chipset than anything else.
IMO, Ajax sites face the same performance penalties as web services using WSDL. It takes time for an xml, to trave back and form, recompiled etc. That one can't be helped until they somehow find a better way to compile XML. I mean you look at an xml document, you'll see more header/tags than data. There's inefficiency in the way it works already.
If they improve the xml efficiency issue, I think Ajax, and Air apps should become a lil more responsive as well. Maybe instead of sending one huge xml chunk, they should break up their applications to chew on smaller chunks.code:
LatecomerX
password
LatecomerX2
1337
password2
makes much more sense thencode:
LatecomerX,password
LatecomerX2,1337,password2
don't they? In short, XML takes the work of raw data processing off the client and protects the integrity of the data to some extent (for example, if there is a missing closing tag, the client can tell that the data is not complete).
Compressing XML data is a good idea, but this also means that it would be have to be decompressed on the client-side, which translates to higher CPU time cost and hence lag on lower-end systems, especially if many AJAX requests are sent and received in a short time.
There's another technology emerging that may become a good competitor against AJAX in time to come - the use of long polling. You may want to read it up on it through the links below.
http://en.wikipedia.org/wiki/Comet_(programming)
http://meteorserver.org/interaction-modes/ -
Event driven... something like ASP?
-
I'm not sure how ASP is event-driven since I don't code in ASP. In the case of Comet, the connection initiated by the client remains open until there is a data transfer triggered by a modification of data on the server, so in a way it is event-driven.Originally posted by ndmmxiaomayi:Event driven... something like ASP? -
You see, that exactly the problem with XML. Inefficiency.Originally posted by LatecomerX:Actually XML is not the only thing AJAX can send and receive during requests, despite the fact that the "X" in AJAX refers to XML. Text and comma-separated values are some of the alternatives used to reduce bandwidth usage in AJAX requests. Of course, if the main usage of AJAX is to insert/replace existing HTML elements on the page or delivering random chunks of data, it's still the best to use XML. I mean, XML data such as:code:
LatecomerX
password
LatecomerX2
1337
password2
makes much more sense thencode:
LatecomerX,password
LatecomerX2,1337,password2
don't they? In short, XML takes the work of raw data processing off the client and protects the integrity of the data to some extent (for example, if there is a missing closing tag, the client can tell that the data is not complete).
Compressing XML data is a good idea, but this also means that it would be have to be decompressed on the client-side, which translates to higher CPU time cost and hence lag on lower-end systems, especially if many AJAX requests are sent and received in a short time.
There's another technology emerging that may become a good competitor against AJAX in time to come - the use of long polling. You may want to read it up on it through the links below.
http://en.wikipedia.org/wiki/Comet_(programming)
http://meteorserver.org/interaction-modes/
Look at the amount of overheads compared to the data. There is no way you can call XML efficient.
If I had my way, I'd have every machine running java, and have XML pass value beans. That way, I make sure my transmission is efficient.
I've yet to look into Comet or try it. I doubt I'd get the chance to since I'm moving out of this industry. =)
One thing I've noticed ever since XML and Web Service. When a transmission is "read friendly" for humans, like how XML and its Schemas are, its seldom efficient. I'm a strongly advocate letting machines read XML and improve its transmission efficiency to reduce the amount of de-compiling and recompiling as possible. No human should need to be able to read XML. If its needs to be readable, build a separate application to do so. There is no point receiving performance penalties of being "human friendly" when hardly anyone looks at what goes between web service applications, or what is being updated in an AJAX standard page.