Make tables responsive

[waldyrious]

See a detailed description of the (potential) issue here. The rulesets adapted from Fluidity may already cover this, but it wold be good to actually confirm that.

[dohliam]

@waldyrious This sounds like a good idea, particularly since some frameworks may have different definitions of what "responsiveness" means. Someone would need to go through each framework and assess it according to some fixed set of criteria (e.g., presence of horizontal scroll, media elements resized or not, accessibility on mobile etc). Once that data has been collected we could easily add it to the Readme to help people choose between frameworks.

[waldyrious]

@dohliam it seems like you're speaking about the dropin-minimal-css project. It would be great to have a responsiveness assessment for all stylesheets listed there, but to be clear, this issue is specifically about validating the responsiveness of downstyler itself :)

[dohliam]

Whoops, you're right! Just looking at your other issue in that project and didn't notice this was somewhere else... (Actually that was here too. Must have got here via the issue link... Now that I'm here, downstyler looks really cool, and I wonder if it might be possible to use it as part of the bookmarklet for dropin-minimal-css to clear out page styles before switching, so I'm glad I dropped by!)

[waldyrious]

So, the Fluidity-inspired rules do indeed cover the max-width for images and other embedded media, but not the wide tables. I've submitted #80 to help test possible improvements to that.

[waldyrious]

but not the wide tables.

I'll retitle this issue so that it reflects the current status, and to make it more actionable.

[waldyrious]

Ok, so it seems that setting tables to display:block + overflow:auto allows them to show a horizontal scrollbar if they're too wide for the container, rather than overflow (see kevquirk/simple.css#78). This appears to have accessibility concerns (kevquirk/simple.css#104 (comment)), though it's not clear which and whether additional CSS could counteract the problem. Unless more clarity emerges on that issue, I'm inclined to just go ahead with the display:block trick.

There are two improvements that could be done to this: First, showing a shadow when there's scrolling to do, so that it's more evident that there's scrollable content; and second, letting wide tables break out of the width-constrained main column (see Layout Breakouts with CSS Grid). Here's one way to do it, which is called "Pop & Plop" in the Thinking on ways to solve CENTERING video:

table {
	position: relative;
	left: 50%;
	transform: translate(-50%);
}

In fact, we could apply this centering + breakout strategy to all tables; those narrower than the container width would be centered horizontally with left & right margins, which is an acceptable default IMO. This would allow tables to stretch past the container width, while still allowing them to scroll when they reach the viewport width:

table {
	position: relative;
	left: 50%;
	transform: translate(-50%);
	display: block;
	overflow: auto;
	width: fit-content;
	max-width: calc(100vw - 2em);
}

There's what the result looks like:

Firefox	Chromium

Seems promising. Once I add the scrolling shadow effect mentioned above, I'm thinking it might be a good idea to go ahead and do it. However, this may be problematic for pages that use tables for layout (#18).