Pure CSS tabs from IE6 + (reincarnation of one solution)
There was an article on Habré on the implementation of tabs on pure CSS, which the author deleted (apparently due to the incompleteness of the decision), while hiding all the comments. Thanks to the author's work, I have eliminated one of the disadvantages of usability in the decision and published it in a comment. The behavior of the tabs became normal, by clicking on the tab (or the button, depending on how you call it), it stood out and remained selected after the mouse was retracted. In order not to lose sight of both solutions and to continue their development, I will provide copies of them. The solution of the author makzimko copied to the sandbox (IE9 +), retaining all the necessary properties. Addition - in the modification in the same place (from IE9 +). New (UPD3) cross-browser solution with support from IE6 - on jsfiddle.net and a single file . Finally, while Opera 11.61 works, a minor fix (UPD4) was needed to support Opera 11.50 and earlier.
(The Habr is inconvenient — deleting articles, accompanied by deleting comments. One cannot be sure when posting a comment that it will remain. The idea of crowdsourcing is lost — the community refined initial raw solutions and the knowledge base — what was written, stored for itself, and for other readers. The article gives a bit more confidence, so the decision was republished to the article.)
The main goal of both solutions:
Implement the mechanism of tabs or buttons for switching content without resorting to scripts, without reloading the page.
Why do you need it? Most likely, this solution will be very useful for pages of wide application, among whose clients users with Javascript turned off. In order not to make two decisions for them - tabs through the server and tabs on JS, you can make tabs on CSS.
The virtues, however, are visible; list the shortcomings.
')
Disadvantages of the original solution (part of them is solved further, part is inherent in the approach):
*) there is no button press memory; : focus could help, but any click on the page will lose focus;
*) non-support for IE8 and below (due to inline-block; solvable; decided in UPD3);
*) limiting the height of the content - due to the solution method, it is necessary to have a fixed height for the content, exceeding which will lead to trimming of the content. (The solution is a scroll for each indoor unit.);
*) non-modularity (if not in the frame) - cannot be used as an independent block on the page, only as a window or frame.
Disadvantages in addition:
In addition to eliminating the first drawback, others are saved and a couple more are added:
*) in addition it is possible to use only one row of tabs or buttons;
*) duplicate content tabs (headers).
However, the importance of the first flaw was greater - it influenced the display, and the flaws that appeared appeared to be hidden from the user and related to implementation difficulties. So, they got a slightly more limited implementation, but a solution similar to real tabs.
In order to properly look at a solution, an anchor must be written in the URL of the page or frame, for example, # tab1. Since there are no anchors in the jsfiddle.net sandbox, a small script is used that switches to anchor after a second. In the current decision it is, of course, not required.
In HTML without JS, we can control the display of content by clicking on links. The way to change the contents of the window without reloading the page is anchors. The page scrolls to an anchor so that it is located at the upper edge of the window or frame. Anything below the anchor will be viewed in a window or frame. This is the basic idea of switching between tab pages.
Next, we need to hide the excess. CSS has an overflow: hidden property ; - the limiter for displaying content outside the block , and the height property: the block height limiter. You need to specify the height of the window in which we will observe the content (here it is, the restriction on the display of the block - we need to place the content in the window or frame and also know what height the block will be for viewing). In the example, these 2 properties are specified in #tabcontent {...} .
Next, we take care of displaying the header with the toggle buttons. It should not move when switching over anchors, so it is outside #tabcontent , in the #tabs block. And you need to close the buttons just pressed with the image of the selected inactive tab. There was no closing in the original decision. In order to have prospects for implementation on CSS1, you do not need to use anything up-to-date. We assign a button duplicate over each page of content ( #tabcontent li ) and depict it pressed. We set the offset of each button manually so that when scrolling along the anchor it will hit exactly the position of the button just pressed. We attribute z-index to double the button so that it is at the top. (Further, it turns out that for IE6-8 and for the rest, this is done by slightly different techniques.) We combine cross-browser properties in a single code.
In principle, it is possible to describe both 2 and 3 rows of tabs in this way, if we accurately calculate the position of the duplicate button in all rows. If you make a full duplicate of the headings above each page (the desired tab is visible, the rest are invisible), you can also create automatically filled multi-line tabs. There is a concomitant question: is it beautiful to duplicate content? If JS is disabled, then in other browsers we will not do tabs. If it is not disabled, we will use JS on the same solution (after all, duplicating procedures is the same ugly?), Duplicate the code on the client. (In the examples from the article there is no example of complete duplication of content, this is an opportunity for the future development of the approach.)
Finally, we ensure non-wrapping of tabs on the second line, because we have a single-line solution. In 2 examples, performed in different ways. In the first (bA9mF / 45), simply the white-space property : nowrap; , in the second (bA9mF / 52) - setting the width of the header so that it is always wider than all the tabs included in it ( #tabs {min-width: 573px; * width: 573px;} )
The solution with the modification is checked and is ready for further development here: jsfiddle.net/bA9mF/45 ( view ).
It looks like this (Fx8-10, Opera11.61, Chrome 16, Safari 5.02 Win):
The coverage with the .pressed button of the last active button and the reaction to mouse pointing on other buttons are shown.
Fx does not work -moz-transition (fixed in UPD2); in Safari 5.02, in this example, gradients are not worked out, so it is done with a uniform fill (possibly, in a higher version, normal). Fx3.6 works too, but without -moz-transition.
Some variations of fonts in browsers are hidden by the enlarged .pressed buttons, but an accurate pixel coverage with a slightly different layout is achievable, and at the same time a normal implementation in IE7-8. To do this, you need to build buttons on the float: left and fix the gaps between them, which are now floating a little because of the inline-block.
UPD : in the LAN, they said that everything in Safari 5.1 can be seen with gradients in Mac and Win. So much the better, now the CSS code works with normal degradation (uniform gray fill) for Safari 5.0. In the styles used -webkit-linear-gradient, which is introduced in Chrome 10+, Safari 5.1+.
UPD 2 : According to Softlink , “ Transition works in FF, but it has a feature: if we change positioning, then for this browser it is necessary to indicate the initial coordinates. ” Thus, it is enough to add the position top: 0; in #tabs li to make Fx work (its example is here ).
UPD 3 22.30: There is a solution for all browsers. jsfiddle.net/bA9mF/52 ( view )
In IE6, there is a slight natural degradation - the buttons are active only when directly hovering over the link and do not work: hover (and should not; for implementation in IE6, they make * .htc files). The same is true for IE8, if it is in Browser Mode: Compat , in this case Document Mode: Ie7 is automatically turned on, not Ie8. The same - and in a separate page . Therefore (this is a general requirement for the IE browser) you need to make sure that the browser is not in compatibility mode. (For more on IE browser modes, see the discussion of this topic with SelenIT2 in the comments .
How the page and effects in IE6 and IE7 look like:
UPD 4 13.02 10.30: Opera 10.51, 11.50 - both solutions in version bA9mF / 52 are not supported (the prototype works, although on the same principle). Surprisingly: it does not work because of the line #tabcontent li> div {margin-top: 266px; ...}, which, if removed, will work, but it is needed so that it works correctly in all browsers without an anchor. Surprisingly, without this line it works correctly everywhere, and in Opera from 10.51 too. Fast fix: jsfiddle.net/bA9mF/65/embedded/result But Oper (up to 11.61) has another bad luck: the imposed tabs go in a narrow window.
(The Habr is inconvenient — deleting articles, accompanied by deleting comments. One cannot be sure when posting a comment that it will remain. The idea of crowdsourcing is lost — the community refined initial raw solutions and the knowledge base — what was written, stored for itself, and for other readers. The article gives a bit more confidence, so the decision was republished to the article.)
The main goal of both solutions:
Implement the mechanism of tabs or buttons for switching content without resorting to scripts, without reloading the page.
Why do you need it? Most likely, this solution will be very useful for pages of wide application, among whose clients users with Javascript turned off. In order not to make two decisions for them - tabs through the server and tabs on JS, you can make tabs on CSS.
The virtues, however, are visible; list the shortcomings.
')
Disadvantages of the original solution (part of them is solved further, part is inherent in the approach):
*) there is no button press memory; : focus could help, but any click on the page will lose focus;
*) non-support for IE8 and below (due to inline-block; solvable; decided in UPD3);
*) limiting the height of the content - due to the solution method, it is necessary to have a fixed height for the content, exceeding which will lead to trimming of the content. (The solution is a scroll for each indoor unit.);
*) non-modularity (if not in the frame) - cannot be used as an independent block on the page, only as a window or frame.
Disadvantages in addition:
In addition to eliminating the first drawback, others are saved and a couple more are added:
*) in addition it is possible to use only one row of tabs or buttons;
*) duplicate content tabs (headers).
However, the importance of the first flaw was greater - it influenced the display, and the flaws that appeared appeared to be hidden from the user and related to implementation difficulties. So, they got a slightly more limited implementation, but a solution similar to real tabs.
In order to properly look at a solution, an anchor must be written in the URL of the page or frame, for example, # tab1. Since there are no anchors in the jsfiddle.net sandbox, a small script is used that switches to anchor after a second. In the current decision it is, of course, not required.
What principle does it work on
In HTML without JS, we can control the display of content by clicking on links. The way to change the contents of the window without reloading the page is anchors. The page scrolls to an anchor so that it is located at the upper edge of the window or frame. Anything below the anchor will be viewed in a window or frame. This is the basic idea of switching between tab pages.
Next, we need to hide the excess. CSS has an overflow: hidden property ; - the limiter for displaying content outside the block , and the height property: the block height limiter. You need to specify the height of the window in which we will observe the content (here it is, the restriction on the display of the block - we need to place the content in the window or frame and also know what height the block will be for viewing). In the example, these 2 properties are specified in #tabcontent {...} .
Next, we take care of displaying the header with the toggle buttons. It should not move when switching over anchors, so it is outside #tabcontent , in the #tabs block. And you need to close the buttons just pressed with the image of the selected inactive tab. There was no closing in the original decision. In order to have prospects for implementation on CSS1, you do not need to use anything up-to-date. We assign a button duplicate over each page of content ( #tabcontent li ) and depict it pressed. We set the offset of each button manually so that when scrolling along the anchor it will hit exactly the position of the button just pressed. We attribute z-index to double the button so that it is at the top. (Further, it turns out that for IE6-8 and for the rest, this is done by slightly different techniques.) We combine cross-browser properties in a single code.
In principle, it is possible to describe both 2 and 3 rows of tabs in this way, if we accurately calculate the position of the duplicate button in all rows. If you make a full duplicate of the headings above each page (the desired tab is visible, the rest are invisible), you can also create automatically filled multi-line tabs. There is a concomitant question: is it beautiful to duplicate content? If JS is disabled, then in other browsers we will not do tabs. If it is not disabled, we will use JS on the same solution (after all, duplicating procedures is the same ugly?), Duplicate the code on the client. (In the examples from the article there is no example of complete duplication of content, this is an opportunity for the future development of the approach.)
Finally, we ensure non-wrapping of tabs on the second line, because we have a single-line solution. In 2 examples, performed in different ways. In the first (bA9mF / 45), simply the white-space property : nowrap; , in the second (bA9mF / 52) - setting the width of the header so that it is always wider than all the tabs included in it ( #tabs {min-width: 573px; * width: 573px;} )
Decision
The solution with the modification is checked and is ready for further development here: jsfiddle.net/bA9mF/45 ( view ).
It looks like this (Fx8-10, Opera11.61, Chrome 16, Safari 5.02 Win):
The coverage with the .pressed button of the last active button and the reaction to mouse pointing on other buttons are shown.
Fx does not work -moz-transition (fixed in UPD2); in Safari 5.02, in this example, gradients are not worked out, so it is done with a uniform fill (possibly, in a higher version, normal). Fx3.6 works too, but without -moz-transition.
Some variations of fonts in browsers are hidden by the enlarged .pressed buttons, but an accurate pixel coverage with a slightly different layout is achievable, and at the same time a normal implementation in IE7-8. To do this, you need to build buttons on the float: left and fix the gaps between them, which are now floating a little because of the inline-block.
UPD : in the LAN, they said that everything in Safari 5.1 can be seen with gradients in Mac and Win. So much the better, now the CSS code works with normal degradation (uniform gray fill) for Safari 5.0. In the styles used -webkit-linear-gradient, which is introduced in Chrome 10+, Safari 5.1+.
UPD 2 : According to Softlink , “ Transition works in FF, but it has a feature: if we change positioning, then for this browser it is necessary to indicate the initial coordinates. ” Thus, it is enough to add the position top: 0; in #tabs li to make Fx work (its example is here ).
UPD 3 22.30: There is a solution for all browsers. jsfiddle.net/bA9mF/52 ( view )
In IE6, there is a slight natural degradation - the buttons are active only when directly hovering over the link and do not work: hover (and should not; for implementation in IE6, they make * .htc files). The same is true for IE8, if it is in Browser Mode: Compat , in this case Document Mode: Ie7 is automatically turned on, not Ie8. The same - and in a separate page . Therefore (this is a general requirement for the IE browser) you need to make sure that the browser is not in compatibility mode. (For more on IE browser modes, see the discussion of this topic with SelenIT2 in the comments .
How the page and effects in IE6 and IE7 look like:
UPD 4 13.02 10.30: Opera 10.51, 11.50 - both solutions in version bA9mF / 52 are not supported (the prototype works, although on the same principle). Surprisingly: it does not work because of the line #tabcontent li> div {margin-top: 266px; ...}, which, if removed, will work, but it is needed so that it works correctly in all browsers without an anchor. Surprisingly, without this line it works correctly everywhere, and in Opera from 10.51 too. Fast fix: jsfiddle.net/bA9mF/65/embedded/result But Oper (up to 11.61) has another bad luck: the imposed tabs go in a narrow window.
Source: https://habr.com/ru/post/138045/
All Articles