No support for "dnom" and "numr"

[quitequinn]

I think it would make sense to add these in..

[quitequinn]

Adding these breaks the test...

 1) should not break perf budget

I'm not well versed in testing... and would love to chat about it and your approach to compiling sometime

[kennethormandy]

Thanks so much for the PR!

So basically the performance budget is so I don’t go overboard with adding every OpenType feature class to this module—or, at least, it’s not in the core. In this case, the test just checks if the module is within 1.75kb gzipped so that I ensure I am writing concise CSS.

Could of concerns with this, it looks like that the .sinf class just got copied in a couple of times? I assume that was just a copy paste error.

Also, the .sinf class might not be the best one to base .dnom and .numr on, since the main stuff is actually coming from this. I added comments:

.subs,
.sinf {
   /* If it doesn’t support `font-variant` */
  @supports not (font-variant-position: sub) {
    font-feature-settings: "subs"; /* …use `font-feature-settings` */
    @supports (font-feature-settings: "subs") { /* If it does support that…*/
      font-size: 1em; /* Override the browser defaults for `<sub>` and `<sup>` */
      vertical-align: baseline;
    }
    /* Since Safari lies and says it supports `font-feature-settings`, fix fallback subscript */
    @supports (overflow: -webkit-marquee) and (justify-content: inherit) {
      vertical-align: sub; /* Restore the browser default for `<sub>` and `<sup>` */
      font-size: smaller;
    }
  }
  /* Hopefully none of that is applicable, and we just use `font-variant` */
  font-size: inherit;
  font-variant-position: sub;
}

Does that kind of make sense? I might need to write up a contributing guide that explains that more in depth.

[quitequinn]

Oops thanks for that.. missed the sinfs..
I'll make a revision... I hope it helps.

[quitequinn]

I couldn't find a font-variant for dnom or numr... so i think the new revision is the only solution.

[quitequinn]

I'm not setting

font-size: 1em; /* Override the browser defaults for `<sub>` and `<sup>`  ...etc*/

because the class doesn't have to be used with tags. ACTUALLY I would suggest you remove that from the prior examples because it is creating conflicts with the current font-size in my case.

[kennethormandy]

Okay, thanks. If you delete the .sinf duplicates and push it to this branch, I will take a look at merging the other stuff.

Can you elabourate or open a separate issue for the 1em thing? Thanks!

[quitequinn]

right!.. working on an example and confirming faked dnom and numr.

in the case of 1em for subs and sinf:
If the intention is to override <sub> and <sup> then I would prefer the 1em targeting only those tags. In this case the 1em is conflicting my div that has .sinf and forcing it to be smaller than the rest. (ex. because the less specific definition is to set it at 2em)

[quitequinn]

Another thing that might be worth considering is finding a solution for removing lineheight changes for the false fallbacks.

In the meantime line-hight: 0; works

[quitequinn]

I think I've set the fake heights appropriately.. but its difficult to say I have a agreed upon solution for the .numr—since I can't find a good definition online.

Type design aside—the numr is dependent on the placement of the dnom.. and the highest we can set it is v-align super... so unless we want to adding in top or some other sort of placement thats the best we can do.

https://jsfiddle.net/w9jtrvtn/1/

[kennethormandy]

Hey thanks for taking time to revise that. I iterated on that and I think this should work, which should be the same result as what you had, but should compile a bit smaller:

.sinf,
.dnom,
.numr {
  @supports (font-feature-settings: "sinf"), (font-feature-settings: "dnom"), (font-feature-settings: "numr") {
    font-variant-position: normal;
    vertical-align: baseline;
  }
  /* Since Safari lies and says it supports `font-feature-settings`, fix fallback subscript */
  @supports (overflow: -webkit-marquee) and (justify-content: inherit) {
    vertical-align: sub;
    font-size: smaller;
  }
}

.sinf {
  font-feature-settings: "sinf";
}

.dnom {
  font-feature-settings: "dnom" 1;
}

.numr {
  font-feature-settings: "numr" 1;
}

…unfortunately, that is causing me problems with Sass now, because they still have a bug parsing comma-separated queries or something. I will have to take a look at that.

That said, I took a closer look at the OpenType spec and it has this part:

UI suggestion: This feature should normally be called by an application when the user applies the frac feature.

Source (I’m sure you checked that too, just trying to understand it better.)

In this library, the CSS classes are the UI / API. So I’m wondering if .frac is sufficient? I’m thinking that’s probably why there isn’t a font-variant-* property for numr or dnom. Do you have a usecase where .frac won’t work?

[quitequinn]

I think there is a use case...

Not to get too creative but showing the dnom in a type specimen is a simple enough case. Alternatively I could see people using a series of dnom or numr to style math equations.

[quitequinn]

Plus I think frac only supports a very limited amount of combinations, dnom and numr are there for when frac falls short