-
Notifications
You must be signed in to change notification settings - Fork 14
Important Docs
Dethe Elza edited this page Jan 13, 2019
·
3 revisions
We use Handlebars for templating, PostgreSQL for data, and Node/Express for our back-end. We are moving away from frameworks, builders, compilers, minifiers, as much as reasonably possible.
- Handlebars Docs
- PostgreSQL 9.6
- Doc search superpower:
mdn.io/[your search terms here
will jump to the (usually) relevant Mozilla Developer Network page. Behind the scenes it does a Google search of MDN and then loads the first result.
Potentially helpful for developing the editing components. None of this is set in stone, but good to have a shared basis for discussion.
- Native form elements Where we want to start from, and rely on as closely as we can.
- Styling file upload inputs
- ProseMirror looks like a good tool for the requirements of our rich text edit widget. Specifically, it can be extended to support footnotes/endnotes. Open questions include how it saves documents and how it will interact with our existing documents.
- Customizing radio buttons without compromising accessibility
- Awesomeplete Autocomplete widget, may or may not be able to do what we need as far as multi-select, ordering. Worth a look.
- HTML5 Validator
- CSS Validator
- Bliss If you find yourself missing jQuery, have a look at Bliss.
- Prefix-free Rather than burdening our stylesheets with every possible CSS prefix, this small JS file dynamically rewrites CSS to only include needed prefixes.
- Coding Colors Easily Using CSS3 hsl() Notation
- HTML5 Security Cheatsheet How to avoid leaking users' personal information
- HTML5 Peeks, Pokes, and Pointers
- Microformats Microformats can be great for semantically marking up data that has no specific tag or is more complex than one tag: people, events, etc.
-
HEAD A list of everything that can go in the
<head>
of a page
For day-to-day work, looking at what is returned by adding ?returns=json
to a URL is probably good enough, but it there are questions about what is actually specified vs. what is implemented, the core data design docs are here:
More detail about our development goals:
- Progressive Enhancement
- You Might Not Need JavaScript
- HTML APIs: What They Are And How To Design A Good One
- URL Design Ironically this is an archive.org link because the original URL is broken.
- What Screens Want Long, but good
- Everything Easy is Hard Again Also long, also good, sums up what we're trying to achieve with this refactor.
- Coding sites with your bare hands
Fun:
Stop all the things:
- Stop using LocalStorage
- Stop using Grunt
- Stop using device breakpoints
- Stop writing code Includes a really good bit about "don't use ARIA" if you scroll down.
- Don't use ARIA It really is the first rule of ARIA, but in the Authoring Guidelines, not specificially the spec.
- Stop using git Video