typography not-font field updates

[cscheid]

Should we move all color declarations to color? It feels weird for base to allow color definitions when we have foreground.

I understand why background is technically there, but are there any good-looking themes out there that have different background colors for type and for the page itself?

I think monospace and headings color definitions also feel off.

[gadenbuie]

Yeah, I 100% agree that there's complete overlap in topography.base with color.foreground and color.background. I'm on board with dropping these.

I do think typography.monospace has the strongest argument for both color and background-color -- both are things people tend to have an opinion about. I included both properties for consistency, but I'd be okay with dropping background-color for everything but typography.monospace. On the other hand, I do think color is a reasonable property to include outside of typography.base.

Edit: it's typography.monospace in the spec rather than typography.code.

[cscheid]

Conclusion from discussion today:

• No support for typography configuration for strong, emphasis (or bold and italic) in v1
  • fonts still have weights+styles, ofc, this is just for the things that would end up as selectors against strong and emphasis in HTML.
• Support for monospace-inline and monospace-block entries (which inherit from monospace if it exists)
• Support for link, same reasons as monospace-inline

[gadenbuie]

Quick sketch of the updated schema.

- id: brand-typography
  description: Typography definitions for the brand.
  object:
    closed: true
    properties:
      fonts:
        description: Font files and definitions for the brand.
        arrayOf:
          ref: brand-font
      base:
        description: >
          The base font settings for the brand. These are used as the default for
          all text.
        ref: brand-typography-options
      headings:
        description: >
          The font settings for headings.
        ref: brand-typography-options-no-size
      monospace:
        description: >
          The font settings for monospace text
        ref: brand-typography-options-text # family, size, weight, style
      monospace-inline:
        description: Inline code, all values inherit from `monospace`.
        ref: brand-typography-options-inline # family, size, weight, style, color, background-color
      monospace-block:
        description: Block code, all values inherit from `monospace`.
        ref: brand-typography-options-block # family, size, weight, style, line-height, color, background-color
      link:
        description: The text properties used for hyperlinks.
        object:
          closed: true
          properties:
            weight:
              ref: brand-font-weight
            decoration: string
            color:
              ref: brand-maybe-named-color
            background-color:
              ref: brand-maybe-named-color

[gadenbuie]

Summarizing from slack, the brand-typography-options were original designed as a consistent set of options across all of the sub-fields of typography.

But some options don't make much sense in practice and represent a maintenance burden. We also have reduced the value of consistent properties by introducing monospace-{block,inline} where the set of options is non-uniform.

I'm proposing we:

1. Drop style everywhere except for headings. It's generally not relevant in any other context.
2. Drop background-color from base and headings.

Here's a sketch of the _brand.yml structure after this change:

typography:
  base:
    family:
    weight:
    size:
    line-height:
    color:
  headings:
    family:
    weight:
    style:
    line-height:
    color:
  monospace:
    family:
    weight:
    size:
  monospace-inline:
    family:
    weight:
    size:
    color:
    background-color:
  monospace-block:
    family:
    weight:
    size:
    line-height:
    color:
    background-color:
  link:
    weight:
    decoration:
    color:
    background-color:

[gadenbuie]

Quarto will have SCSS and theming support for code line-height. It'd be great if bslib supported the same names.

Originally posted by @cscheid in #15 (comment)

[gadenbuie]

From @gordonwoodhull's table of Typst support of these fields