revisiting

the tab-select hack

As “tab-select” equivalent hacks have been regularly used on this site since at least october 2013, I thought that maybe it was about time to upgrade some of my use of it a little. Never mind that it has been called a “hack” by many for a long time, as what is called and what isn't called “hacks” in HTML/CSS constructs depends largely on what the person you talk to feels comfortable with or not.

My simple approach to the entire “hack” issue is that “what works works, and what doesn't work doesn't work” – no “opinions” will change that. If in doubt of reliability across browser-land now and in the fore­see­able future, I check the code validity of the construct in question.
When all is found to be OK, I carry on doing what needs to be done to make whatever it is work to my satisfaction. Thereafter I can figure out if what I have come up with is of any use.

the tab-select hack explained

Some call it the “input hack”, which is logical since it uses the state of an input element to manipulate styles.
Here's how it works…

  1. place an input type=checkbox or input type=radio element in the source-code.
  2. use the input:checked (or not) status to manipulate styling of elements following the input element.
  3. to keep the input element from visually show up in all its “uglyness”, declare opacity:.001 on it and overlay it with appropriate size in front of an element that explains its purpose.
  4. to keep input from showing up in screen readers (where it does no good), add an aria-hidden="true" attribute to the input element.
  5. make sure not to use display:none on any of the content the input status is controlling. The content must stay accessible even if it is to be kept out of view until selected.

… and that's basically all there is to it. I have expanded some on a few details further down this page.

The “tabbed content” demos below are lifted from the old but upgraded tabbed content experiment, final version page.

flipbook tab-demo open

over­view

features…

  • content‐blocks hold any type and mix of content.
  • flexible content‐block size = vertically expandable beyond min-height.
  • responsive (with the page).
  • HTML/CSS only (no script).
  • not using target = does not mess up page addresses with in‐page links.
  • hidden in clear view = no “invisible” content positioned outside browser window.

More tabs‐lines can of course be added, using the same technique – see below. And leaving out tabs doesn't change how it works.

Note: to see how tabs are sequenced in normal flow, you can open all tabs at once.

flip­book

You may call it what you like, as this tabbed flipbook is of course well suited to split up and present any content, being it text, images, videos, menus, or a mixture of all. Its use is, as for most things web, only limited by our imagination and taste.

It can easily be styled with transitions and effects, to satisfy those who believe web pages need that sort of thing. Personally I don't care much for effects, so all I have in these demos is a quick opacity transition.

For this demo I have kept everything simple, as it is more a proof of concept than anything. Not much chance that the concept will end up in the garbage bin, but it does need time to grow into something useful.

pictures

citrus reflections

An image that is given no class, following directly after first‑child headline, is styled to have that very same headline layered in front, as an image title. This is an idea borrowed from sketchbook, which is an old “tabbed content” variant of mine that also uses INPUT for in‐page user‐interfacing.

Such an “overlay‐on‐images” is nothing special – only involves z‑index and negative margin‑top in this case. Easy to remove or change into something completely different.

tailored

tailor individual tabs

Horizontal position and width of individual tabs, are tweaked in this demo. It is easy to tweak individual tabs and overall line‐up, no matter how many tabs and tab‐lines the line‐up consists of.

It is of course not necessary to fill a line with tabs, or limit number to five pr. line. It will work just fine no matter the number of tabs, as long as they are styled in percentages to stay within tab‐line width.

Tab‐tailoring can be taken too far, as it is easy to position tabs so they visually do not follow source‐code (HTML) order. I always follow source‐code order visually for content, and advice everyone to do the same – especially when including “show/hide” solutions.

finally

This page‐design itself is responsive, and the tabbed flipbook with its content naturally follows suit and adjusts to a wide range of browser‐windows.

Horizontally tabbed interfaces like this are not very suitable for really small screens, as those tabs will end up being compacted too much. Thus, this demo expands fully open on narrow screens – break-point at 643px.

I have a preference for “quiet and simple” web designs, down to the smallest details. Consequently, for me it is natural to implement “clever” solutions in such a way that they do not immediately call for attention and/or disturb the average visitor.

…next follows a two-liner demo, with visual cues to how :hover works…

over­view

features…

  • content‐blocks hold any type and mix of content.
  • flexible content‐block size = vertically expandable beyond min-height.
  • responsive (with the page).
  • HTML/CSS only (no script).
  • not using target = does not mess up page addresses with in‐page links.
  • hidden in clear view = no “invisible” content positioned outside browser window.

More tabs‐lines can of course be added, using the same technique. And leaving out tabs doesn't change how it works.

flip­book

You may call it what you like, as this tabbed flipbook is of course well suited to split up and present any content, being it text, images, videos, menus, or a mixture of all. Its use is, as for most things web, only limited by our imagination and taste.

It can easily be styled with transitions and effects, to satisfy those who believe web pages need that sort of thing. Personally I don't care much for effects, so all I have in these demos is a quick opacity transition.

For this demo I have kept everything simple, as it is more a proof of concept than anything. Not much chance that the concept will end up in the garbage bin, but it does need time to grow into something useful.

picture

citrus reflections

An image that is given no class, following directly after first‑child headline, is styled to have that very same headline layered in front, as an image title. This is an idea borrowed from sketchbook, which is an old “tabbed content” variant of mine that also uses INPUT for in‐page user‐interfacing.

Such an “overlay‐on‐images” is nothing special – only involves z‑index and negative margin‑top in this case. Easy to remove or change into something completely different.

exam­ple

reduced number of tabs

Reducing number of tabs and containers in HTML without modifying line‐up in CSS, will for this “two‐liner” result in the following…
…which in my opinion makes perfect use of space – at least in my design.

expand

expanding all tabs

Opening entire flipbooks in one go by :target‐addressing “#flipbook” – an element containing the actual flipbooks, does in my demos show hints of tabs…
…because that is how I like it here.

With flipbooks in expanded form, a tab counter is included to make it easier to keep track of tabs down the page.

I chose to attach the “#flipbook” ID to the section container all demos are nested inside, and the regular sitewide :target styling then also kicks in along with the specific one, showing blue background on first headline in the section that is being targeted.

line-up 1

line-up check v/h2

Otherwise nothing to see here.

line-up 2

line-up check v/h3

Otherwise nothing to see here.

line-up 3

line-up check v/h4

Otherwise nothing to see here.

line-up 4

line-up check v/h5

Otherwise nothing to see here.

finally

This page‐design itself is responsive, and the tabbed flipbook with its content naturally follows suit and adjusts to a wide range of browser‐windows.

Horizontally tabbed interfaces like this are not very suitable for really small screens, as those tabs will end up being compacted too much. Thus, this demo expands fully open on narrow screens – break-point at 643px.

I have a preference for “quiet and simple” web designs, down to the smallest details. Consequently, for me it is natural to implement “clever” solutions in such a way that they do not immediately call for attention and/or disturb the average visitor.

styling limitations

Controlling input elements visually is not the easiest thing in the world, as they literally “live in a layer of their own”.

For the input type=radio element declaring width, height, margin, opacity, font-size, position and z-index works fine, but in practical use across browser-land that's about it. Also, appearance is browser-dependent and rather ugly. Thus, to make input work for cases like the one presented on this page, we have to be a little creative.

Lowering opacity for an input element to almost zero, and then layer it in front of an element that both in content and style explains its role, takes care of the visual without affecting function. As all inputs and visual tabs are absolute positioned, further layering allows for easy control of “tab in front of tab” and “hiding input for active tab”, etc.

For the “tabbed content” demos on this page, where the visual tabs grow taller on :hover, I size up font-size on input slightly when hovering to make it follow the visual tab vertically.

Vertical size of the input is declared in em, so it changes with font-size. The hori­zon­tal size OTOH, is fixed to a % of outer tab-container's width and is therefore not affected by font-size.

The inputs for each tab-height is given their own initial font-size value to create the tailored (invisible)* “catch-the-pointer” effect.
*(In the second of the working demos above, the inputs in front of the center tabs are made semi-transparent so the more or less synchro­nized :hover effect can be seen.)

A reasonable sized and positioned input element works fine with on-screen tapping, so no need to modify anything for screens / devices without mouse-pointers and :hover effects.
However, as I see no point in having “tabbed content” on small screens, I make sure the “tabbed” visual design gets linearized and simplified for very narrow windows / screens.

so much more

I have included various “visual trickery” in the “tabbed content” stylesheet used for the demos on this page, and the content is of course also affected by site-wide styles. All of that is simply too much to explain in one article, so I have left it out here.
Some is explained in individual slides in those demos above, and everyone who can read CSS can make it out for themselves anyway.

I am obviously quite comfortable with this form for workaround for browsers' missing native in-page tabbing func­tion­ality, and when done right such imple­men­tations should not cause problems for any end-users.

Unless someone presents a perfect case against the use of input type=checkbox and input type=radio elements for conditional styling, I will continue to test them out and literally stretch them as far as they will go.
Whether or not I can come up with suitable real-world cases for “in-page tabbing”, is another question entirely.

sincerely  georg; sign

Hageland 04.oct.2016
last rev: 20.jun.2021



www.gunlaug.comadvice upgradeadvice upgrade navigation