---
tags: website
---

# Call Ryan & Boris re CSS (27 May 2020)

- Firefox and Chrome printing engines - simple style sheets so that we can follow

- layout of the page vertically is just box, horizontally is flexbox
- acceptance testing: printing suite, boundaries? (browserstack: automate)
- ie9 + firefox print engine

> Design and layout conventions -
> What (semi) universal patterns should be adhered to? For instance, you’ve established simple spacing patterns with the mp-section blocks, and often limit element width to make room for the Contents column on the right side of the page. Are there specific contexts in which these (and others) need to be maintained (e.g. the Contents column should always be visible on the right on certain types of pages)? Note: If they’re too numerous to call out in the abstract, I can just submit or show you the pages, and we can discuss any issues as they come up.

Our things should look more like documents than brochures; our target audience needs for it to feel bureaucratic, not flashy.
How you structurre HTML is completely up to you, but it must be accessible ot other people to fix (for example for a typo).

Core: simple enough to be accessible to outsieder

layout: theme has its own space, site has its own space, page has its own space. Page space can be wildly customised (and easy to print, more portable).
In the page, create whatever you think is meaningful, responsively.

Not on marketing site, but on other sites: content on the right hand, contents changes place in print.

publiccode.net can look quite different from the rest of our websites

Built in sass compiler not used, because css is easier/more accessible (no sourcemaps requiried; let people use 'inspect element')

Ryan: no pre-processor usage?

CSS developed for our specific usage - we have highly structured contetn we want to use in different contextts

Sass - can be used to build complex things or streamline menial tasks

overarching priorities: lowest possible technical debt, greatest opoprtunity for others to contribute

B: no sass = not a hard requirement

> CSS structure and compilation - Do you have particular guidelines around things like non-minimized readability or code placement (e.g. absolutely no inline CSS; always be encapsulated in a single script tag per page)?

> Also, what’s your stance on SASS (or LESS)? I’ve been using SASS to write the code, which of course affects both source and output. If necessary, I can convert to standard CSS (though I’d be sad ;)

> CSS syntax and naming - Are there conventions you’re (strictly) following for attribute naming, definitions, or ordering? For instance, hyphenated attribute naming (which I noticed in your code, and replicated), or ordering style attributes before positioning, etc.

No system right now, but if you'd like to use one, pick one that is easy for pepole to edit. Bemn? Relatively predictable, but doesn't need to be standard everywhere.
In-line CSS is fine - set sensible higher level, and then overwrite at the lower level.

> CSS integration - I’ve generated 600+ lines of new CSS (for the homepage, codebase maturity index and details pages), a little bit of which collides with the existing site-wide and homepage-specific code. I can simply override or replace some of that, but don’t want to overly complicate what is currently pretty clean and low-inheritance code.
>
Do what you want, we'll fix it later

> JavaScript - I assume by default you are keeping JS to a minimum (which Elena echoed). I had two potential uses for it, but can do simpler versions of them with pure CSS, if you would prefer. The two uses are a tooltip system (with the future intent of pullling terms from a glossary), and a light box gallery (for codebase image examples).
>
Only if it's necessary; if it gives you an edge. If you need interactiveness, Javascript. HTML for content, CSS for design.
Simple animations: use CSS

Javascript complicates printing.
Rollovers complicate things signifiantly on mobile/keyboard only nav

Our snazziness requirements: less like the candy company, more like the planet.

> Code libraries and attribution - Any restrictions, and/or acceptable license types? Are we okay to use code not covered by license but which asks for attribution, and if so, are you okay with attribution comments mixed into code?
>
No restrictions. Won't buy anything. Ideally code is simple enough we don't need a lot of attribution.

> Browser compatibility - What’s the baseline for browser support? Do you prefer to expand support by including browser-specific prefixes even for attributes that are relatively standardized and prefixless these days? Are you trying to avoid newer/more experimental attributes (e.g. those that may rely on prefixes?)

> Code maintenance - Any particular practices or concerns about future rust or breakage?
>
Make it so simple it doesn't. blink tag? spinning email icons and rainbow balls?
evergreen design?

> Jekyll - I think I can see what needs to be done in terms of structure here, but any quick pointers you have (via email or on the call) would be helpful! :)

Procedural rather than rules and guidelines

WCAG2 or 3 as goal (assuming we're eventually publicly regulated)

trial by fire and constructive optimism