fluid layout + responsive w/ row+span causes block-regions to be too narrow

[thedannywahl]

Moodle block regions need to be (I think) a minimum of 200 pixels, using the fluid grid and bootstrap responsive breakpoints causes the block-regions to become too narrow.

Probably we won't be able to use row+span but will have to write a custom responsive layout that allows fixed column widths or at least min-width on block-regions.

[ds125v]

I originally tried to go with fixed columns, but Bootstrap didn't seem designed to make that easy. Experimenting with min-width suggests that it breaks the layout, which I kind of half-expected. To be exact it shrinks till it hits the min-width size, then the right column slips below the left.

I'm trying to stay as close to Bootstrap (and Moodle) upstream where possible so I think the first approach should be to use CSS to trim down the margins and padding (on blocks, central column, and the sides of the page) at smaller sizes to see what we can manage via that.

By default the blocks get down to 155px width before the mode changes so we need to find about 45px per block-column to get up to 200px. Unfortunately the blocks only get 3/12 of the total so we need 180px total. There's 15px padding on each side of the block, and 20px on each side of the two nested containers, which is 140px we've got to play with, which is a bit short. What's the absolute minimum we can live with?

Would changing from a 3/6/3 layout to a 4/8 layout when we've only got two columns help?

[ds125v]

With a responsive non-fluid layout of 3/6/3 or 3/9 you get blocks of 270px, 220px then 166px as it steps down (then back up to a bit over 700 pixels when it goes to a single column). With a 4/8 or 8/4 layout you get blocks of 370, 330, 228 (then back up to 700-odd).

With a responsive fluid layout of 3/6/3 you get blocks going smoothly from 315px down to 155px (then back up to a bit over 700 pixels when it goes to a single column). With a 4/8 or 8/4 layout you get blocks of 400px smoothly down to 212 (then back up to 700-odd).

I think a combination of using the 4/8 layout, and losing some padding at the thinnest responsive setting might be enough to get by and remain vaguely faithful to the Bootstrap core. What do you think?

[thedannywahl]

I guess the question is do we NEED to use a "bootstrap-approved" layout using row+span or can we use container + responsive in a Moodle layout.

I have had success with that 2nd method: using the default moodle layout and writing media queries that use the bootstrap responsive breakpoints - giving us fixed width columns and a fluid main-content region.

[ds125v]

Well, bear in mind that by making the block columns fixed in width, you're just transferring the extra pixels into the central column. So you trade (sometimes) too small blocks for (sometimes) too wide content which can for example lead to people creating content on desktops that's too wide for tablets or netbooks. That's one of the reasons I like the 4/8 idea as it reduces the variation of both a little.

But mostly I'd try "the Bootstrap way" first as it's my experience that there are genuine benefits to sticking close to Bootstrap e.g. I filed a few bugs on the Bootswatches and after they fixed them I just had to copy a directory over. In previous iterations that would have involved hand-editing 10 files and running a script 10 times. And in versions before that it would have required painstakingly recreating many days of tricky work hand-porting the changes, and it would be so much work that doing it for more than one bootswatch would have been out of the question. I've found that the closer I stick to Bootstrap the faster and easier things have gone (and the same with Moodle core, to an extent, though generally Bootstrap wins if the two clash I have rolled back almost all the non-standard stuff I added when I was working on a theme for my own institution to be more like Moodle core).

For another relevant example, I managed to make a responsive version in about 5 minutes despite no previous experience with that kind of thing just by dropping a pre-created CSS file in place. In earlier drafts when I was using non Bootstrap layout that simply wouldn't have worked without a great deal of fiddling. Getting something mostly working from step 1 and then building from there is a pretty good motivator. Similarly, when the next version of Bootstrap comes out, I want to minimize the amount of time spent adapting to it. And various other elements built on the Bootstrap framework might expect certain conventions to hold, e.g. if people can take advantage of some 3rd party tool to create a Bootstrap.css file with their school colorscheme then I want them to be able to just drop it in place.

Obviously individual themes can build on this foundation and make more radical design decisions based on their intended usage and probably existing web designs that they're trying to fit in with, but I'm fairly happy for this github to be the boring core which people take as a prototype or parts-kit and build more exciting things from (hopefully returning with bug reports and fixes or even some of the more generally useful things they build along the way). And layouts and block sizes/locations are an area that have always allowed for fairly easy experimentation in Moodle so it's not an area where I think people will struggle.

Also related, one of the reasons my theme currently cycles randomly through variations by default is that you can trace a lot of the historical wrong-turns in Moodle presentation layer code to someone making it look okay in the default theme and considering the job done, even if that meant colors, positions etc. were hard-coded with font tags and br's. Multiply that by a hundred times and Moodle became very difficult to theme. Having a block that is always an exact pixel width is much easier in the short term, just as always having a white background is easier, right up till the point when you want it to be a different width, or color (e.g. the green and red asterisk icons are gifs created to blend into a white background so need to be redone now). Kind of like the difference between designing an app for Android's many form factors versus the small set of Apple ones.

[ds125v]

I've just implemented an internal .less compiler. This is relevant to this bug as a) I appear to have broken fluid responsive layouts, and b) I know a bit more about less variables than I did this morning and the behaviour of the grid layout can be controlled by setting less variables.

Do you think you could achieve what you're aiming for just by fiddling with the grid variables like @fluidGridColumnWidth found at the bottom of this file?

https://github.com/twitter/bootstrap/blob/master/less/variables.less

[thedannywahl]

"Well, bear in mind that by making the block columns fixed in width, you're just transferring the extra pixels into the central column. So you trade (sometimes) too small blocks for (sometimes) too wide content which can for example lead to people creating content on desktops that's too wide for tablets or netbooks."

Unless we use container which sets a max-width even on an HD screen

"Also related, one of the reasons my theme currently cycles randomly through variations by default is that you can trace a lot of the historical wrong-turns in Moodle presentation layer code to someone making it look okay in the default theme and considering the job done, even if that meant colors, positions etc. were hard-coded with font tags and br's. Multiply that by a hundred times and Moodle became very difficult to theme."

Couldn't agree more! The problem is that YUI is designed to be colors and fonts, etc... so we're just undoing a lot of stuff.

[ds125v]

Setting a max-width is something I've done for my current institution's theme, and it's been a bit of an issue with some parts of Moodle. It's possible that it's other stuff in my theme that's interfering with it, but I think a lot of stuff only really works with a certain minimum horizontal width and assumptions may have been made about what size of screen you have, whether your layout is fluid or not, how many columns you have visible etc. Though that's the exact opposite of the problem here, as in that case I've got fixed columns and a semi-fluid centre column inside a container with a max- (and min-) width set which leads to the center sometimes being too small for its content.

I've actually thought about using the responsive stuff to have an "full screen" button for those situations. So you can have the usability and look of a fixed-width theme but when people need the extra space they've got an escape hatch.

On the subject of YUI. The YUI CSS is actually split into 2 parts, a "reset" (which is fairly innocuous, though probably redundant with Bootstraps reset) and a styling part called "base". It seems that they expect people to only apply those styles to specific areas (i.e. the YUI popups and other such widgets) rather than blanket apply them to the whole site (unless it was an entirely YUI-based app). Instead you were supposed to add a .yui3-cssbase to the parent of anything you wanted to use the styles to limit the effects. I wonder how difficult it would be to retrofit that to Moodle?

http://yuilibrary.com/yui/docs/cssbase/#context