From e308781323d3bc2aefc917aa1a2b192705106531 Mon Sep 17 00:00:00 2001 From: Estelle Weyl Date: Fri, 12 Jan 2024 15:03:04 -0800 Subject: [PATCH] CSS content update: learn to support older browsers (#31473) * supporting older browsers page * remove more legacy cruft * typo * changes the entire see also * Apply suggestions from code review Co-authored-by: Dipika Bhattacharya * Apply suggestions from code review Co-authored-by: Dipika Bhattacharya * Update files/en-us/learn/css/css_layout/supporting_older_browsers/index.md Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> * rewrote selector section * Apply suggestions from code review Co-authored-by: Dipika Bhattacharya * fix typo --------- Co-authored-by: Dipika Bhattacharya Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> --- .../supporting_older_browsers/index.md | 156 ++++++------------ 1 file changed, 53 insertions(+), 103 deletions(-) diff --git a/files/en-us/learn/css/css_layout/supporting_older_browsers/index.md b/files/en-us/learn/css/css_layout/supporting_older_browsers/index.md index 6fc5d0e6b48b5d8..8080f57d7a32eba 100644 --- a/files/en-us/learn/css/css_layout/supporting_older_browsers/index.md +++ b/files/en-us/learn/css/css_layout/supporting_older_browsers/index.md @@ -2,13 +2,14 @@ title: Supporting older browsers slug: Learn/CSS/CSS_layout/Supporting_Older_Browsers page-type: learn-module-chapter +browser-compat: css.properties.grid-template-columns --- {{LearnSidebar}} {{PreviousMenuNext("Learn/CSS/CSS_layout/Legacy_Layout_methods", "Learn/CSS/CSS_layout/Fundamental_Layout_Comprehension", "Learn/CSS/CSS_layout")}} -There will be visitors to your site who use older browsers, or browsers which may not support the features you have used. This will always be the case on the web — as new features are developed, different browsers will prioritize different things. This article explains how to use modern web techniques without locking out users of older technology. +Visitors to your website may include users who either use older browsers or use browsers that do not support the CSS features you've implemented. This is a common scenario on the web, where new features are continuously being added to CSS. Browsers differ in their support for these features because different browsers tend to prioritize implementing different features. This article explains how you as a web developer can use modern web techniques to ensure that your website remains accessible to users with older technology. @@ -35,125 +36,74 @@ There will be visitors to your site who use older browsers, or browsers which ma ## What is the browser landscape for your site? -Every website is different in terms of target audience. Before deciding on the approach to take, find out the number of visitors coming to your site using older browsers. This is straightforward if you have an existing website which you are adding to or replacing, as you probably have analytics available which can tell you the technology people are using. If you have no analytics or this is a brand new site, then there are sites such as [Statcounter](https://gs.statcounter.com/) that can provide statistics filtered by location. +Every website is different in terms of its target audience. Before deciding on an approach, find out the number of visitors coming to your site using older browsers. This is straightforward if you're adding to or replacing an existing website, as you probably have analytics available that can tell you the technology your visitors are using. If you don't have analytics or you're launching a brand new site, then sites such as [Statcounter](https://gs.statcounter.com/) can provide relevant statistics, which can be filtered by location. -You should also consider the type of devices and the way people use your site, for example, you may expect a higher than an average number of mobile devices. Accessibility and people using assistive technology should always be considered, but for some sites that may be even more critical. In my experience, developers are often very worried about the experience of 1% of users in an old version of Internet Explorer, while not considering at all the far greater number who have accessibility needs. +You should also consider the type of devices and the way people use your site. For example, you can expect a higher-than-average usage of your website on mobile devices. Always prioritize accessibility and people using assistive technology; for some sites, this may be even more critical. Developers are often very worried about the experience of 1% of users, while overlooking the far greater number who have accessibility needs. ## What is the support for the features you want to use? -Once you know the browsers that come to your site, you can assess any technology that you want to use against how well it is supported and how easily you can provide an alternative for visitors who do not have that technology available. We are trying to make this easy for you at MDN, by providing browser compatibility information on each page detailing a CSS property. For example, take a look at the page for {{cssxref("grid-template-columns")}}. At the bottom of this page is a table, which lists major browsers along with the version they began supporting this property. +{{Compat}} -![Browser compatibility table. This table provides information on which browsers are compatible with the technology that you are looking for and the version from which the browser started supporting that functionality. Browser and mobile phone browser compatibility information are displayed separately. The browser names take up the column headers.](browser-table.png) +The above table is included at the bottom of every feature page under the section "Browser compatibility". After identifying the browsers your site visitors use, you can assess any technology that you want to use against how well it is supported across browsers and how easily you can provide an alternative for visitors who do not have that technology available. + +On MDN, we provide browser compatibility information on every CSS property page. This compatibility information, presented in a table, includes a list of major browsers along with the versions that started supporting the property. The browser names take up the column headers. For example, take a look at the above table or the page for {{cssxref("grid-template-columns")}}, with special attention to the `subgrid` (most recently supported) and `masonry` (experimental and not supported) values. + +These browser compatibility tables provide information on which browsers are compatible with the technology that you are looking for and the version from which the browser started supporting that functionality. Browser and mobile phone browser compatibility information are displayed separately. Another popular way to find out about how well a feature is supported is the [Can I Use](https://caniuse.com/) website. This site lists the majority of Web Platform features with information about their browser support status. You can view usage statistics by location — useful if you work on a site that has users mostly for a specific area of the world. You can even link your Google Analytics account to get analysis based on your user data. -Understanding the technology your users have, and the support for things you might want to use puts you in a good place to make all of your decisions and to know how best to support all of your users. +Understanding the technology your users have because of the browser they're using and the cross-browser support for features that you might want to use on your website, puts you in a good place to make all of your decisions and to know how best to support all of your users. -## Support doesn't mean "looks the same" +## Feature support does not mean identical appearance -A website can't possibly look the same in all browsers, because some of your users will be viewing the site on a phone and others on a large desktop screen. Similarly, some of your users will have an old browser version, and others the latest browser. Some of your users might be hearing your content read out to them by a screen reader, or have zoomed in on the page to be able to read it. Supporting everyone means serving a version of your content that is designed defensively, so that it will look great on modern browsers, but will still be usable at a basic level for users of older browsers. +A website can't possibly look the same in all browsers. Some of your users will be viewing the site on a phone and others on a large desktop screen. Similarly, some of your users will have an old browser version, and others the latest browser. Some of your users might be hearing your content read out to them by a screen reader, while others might need to zoom in on the page to be able to read it. Supporting everyone means serving a version of your content that is designed defensively, so that it will look great on modern browsers, but will still be usable at a basic level for all users no matter how they are accessing your content. -A basic level of support comes from structuring your content well so that the normal flow of your page makes sense. A user with a very limited feature phone might not get much of your CSS, but the content will flow in a way that makes reading easy. Therefore, a well-structured HTML document should always be your starting point. _If you remove your stylesheet, does your content make sense?_ +A basic level of support comes from structuring your content well so that the normal flow of your page makes sense. For users on a limited data plan, their browsers might not load images, fonts, or even your CSS. However, the content should be presented in a way such that it is accessible and readable even when these elements are not fully loaded. A well-structured HTML document should always be your starting point. Ask yourself: _if you remove your stylesheet, does your content still make sense?_ -One option is to leave this plain view of the site as the fallback for people using very old or limited browsers. If you have a tiny number of people coming to the site in these browsers it may not make commercial sense to pour time into trying to give them a similar experience to people on modern browsers. It would be better to spend the time on things which make the site more [accessible](/en-US/docs/Web/Accessibility), thus serving far more users. There is a middle ground between a plain HTML page and all the bells and whistles, and CSS has actually made creating these fallbacks pretty straightforward. +It doesn't make commercial sense to spend time trying to give everyone an identical experience of your website. This is because user environments can vary widely and are beyond your control. There is a balance you need to strike between a plain HTML page and a fully featured website. It is helpful to test a plain, CSS-less view of your site to ensure that the fallback experience of your site is accessible. This fallback may never be viewed by people using very old or limited browsers, but may be viewed by your main target audience — users of modern browsers — when their browser or Internet connection fails temporarily. CSS simplifies creating these fallbacks. Therefore, it is better to focus on what you can control, that is, spend the time to make your site [accessible](/en-US/docs/Web/Accessibility), thereby serving more users. ## Creating fallbacks in CSS -CSS specifications contain information that explains what the browser does when two layout methods are applied to the same item. This means that there is a definition for what happens if a floated item, for example, is also a Grid Item using CSS Grid Layout. Couple this information with the knowledge that browsers ignore CSS that they don't understand, and you have a way to create simple layouts using the [legacy techniques](/en-US/docs/Learn/CSS/CSS_layout/Legacy_Layout_Methods) we have already covered, which are then overwritten by your Grid layout in modern browsers that understand it. +CSS specifications contain information that explain what the browser does when two similar features, such as layout methods, are applied to the same item. For example, they define what happens if an item is floated and is also a grid item and part of a CSS grid container. There is also a definition for what happens when an element has both {{cssxref("margin-top")}} and {{cssxref("margin-block-start")}} properties set. -### Falling back from grid to float +When a browser doesn't recognize a new feature, it discards the declaration as invalid [without throwing an error](/en-US/docs/Web/CSS/CSS_syntax/Error_handling#css_parser_errors). Because browsers discard CSS properties and values they don't support, both old and new values can coexist in the same ruleset. Just make sure to declare the old value before the new value so that, when supported, the new value overwrites the old value (the fallback). -In the example below, we have floated three `
`s so they display in a row. Any browser that does not support [CSS Grid Layout](/en-US/docs/Learn/CSS/CSS_layout/Grids) will see the row of boxes as a floated layout. A floated item that becomes a grid item loses the float behavior, which means that by turning the wrapper into a Grid Container, the floated items become Grid Items. If the browser supports Grid Layout it will display the grid view; if not it ignores the `display: grid` and related properties and the floated layout is used. +For example, most browsers support the two-value syntax of the {{cssxref("display")}} property. If a browser doesn't, it will use the older, single-value syntax. ```css -* { - box-sizing: border-box; -} - -.wrapper { - background-color: rgb(79 185 227); - padding: 10px; - max-width: 400px; - display: grid; - grid-template-columns: 1fr 1fr 1fr; -} - -.item { - float: left; - border-radius: 5px; - background-color: rgb(207 232 220); - padding: 1em; +.container { + display: inline-flex; + display: inline flex; } ``` -```html -
-
Item One
-
Item Two
-
Item Three
-
-``` - -{{ EmbedLiveSample('Falling_back_from_grid_to_float', '100%', '200') }} - -### Fallback methods +Similarly, this [error-handling](/en-US/docs/Web/CSS/CSS_syntax/Error_handling#vendor_prefixes) ensures old CSS code bases continue to work even if legacy {{glossary("Vendor_Prefix", "vendor-prefixed")}} features are no longer supported. While vendor prefixing is no longer commonly used, if you must include a vendor-prefixed property or value, make sure to declare the prefixed value before the standard value so that, when supported, the new value overwrites the fallback value. -There are a number of layout methods which can be used in a similar way to this float example. You can choose the one that makes the most sense for the layout pattern you need to create. +### Using new selectors -- Float (and clear) - - : As shown above, the float property ceases to affect the layout if floated items become flex or grid items. The {{cssxref("clear")}} property also has no effect once the cleared item becomes a flex or grid item. -- display: inline-block - - : This method can be used to create column layouts, if an item has `display: inline-block` set but then becomes a flex or grid item, the inline-block behavior is ignored. -- display: table - - : This method can be used to create table layouts, if an item has `display: table`, `display: table-cell`, etc., set but then becomes a flex or grid item, the display value is ignored. -- Multiple-column Layout - - : For certain layouts you could use [multi-col](/en-US/docs/Learn/CSS/CSS_layout/Multiple-column_Layout) as a fallback, if your container has any of the `column-*` properties defined on it and then becomes a grid container, the multicol behavior will not happen. -- Flexbox as a Fallback for Grid - - : [Flexbox](/en-US/docs/Learn/CSS/CSS_layout/Flexbox) has greater browser support than Grid due to being supported by IE10 and 11. If you make a flex container into a grid container, any `flex` property applied to the children will be ignored. +Including new selectors that aren't supported in all browsers needs to be handled more carefully. If a selector in a comma-separated list of [selectors is invalid](/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS#selector_support), the entire style block is ignored. -For many layout tweaks in older browsers, you may find you can give a decent experience by using CSS in this way. We add a simpler layout based on older and well-supported techniques, then use the newer CSS to create the layout that over 90% of your audience will see. There are cases, however, when the fallback code will need to include something that the new browsers will also interpret. A good example of this is if we were to add percentage widths to our floated items to make the columns more like the grid display, stretching to fill the container. - -In the floated layout, the percentage is calculated from the container — 33.333% is a third of the container width. In Grid however that 33.333% is calculated from the grid area the item is placed in, so it actually becomes a third of the size we want once the Grid Layout is introduced. +If using vendor-prefixed [pseudo-elements](/en-US/docs/Web/CSS/Pseudo-elements) or new[pseudo-classes](/en-US/docs/Web/CSS/Pseudo-classes) a browser may not yet support, include the prefixed values within a [forgiving selector list](/en-US/docs/Web/CSS/Selector_list#forgiving_selector_list) by using {{cssxref(":is", ":is()")}} or {{cssxref(":where", ":where()")}} so the entire selector block doesn't get [invalidated and ignored](/en-US/docs/Web/CSS/Selector_list#invalid_selector_list). ```css -* { - box-sizing: border-box; +:is(:-prefix-mistake, :unsupported-pseudo), +.valid { + font-family: sans-serif; } - -.wrapper { - background-color: rgb(79 185 227); - padding: 10px; - max-width: 400px; - display: grid; - grid-template-columns: 1fr 1fr 1fr; -} - -.item { - float: left; - border-radius: 5px; - background-color: rgb(207 232 220); - padding: 1em; - width: 33.333%; +:-prefix-mistake, +:unsupported-pseudo, +.valid { + color: red; } ``` -```html -
-
Item One
-
Item Two
-
Item Three
-
-``` - -{{ EmbedLiveSample('Fallback_methods', '100%', '200') }} - -To deal with this issue we need to have a way to detect if Grid is supported and therefore if it will override the width. CSS has a solution for us here. +In the above example, the `.valid` content will be `sans-serif` but not `red`. ## Feature queries -Feature queries allow you to test whether a browser supports any particular CSS feature. This means that you can write some CSS for browsers that don't support a certain feature, then check to see if the browser has support and if so throw in your fancy layout. +Feature queries allow you to test whether a browser supports a particular CSS feature. This means that you can write some CSS for browsers that don't support a certain feature, then check to see if the browser has support and if so, throw in your fancy new features. -If we add a feature query to the above example, we can use it to set the widths of our items back to `auto` if we know that we have grid support. +We can add a feature query to test for `subgrid` support, and provide styles based on that support: ```css * { @@ -161,24 +111,24 @@ If we add a feature query to the above example, we can use it to set the widths } .wrapper { - background-color: rgb(79 185 227); + background-color: palegoldenrod; padding: 10px; max-width: 400px; display: grid; - grid-template-columns: 1fr 1fr 1fr; + grid-template-columns: repeat(3, 1fr); } .item { - float: left; border-radius: 5px; background-color: rgb(207 232 220); - padding: 1em; - width: 33.333%; } -@supports (display: grid) { - .item { - width: auto; +@supports (grid-template-rows: subgrid) { + .wrapper { + grid-template-rows: subgrid; + gap: 10px; + background-color: lightblue; + text-align: center; } } ``` @@ -188,31 +138,31 @@ If we add a feature query to the above example, we can use it to set the widths
Item One
Item Two
Item Three
+
Item Four
+
Item Five
+
Item Six
``` {{ EmbedLiveSample('Feature_queries', '100%', '200') }} -Support for feature queries is very good across modern browsers. However, you should note that browsers that do not support CSS Grid also tend not to support feature queries. This means that an approach as detailed above will work for those browsers. What we are doing is writing our old CSS first, outside of any feature query. Browsers that do not support Grid, and do not support the feature query will use that layout information they can understand and completely ignore everything else. The browsers that support the feature query also support CSS Grid and so will run the grid code and the code inside the feature query. - -The specification for feature queries also contains the ability to test if a browser does not support a feature — this is only helpful if the browser does support feature queries. In the future, an approach of checking for lack of support will work, as the browsers that don't have feature query support go away. For now, however, use the approach of doing the older CSS, then overwriting it, for the best support. +Feature queries are supported in all modern browsers. Write your CSS for fully supported features first, outside of any feature queries. Once your site is usable and accessible to all users, add new features within feature query blocks. Browsers that support the feature queried can then render the newer CSS inside the feature query block. Use the approach of writing well-supported CSS first, then enhancing features based on support. ## Testing older browsers -With the majority of browsers supporting Flexbox and Grid, it can be reasonably hard to test older browsers. One way is to use an online testing tool such as Sauce Labs, as detailed in the [Cross browser testing](/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing) module. +One way is to use an online testing tool such as Sauce Labs, as detailed in the [Cross browser testing](/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing) module. ## Summary -You now have the knowledge to confidently use techniques such as Grid, create fallbacks for older browsers, and make use of any new techniques that might come along in the future. +You now have the knowledge to provide fallback CSS for older browsers and confidently test for new features. You should now feel confident making use of any new techniques that might come along. Now that you have worked through our articles on CSS layout, it's time to test your comprehension with our assessment for the module: [Fundamental layout comprehension](/en-US/docs/Learn/CSS/CSS_layout/Fundamental_Layout_Comprehension). ## See also -- [Using Feature Queries in CSS](https://hacks.mozilla.org/2016/08/using-feature-queries-in-css/) -- [CSS Grid Layout and Progressive Enhancement](/en-US/docs/Web/CSS/CSS_grid_layout/Grid_layout_and_progressive_enhancement) -- [Using CSS Grid: Supporting Browsers Without Grid](https://www.smashingmagazine.com/2017/11/css-grid-supporting-browsers-without-grid/) -- [Cascading Web Design with Feature Queries](https://24ways.org/2017/cascading-web-design/) -- [Using Feature Queries (Video)](https://gridbyexample.com/learn/2016/12/24/learning-grid-day24/) +- [`@supports`](/en-US/docs/Web/CSS/@supports) at-rule +- [CSS at-rules](/en-US/docs/Web/CSS/At-rule) +- [Using feature queries](/en-US/docs/Web/CSS/CSS_conditional_rules/Using_feature_queries) +- [CSS conditional rules](/en-US/docs/Web/CSS/CSS_conditional_rules) module {{PreviousMenuNext("Learn/CSS/CSS_layout/Legacy_Layout_methods", "Learn/CSS/CSS_layout/Fundamental_Layout_Comprehension", "Learn/CSS/CSS_layout")}}