badlydrawnrob / print-first-css Goto Github PK

Without table-layout: fixed, you'd need to use <br> to wrap text. By default the width of the table contents will depend on the text length, too.

without fixed table

with fixed table

It's not exactly pretty, but just use css variables: badlydrawnrob/anki#38

https://blog.alexwendland.com/2018-11-20-npm-install-scripts-intro/ and https://snyk.io/blog/ten-npm-security-best-practices/ — dunno if this applies to repo installs.

• Using pre means total area no longer divisible by 4
• pre-line and pre-wrap work

Nested queries: IE11 does not support nested queries

Potential changes for accessibility:

Notes:

Do not change :focus styles! It’s an accessibility no-no: http://bit.ly/1T12z1S

Currently not sticking to the printable css philosophy in Anki Themes. Should print styles be considered and @media screen rules used?

• Possibly overkill (% chance I'd need this?)
• Can you even print from Anki?!
• A styleguide for an ePub-style document (print and screen)

See this thread

• Option 1: "quote: odd chars"
• Option 2: Use >- or |- characters

Perhaps using a <hr> with a .page-break class? (or no class at all)

• info here
• and here
• styling for ebooks

Needs a debate on which method to use, whether to blanket-force responsive images ... and so on.

• max-width: 100% on all images [using]
• center all images?
• responsive? resolution?
• Aspect ratios?

Should probably consolidate files a little better, or at least not have to keep resetting things where possible

• Normalise?
• @print?

Especially npm run build

Should I be concerned about basic forms or is this a job for each individual site?

• Check some healthy resets
• Leave it to the browser Gods

Within the #10 issue, how might I be able to write standard markdown, but style in a subtle, useful manner?

Decide

• Do I stick to basic styling in print-first-css (a blank canvas)
• Or set up some "academic" style defaults?
  • Or, use a child theme for this?

Examples:

• Link styling — could be useful for footnotes or references

• Goldilocks the --font-family-mono
• Use a set --font-family rather than the generic --ios/android font stack?
• Does the mono line-height need updating?
• Does it look the same on ios and android?
• See also this link and another explanation

Currently the --font-family-mono font is often too big, compared to the --font-family --font-size:

Default

--font-size-m

It's a bit of an in-betweeny font size.

Something to consider (especially for "child themes") — including:

1. Do not change :focus styles! http://bit.ly/1T12z1S
2. Hiding text and screenreaders
   • :before and pseudo elements

Hashes fail silently if they've been used but not declared — $this.hash.isnt.setup but is referenced, with no errors given

In Material Design (and original cardinal-stylus) I was using --font-tracking variables:

• letter-spacing: $font.tracking.pppp

Put back in?

If you had a script.txt file, you could split the command onto lines ...

some command^
 next command

Also, see using npm as a build tool (I think you can do something like "styleguide": "pandoc.txt" to pull a CLI script from a text file:

• Use a .sh file?
• Use a makefile?
• Fail if command doesn't exist?
• Styleguide (specimen) — with correct template and styles
  • Currently using Marked2 app
  • Table of contents?
• Security (see #25)

Got lost along the way (using package.json for tags)

Some changes to links:

• Force links to always be black with !important

Is it possible to add them as footnotes, instead of using [raw text] in brackets?

• Old article
• @page
• Use (or convert to) shortlinks instead?

Currently using npm version ... which is good, but requires manual pushing of tags (and you can't seem to commit and version at same time)

• Conventional commits
• Github releases

Are they secure? #25

The documentation on the README still needs some work:

• Improve writing styleguide (css, markdown, academic)
• REDUCE, Reduce, reduce (distill what you can)
• Make it visual
• Make it memorable
• Don't make me think!
• Styleguide
  • See #10 and #24
  • font-size / line-height combinations
  • This markdown.css is also kinda cool
  • A great example of documentation done well
• Accessibility in writing?
• Boxes and child themes (see below)

Sketch out the pros and cons, as well as the workflow options

Markdown is a simple formatting method, so it's probably best not to get too clever when writing and formatting ... but when adding HTML, current difficulties:

• Marked App seems to add empty paragraphs, causing broken layout
• Pandoc doesn't seem to suffer from this problem

Code example:

<div class="split"><div class="split-left">

- list
- of
-stuff

</div><div class="split-right">

Content

</div></div>

Need to decide whether it's best to:

1. Use Markdown for full pages (with HTML inside file)
2. Use Markdown for partials (and a templating language)
3. Use Markdown with frontmatter
4. Use javascript to style some elements (the introduction, for instance)

HTML inside Markdown is easy(ish) to compile, and if done right can provide some flexibility (such as figcaption etc) — but feels a bit hacky, somehow.

Perhaps there's a balance between building a structure and using markdown files, within that structure.

Possibly best to avoid them ... see this thread

Perhaps a side-note on @font-face and customising your fonts?

• Font stacks
• Embed fonts

• Remove $grid hashes?
• Remove dependencies (original Cardinal Stylus)
• Remove buttons?

Just-in-time and revise as-you-go — easy to understand for beginners and just enough for serious writing. Do the next right thing.

• A refresher on quasi-academic writing. See also source/ecss/specimen.md

Decide a general tone, style (academic? head first) as a standard default. This can always be extended or updated for child themes.

See also:

• #13 images, #20 page breaks
• #18 Adding html, #17 using markdown

Inspiration

1. Going to print
2. Designing for print
3. Economist style guide
4. Gov.uk styleguide

Must be

1. Easy to understand and reckon with (the stupid version of future me)
2. Must be easy to write in Markdown (including extra html markup)
3. Must work in any version of Markdown (Stick with CommonMark)
4. Easy to extend (for specific needs)
5. Looks pretty

Basics

• ins, and del vs s?
• Semicolons, colons, dashes
• Maths and symbols (not <code>)
• Tone and voice
• abbr usage
• When to use bold to highlight terms?
  • Does it detract from the text or not?
• When to use italic to highlight terms (or places, authors, titles)
• To use or not to use <i>, and <b> for visual styling?

Ordering

• Create a generic page similar to this
• I find it easier to scan when h2 are each on their own page
  • Or, style so it's a column layout (or depending on child theme)
• Set order of elements, when/where to use (headers especially can look awkward in some situations)
• Better figure and figcaption defaults
• Guides for highlight words (see data-analysis notes)
• Images styleguide (rough guide on sizes, dimensions, so on)

Tables, instructions, lists

See here and here

• Tables with and without headers (what are the semantics)
  • Section headers?
  • Real headers?
  • Style table headers?
  • Or, use a data list (dl) if there's no need for column / row headers?
  • Longer content, other content

Code examples, references, images

• How to structure internal/external links?
  • Ease of reading, less distraction, yet Brutalist.
• pre inside figure (with figcaption)
  • linking to a figure (and format, i.e. fig. 1 fig.1 — description
  • figure plus quote
  • figure + figure or figure > img + img (what happens when more than 1?)
• pre + pre (multiple stacked code blocks, quite useful, in css already)
• code inside other elements? h1, blockquote, etc
  • Or, make a note never to use within elements whose font is bigger (easier)
• Table of contents for longer articles
  • e.g: Real python, HTDP, Ben Frain
• Reliable (MD compiler agnostic) footnotes or references (see Economist style guide)