[css-fonts] Specifying a direction without a specific angle

[frivoal]

(this is a follow up from #8914 (comment))

While we have the ability to specify a precise angle of oblique fonts (thanks to font-style: normal | italic | oblique <angle [-90deg,90deg]>?), we don't seem to have a system to specify left vs right leaning italic or oblique fonts, which are desirable for i18n reasons (see w3c/afrlreq#17).

How about something like this:

• Expand the font-style descriptor in font-face letting you know if a (non-variable) oblique or italics font face is left or right leaning.
  Maybe: font-style: auto | normal | italic [left | right]? | oblique [left | right | <angle>{1,2}]?

  When you don't specify left nor right (on a non variable font), the ua should probably generally assume right, unless the font technology has some built in indicator.

• Expand the font-style property to let authors ask for a particular slant direction:
  Maybe: font-style: normal | italic [left | right]? | oblique [left | right | <angle>]?

  Then, if you've got italics (or oblique), but they're leaning the opposite way of what was requested, you don't use the provided font-face, and synthesize instead (if font-synthesis allows).

[Crissov]

It feels like it should also be possible to request an oblique font that is slanted forward or backward with respect to the inline progression, not just statically left or right.

I’m not sure this is already covered sufficiently as well: When specifying a -5deg slant angle, authors would probably prefer the –20° font be chosen over the +5° one, although the latter is numerically closer.

[svgeesus]

It feels like it should also be possible to request an oblique font that is slanted forward or backward with respect to the inline progression, not just statically left or right.

In addition, or instead? Looking at the RTL examples from @r12a it does seem that left or right would be more useful as expectations differ depending on writing system.

I’m not sure this is already covered sufficiently as well: When specifying a -5deg slant angle, authors would probably prefer the –20° font be chosen over the +5° one, although the latter is numerically closer.

Yes, the need to match in the desired direction (rather than to the closest, which might slope the opposite way) was discussed last week at TPAC and I proposed a change to the spec to say so.

[astearns]

Yes, the need to match in the desired direction (rather than to the closest, which might slope the opposite way) was discussed last week at TPAC and I proposed a change to the spec to say so.

In that discussion Myles reminded us the spec already does this. Do you think the spec still needs changes for this particular bit?

[svgeesus]

I guess I also wanted to make it clearer up-front. But yes, once you drill down into the details, we have (for greater than or equal to 0deg and less than 11deg)

3. Otherwise, oblique values above the desired oblique value are checked in ascending order followed by oblique values below the desired oblique value, until 0 is hit. Only positive values of oblique values are checked in this stage

and then (for greater than or equal to 0deg and less than 11deg,)

3. Otherwise, oblique values below the desired oblique value are checked in descending order until 0 is hit, followed by oblique values above the desired oblique value. Only positive values of oblique values are checked in this stage.

and then

less than 0deg and greater than -11deg, follow the steps above, except with the negated values and opposite directions. If the value of font-style is oblique and the requested angle is less than or equal to -11deg, follow the steps above, except with the negated values and opposite directions.

So yes, I agree with @litherum that the spec covers this case, with a bit of discovery effort. I would like it to be clearer up-front.

[frivoal]

As far as I can tell, the last two comments above (and the second half of the 2 comments before that) are a side discussion, rather than a direct response to what is proposed in the opening comment. Right? If so, I suggest opening a separate issue to discuss that (even if it's editorial), and leaving this one for its original purpose.

[svgeesus]

@frivoal could you expand your proposal to take into account the suggestion from @Crissov to allow logical as well as physical directions?

[astearns]

Please re-add agenda+ once the response to @Crissov is ready, @frivoal