Provide base stylesheet with responsive defaults

[iangreenleaf]

We want to provide a base stylesheet that provides reasonable defaults that stylesheet authors may use to get them started. In general, it should aim to be unopinionated, as far as that's possible while still being useful. We already have something along these lines but we need to:

1. Add whatever basic responsive stuff we can so that stylesheets using this starter will achieve a decent amount of responsiveness without the authors taking a lot of steps themselves
2. Make sure we have the right documentation so people know that this sheet exists and how to use it.

[mrwweb]

Some initial thoughts to get things rolling:

1. There should be no IDs used in the base stylesheets if at all possible. If not, limit them. Ideally, each selector is a single class or element selector. Keep priorities low in base sheets.
2. I think we should consider providing a few different base stylesheets that people can selectively @import() into their own sheets. (If/when Plans moves to HTTP/2, the impact of the multiple requests will be negligible.) We could then provide separate sheets that authors can choose to include for:
   • Reset/Normalize (I vote normalize)
   • One or more standard layouts probably pulled from @baldwint's work. Each would be a different sheet so author could include 1 or 0 of these. These could include left, right, and top navigation patterns. More than one layout sheet might be overkill, but I think it should remain separate no matter what.
   • Standard layout styles for notes, secrets, info messages, etc.
   • Some more opinionated "nice" styles for progress bar, form styles (maybe include formalize.css?), etc. Another example: I add brackets around all usernames and planlove links with :before and :after pseudo-elements and it requires about 4 selectors to catch all the places usernames appear.
3. Besides these base sheets, I think it would be totally Next Level(TM) to provide a style-less sheet with commented selectors we know work (see selector priorities point above) to speed up custom stylesheet writing.
4. I'd put the documentation directly on Preferences > Styles, divided into two sections. The first would explain what Custom Styles are, how to use them, and where to find them. The second would be for developers.

[iangreenleaf]

@mrwweb I totally agree with most of that.

Regarding (2), I agree that we should have at least a couple different options, a base level that is a no-brainer to include, and something else that includes a basic layout (I imagine the majority of stylesheets would benefit from something like @baldwint's modern.css, which provides the standard left sidebar, footer, etc). My thinking on CSS customization in general is that we should move away from the "customize everything!" approach towards an implicit contract that stylesheets will modify the broad page layout and of course any of the stylistic stuff, but the smaller page components will be defined more like OOCSS modules and custom stylesheets will mess with the layout of those at their own risk. So following that philosophy, the base stylesheet probably ought to contain a bunch of stuff like progress bar and form styles.

Here's another question I don't know the answer to: if our base stylesheet doesn't provide layout hints (like floating the sidebar), can it still offer sane responsive defaults that will work for everyone? Or are those two things linked too strongly to be separated?

[mrwweb]

majority of stylesheets would benefit from something like @baldwint's modern.css, which provides the standard left sidebar, footer, etc

I think that makes sense for the layout sheet that people can optionally include.

the smaller page components will be defined more like OOCSS modules and custom stylesheets will mess with the layout of those at their own risk

I think that can work. And if that's the case, I think loading it directly in the head and not making it optional might make sense. If those styles are light on CSS specificity, overriding won't be much of a problem. (This is another reason to avoid IDs, then stylesheet authors could use them instead of something like !important or the double-class hack.)

if our base stylesheet doesn't provide layout hints (like floating the sidebar), can it still offer sane responsive defaults that will work for everyone?

A plain HTML page is responsive, so CSS mostly just breaks responsiveness. The only "sane-default" I can really think of that might be worth including would be a max-width on the body/wrapper, but even that is specific to font-size and layout. The other issue is a mobile menu which I'm going to put in a separate ticket right now.

[iangreenleaf]

the smaller page components will be defined more like OOCSS modules and custom stylesheets will mess with the layout of those at their own risk

I think that can work. And if that's the case, I think loading it directly in the head and not making it optional might make sense. If those styles are light on CSS specificity, overriding won't be much of a problem. (This is another reason to avoid IDs, then stylesheet authors could use them instead of something like !important or the double-class hack.)

Good point, I had contemplated that option earlier and moved away from it, but now you're making me think again that it might be the way to go. We can definitely keep those things low on specificity, and overriding sends the right implicit message of "go ahead, but now this is tightly coupled and you're responsible for keeping up with changes".

A plain HTML page is responsive, so CSS mostly just breaks responsiveness. The only "sane-default" I can really think of that might be worth including would be a max-width on the body/wrapper, but even that is specific to font-size and layout. The other issue is a mobile menu which I'm going to put in a separate ticket right now.

Huh, I'd never thought of it that simply, but you're right, I tried disabling CSS and the small screen does pretty okay with that.

So I guess we should focus more on a modern.css-type of sheet with appropriate fallbacks, and not offer anything in the base sheet.