I'm working on a large website that has hundreds of pages with headers, footers, pop-ups w/ iframes, buttons, logos, etc all over it.
It's been developed for several years. The entire time there have been no DOCTYPE tags, so all the code that has been written for it has been written against quirks mode.
Here is my question:
What are the likely issues to run into if switching the whole thing to non-quirks mode?
Are there going to be so many issues that it isn't worth it to switch?
You should go and try it. Make a test installation and test it.
I did the same thing lately and there were some problems. Most of time I had no big problems, but sometimes it is really very hard to fix everything, because standard mode simply doesn't support some weird behaviour of qwirks mode. But I am happy to have the conversion done. Also those pages didn't look the same in all browsers, because qwirks isn't 100% same everywhere.
Related
Can someone explain me why TWebBrowser control is working so slow on all XE editions of Delphi including XE5 and possibly XE6? To test this you need to create a new Delphi project and put TWebBrowser control in it. On form show event, navigate to this website:
http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html
Please test this on Windows 7 or later. When navigation is complete, run setImmediate test and watch the results. It will take huge amount of time to complete the test. It will take about a minute to finish this.
When you open true Internet Explorer browser and do the same thing - test will be completed instantly (~200 miliseconds).
Some additional wierd informations:
When you recreate this procedure on old versions of Delphi (Delphi 7 to be precise) the web-control works as fast as it should be working and test is completed instantly. But the HTML5 speed test will still works slow (alternative test on this page).
Another weird thing is, the same slow behavior can be seen on C++ Builder but not in Visual Studio products. Is Microsoft deliberately slowing down the TWebBorwser in Embarcadero products?? I can't belive this.
I was trying to overcome this problem with diffrent methods such as:
Trying different feature options in registry such as:
FEATURE_GPU_RENDERING,
FEATURE_BROWSER_EMULATION (11001),
FEATURE_ALIGNED_TIMERS (undocumented option),
FEATURE_ALLOW_HIGHFREQ_TIMER (undocumented option),
Setting timerBeginPeriod(1) - no effect.
Please, if someone have any clue how to fix this issue - share this information with me.
UPDATE1
I made standalone test app if anyone cares. It can be downloaded here: http://mp.org.pl/download/ietest.zip It contains source and exe app with htm file. HTM file contains some js procedure that works 10 times faster in standalone IE than in TWebBrowser control. It uses setImmediate as a test (the same procedure used in test described above). But it can be easier for testing this way.
I can also see the behavior described (in your original post and in the comments). I have a few thoughts, but not necessarily an answer.
One should expect some difference in performance between the WebBrowser control and IE, in part because your Delphi app will need to build in support for certain features/APIs that IE supports out of the box.
For example, the WebBrowser control fires notifications related to tabbed browsing (old, but relevant), but it does not intrinsically handle those notifications or update the UI. You have to respond to the notifications and draw the tabs yourself. By default, IE is hardware accelerated and uses certain Windows APIs that may not be directly supported by Delphi's VCL (for resource/performance) reasons. (Hardware acceleration could account for some of the performance differences you've noticed.)
(And, for the record, I don't believe a list of differences between IE and the WebBrowser control was ever documented. I certainly don't remember seeing one in the portfolio.)
Also, the default values for various feature controls vary between IE and applications hosting the WebBrowser control. Part of the reason for this stems from the idea that IE needs to highlight performance over compatibility whereas applications generally need to emphasize compatibility over performance. You may wish to review the feature control reference to see if there are other FCKs you need to enable for your app.
Second, your loops are very tight, perhaps too tight. You've got one request piling on earlier requests and you're not really leaving much room for processing, even with setImmediate. (IIRC, we're not really supposed to use anything smaller than 250ms for setInterval without risking performance hits from the sheer number of requests.) The remarks in the setImmdiate ref. page provide some guidance, as does this article on requestAnimationFrame.
One reason why dragging the window appears to improve performance may due to the priority of window drag repaint requests. They may be forcing your loops to hold long enough (or even break) to allow other events to process. Hard to say without with tracing the system with a debugger.
Have you ever had to add application.processMessages() to your Delphi apps in order to allow the system a chance to handle the work you've already assigned? A similar need may be coming into play given the nature of your test.
Performance testing and timing is a tricky thing. You need to make sure the test isn't imposing so much overhead that it interferes with the actual work you're trying to perform.
Finally, there were some questions about the document mode of the page as it's loaded into your project. When I first started messing around with your sample, I couldn't get project4 to load slowtest.html in anything other than IE5 quirks mode (notoriously slow). Here's what eventually started working for me:
<!DOCTYPE html>
<!-- saved from url=(0023)http://www.contoso.com/ -->
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>
<script type="text/javascript">
...
(Note, I deleted your initial doctype declaration and rewrite it to resolve a syntax error that was being reported by the F12 tools debugger.)
A few style key points here:
I used a mark of the web to load the page in the Internet zone. I find this makes it easier to load the page in edge mode, as pages in the intranet zone are loaded in compatibility view by default (unless you map the zones differently).
The x-ua-compatible header needs to be one of the first in the head block. It can follow title, but not much else.
Stylistically, elements need to be specified in lower case these days. There's a possibility that not following the current conventions forces the parser to fall back to an earlier rendering that supports the conventions.
Once I was able to control the documentMode at runtime, I found results I expected: older document modes ran more slowly. I also found that using requestAnimationFrame instead of setImmediate led to even better performance, but also surfaced the timing issue almost immediately.
In the end, this may be a case where the test highlights a problem, but not necessarily one you're trying to solve. (Insert Inigo meme here.) I get that you're trying to resolve a bottleneck. Are you sure you've found the correct bottleneck?
You may not be able to replicate the same performance of the native browser, but perhaps you can refactor the code to perform adequately without the extra overhead? Is there anything that might be better handled with a worker or some other implementation technique?
Hope this helps...
Internet Explorer 10 has so-called compatibility mode, which can be activated to make older sites display properly.
If the compatibility mode is enabled, does it slow the overall pages performance and/or JavaScript? And is there any other impact apart from performance eg. overall stability, memory usage etc?
After a bit of thought, I think the answer to your questions is:
It depends.
It depends on what your site does with css. It depends what your site does with markup. It's entirely possible that some new CSS thing has come out in the last few years that IE 11 added very good support for, and the team of engineers spend lots of time optimizing. The old legacy way to do it might work, but be slower because it's old code that never got refactored and optimized. Imagine that repeated over and over... an old IE8 feature that now has a much faster IE11 css or markup equivalent... and you're not getting to leverage any of it.
Or, maybe your site uses none of that functionality, and it's (about) the same no matter which mode you're in. While the likely scenario is that you will probably see some sort of performance hit by running in compatibility mode, it certainly isn't guaranteed.
As I have been learning, I have developed a bad habit of only doing things in chrome. More recently I have started looking at stuff I make in other browsers; it sucks. I have noticed that the positioning in firefox is a little different, safari is basically the same, and IE is a hot mess. For now I am just going to focus on getting things to work correctly in firefox. Is there a sort of if Firefox conditional statement?
There is no equivalent to IE Conditional Comments in Mozilla based browsers like Firefox.
Depending on your server-side platform (if any), you could elect to sniff the browser type and conditionally include different style-sheets. Of course, you want to avoid this as much as possible. Usually by fixing things to work consistently across all browsers, you end up with better, more robust, site that will probably save you time in the long run.
Regarding CSS differences, you might consider starting with a reset CSS, such as the one suggested in Joe's answer, to provide a uniform baseline.
Regarding standardization of HTML and other features between the browsers, you might want to check out modernizer.
I find this script will solve a lot of quirks (minus IE of course) reset.css
I'm putting together some virtual machines to test different browsers and I'm wondering if there is any compelling reason to be able to test the same version of IE on different versions of Windows. (i.e. IE8 on XP and Vista) I'm mostly talking about testing CSS to make sure it "looks right" across browsers, but if there were major differences in JavaScript I would want to know that too.
Are different versions of IE "generally the same" on different versions of Windows? Thanks!
The time and cost of testing different versions of windows would be better spent in other places. This would be one of the last things I would look at when looking for rendering issues.
I agree with both people who have answered previously, despite the fact that they disagree with one another.
In general, IE will act very largely the same across all versions of windows. However, there can be (and are) some occassional subtle differences. Whether these are important are not is up to you.
For the great majority of websites, I wouldn't bother with it. But for very precise web applications where you're using something like complex javascript, or if you require layout to be correct to the pixel for some reason, then it could be worth it. I'm thinking of cases where people are generating os-type applications in JavaScript where the DOM is really being pushed around, and where exact layout and flawless event-handling is critical.
Yes, I am currently testing something out and have varying results between XP and Vista.
--assuming you already have both platforms.
No, I would stick to testing on the current (IE8) and previous (IE7), unless it is a requirement to support older versions. These browsers should render the same across different versions of windows.
I personally dont bother with IE6, the sooner that is gone, the better
I would think there would be very limited cases where you'll notice a difference in IE between Windows versions. One example where you would is a Google toolbar bug I've seen in IE6 that renders html forms unusable. That bug seems to go away when you upgrade to IE8. But that problem is more Google Toolbar than IE.
Other differences you run into may be security or plug-in related. But in the default IE configurations I don't think you'll see any differences in rendering.
My company makes its money off of a great user experience using IE6, 7, Firefox and Safari. 90% of our traffic ends up IE and probably 60% of that traffic is still IE6. IE6 has a bunch of known gotcha's such as accessing DOM objects while they are still being inserted crashing the browser. Almost none of these issues surface during routine testing, they almost always include some odd timing race condition that only affects our most important client of the week.
What process or tools do you use to ensure that known patterns that crash IE are not present in your code?
Added: For those suggesting sticking to 3rd party libraries: I agree that it will help a lot, but you still have to glue those APIs together with Javascript. Is there anyone that is not just crossing their fingers and waiting for someone out in the wild to let them know that there code has just crashed their system?
We don't worry about it. Instead, we use a third party tool like jQuery (well, EXACTLY like jQuery in our company) to ensure cross-platform idiosyncrasies are handled.
I recommend you rely on as many popular 3rd party frameworks as you can. They've undergone far more revisions and testing than you can ever perform. Obviously this means you should be using jQuery for all your JS related work.
Unfortunately there is no silver bullet for these browser bugs, as long as you go with JS & HTML you will continue to have these gotchas. At best you can compile a list of them, publish them on a blog, let the community discuss them and make sure all your devs learn them.
This is an example why Flash and SilverLight exist, which may seem like shocking suggestions considering you've spend an unmeasurable amount of time developing your UI, but if you want to be free of browser/OS bugs, going with a 1 company delivery package is the only way to break the 99.9% barrier for web bugs.
I do a try on window.event.srcElement (which'll only work in IE) and put the non-IE stuff inside the catch, and tie stuff up in my finally.
All other browsers seem to throw an exception with window.event.srcElement so I use that line first and if it gets passed that line it'll obviously be IE so I place my IE code there, if it ever goes to the catch it's clearly a browser that is a bit more standards compliant so I put the alternate code there.
This has saved my ass a lot when it comes to writing Javascript events dynamically using server side code that involves mouse events.
Hope that helped, gives you a way of supporting multiple browsers with different code without server-side detection.
Beleive it or not some of jQuery (and other libraries) functions don't work on all browsers.
Beleive it or not some of jQuery (and
other libraries) functions don't work
on all browsers.
Ofcourse, if you relate to IE5 or NN4, jQuery may not be the best pick. Otherwise, you won't have a problem with this.
I use jQuery for a HUGE site and i don't have problems with library. I have problems with plugins, but this is a different story.
And btw, i have less than 10 lines of pure js in my files. If you learn to use jquery efficiently, you won't need any js knowledge (sounds weird, but... this is my case :P )