Slashdot Mirror
A Mozilla Plugin to Help Overcome IE Rendering Flaw
least_weasel writes "An article on Ars Technica reveals Mozilla's intention to create and release a plugin for Internet Explorer that would allow the often-criticized IE to utilize some of the cooler rendering code developed for Firefox. The current WIP focuses on rendering using HTML5 standards, but the plans seem to be more ambitious than just fixing this one small piece of IE. The article covers some of the plans, hurdles, and potential benefits. It also spills the beans on the code name for the project: Screaming Monkey."
What's the advantage over just installing Firefox? Do people who don't have permission to install software have permission to install plugins like this?
Great idea... but if someone would have the wits and knowledge to look for this plugin, wouldn't they be using FF already? If websites prevented stuff from working without this plugin, wouldn't that just turn off viewers? Not sure how this is going to help, people have been harping at Microsoft about standards for years and all they've done is move towards them at the pace of a snail.
Comment removed based on user account deletion
Is it a sad or happy day for Microsoft, when their competitors get bored with beating them, and instead try to improve the Microsoft products to make them competitive - for free?
I run Firefox for NoScript and AdBlock...I could care less about rendering a page .002 picoseconds faster.
So I take it Balmer is involved in some way?
To: M$
From: KindFolk@mozilla.org
Subject: U JUS GOT BITCHSLAPPED!
it will be used by ie developers to test ff compatibility ... rofl
mov ax,4c00h
int 21h
I've been reading about this for months. Its not exactly top secret.
https://wiki.mozilla.org/Tamarin:ScreamingMonkey
FYI, Screaming Monkey was already discussed in an earlier story.
The only problem is getting people to install the plugin. My own solution was to use the market penetration of Java Applets to develop a shunt that would render Canvas using Java APIs. (Note that the events system has not been completed in that demo. Make sure you click outside the block falling area so that the browser receives the keyboard commands.)
The same sort of shunt could be done with Flash 9 or Silverlight. Which would do a nice end-run around the problem of getting plugins installed.
Javascript + Nintendo DSi = DSiCade
I think Microsoft owes Mozilla another cake. This probably saved a lot of money and a few man hours for Microsoft. Or they can just let Mozilla bask in their humble glory.
Please visit http://www.mederbil.com/ i7, GTX 275, 4 1TB Caviar Green in RAID 0+1 array, EVGA X58 3X SLI Board, Silver
Now with all of the features of Firefox, without the bother of all the security.
A plugin that'll help another brower to actually follow standards... wow. Well, I've gotta admit it's still probably easier than actually forcing the devs to do their damn jobs right... The name is fitting though.
Ubuntu releases OS in the name of Windows 7
Named in dedication of the countless developers, developers, developers, developers who worked on the project!
When asked how they felt about Mozilla, they developers replied "I LOVE THIS COMPANY YEAH!!!!!"
HTML 5: have DOM storage (session and local) and database storage. These should all be SameOrigin. Meant to block userâ(TM)s deleting of tracking cookies. Use of database storage, there can be SQL injection against the local database. Some browsers support GlobalStorage that donâ(TM)t have SameOrigin control. Lots of new attack surface in FF3. Websites can be protocol handlers (support spyware!!). Installation of protocol handler is one click. WebKit is a big supporter of HTML5 and supports these issues.
HTML5 has limited storage (~ 15 Mbytes total) allowing easy exhaustion attacks and there is no UI to manage this. DOS is easy. Can easily plant arbitrary evidence on a system. HTML 5: Security âoeneed to write this sectionâ.
We now have web developers making desktop apps without any security or privacy expertise. The Web is becoming more heterogeneous and far far more dangerous.
Hey, that's great. Do they also have plans to fix the flaws in Firefox?
Off the top of my head, could we finally have support for SVG as a native image format? Or even just SVG rendering that isn't slower than a stone cow?
Don't want to sound like the grumpy old man, I just want most of my web shit to work in *one* browser before I worry about how it works in every browser.
Never approach a vast undertaking with a half-vast plan.
Well i'll be darned, I guess someone should call the XHTML2 camp and tell them they lost the war!
Nah, don't bother them. They're busy working on the HD-DVD website.
Those who believe the Internet is private,
find their privates are on the Internet.
I didn't RTFA to get their cut on this, but my opinion after many years as a web developer has been that MS more-or-less deliberately left IE borken just to make the web hard to use for most users. The security gaffs that left Windows pwnable might have been real issues, but I think the rest was a strategic gamble to keep people locked into the "your desktop is the only reality" Matrix-ish crapola that keeps them raking in the cash on OS and Office sales. Only the web sort of went ahead and won anyway, mostly. IE being F.U.B.A.R. is now just a sad joke.
If that's the case, then IE should indeed by fixable, and probably easily. There might be former/reformed MS coders in the readership who could comment on this. Guys and gals; did you do as good a job on IE as you wanted to? Or was there a certain shaved ape making "suggestions" about priorities that left IE crippled?
=^..^= all your rodent are belong to us
HTML and XML are co-standards, not competing standards. There has been some talk about renaming XHTML2 to XHTML5 to emphasize this. XHTML is only needed if you're using another XML-based language on the page, and is very susceptible to errors. HTML, on the other hand, is less prone to errors, and the page will at least render. It is also supposed to be served as text/html, whereas XHTML is to be served ONLY as application/xml as of XHTML1.1. If you have a XHTML1.0 Strict or XHTML1.1 page out there being served as HTML, you have basically served badly formed HTML4.
Learn about Photography Basics.
We now have web developers making desktop apps without any security or privacy expertise. The Web is becoming more heterogeneous and far far more dangerous.
What bothers me is how security is somehow pushed to the forefront as the most important issue, even more important than functionality.
The most secure system is one that is turned off. This new stuff they're adding increases the attack surface, sure, but it's also necessary to build stuff that actually works (like a web app that doesn't die when your wifi does).
But even aside from the issue of functionality vs. security, there's the issue of security somehow being way more important in the browser, which I think is nonsense. Client-server apps have always had lousy security, and were easily hijacked. Just because they now run in a browser, the threat level hasn't changed. A hacker that is determined can break in sure, but they've always been able to break in. Nothing has truly changed, except for the perception of the threat level.
All in all I think the web stack is pretty secure by default, when comparing it to the alternatives.
Any person clever enough to install that plugin would be clever enough to use a real web browser to begin with.
HTML5 comes in two flavours. One is straight HTML5 which is based off HTML4 (same parsing rules), the other is XHTML5 which is strict XML and requires the application/xml content type. None of them are really related to XHTML2 which is mostly dead at this point.
Thanks Mozilla,
This is just great!
Now, how about fixing the memory leaks that cause Firefox to use 280 MB of RAM with one tab open and default extensions after 20 minutes?
http://clightnirish.wordpress.com/
can design on a sane model with sane tools, deploy the plugin when the users are IE.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
"A Mozilla Plugin to Help Overcome IE Rendering Flaw"
Should it not read: A Mozilla Plugin to add Enhanced IE Rendering?
Come on. This old fight between browsers is becoming stale. IE included many things now in the HTML specs that were not available in any other browser, such as CSS Style for shadow effects, etc. Why is it that when something new comes out for IE that it is automatically described as a "bug" fix or a workaround to a "flaw"?
Please people, I like FF and IE for different reasons. At least write unbiased stories and stop bashing each other's code efforts.
Wow, 293,601,280 bytes? That would really it into the total of 8093,454,336 bytes! Teh horror.
This is exactly backwards to what most of us need. We need a [multiplatform] plugin for Firefox that will allow broken IE-only sites to work under Firefox so we can continue to use the browser of our choice. Not that I want to promote the use of IE-only coding, but the reality is that if the site doesn't work, the average users always blame Firefox, not the site designer.
Dunno if you can *prevent* LAN theft...but I bet you could _patent_ Lan Theft(tm)
> Canvas is a strange pick though for something to extend IE with. There's excanvas, which does a reasonable job of emulating canvas on IE using VML.
TFA says it's because ExCanvas is too slow.
Have Mozilla send come checks to all major software companies (Adobe wink wink) - perhaps Google can through in a few $100 million in the pot too to distribute. Goal: install Firefox (if not installed yet) and make Firefox the default browser. A little taste of Microsoft's own medicine.
*nawcom sips from his glass of kool-aid*
From reading the article, it's not clear to me exactly what this will do, aside from make some HTML5 elements available. Will this fix IE's numerous CSS flaws? To me, that is *vastly* more important than adding HTML5 stuff.
The most secure system is one that is turned off. This new stuff they're adding increases the attack surface, sure, but it's also necessary to build stuff that actually works
well, my (and most people's) definition of 'works' is one that keeps me and my data secure
your argument is bogus and assumes your specification for doing something contains only *one* criterion, which is a crazy idea, and not how engineering works
...when I need them. You hit the nail on the head, pal.
Good thing I scrolled to the bottom of the page before I posted and avoided the dreaded "Redundant".
Did anyone think about pages that detect user agent strings? A lot of devs use the UA string to "fix" these rendering problems on a per browser basis. This plugin would "break" the pages that have already been "fixed" causing quite a headache to the devs who would never know that their page does not work correctly in this version of IEx because it has a nifty plugin to fix things. Sound like dev's will have yet another variable to watch out for.
And for thoes who say this plugin is somehow for devs: any developer who wants real cross browser compatibility will use the target browser not some add on crap. Any developer who says "I don't care what it looks like in IE" obviously does not have a job developing public web sites (or won't have a job doing so much longer). Even if you don't like the browser you don't ignore 70+% of your customers (or any % of your customers). I have every browser imaginable available to me to make sure my pages work properly in all browsers.
And as far as bashing IE for the rendering flaws it has, I would look first to fix FF's rending flaws. I'm not going to list the dozens of bugs and out-of-compliance standards FF has, anyone who thinks FF has no rendering bugs is seriously delusional. And no production browser has yet to pass the acid 3 test, that includes FF and IE. And even if one browser did pass the test, devs still have to cope with all the other browsers that didn't.
Not only did you fail to get first post, but you weren't even close. The English language lacks the ability to express the sheer magnitude of your monumentally epic failure; CowboyNeal's waist is anemic by comparison. I would suggest you try again, but failing so spectacularly has probably left both your body and mind in a highly unstable state. It's probably best for everyone involved if you just killed yourself. But you would probably just fail at that, too. Sometimes you just can't win.
--Summer Glau
~jeremypv
What's the difference between web developers and regular developers? Take a look at any desktop applications and tell me that they're programming with better security practices than web developers. Windows, apache, IIS, OSX, and many more programs include critical security holes that can be exploited externally; how is a buffer overflow any better or worse than improperly escaped SQL?
Developers as a whole have been programming without security and privacy expertise, web developers just happen to have a program that's exposed to (at best) everyone in a particular company, or often everyone in the world. With that kind of exposure, what percentage of non-web-based programs would survive without getting exploited?
Sorry, rant over. Security is a big concern, and for things which need to be very secure these features shouldn't be allowed. However, that shouldn't keep the browsers from increasing functionality and usability. Hopefully developers are learning their lessons and becoming more security conscious.
> What bothers me is how security is somehow pushed to the forefront as the most important issue, even more important than functionality.
You can't bolt on security as an afterthought. It has to be part of the design.
I'd rather have a protocol designed with security in mind than one that makes it easy to steal my passwords and personal information, but where the widgets are 10% flashier.
Of course, I also know that my PC is under constant attack from botnets and such (and I can get logs to prove that), being secure only because I have more sense than to install insecure software.
The average home PC I have repaired is replete with spyware because people don't patch and don't know better than to install crappy software that has the shiny widgets they want.
All in all I think the web stack is pretty secure by default, when comparing it to the alternatives.
Really? My opinion is that the "web stack" (not sure which stack you mean here; MSIE-Windows, FF-Windows, Safari-MacOSX, Konq-Linux, etc) has by far the worst record so far. MSIE-Windows has to be the #1 vector for infection now, and has been for at least the last 6-7 years. Which alternative are you thinking of? Because the "web stack" is, in my opinion, the premier virus runtime environment.
My opinion is that web designers made a HUGE mistake in not treating network input cautiously. The emphasis has been on "rich APIs", "data structure passing", extensibility, desktop integration, and so on. These are undoubtably good things in the absence of malicious input, but the fact is, there is a lot of malicious input out there. Web browsers would benefit greatly from some simple privilege separation; the Mozilla camp could do this with some effort, but MSIE is pretty much dead in the water here due to the level of integration with the base system. I understand the HTML5 camp's worry that Flash/Flex will become a de facto standard, but in my opinion, web security has not been taken seriously enough. These kinds of vulnerabilities have become a major source of income for organized crime in the East, and still people like you are saying that security is not the most important issue? Gimme a break.
That's the attitude that made IE what it is today.
I dream of a better world... one in which chickens can cross roads without their motives being questioned.
you have been thoroughly pwned
The fact that more and more free software is being made available to proprietary platforms such as Windows (and in this case IE) might be a bad thing.
I'm actually not completely against proprietary software but I think Linux and *BSD may become irrelevant if this trend continues.
If IE gets a plugin which basically turns it into Firefox, why even bother downloading and installing Firefox anymore?
If KDE4 rocks and gets ported to Windows and runs great there too, why use Linux?
Windows (or Mac OS X) could very well become the premier platform for running free software, if this trend continues.
Maybe this is what Microsoft means when they mentioned that they want to "outsmart Linux", maybe that's why they now invest in OpenSource and try to act like they're suddenly great supporters of OpenSource: because they want people to port the cool Linux apps to Windows, so that in the end only Windows is being used because there will be no more arguments for using Linux except for freedom (which most people, even many Linux users don't really care about). They don't want to beat Linux anymore, they can't do that anyway, so they now want to make sure that Windows is being used as the ultimate platform for everything, be it proprietary or free software.
I think people should focus more on making Linux great instead of porting everything so that people can just stay with Windows and the standard proprietary software like IE.
One - The project should not be called Screaming Monkey. It should be called Airborne Chair.
Two - This seems like a complete waste of the Mozilla team's time, in my opinion. I don't want to diss their hard work, but Firefox is an exceptional piece of software, so it would make more sense to concentrate on making it even better/faster/smaller, rather than waste the time fixing monkey code (or rather making an add-on that fixes functionality in monkey code).
Three - In addition to concentrating the technical abilities on improving Firefox rather than the monkey code, Mozilla's marketing people should be concentrating on getting this browser installed on as many computers as possible. I know they already do this, but they need to do even more. All too often, I find computers out there that run IE by default. This can be changed by lobbying computer manufacturers to make Firefox the default out of the box, in addition to continued press coverage, ads placed in major newspapers and other media, etc. Because when the majority of users make the switch, nobody will care how many bugs there are in IE. Hell, Microsoft might even decide that it offers them no return on the cost of developing it, and the next IE will be Firefox modified to look like IE, with an OSS license, of course. That should be the goal, not fixing someone else's problems.
McCain/Palin '08. Now THAT's hope and change!
Pidgin their IM
I hope they can figure out Pidgin since you apparently are completely unable to.
created by MS who then sues mozilla for stealing "their" code.
Child
"Mommy! That mean man tricked me into installing IE again. Make it go away!"
/ Child
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
I think it's Korea with tons of IE6 dependent pages. If a plugin like this works for them, it has value.
Can we go the other way? Make a weird plugin that can fake IE6 behavior so that we can let them escape from the rusty tyrannosaurus trap?
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
sounds sort of like buying an alchoholic a bottle of scotch.
I am disturbed that you didn't spell Stoopid correctly.
It also spills the beans on the code name for the project: Screaming Monkey.
Ha. Ha ha. Ha ha ha.
The higher the technology, the sharper that two-edged sword.
There had better be an easy way for web designers to tell if IE has that plugin installed or I'm going to be really pissed.
It's hard enough dealing with IE's crappy rendering... it will be so much more painful if the rendering engine in IE isn't *consistently* broken and we have no way to tell the difference in our code.
Come play free flash games on Kongregate!
What bothers me is how security is somehow pushed to the forefront as the most important issue, even more important than functionality.
You shouldn't be bothered, since it isn't. Which is a problem.
The most secure system is one that is turned off. This new stuff they're adding increases the attack surface, sure, but it's also necessary to build stuff that actually works (like a web app that doesn't die when your wifi does).
That's not the issue, at all. This new stuff could be excellent, yes. But if it is developed without keeping security in mind, it is worthless -- worse than worthless, it is harmful -- in the context of the web. If you don't tackle these (some rather obvious, some somewhat tricky) problems now, rest assured, attackers will tackle them. Successfully.
But even aside from the issue of functionality vs. security, there's the issue of security somehow being way more important in the browser, which I think is nonsense. Client-server apps have always had lousy security, and were easily hijacked. Just because they now run in a browser, the threat level hasn't changed. A hacker that is determined can break in sure, but they've always been able to break in. Nothing has truly changed, except for the perception of the threat level.
All in all I think the web stack is pretty secure by default, when comparing it to the alternatives.
Interesting analysis. I don't agree with it. Security being important in the browser does not stem from the feeling that it should be "more secure" than your regular client-server app. It stems from the fact that you do not trust the server to feed you valid data. Browsers get a lot of crap thrown at them during a regular browsing session; you cannot, by the very nature of it, assume to trust every website linked from everywhere else. As such, since you cannot trust your input, you should assume that it is malicious. This is why security in the browser is important. It's not just the interaction between your browser and Google Mail that's interesting -- it's the interaction between your browser, Google Mail, and the other website you have open at the moment, whose author you do not know.
So yes, security-by-default is a lot more important in a browser designed to browse lots and lots of untrusted content without that leading to a local system compromise.
And yes, by that very nature, many browsers have some measures that make them considerably more secure for running webapps and the like than executing native code would be. The design is to not let ECMAscript and other such supplied code screw with your system or other sites you may also be visiting now, have visited in the past, or will visit in the future. This is valuable.
Local storage is an interesting feature. I don't think I will like 95% of the applications it will be used for, but the other 5% might become some truly stunning stuff. So long as those 95 other % don't really, really screw it up.
The flipside of the sandbox-model we currently have with browsers is that many "web-coders" never really bother to look at the implications of security. A lot of ECMAscript out there is absolutely atrocious security-wise, and security concepts on the server side are, apparently, really really hard to grasp for many people. If you give these people more features that can cause greater harm and do not properly put sandboxing into the design, you'll end up with a lot of vulnerable, unprotected code. Right now you "just" deal with Cross-Site-Scripting, server-side SQL injection, etc. -- just imagine how much fun it'll be when you have to deal with local SQL injection, local cross-site-scripting, and the ad you just loaded off of the Slashdot adserver fetching all your site-local storage to their servers -- including all the mail you recently viewed. It'll happen.
You missed the key word there...professional. It means one who makes money from their profession. Developing to standards is great but it doesn't necessarily put food on the table. Idealism is nice, but it can cause one to starve. My guess is you are still in school and haven't had to pay any bills?
But even aside from the issue of functionality vs. security, there's the issue of security somehow being way more important in the browser, which I think is nonsense. Client-server apps have always had lousy security, and were easily hijacked. Just because they now run in a browser, the threat level hasn't changed. A hacker that is determined can break in sure, but they've always been able to break in. Nothing has truly changed, except for the perception of the threat level.
There are reasons why browsers are different from other client/server applications:
Part of the point of HTML5 is to make it easier to do things like implement a desktop application in the browser. As such, the comparison with the security of client/server applications is not appropriate. It's the equivalent desktop application's security that should be the goal.
It's also worth noting that the easiest time to add security is at the beginning. Once applications have been written to a certain model, it's expensive to change the model. Now, when there are no HTML5 applications, is the best time to make their security model robust.
For some websites and their applications, such as Netflix's Instant Watch application, the IE engine is still required. When ever I want to watch a movie over Netflix, I have to use IE7 instead of FF3.
ScreamingMonkey is a project that aimed at providing IE with a JS runtime able to run EcmaScript 4 programs.
Since ES4 is apparently dead, I'm not sure where that leaves ScreamingMonkey.
The canvas stuff is a different project that follows the same general approach, but on a different browser component.
Use of database storage, there can be SQL injection against the local database.
Depends where the SQL is coming from. And a properly designed framework should make it difficult to do this.
I'm not convinced SQL was a good choice, but SQLite is probably the simplest thing that could be implemented in all browsers that fills the requirements: decently fast, embeddable, and optimized for lots of small chunks of data.
and there is no UI to manage this.
Is there any standard that requires a UI to manage cookies?
If HTML5 gets popular, there will be a UI.
Don't thank God, thank a doctor!
XHTML is only needed if you're using another XML-based language on the page,
Doesn't mean it's a bad idea otherwise.
and is very susceptible to errors.
On purpose. That was a design feature -- so people would stop making horribly twisted and downright broken code.
HTML, on the other hand, is less prone to errors, and the page will at least render.
It does, however, require a hell of a lot more complex of a parsing engine, let alone rendering engine.
XHTML, you can just throw through any old dumb XML parser.
Which means that XHTML is more prone to you making a typo (or something like that), that you'll catch immediately, because any browser that supports XHTML will refuse to render it. HTML, on the other hand, will be prone to subtle errors in your document that the browser will silently correct.
So, additionally, HTML is much more prone to errors in the browser's parsing code, as well as subtle errors in the document, so a document may stop working after awhile.
If you have a XHTML1.0 Strict or XHTML1.1 page out there being served as HTML, you have basically served badly formed HTML4.
Except you can make an XHTML document also appear as well-formed HTML4. Meaning you get all of the above benefits, but your users don't have to upgrade their browsers, as long as you can still serve it as text/html.
The only problem is, how do you serve it as XML to supporting browsers, and HTML to nonsupporting browsers, given that there's no way to tell (short of testing every browser) which is which?
Don't thank God, thank a doctor!
I immediately thought that it was a plugin for Firefox to fix Internet Explorer rendering. I'm like... wha?
Should read: "A Mozilla-Developed IE Plugin to Help Overcome Rendering Flaws"
Homonyms are fun!
You're driving your car, but they're riding their bikes there.
The way to get this installed is for big websites (Google for example) to use the same drive-by-download used by spyware to install these plugins. The clueless "internet == blue E" people are most likely to just say
"yes" to such drive by downloads without bothering to check what it says and those who know better will be likely to install it too (especially if e.g. Google says "install this plugin to get a better experience with Google Maps")
I remember when Mozilla seemed to concentrate on their customers needs. Now, they seem to be behaving more and more as a subsidiary of Google. (They seem to think that you don't need a reliable, usable desktop email client anymore-- because THEY'VE decided that you're gonna be happy using GMail!) And now, maybe because Google needs IE to work better, Mozilla pours time and effort and money into fixing IE.
The corporation seems focused on making big deals, the old software which I loved since Mozilla 0.6 seems to be getting treated as "legacy crap". Hey, business people, you don't gains market share by improving your competitor! What ARE they thinking?
My Advice->Forget trying to enhance IE & Use your resources to enhance only firefox..
Sql injection can be exploited more easily. To exploit buffer overflow, you need some compiler and assembly knowlege is very helpful. To exploit sql you need to type some text into a field.
Extreme Programming - Redundant Array of Inexpensive Developers
but MSIE is pretty much dead in the water here due to the level of integration with the base system
You should probably take a look at IE7's protected mode (unfortunately only available on Vista-based systems) before making that sort of sweeping assertion.
It's official. Most of you are morons.
Now we just need the Linux community to fix all the bugs in Windows 7 & M$ may just become usable.
Ah, so that's why Gates made Windows Vista?
Adobe would never do something like this when it makes money selling Flash. This plugin allows people to do things that used to require flash to get interactive content.
Hmm, interesting. It looks like MSIE 7 does do privilege separation, along with a couple other protections. I stand corrected. In my defense, I do not have Vista, so I was unaware of this.
Phishing, spamming, sniffing, exploiting etc. are a fact of life for years now, and will continue to do so.
It's pretty simple, the old protocols http, dns, etc. that were developed to *function*, do function, but no longer meet the requirements.
The reason why security *has* to be pushed to the forefront is because it *is* required for today and the future.
Usually, it's about budget and security becomes an afterthought or calculated risk.
So, IMHO the GP is making an excellent point.
but the plans seem to be more ambitious than just fixing this one small piece of IE
Just just made a typo
It's supposed to be "this one small piece of crap"
Don't worry, lot of people do this mistake.
You'll thank me later.
"they sure as hell notice when things don't work right"
TFA:
"but the browser's defensive security mechanisms insist on prompting the user before every time it is used. This detracts from the seamlessness of the plugin and makes it difficult to use for conventional web applications"
Sorry, but unless MS generously decides to relax this we'll all be getting calls about how our websites "don't work right".
My turnips listen for the soft cry of your love
"It's not a perfect emulation, ofcourse, but in my experience it's good enough once you learn its limitations"
TFA:
"... ExCanvasâ"a complex library that implements many of the Canvas element's features with VML, Microsoft's proprietary alternative to SVG. Unfortunately, scripted manipulation of VML is too slow to be used for highly interactive web applications"
My turnips listen for the soft cry of your love
The only problem is, how do you serve it as XML to supporting browsers, and HTML to nonsupporting browsers, given that there's no way to tell (short of testing every browser) which is which?
thats no problem. browsers that support application/xhtml+xml already send it in the Accept header with every request.
I think the focus on browser security has come around because people tend to use a single web browser to surf random sites on the Internet, which are not under corporate control.
Thick client apps that suck, typically don't suck over the internet to 3rd party servers - they suck to a intranet server.
The web browser just talks to strangers a lot more than a thick client app would normally.
mmm, why not the complete gecko engine as an activex plug-in? (maybe somthing similar is possible with a java applet in javaFX using the jwebpane (webkit))
Sql injection requires knowledge of sql and either a way to get the structure of the database or some luck with guessing tables. If you're going to say that sql injection is just typing text into a field, you could say the same for buffer overflow.
Nah, the most secure system is one that is turned off, unplugged, encased in concrete, and sunk to the bottom of the deepest part of the ocean.
Just let the dead horse die already. Fixing IE will just help to get the droves of idiots to stick with IE even more. More websites that code as they should code and not specifically for IE will create a disdane for IE when it breaks and customers can't buy stuff online or can't view this or that. This will cause droves of people to find an alternative. Whether that is Opera, Firefox, or some other alternative shouldn't matter. The fact that IE would be dead *would* matter. Microsoft needs to be shown they are not king and they need to listen to consumer's more than they listen to larger corporations. Their real end users are home users not corporate monstrosities. Sure the corps pay the bills, but the people using it are out in the homes. But I digress, it'll come down to pitchforks and torches before anything gets done. That goes for both politics & software...
"When the people fear the government, there is tyranny. When the government fears the people, there is liberty."
How does it make closed source look bad? I can see how it makes MS look bad, but how closed source in general?
If the Mozilla team ever comes up with its own idea instead of implementing Opera's ideas poorly, then it might make closed source look bad. But that's not likely to ever happen.
I've got FF 2.0.0.16 on up-to-date XP. I've never found the amount of memory usage to have any notable impact on my browsing experience. What I *have* noticed, though, is that browsing gets notably slower, and the CPU often gets pegged by FF, once FF's page fault count gets much above 2 million (as according to Process Explorer). The situation is gradually improving, as v.16 doesn't slow down as much as v.15 did.
Cheers,
"What in the name of Fats Waller is that?"
"A four-foot prune."
browsers that support application/xhtml+xml already send it in the Accept header with every request.
Actually, no, they don't.
I remember trying this awhile ago. Firefox sent it, but it required some weird parsing rules to detect it. I also seem to remember that Firefox didn't give it any higher a priority than it gave straight html, meaning that with things like Apache, it would just fall back to the default. I suppose I could write an app and detect any mention of it in the Accept header...
However, Safari did not send it. I remember Safari sending something more like "Accept: */*". This was a long time ago, so I may not be remembering right, and they might be sending something else by now...
Which, by the way, is the other problem with the Accept header: every browser has to accept */*, because they can always download the file, or pass it off to another application. But that */* still has meaning -- if I wrote a client that was designed to scrape it for something, I'd probably have a very limited number of content-types listed in my Accept header (if I sent one at all).
I haven't found a reliable way to detect XHTML support this other than to send it to the browser, and see if it renders, or if it presents me with a "Save As" dialog -- and then to maintain a list of known-good User-Agents. I really don't want to do User-Agent detection.
Don't thank God, thank a doctor!