- From: WebMechanic via GitHub <sysbot+gh@w3.org>
- Date: Sat, 25 Jan 2020 19:55:47 +0000
- To: public-css-archive@w3.org
came here via https://github.com/w3c/csswg-drafts/issues/2764#ref-issue-365585720
so.. bump!
The above problem could be fixed if the _bolder_ and _lighter_ keywords would actually do what their name suggests; **at least for variable fonts.** No need for keyword handling in calc() then.
Maybe some variation of `current()` or `inherited()` could do the trick if nesting functions in `calc()` is supposedly easier. But that's a different story to than using an unknown variable set of bolder/lighter fonts.
_Variable Fonts are a thing now!_
Unfortunately neither "bolder" nor "lighter" move to the next **weight variation** within a _variable font_, but act binary as "bold" or "un-bold" aka "normal". That was fine when most ordinary fonts typically featured a binary state for normal/bold as well.
Also going bolder or lighter (font wise) within nested elements does not imply moving in steps of 100 _only_. A variable font could contain just three presets for its the "wght" axis using 200, 400, 600 or any other set of arbitrary numbers between 1 and 1000.
The same is true for an equivalent set of carefully crafted `@font-face` declarations using classic single font files.
With a fallback list of different variable fonts such as `font-family: "Bahnschrift", "League Spartan Variable", "Source Sans Pro"` one could build a working ramp of the _proper_ font-weights of such fonts whilst being ignorant about what "wght" values actually exist.
_Using "bolder" or "lighter" could (should) **continiously select** the next available weight variation._
Here each letter of the words "Fonts" and "Mood" is a set of nested `<b>` elements that might progressively get `bolder` from whatever weight `<p>` currently has set and eventually reaches whatever weight ("wght") the font's upper limit would be.
```css
b {font-weight:bolder} /* life could be easy ... */
```
```html
<!-- crudo ma bello -->
<p>Variable <b>F<b>o<b>n<b>t<b>s</b></b></b></b></b> R <strong>côôl</strong></p>
<p>G<b>o<b>o<b>o<b>o<b>o<b>d</b> Morning</b></b></b></b></b></p>
```
Although the markup is ugly, the CSS remains fairly simple and _intuitive_.
Today I can do the same thing but with much more effort and have to use an explicit amount of nested B selectors - unlike the oneliner above. I also need to keep the ramp values at a specific start/end point or the result could look choppy when used in a possibly different context.
If `<p>` happens to be set elsewhere to the usual `normal` (400), the effect would not look as intended.
```css
/* ... but it's not ... */
p {font: 200 2rem/1 "League Spartan","Bahnschrift","Source Sans Pro",sans-serif;}
p > b { font-weight: 300 }
p > b > b { font-weight: 400 }
p > b > b > b { font-weight: 500 }
p > b > b > b > b { font-weight: 600 }
p > b > b > b > b > b { font-weight: 700 }
p > b > b > b > b > b > b, strong { font-weight: 800 }
```
Using CSS properties the CSS can become simpler ...
```CSS
p {--w:1 }
p b { font-weight: calc(var(--w) * 200) }
```
but the HTML gets even worse:
```html
<p>G<b style="--w:1">o<b style="--w:2">o<b style="--w:3">o<b style="--w:4">o<b style="--w:5">d</b> Morning!</b></b></b></b></p>
```
Cheers.
--
GitHub Notification of comment by WebMechanic
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2764#issuecomment-578437836 using your GitHub account
Received on Saturday, 25 January 2020 19:55:49 UTC