[css-fonts] It should be possible to slant glyphs to the left for italics/oblique

[r12a]

Some right-to-left writing systems italicise by sloping the letters to the left (ie. in the reading direction).

Here is an example from the N'Ko Kigelia font. The creators of the Kigelia font conducted research with the users and standardisation body for the N'Ko script what their preference was, and this was the user's preference for the default styling of N'Ko italics.

Some Hebrew authors also prefer to slope in the direction of reading, although this tends to be author preference.

The following is a photo of an Arabic newspaper letterhead. See the oblique text in the middle line.

The CSS font-synthesis properties don't provide any mechanism to indicate the direction of lean. Could we please add something to support these international users.

[This gap is being tracked at https://github.com/w3c/afrlreq/issues/17]

[svgeesus]

From Font style: the font-style property:

oblique <angle [-90deg,90deg]>? Controls matching against an oblique face. Positive angles represent a clockwise slant; negative angles represent a counter-clockwise slant. The lack of an <angle> represents 14deg. (Note that a font might internally provide its own mapping for "oblique", but the mapping within the font is disregarded.) Fractional and negative values are accepted; however, values less than -90deg or values greater than 90deg are invalid. If no oblique faces exist, and font-synthesis-style has the value auto, a synthetic oblique face will be generated.

So, this is already explicitly possible: set font-style to the desired value, such as -14deg and set font-synthesis-style to auto.

[r12a]

Thanks for helping me find this, @svgeesus ! That's great.

Fwiw, i wrote a test - see https://github.com/w3c/character_phrase_tests/issues/56

Gecko appears to support negative oblique, but Blink and WebKit don't. I'll close this and raise bugs for the latter two.

[r12a]

There is a fly in this ointment that i think may be worth noting. I created another test that included N'Ko but also Arabic, Hebrew, and Ukrainian. It turns out that if there is a font with an italic face, the oblique value gives way to that font, which is, if i read it correctly, what the spec expects.

https://github.com/w3c/glyph_character_tests/issues/10

No font-family styling is set in the test page, so the result will be a little unpredictable because it relies on fallback fonts. In my case, the result is:

There is no italic font for N'Ko, so the oblique styling applies, the default Arabic font set by me in my browser also has no italic correspondence, so same result. For Hebrew and Ukrainian, the text does get rendered by fallback fonts which have italic versions. Consequently, the left-leaning oblique setting is not applied, and the italic font face is applied - however, these fonts lean to the right. Also note that the italic font uses very different shapes for some letters than the regular font in cyrillic.

CSS seems to currently be assuming that oblique and italics are the same thing, but i'm not sure that that always holds. This is shown clearly here, where the current mechanism spoils the attempt to have a left-leaning slant. It may also be that authors want to slant regular glyphs rather than introduce the quite different glyph shapes associated with 'italicisation' in cyrillic, or they may want to use the italic font face, but slant it to the left(?).

It seems to me that you can turn off oblique synthesis using font-synthesis-style: none, but i wonder whether there should be another value, perhaps synthesise, that prevents the automatic default to a random italic font, and allows the author to slant an existing font face, even an italic one, in the opposite direction??

[r12a]

I forgot to mention that if you set the text to italic using font-style:italic that also knocks out the left-leaning, even if no italic font exists.

[frivoal]

After talking with the i18n group on a teleconf about this, I think we have few sub-issues here. Quite possibly they should all be filed as separate things, but since they stem from this discussion, here they are, to get started.

• when asking for oblique specifically, falling back to italics is not a good idea. The paragraph that defines oblique seems in agreement with that, but the paragraph after that muddles the issue, and picks “a font to use which is closest to the requested angle” seemingly without regard for italics vs oblique. Going from oblique to italics is probably not intended, but that should be clarified.

• “a font to use which is closest to the requested angle” may not be fine if the closest one doesn't have the same sign. Let's say you're asking for -12deg, and there's +10deg and +20deg. Clearly, +20deg is not what you want, but there's a fair chance that the direction of the slant matters more than the exact angle, and that you'd rather have synthetic -12deg rather than +10deg. For italics that might be debatable (correct letter-shape might matter more than correct direction, though maybe not), but for oblique it's pretty clear that you'd want the right direction, even if that means synthesis.

• font-synthesis-style(“controls whether user agents are allowed to synthesize oblique font faces when a font family lacks oblique faces.”) having only a choice of auto | none where none means “Synthesis of oblique faces is not allowed”. Seems not quite right, or at least insufficient. Turning off synthesis of oblique faces when italics is requested seems like the right thing to do, but as written, it also turns off synthesis of oblique faces when oblique is requested. Unlike italics, oblique is easy to synthesize. So, we might want a separate control to turn off synthetic oblique when oblique is requested (or we might not), but the may control that turns off oblique when italics is requested should not also turn off synthetic oblique when oblique is requested.

• We don't seem to have a general system that deals with left leaning italics or obliques. I suspect we might want something like:

  1. a 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.
  2. a property asking for one direction or the other 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).

[xfq]

In vertical writing mode, the glyphs may not be slanted to the left or right, but to the inline direction, but we can understand it as slanting the glyphs to a certain physical direction in horizontal writing mode, and then rotate the text 90 degrees clockwise, so I I think it's probably ok to use physical keywords here.

[himorin]

In vertical writing mode, the glyphs may not be slanted to the left or right, but to the inline direction, but we can understand it as slanting the glyphs to a certain physical direction in horizontal writing mode, and then rotate the text 90 degrees clockwise,

we may need to recall #2983 and #2869 on this point? for above cases, we may consider these as a part of normal italic with taking rightmost vertical line of character frame as baseline, although...

so I I think it's probably ok to use physical keywords here.

How about cases like applying italic over mixing N'Ko string with latin or cyrillic? I'm not familiar with N'Ko italics, but if inserted latin or cyrillic are leaning to right, we could want to have some dir (rtl/ltr) based value?

[svgeesus]

a font to use which is closest to the requested angle

Perhaps we should clarify that like this

a font to use which is closest to the requested angle and of the correct sign

[css-meeting-bot]

The CSS Working Group just discussed [css-fonts] It should be possible to slant glyphs to the left for italics/oblique, and agreed to the following:

• RESOLVED; *if* a browser does synthesis of oblique, there SHOULD be at least one synthesized font in each direction

The full IRC log of that discussion

<TabAtkins> addison: This is an observation from gap analysis, maybe let Richard intro this
<chris> q+
<TabAtkins> r12a: I think florian expanded the qs and info significantly. I'll do a brief intro then pass it.
<chris> q-
<r12a> https://github.com/w3c/csswg-drafts/issues/8914#issuecomment-1649678597
<chris> q+ florian
<chris> q+
<TabAtkins> r12a: If you follow that link, you'll see a picture which'll help follow
<TabAtkins> r12a: there are orthographies aroudn the world where if you italicize, in some cases, or definitly oblique text, it doesn't lean to the right it leans to the left - generally the reading direction of that script
<TabAtkins> r12a: the way the spec addresses this is problematic atm
<TabAtkins> r12a: if there's an italic font available, the browsers tend to switch to that automatically
<TabAtkins> r12a: But the italics available don't necessarilly lean to the left, they'll usually lean ot the right
<TabAtkins> r12a: So if this font is substituted you don't get what you expect
<addison> (btw, I18N+CSS meeting calendar entry: https://www.w3.org/events/meetings/d737b1d9-bb00-4b14-9507-0338465ee8ed/20230926T220000/)
<TabAtkins> r12a: So it seems we need to separate more clearly the separation between italic and oblique, and allow you to insist on oblique
<myles> q+
<TabAtkins> r12a: italicization isn't the same as oblique anyway
<TabAtkins> r12a: in a script like cyrillic the letterforms are very different
<TabAtkins> r12a: so that's another reason not to munge together italics and oblique
<florian> https://github.com/w3c/csswg-drafts/issues/8914#issuecomment-1651137267
<chris> ack florian
<TabAtkins> florian: for full details of what i'll be talking about, this is the original comment
<TabAtkins> florian: a few points to make fixes in the spec
<TabAtkins> florian: overall it seems the spec is trying to say that falling from italic to oblique is a thing but the reverse isn't, which is reasonable
<TabAtkins> florian: but ambiguous
<TabAtkins> florian: there are some places taht seem to suggest they're talking about falling back from oblique to italic, we shoudl clarify
<TabAtkins> florian: Also there's some bit that takes the closest available angle, it should take sign into account
<TabAtkins> florian: Choosing the wrong direction because it's a clsoer angle seems bad
<TabAtkins> florian: Also synthesizing italics is problematic. If you synthesize, you generate oblique for it
<TabAtkins> florian: We have a control to say *no* synthesis
<TabAtkins> florian: But the way this is written, it suggests tha tif you turn it off, it'll turn off *oblique* synthesis as well.
<TabAtkins> florian: And that's bad. Oblique synthesis is easy and reasonable - real oblique can be slightly better but it's very close, unlike synthetic italic.
<astearns> thinks these should be separate issues, going forward
<drott> q+
<TabAtkins> florian: So ahving the same control turn off both italic and oblique synthesis seems bad.
<chris> q?
<TabAtkins> florian: So I think we need to at least not disable oblique synthesis when turning off italic synthesis.
<TabAtkins> florian: And *maybe* we need a way to control oblique synthesis, unsure that's needed.
<TabAtkins> florian: Anothe rissue, a variable font can have a numeric axis for oblique
<TabAtkins> florian: But for non-variable fonts we don't know the lean direction
<TabAtkins> florian: Might be useful to have in @font-face a way to indicate the lean direction
<TabAtkins> florian: So browsers can know what it has and give the right one
<TabAtkins> florian: If we want to give authors this choice, we need to give that info to browsers.
<astearns> ack chris
<TabAtkins> astearns: This is a great list of issues; after this meeting we shoudl split these up
<TabAtkins> chris: some of this wording about italic and oblique dates back to css1
<TabAtkins> chris: it's trying desperately to ensure it's different from normal text, no thought about i18n or good typography
<TabAtkins> chris: So I think some of that wording can just be backed off
<TabAtkins> chris: For closest angle, I think has an easy fix; find the closest angle of the desired lean direction.
<TabAtkins> astearns: fantasai suggests we resolve on that
<fantasai> scribe+
<fantasai> TabAtkins: Should we still pick the wrong direction if you only have one direction?
<TabAtkins> drott: We already ahve italic-left vs right control tho
<TabAtkins> chris: For varaible fonts, yes. This is for non-variable
<TabAtkins> myles: Chris talked about users pref
<TabAtkins> myles: Does the angle actually have semantic meaning?
<TabAtkins> myles: If we pick the wrong angle, does that change the semantic meaning of the text, or does it just look ugly?
<drott> We have control `oblique n deg` which can be positive or negative.
<TabAtkins> chris: I think it's actually *wrong*, not just ugly
<TabAtkins> chris: If some text leans left and suddenly some leans right it just looks horrible
<TabAtkins> myles: Do these langs have a concept of italics historically?
<TabAtkins> r12a: Two african scripts in recent use, didn't have italics until font designers started working with them
<drott> For italic font-style, we don't have a way to express which direction it should go.
<TabAtkins> r12a: They asked the speakers what direction it should lean, and they clearly said it should lean left
<TabAtkins> r12a: n'ko [i think i got the name right]
<TabAtkins> r12a: For hebrew and some extent arabic, it's a personal choice
<TabAtkins> r12a: Some people prefer left, some prefer right
<drott> q?
<TabAtkins> myles: So my q is if fonts exist that are in the correct direction, why not use that?
<TabAtkins> r12a: There's very limited support, N'Ko has like 4, and 2 aren't complete. Noto has just developed a new font based on this discussion.
<astearns> ack myles
<TabAtkins> r12a: For Hebrew there are fonts that lean both ways
<TabAtkins> r12a: that's where florian's suggestion of being able to select a font based on lean direction comes from
<TabAtkins> myles: So sometimes it's personal pref, but sometimes it's valid linguistically
<TabAtkins> fantasai: I'm not sure I understand
<TabAtkins> fantasai: If author requests a slant of -12deg, why would give it a +5deg slant? If you had an option of -20deg or whatever
<TabAtkins> myles: Say numbers again?
<myles> the relevant part of the spec: https://drafts.csswg.org/css-fonts-4/#ex-ascending-oblique-13
<TabAtkins> astearns: I think the proposed resolution is, when searching for the nearest angle, find the angle in the same direction first, then find nearest angle in any direction if there's nothing.
<TabAtkins> myles: The spec does that
<TabAtkins> myles: If you request positive, it'll search the positives first, etc
<TabAtkins> drott: So question is if you want to cross 0 or not
<fantasai> astearns: In case where sign of the angle is ... is it better to switch the sign or find the closest on that side
<TabAtkins> myles: I thought richard just said neither is semantic
<TabAtkins> r12a: correct, but i also said N'Ko speakers would be happy with the wrong lean
<florian> q+
<TabAtkins> r12a: hebrew speakers would prefer one direction, but would be okay with either better than nothing
<TabAtkins> chris: The comparison isn't against nothing, it's against synthesis
<TabAtkins> chris: Not clear that wrong direction si better than synthetic
<TabAtkins> r12a: If you said you wanted an oblique font, the impls will switch to an italic font if needed, and you can't control the direction of that. That jump can be problematic.
<TabAtkins> r12a: So part of the discussion is if you want oblique you should be able to keep it
<TabAtkins> astearns: We already have preserving the sign, if possible
<TabAtkins> astearns: Coudl open a separat eissue of if there's anything different to do when the choice would change sign
<TabAtkins> astearns: Then we can go to the rest of the issue about italic vs oblique
<astearns> ack florian
<TabAtkins> florian: Even if direction is a pref and both would be fine, issue is the doc is unlikely to be a single font
<myles> q+
<myles> q-
<myles> q?
<TabAtkins> florian: If you have, say, bold italic in the middle of non-bold italic, and you have one font but not the other so you synthesize, if the direction clashes it'll look horrible
<TabAtkins> florian: Whether you want to switch to another font that you know leans the right way, or synthesize, dunno. But switching direction can be very unacceptable, depending on context.
<myles> q?
<astearns> ack drott
<myles> ack drott
<TabAtkins> drott: how important do you find it to be that this is synthetic or not?
<TabAtkins> drott: Is you main focus on matching, or synthesizing?
<TabAtkins> drott: I think our synthesization doesn't take angle into account
<TabAtkins> drott: So q is if angle should key into our choice to synthesize
<TabAtkins> r12a: I don't think that's part of what i'm requesting, I was assuming you could set an oblique angle
<TabAtkins> drott: So you're more interested in font matching than synthesis?
<TabAtkins> r12a: I think so, I'm not a CSS font expert. I'm interested in users getting the behavior they want, leaning left or right.
<florian> s/other so you synthesize/you would need to either synthesize or fallback to a font family that does can lean the right way.
<TabAtkins> drott: But you'd expect authors to bring fonts for that?
<TabAtkins> astearns: For my clarification, when you said synthesis only uses one angle, is it only one direction too? Or can it go left and right?
<florian> s/it'll look horrible/it'll look horrible, possibly into unreadable territory as letters colide and overlap
<TabAtkins> drott: I'd have to check.
<TabAtkins> myles: We have a hardcoded angle with a fixed direction.
<TabAtkins> myles: the way the spec phrases synthesis is, in your family you ahve fonts, and if the browser wants to add more, it can do it. as many as they want.
<TabAtkins> myles: So the spec is phrased as if the fonts are not created in response to request, they're just *there*
<wolfgang> s/ahve/have/
<TabAtkins> astearns: Ah so my udn erstanding of richard's concern is that browsers should have synthetic oblique for both left and right. At least those two, even if there's only one angle in each direction.
<TabAtkins> myles: I think that's reasonable.
<TabAtkins> myles: Digging deeper, users don't care about synthesis they just want it to look right
<TabAtkins> myles: From impl, synthesis and selection are very different.
<wolfgang> s/udn erstanding/understanding/
<TabAtkins> myles: If there's a font with the right angle, everyone gets the right answer.
<TabAtkins> myles: Remaining question is if there isn't a correct-direction font we *could* synthesize a good one.
<TabAtkins> myles: But right now the spec doesn't have must-level requirements for synthesis at all.
<TabAtkins> myles: But I think the spec should *at least* have a should-level note suggesting that if you synthesize, we should have two directions.
<TabAtkins> myles: At most a should-level, not must, given the lack of requirement around synthesis right now.
<TabAtkins> r12a: You can set negative angle and get synthesis correct in some browsers
<TabAtkins> myles: Really?
<TabAtkins> r12a: You shouldn't necessarily automatically fall back to a font of *any* type, if you actually want to specify an oblique
<TabAtkins> myles: In our impl, those have to be the same, for mechanical reasons, oblique and italic have to be treated the same.
<TabAtkins> myles: I agree philosophically it's wrong, our impl just constrains us.
<drott> q+
<astearns> ack drott
<TabAtkins> drott: What I'm gathering is that about fallback, you won't want to fallback in the wrong direction. That's not currently in the matching algo.
<TabAtkins> drott: So that brings us back to the "should we cross 0" in fallback.
<TabAtkins> drott: The algo currently prefers the correct lean but will change direction if needed.
<TabAtkins> astearns: That's a seaprate issue we'll discuss in the future, seeing if there's anything else here we can resolve on.
<TabAtkins> astearns: So back to Myles' suggestion about a note saying browsers should synthesize oblique in both directions
<TabAtkins> fantasai: I would go further and say *if* the browser is synthesizing, it *must* have both directions. Not sure why we'd allow unidirection if you're synthesizing in the first place.
<TabAtkins> drott: We don't have an internal API for that. I can see the utility of it.
<TabAtkins> drott: I think it's acceptable.
<TabAtkins> astearns: So the value of a note is showing our interest in it being ipmlemented. But not requiring it due to underllying tech stack.
<TabAtkins> fantasai: can't put MUST into notes
<TabAtkins> astearns: Right, not using 2119
<fantasai> TabAtkins: counter-proposal is, normatively state "if you synthesize, you must synthesize both directions"
<fantasai> TabAtkins: the main concern was that sythesis was an optional feature, right?
<TabAtkins> astearns: And drott didn't want it to be must because currently they can't synthesize both directions
<Bert> q+ to ask if there shouldn't be a way to ask left or right leaning, instead of a precise angle.
<wolfgang> s/ipmlemented/implemented/
<TabAtkins> astearns: So I was sticking with a note to express our preference.
<TabAtkins> myles: Might be able to compromise here, start with less strict req.
<TabAtkins> myles: I expect we'll implement it, no reason not to. And then we can upgrade to a requirement later.
<astearns> ack Bert
<Zakim> Bert, you wanted to ask if there shouldn't be a way to ask left or right leaning, instead of a precise angle.
<drott> q?
<TabAtkins> fantasai: I'm fine with SHOULD for now, cranked to MUST later.
<myles> s/I expect we'll implement it/I expect everyone will implement it/
<TabAtkins> Bert: In most cases I really just carea bout left vs right, can I avoid specifying a number?
<florian> q+
<TabAtkins> astearns: I like the idea but it shoudl be a separate issue
<astearns> ack florian
<wolfgang> s/carea bout/care about/
<TabAtkins> florian: I'd filed that in a bunch of bullets, agree to file it. It was convenient to centralize them for a bit, let's split them out.
<wolfgang> s/shoudl/should/
<TabAtkins> astearns: First, action florian to split out bullets into separate issues.
<TabAtkins> fantasai: Agree should file separate issues, don't think that should block us from discussing.
<TabAtkins> astearns: Right, dont' think we have a conclusion on that topic (just specify lean direction) but think we can go back to the synthetic q
<wolfgang> s/dont'/don't/
<TabAtkins> myles: proposed resolution is *if* a browser does synthesis of oblique, there SHOULD be at least two synthesized fonts, one in each direction
<drott> yes, lgtm
<TabAtkins> astearns: objections?
<dbaron> (maybe could be simplified to "SHOULD be at least one synthesized font in each direction", but doesn't matter to me)
<TabAtkins> RESOLVED; *if* a browser does synthesis of oblique, there SHOULD be at least one synthesized font in each direction
<TabAtkins> astearns: so, fallback for oblique
<TabAtkins> florian: Depending on which part of the spec you read it either says oblique->italic is not a thing, or suggests it's okay. I think we should remove the part that suggests it's okay.
<drott> q+
<TabAtkins> florian: I think there's a part that talks about picking a font for the closest angle, that doesn't seem to differentiate betwen italic and oblique
<jfkthame> q+
<TabAtkins> drott: I'd be in favor of seaprating italic to oblique, but that's a breaking change
<TabAtkins> florian: From italic to oblique, yes, but from oblique to italic?
<TabAtkins> myles: For us yes
<wolfgang> s/seaprating/separating/
<TabAtkins> drott: Similar to what myles says, we don't make an internal distinction between oblique and italic
<TabAtkins> fantasai: Worth pointing out the spec currently says, in the space where things are more precise, it runs thru all the obliques in the positive direction, then the italics, then the obliques and italics in the negative.
<TabAtkins> myles: I wrote that on purpose to achieve this.
<TabAtkins> fantasai: I don't think we want to change this but might want to give some control over this.
<TabAtkins> astearns: Q for i18n folks.
<TabAtkins> astearns: If author specifies oblique in positive direction, is it acceptable to get italic in positive direction, or would be better to get oblique in negative direction?
<TabAtkins> jfkthame: Neither one
<florian> q+
<TabAtkins> fantasai: My intuition is matching the slant is more than letterform
<drott> agree with fantasai
<astearns> ack drott
<florian> q-
<TabAtkins> r12a: don't understand why you'd go for a negative oblique if you asked for positive
<astearns> ack jfkthame
<TabAtkins> myles: The reason I wrote it this way is if you are using a weird font that leans the wrong way, and the user asks for italic, you want it leaning the wrong way rather than nothing.
<TabAtkins> jfkthame: Agree that we shouldn't fall back to italic when oblique is requested. I know it's what we currently do but we shoudl change it, better to synthesize oblique than fallback to italic
<TabAtkins> jfkthame: Also think we should synthesize a slant rather than choose a wrong lean.
<florian> +1 to jfkthame
<florian> q-
<florian> q+
<TabAtkins> astearns: Is it possible to resolve to remove the italic fallback?
<myles> q?
<TabAtkins> florian: q for jfkthame
<TabAtkins> s/florian/fantasai/
<TabAtkins> fantasai: If you don't have synthesis enabled, better to fall back to wrong-direction lean, or upright?
<fantasai> s/wrong-direction lean/matching-direction italic/
<TabAtkins> jfkthame: I think if you don't have synthesis enabled, you'd end up with
<TabAtkins> jfkthame: you'd get the same font you would have got, without synthesis. so no fallback from oblique to italic, not across zero. so font-matching rules would determine what font you get
<TabAtkins> TabAtkins: So given elika's question, you'd get upright?
<astearns> ack florian
<TabAtkins> jfkthame: yes
<TabAtkins> florian: I think i agree with jfkthame if the browser is capable of synthesis. In a browser that isn't i'm less sure.
<TabAtkins> florian: I agree that if you ahve synthesis, getting italic rather than synthetic oblique is weird.
<myles> q+
<TabAtkins> florian: But if you can't get synthesis it gets murky
<TabAtkins> jfkthame: Is there any browser that does no synthesis.
<TabAtkins> florian: Dunno but Myles was mentioning it being optional and that seems important.
<TabAtkins> myles: Biggest argument for fallback between oblique and italic. First is just software design, currently hard.
<TabAtkins> myles: other is compat
<wolfgang> s/ahve/have/
<TabAtkins> myles: For us to do it, we'd have to run an experiment (in Firefox?) to implement the new behaior and see if there's complaints
<wolfgang> s/behaior/behavior/
<drott> Agree
<TabAtkins> fantasai: My take is that, on the web, given the wide variety of environs, preserving that there is a slant is probably important in some cases, so having it fallback to italic if you don't have oblique *and* can't synthesize is reasonable default.
<drott> ^
<TabAtkins> fantasai: Might want to allow turning that off and say "italic only" or "oblique only", but by default having them fallback to each other makes for a more robust behavior.
<TabAtkins> myles: My point about compat is if the author happened to always be right, then no need to fallback. only when author gets it wrong does it matter.
<TabAtkins> florian: if choice is fallback to italic *or* synthesize oblique, I think synthesize oblique is preferable. fallback to italic is fine if there's no other option.
<TabAtkins> florian: And I think that preserves compat reasonable
<astearns> q?
<astearns> ack myles
<myles> q-
<florian> s/that preserves compat reasonable/that preserves reasonable compat
<TabAtkins> astearns: I think we're done for the moment, should split out the issues and take them bit by bit. Sound okay?
<xfq> +1

[frivoal]

Follow up issues based on https://github.com/w3c/csswg-drafts/issues/8914#issuecomment-1651137267 filed:

• https://github.com/w3c/csswg-drafts/issues/9389
• https://github.com/w3c/csswg-drafts/issues/9390
• https://github.com/w3c/csswg-drafts/issues/9392

[svgeesus]

See also

• https://github.com/w3c/csswg-drafts/issues/2869