7 steps to prepare for IE10 and Windows 8
As you probably already know, on February 29, Windows 8 Consumer Preview was released , and with it the 5th platform preview version of Internet Explorer 10 . In this article I will discuss how to prepare for the new version of IE. And although the narration will be predominantly around IE10, many of these tips apply to other browsers, including other platforms.
1. Use <! Doctype html>
The first, very, very, very first thing to start with is to make sure that you give all the pages with the correct doctype. In the world of html5, this is one small and very simple line:
')
<!doctype html> This should be the very first line you write. If the template of your page is automatically generated by development tools and there is no this line, correct the template. If your CMS renders pages without doctype, update the templates used.
I repeat, this is a very, very simple step, however, it is extremely important. The correct doctype tells the browser how to handle the page content. IE9 and IE10 in the absence of a doctype switch to quirks mode.
In IE9 , many new features don't work in compatibility mode, including canvas, audio, video, and CSS3 features. In IE10, the compatibility mode uses the mechanism described in the HTML5 specification: this is the same standard mode, but with the compatibility fixes that are described in the specification, which also corresponds to the behavior of other browsers.
(Let me remind you that the HTML5 specification, among other things, also contains rules for browsing pages, including in compatibility mode. Examples: case sensitivity , form , image content layout.)
See also the presentation of Vadim Makeev from Opera Software: Doctype. Point ( video ).
What mode does my page work in?
You can see in which mode your site is displayed via DevTools (F12):
Standards and Quirks modes comply with the HTML5 specification.
IE10 also supports quirks mode from IE5 for non-doctype sites running in compatibility mode (sites), and sites that explicitly indicate the need for such a mode via meta tags with X-UA-Compatible:
<meta http-equiv="X-UA-Compatible" content="IE=5"> 2. Solve compatibility issues
In addition to incorrect doctype, there may be other reasons why a particular site is not displayed by default in standard mode:
- The site is listed in the compatibility list used by IE . There are about 7 Russian sites on this list today. As a rule, these are popular sites for which developers have set the compatibility mode, or users often do it manually to improve the display. The de-listing procedure for resource owners is described on MSDN .
- Wrong doctype used.
- One mode or another is registered on the page through the X-UA-Compatible meta tag .
And even if everything is fine with the doctype and compatibility mode, this does not mean that the site will fully work correctly in IE10. For example, a site can use the so-called browser sniffing, defining a browser using the user agent string or other features and giving different code to different browsers.
Or, say, a site may use an outdated library that used a bug or a special hack in older versions of IE, but stopped working correctly in the new version with bug fixes.
There may be many such reasons, and to determine possible sources of errors it was easier, we have a special tool - the compatibility inspector (compat inspector).
Compatibility Inspector
The inspector is a JavaScript library that can be easily added to your page:
<script src="http://ie.microsoft.com/testdrive/HTML5/CompatInspector/inspector.js"></script> After that, the loaded script analyzes the page for possible problems and gives a summary of the results in the form of such a counter:
By clicking on the counter, you can see the specific problems found and recommendations for correcting them:
For example, in the user profile on Habré, the Compatibility Inspector says that, in accordance with the DOM Level 3 Core standard, the createElement method does not support text arguments with angle brackets. This feature was used in older versions of MooTools, which the inspector also suggests and recommends upgrading to the latest version. A simple check shows that the old version of MooTools is actually used on Habré.
Or, for example, many users of Windows 8 Consumer Preview complain that Yandex.Maps do not work in IE10. The inspector suggests that the site probably uses the user agent test and offers to check it by giving the site another user agent, pretending to be another browser (this is done by checking one checkbox in the checkbox Verify). After that, the cards begin to work.
I hope all such problems will soon be corrected.
How to "add" compatibility inspector to someone else's site?
If you want to try the compatibility inspector on a foreign site, as I did for Habr and Yandex, or on my own, without making changes to the code of the site itself, it is also possible.
To do this, you need to install Fiddler and add a snippet to it (edit the processing rules via Rules -> Customize Rules ...). After this, Fiddler will be able to insert the inspector code into the body of the pages locally on your computer.
Once again links : compatibility inspector and instruction .
3. Identify features, not browser
This topic is discussed a lot, and yet it will not be superfluous to recall it again. The more standard the behavior of browsers becomes, the more new features appear and the faster and more automatically the browsers are updated, the more important it becomes that web developers, building their websites and web applications, rely on the capabilities of browsers and their presence, rather than on specific browsers and their versions.
Yes:
- Capability check . Check if the browser supports the required methods and properties before using.
- Behavior check . Test whether there are known problems before applying workarounds.
Not:
- Check specific browsers . Do not use browser identifiers (for example, the user agent string) to adjust behavior.
- Unsubstantiated assumptions. If you checked any one opportunity, it does not mean that others will work.
Adjustment to a specific browser may seem a reasonable solution only in the short term, however, in real solutions for end users this greatly limits the adaptive capabilities of the pages, starting with the fact that the site can stop working with the release of the new version of the browser (new features, bug fixes, changes in standards, etc.), and ending with the fact that workarounds used in this process may be unnecessary and inefficient.
Using modernizr is a good starting point.
See also Same Markup: Writing Cross-Browser Code and Browser and Feature Detection articles .
Conditional comments
Many of you are probably familiar with conditional comments for IE, which allow you to insert one or another code for different versions of IE. I think many also faced situations when conditional comments were inserted incorrectly, as a result of which, for example, the site knew only IE7 and 8, giving all the IE6 markup to all other versions of IE (including new ones).
Familiar? I have news for you:
<!--[if IE]> <br/> IE10 .<br/> IE . <br/> <![endif]--> That's right: IE10 ignores conditional comments. You can continue to use them for previous versions of IE, however, for more modern browsers, use feature detection.
4. Provide a mode without plug-ins.
If this is news to you, then welcome to the harsh reality. It is important that your website or your web application remain functional and solve the tasks assigned to them even with plugins disabled. This applies to Flash, Silverlight and any other extensions (for example, based on ActiveX).
If you have developed websites for iOS devices, this situation should be familiar to you. In Windows 8, IE10 is presented in two modes: for the desktop with all user-installed extensions and in metro-mode with the extensions disabled.
From the metro-mode, the user can easily switch to the desktop mode, however, it makes no sense to display messages like “install the Flash Player plugin” - this will not help him.
What is recommended to do:
- Provide an alternative solution for the implementation of functionality that requires plug-ins today. For example, you can use HTML5 features to play Audio / Video and graphics; for advertising banners provide an alternative as an image.
- Revise the work of the site, if it is strongly tied to the use of plug-ins: move towards modern web standards, or switch to creating alternatives in the form of a Metro-style application for the Windows Store.
- If you need to use extensions to give the correct message, prompting the user to switch to desktop mode.
See also Browsing Without Plug-ins and Moving to Standards-based Web Graphics in IE10 .
5. Add prefixes where appropriate and follow standards closely.
I will not discuss whether it is good or bad to use prefixes, however, today it is a given. There are browser prefixes and they allow different manufacturers to implement the support of developing and not very stable features until the final acceptance of a particular specification (or at least reach the status of Candidate Recommendation) and receive feedback on implementation from the community.
If you want to use new features in IE10, do not forget to update your code by adding properties and methods with the necessary prefixes for all major engines (for example, -ms- for css-properties in IE) and a prefix-free version for the future for more or less stable features. .
Let me remind you that a lot of new features have been added already in IE9, and even more from in IE10:
For information on how to develop using prefixes, see, for example, article A Best Practice for Programming with Vendor Prefixes and the library --prefix-free from Lea Verou.
6. Design for different screens.
In my article " On the sails of HTML5. How new technologies change the modern web " I already told that the dream of many and many web developers that the sizes and resolutions of screens will only grow to crumble to pieces, faced with mobile and tablet scripts, the popularity of which has already led to reconsider many approaches in the development of web sites and web applications.
Responsive design - these are two cherished words that you need to look for to learn how to achieve flexibility in relation to different resolutions and screen sizes.
For Windows 8, you need to be prepared for two main points:
- A wide variety of devices of completely different form factors: from relatively small tablets to large screens of monitors and panels.
- Snapped-up metro-style applications, including IE10.
Variety of screens
The recommended minimum screen size for Windows 8 is 1366x768, in which case the Snap function will work, which is described below. For Metro style apps, the minimum requirement is 1024x768. The site in IE10, running in Metro mode, occupies the entire screen.
However, given that the desktop browser can work at lower resolutions (for example, 800x600 or 1024x600), the need to take into account small resolutions still remains.
If the user's screen resolution is larger than you expected and your site does not take this into account, for example, leaving a large empty space to the right when aligning to the left, it will not be very pleasant for the user to see the empty half of the screen. If you rigidly set the size of the text and do not take into account the size of the device, it can easily happen that the text on the big screen will be too small.
A similar story with the size of the graphics and the need to scale it on large screens (using different sets of raster graphics, or using SVG).
Responsive design. CSS3 Media Queries. Bing.
See also CSS Corner: CSS3 Media Queries and Response to Multiple Devices with CSS3 Media Queries .
Snapping ("parking")
Technically, this story is somewhat similar to the task of developing a common solution for desktop and mobile scenarios. The Snap function in Windows 8 allows you to attach a Metro style app to the side (right or left) so that it is constantly on the screen:
In this state, the width of the space allocated for the site is 320px, which is similar to mobile scenarios and is also available for adjusting the display using the CSS3 Media Queries.
See also the article Device adaptation .
7. Design your fingers, mouse and keyboard.
Finally, do not forget about how the user interacts with your site (by the way, regardless of whether it uses the desktop or metro mode of Internet Explorer). He can control the mouse and keyboard, and maybe his fingers.
The latter means that it’s time to think whether it’s convenient to work with your website or web application using natural input?
In general, recommendations for normal applications that support police input (including mobile applications for different platforms) are applicable to sites: the importance of instant visual response, minimum target sizes and padding between them, overlap zones, etc.
From a technical point of view, I recommend paying attention to these two articles: Touch Input for All 10 .
Summary
I repeat once again the necessary fad to be fully armed at the right time:
- Use the correct doctype
- Check rendering mode and possible problems with the consistency inspector
- Switch to the “feature detection” approach
- Consider what the user will see when there are no plugins.
- Add ms prefixes for experimental features and non-prefix alternatives for the future.
- Prepare for different screen sizes and display modes
- Allow the user to conveniently work with your fingers with your website or web application.
Source: https://habr.com/ru/post/139848/
All Articles