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 foreseeable 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…

place an input type=checkbox or input type=radio element in the source-code.
use the input:checked (or not) status to manipulate styling of elements following the input element.
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.
to keep input from showing up in screen readers (where it does no good), add an aria-hidden="true" attribute to the input element.
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.

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 horizontal 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 synchronized :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 functionality, and when done right such implementations 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

side notes.

there must be order…

As with all HTML/CSS constructs, even something as simple as this has to be properly coded to work as intended, without messing up the mental model of natural sequence of content for some end-users.

The source-order I use for “tabbed content”, is the same as used for “non-tabbed content” – with the addition of generic containers to separate groups of content for conditional styling. Take away the extra styling used to visually organize the “tabbed content”, and it flows down the page in its natural and logical order same as everything else on the page.

HTML source-order

<div class="tab">
<input type="radio" aria-hidden="true">
<h3>tab title</h3>
<div>tab content</div>

<!-- more “tabbed content” in same tab-group -->

<input type="radio" aria-hidden="true">
<h3>tab title</h3>
<div>tab content</div>
</div> <!-- end of tab-group -->

source-order reflected in CSS

div.tab {…}
div.tab>input {…}
div.tab>input+h3 {…}
div.tab>input+h3+div {…}

advantages…

Source-order defines the visual and actual connection, as tab-content follows directly after tab-headline in source.
Many tabbed interfaces have a disconnect between visual tabs and content in source-code, with all tabs placed in one area and all tab-content placed elsewhere.

Does not rely on javascript.
Works as intended also without script support.

Not relying on in-page links.
Page doesn't move to :target as with in-page links.

The use of tab-headlines allows for regular keyboard tabbing between headlines.
No differences between “tabbed” and “non-tabbed” content, and no need to “reinvent” or “adjust” keyboard tabbing.

disadvantages…

Unexpected outcome in screen readers?
Maybe, as the direct and logical connections between tab-headlines and tab-content makes “tabbed” content behave as “non-tabbed” content when the input is hidden via the aria- attribute.

The seemingly unintended use of the input element for pure styling, is frown upon by some.
Code validators are perfectly OK with it, and CSS capable browsers provide input elements' status for styling as they are supposed to. Thus, no problem.

In non-CSS and nonaria- capable browsers the now redundant input elements show up as artifacts that may catch focus.
That's the only negative point I have found, but since the input elements do not have anything to interact with it does no harm. Have only tested visually in Lynx, and experienced no real problems.

considerations

Is the input element used correctly on this page? Is the input element only valid when used in a form and/or with a label?
Let's see now…

The input element with a type attribute whose value is "radio" represents a selection of one item from a list of items.
Permitted parent elements: Any element that can contain phrasing elements. source: W3C: input type=radio

Fits the “tabbed content” bill perfectly as far as I can see. Whatever anyone find “hacky” in the use of the input element to select content for styling, must remain “undefined” until someone rewrites the W3C standards I base my work on. Looks like they may have done just that, or at least they have now removed the W3C article I quoted from. Shit happens…

My use of the input element for styling purposes, is based on some old and obscure browser test pages on the W3C site (here is actual test page), where browsers' CSS support for input elements' status were tested.

Since those tests worked fine in Opera (on Presto) way back in time, I experimented with input based play-things a decade or so ago. Lack of support in other browsers meant I didn't find much use for any of it outside my sandbox back then though.
Browsers have improved quite a bit in later years, but in-page tabbing still requires some form of work-around.

regarding “hacks” in general

Calling something a “hack” in web design, does not in itself carry a negative or a positive charge. One can find “smart hacks”, “ugly hacks”, “unintended hacks” and “totally nonsensical hacks” on-line.
One has to understand a piece of code, and its purpose, before categorically classifying it as either a “good hack” or a “bad hack”, or, as in most cases, maybe “not a hack” at all.

Non-valid HTML/CSS is either sloppy work or genuine browser hacks.
Should be avoided whenever possible.

Unintended and/or unexpected use of anything in web design, may have negative impact on some end-users' experiences.
Potentially problematic issues should be checked up on on a case-by-case basis. No need to make anything particularly difficult for anyone just for the sake of it. OTOH: no reason not to make full use of what's in the toolbox.

Again, 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.
Personal preferences are just that … personal preferences.

revisiting

… the tab-select hack

the tab-select hack explained

flipbook tab-demo open…

overview

features…

flipbook

pictures

citrus reflections

tailored

tailor individual tabs

finally

overview

features…

flipbook

picture

citrus reflections

example

reduced number of tabs

expand

expanding all tabs

line-up 1

line-up check v/h2

line-up 2

line-up check v/h3

line-up 3

line-up check v/h4

line-up 4

line-up check v/h5

finally

styling limitations

so much more

revisiting

… the tab-select hack

the tab-select hack explained

flipbook tab-demo open…

over­view

features…

flip­book

pictures

citrus reflections

tailored

tailor individual tabs

finally

over­view

features…

flip­book

picture

citrus reflections

exam­ple

reduced number of tabs

expand

expanding all tabs

line-up 1

line-up check v/h2

line-up 2

line-up check v/h3

line-up 3

line-up check v/h4

line-up 4

line-up check v/h5

finally

styling limitations

so much more

overview

flipbook

overview

flipbook

example