– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

github-bot, take up w3c/csswg-drafts#11824

[css-color-adjust-1] Forced Colors Mode Webdriver Emulation

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11824.

alisonmaher: this proposal is to add a new webdriver extension that keeps track of forced-color-mode emulation state, proposed light/dark

alisonmaher: it forces forced-color-mode if it's not none, and update the ysstem color mappings

alisonmaher: so it's a consistent experience across browsers

alisonmaher: put up a PR, using windows colors currently but we can do whatever

alisonmaher: so do we want to pursue? and not sure about process, if we need webdriver approval or just css

astearns: any webdriver already in?

alisonmaher: none in yet, but the multi-screen stuff has a proposal. i think this'll be the first.

astearns: anyone know how the webdriver folks like to have proposals put together?

alisonmaher: not sure. i looked at other webdriver specs, seemed better to put it in the sepc itself

alisonmaher: we can check

<bramus> https://drafts.csswg.org/css-viewport/#automation is the webdriver part for viewports

<kbabbitt> TabAtkins: we took a resolution to put webdriver stuff in our specs a while back

<kbabbitt> ...suggest we go with this for now and then check with webdriver folks

fantasai: tangential - how are we planning to test the final hookups to ensure it's working?

alisonmaher: when we test this we make the call to set one of the emulation states

alisonmaher: so the expectation would test the emulation's forced colors

alisonmaher: so we coudl use none to check it's not applied, then verify non-none works with different colors

fantasai: slightly different question acutally. we're gonna test this emulation, we can tell things are working as expected.

fantasai: but if you have a browser that supports teh webdriver emulation but doesn't acutally support asking the OS about the light/dark status, they should presumably fail *something*

alisonmaher: suppose could be thru the media query

fantasai: how do we test the MQ then?

astearns: your question is valid, but there's nothing in WPT that lets us close that final gap. it'll have to be something in the browser's own infrastructure that'll verify it work

fantasai: yeah my point is just that we should have some form of test that'll verify this

florian: as much as we like automated tests, i think there are some things that are impractical to test automatically, and this might be one of them. We should still have shared tests but they'll have to involve manual steps

emilio: similar. this feels like you'd need to tweak an OS setting, assume the browser wants to pay attention to that.

<fantasai> Even the browser's own testing infrastructure will be an emulation layer

emilio: like, firefox lets you force colors regardless of the OS, that's similar to what we're using in wpt

emilio: so wpt can test that there's a switch and that it works correctly, but it can't test when the browser decides to trigger that

fantasai: yeah, that just seems to be a hole in our testing plan

alisonmaher: that seems to apply to testing system colors in general

alisonmaher: but this'll cover the rest of the space past that

fantasai: right, i think this is definitely an improvement.

fantasai: just be sure not to represent that this covers the whole space

astearns: so are we looking for a resolution to add this?

alisonmaher: yes, and i can do the extra work to double check with the webdriver folks

astearns: and would be easier with a spec in place

astearns: proposed resolution is to accept the PR, and go check with webdriver folks for approval

astearns: objections?

RESOLUTION: Accept the PR, check with webdriver folks for approval

fantasai: process - forced colors is in CR, so we shoudl make edits in ED, ping webdriver, and then publish an updated CR

github-bot, take up w3c/csswg-drafts#11462

[css-align] `justify-items` and block splitting inline

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11462.

oriol: when justify-self:auto, spec says it should resolve to the value of justify-items of the parent box

oriol: there's one exception - when finding the position of an abspos item

oriol: this implies that "parent box" means containing block

oriol: with one exception - a block inside an inline. the inner block splits the inline

oriol: and the inline does not establisha containing block

oriol: so from which element should we take justify-items, if any?

oriol: taking it from parent inline seems weird to me

oriol: so not fond of the current spec text

oriol: another otpion is taking it from the CB

oriol: or Ian mentioned saying that, currently jsutify-items applies to all elements, we can say it doesn't apply to inline elements

oriol: so if the parent is inline, we'd treat justify-self:auto on the child as "normal"

oriol: no strong opintion, i think spec just didn't consider the case

fantasai: you're right the spec didn't consider this case

fantasai: i think the intent of "look at the parent" was to do something simple

fantasai: which is why we didn't look at the CB

fantasai: two things that shoudl remain true are...

fantasai: i think we need to ignore anonymous boxes for this purpose

fantasai: for flex and grid they need to look at their parent, for abspos they dont' look at anything

fantasai: for here, probably shoudl do whatever is simplest

fantasai: whether it's look at parent element (doable during style resolution) or look at something else

<fantasai> TabAtkins: agree with fantasai , we should do the simple thing

<fantasai> TabAtkins: block-splitting-inlines are weird

<fantasai> TabAtkins: I would compute to normal, i.e. it doesn't take from it's parent if its parent is inline

<fantasai> TabAtkins: seems like easiest thing to do

florian: in agreement, the msot intuitive thing is to walk up the tree until you find a block

florian: but this is a weird situation and doesn't really matter, so going to "normal" seems fine too

<iank_> i'd prefer "normal"

astearns: so proposed resolution from Tab is to have "auto" compute to "normal" if the parent is inline

oriol: i'm fine. not sure if it's actually simpler or not, in Servo we have the style fo the CB but not necessarily the parent. This sounds good to me tho

astearns: and interpreting Ian's comment as agreeing with TAb

astearns: objections?

florian: so this happens at style resolution time, right? so the fact that the inlne box isn't a parent of the block box at tree-building time doesn't matter, correct?

iank_: incorrect, i think we're the only one that *does* respect the parent/child relationship (we get filters correct, for example)

iank_: but i don't think it actually matters that much for this

astearns: so objections again?

RESOLUTION: if parent is inline, then justify-self:auto computes to normal

github-bot, take up w3c/csswg-drafts#11460

[css-inline-3] Requiring authors to declare two values for `text-box-edge` is a mistake

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11460.

jensimmons: right now, t-b-e requires an author to specify both values

jensimmons: if they just say "cap" not "cap auto"/etc, then it's supposed to be invalid, but there's not interop

jensimmons: i think that's a mistake, i was writing an article in december and foudn it hard to teach because i had to teach the whol elinebox model

jensimmons: i think we should allow declaring just one and make some assumptions

<fantasai> w3c/csswg-drafts#11460 (comment)

jensimmons: if they declare cap/edge/alphabetic, we assume the other is auto

<florian> The whole model is indeed complex to understand. I support making easy things easy, and letting authors get what they probably want without needing to understand the whole thing if we can.

jensimmons: there's a question about.... shouldn't we try to do something more magic for authors? like if you are trimming the cap edge you probably want to also trim the alphabetic edge. this started from an author request to trim both with just one value

jensimmons: but when i was makign demos, i foudn there are plenty of times you do want to trim to both cap and alphabetic, but there are plenty of times you want to do something different too. so i think we should just default "auto" for the missing one

<fantasai> +1 to this proposal from me, I think it makes sense to default omitted values to auto

astearns: any concern that each individual value expands to the correct two values differently?

astearns: is that hard to teach, or is it more like any partiuclar author is only using a few of these, and our default expansion for that value is probably what they want

jensimmons: i think for "text" becoming "text text"/etc I think it's pretty obvious, tho I'd be interested in hearing if someone thinks differently

jensimmons: you don't in one rule that "ideographic" and "cap". you might mix them on one page, but they'll be on different elements

fantasai: we have a bunch of places where if you *can* duplicate the value, we do, and we do something else if we can't

astearns: yeah, this is just a little more complex, since you have "auto" sometimes in first, sometimes in second

fantasai: you're basically default the "other" value. it's like background-position, if you say "left" you get "center left", if you say "top" you get "top center"

jensimmons: question is just if someone is doing ideographic a lot, is "ideographic" alone implying doubled?

florian: doing ideographic both ways makes the most sense by defualt. i agree with the proposal

florian: just give people what they likely want by default without having to udnerstand the whole model

jensimmons: yeah, just should have a default rather than the current bheavior which is invalid, which doesn't do anything

kizu: as an author, if we could have alphabetic/ideographic as shorter keywords, a bit long to write when we have other shorthands like "cap"

kizu: like "cap a" instead of "cap alphabetic"

astearns: probably fair, but a separate issue

<TabAtkins> +1 to the proposal

astearns: comments? objections?

RESOLUTION: Allow text-box-edge to take a single keyword, expanding as specified in Jen's final comment

github-bot, take up w3c/csswg-drafts#11472

[css-inline-3] text-box accumulation unexpected behavior

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11472.

fantasai: probably helpful to look at the issue examples

fantasai: an author was playing with text-box-trim and was surprised when it cut into a button he'd styled

fantasai: reason is because, normally if you have padding/etc we dont' trim thru the padding/border. but the button was an inline block, so it sits on a line, and we ignore the contents of lineboxes when trimming. we just trim to the root inline box no matter what's on the line.

fantasai: it seems like this is something that people will trip over as well. there are workarounds, but there are reasons the author might have wanted to use inline-block specifically

fantasai: so options are we could make authors work around this

fantasai: or we could make a rule that says if you have an inline-block on a line, that pushes out the text edge to the margin edge of that block. (rather, any atomic inline, not just inline-blocks)

fantasai: so the rule for text trim would introspect into the linebox content, and if it finds an atomic inline it would push the edge out

fantasai: so wanted to check the wg's opinion

jensimmons: if we made the second change...

jensimmons: i could also see this author applying text-box-trim to the button itself to get the text vertically centered

jensimmons: will that get screwy?

fantasai: no, because it'll push to the amrgin edge fo the box *after* the box's position ahs been computed

fantasai: if they were using text-box-trim on the button itself that'll change the button's sizing. then if it's on the paragraph too, we don't care about *how* the atomic inline figured out its margin box, we'll just use that

<iank_> are you sure you want margin-box and not border-box? e.g. margins on inline-blocks are typically used to pad the line-box.

dbaron: i think from a high level persepctive the result you want makes sense.

<fantasai> iank_, yes I'm sure

dbaron: tryign to remember how text-box-edge works, waiting for the spec to load

<fantasai> iank_, I think if the author asked for that extra space, we should give it to them

florian: maybe a silly question

florian: would it be an option to go with border edge rather than margin edge? or am i missing something?

<fantasai> iank_, ... although I suppose maybe it's similar to margin collapsing

<fantasai> iank_, hmmm

dbaron: i think we're reasonably consistent that waht matters for atomic inlines is their margin edge

iank_: i ahd the same question. margins are typically used to simulate the same metrics as the text around it. so if margins are used that way it makes sense to trim to the border box, i think

iank_: becuase if they're being used to simulate a descent, and you're trying to trim the descent

kizu: if we want this behavior, we need a way for an element to opt out, if it *wants* to hang from the line you're trimming to

kizu: if we use margin box you could use negative margin to bring it back down (unless we do something magic there to not consider negative margin for text-trim)

astearns: similar question. first option was make the author fix it. if we change the default behavior, can they fix our choice?

fantasai: i think roman's point is correct. if we use the margin edge, author can use negative margin to shift that edge inward

fantasai: but if we use the border edge, author has no control

fantasai: so proposed reoslution is text-box-trim does not trim further into the linebox than the outermost margin edge of any atomic inlines in the linebox

astearns: and that's sufficient to solve this author's issue?

fantasai: i believe so

astearns: objections?

RESOLUTION: text-box-trim does not trim further into the linebox than the outermost margin edge of any atomic inlines in the linebox

<dbaron> (I presume this affects how text-box-trim affects block containers.)

github-bot, take up w3c/csswg-drafts#11365

[css-inline-3] -top/-bottom vs -over/-under

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11365.

fantasai: in 10713 we resolved to add reorderable keywords to text-box-edge

fantasai: i didn't edit that into the spec yet because i ran into this issue

fantasai: what keywords do we actually want

fantasai: in horizontal text top/bottom are pretty obvious. we ahve text-top/text-bottom etc

fantasai: when you have vertical it's more interesting

fantasai: in our specs, and in things like ruby-position, we use the terms over/under to refer to "above the baseline" and "below the baseline"

fantasai: so what keywords do we want to use for text-edge? top/bottom, or over/under, or a mix? text-top and ideographic-over?

fantasai: murakami-san proposed we be consistent with top/bottom keywords we have already.

fantasai: i don't have a strong opinion, we just need to resolve on that

florian: so that would be consistent with the opentype naming?

fantasai: so over is sometimes top, sometimes left, sometime sright, depending on WM

fantasai: top in CSS, aside from vertical-align, is always page top

fantasai: but in vertical-align it's the over/udner side

fantasai: which can be left/right

TabAtkins: i was just confused, i thought florian was saying the opentype "top" wasn't always the css "over"

fantasai: no, it's always the same

jensimmons: so everyone's consistent that "top" isn't always top

astearns: and we can always go with top/bottom for now and always add over/under in the future as aliases if we need to

fantasai: yeah we could

florian: don't expect we'll need to tho

astearns: so proposed resolution is we stay with text-top/text-bottom?

fantasai: -top and -bottom for all keywords in this property

astearns: objection?

RESOLUTION: use -top and -bottom as the direction suffix for all keywords in this property (referring to over/under)

github-bot, take up w3c/csswg-drafts#10713

[css-inline-3] Allow re-ordering of <text-edge> keywords

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10713.

fantasai: I think the last issue is what was blocking this issue, so assuming we're still fine with the reordering I'll make these edits

fantasai: #11365

github-bot, take up w3c/csswg-drafts#2528

[css-fonts-4] Feature for making text always fit the width of its parent

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/2528.

kizu: i have some slides

kizu: [presents slides]

kizu: this issue was opened back in 2018

kizu: therea re many libraries that try to do this effect

kizu: lots of typography examples in the real world, but it's not on the web

kizu: i wrote two articles about some pure-css techniques

kizu: these were my most popular articles, so clearly people want these features

kizu: here's an example of text sizing to fit its container

kizu: here's another example, obviously it's "fit to inline space", not necessarily width

kizu: fitting text is complicated, this is why we didn't ahve it for a long time

kizu: my workarounds are hacky, as usual

kizu: but it's possible.

kizu: there are no loops, it works

kizu: want to talk about some complexities

kizu: first issue is optical sizing

kizu: generally when we size text the size is proportional to its font-size, but opsz also lets the font respond to its size

kizu: see in this example, the change is non-linear. can even change the glyphs itself

kizu: another example, in cSS there can be fixed-size elements on the line, margins or letter-spacing, etc.

kizu: so just getting text width and calcualting a ratio doens't work

kizu: there are some cases you can't solve

kizu: but we don't necessarily need to solve these, okay for them to be broken. i have some ideas to minimize issues tho

kizu: one idea is when we first size the text, we freeze some values

kizu: this is the most complex part, but i don't think obscure cases should prevent us from solving common ones

kizu: common cases are straightforward, and fixed-size elements are solvable

kizu: i wont' go thru full details but here are a few

kizu: timing

kizu: i think it should happen when you first render text at normal font size, apply wrapping and balancing, then before justification alignment, we try to fit the text

kizu: this could be configurable

kizu: with freezing...

kizu: might need to render the text up to four times, but not more, to handle frozen sizes and optical sizing adjustments

kizu: in the first step we render as normal, then freeze the nonlinear dependencies. later renderings we use those frozen sizes

kizu: this allows us to know some variables in the algo, next time we can account for static space without freezing, then we can freeze them again in the final size. will make optical sizing approximately right, even if not exactly correct. looks good in my experiments

kizu: for the API, a few options

kizu: think we should start from font-size

kizu: font-size is our minimum size. this lets us do wrapping and balancing.

kizu: gives us better fallback too, if a browser doesn't support the resizing it'll be rendered as normal at the specified font size

kizu: and it's more accessible, font can't get too small to read

kizu: so no scaling down

kizu: a proposed proeprty is text-grow: <text-grow-type> || <max-font-size>

kizu: <text-grow-type> = none | consistent | per-line

kizu: consistent is we consider all lines to have the same size. easier to implement, we just find the longest line box and then apply the font size to everything

kizu: per-line change each line independently, after wrapping

kizu: for <max-font-size>, i think we want it. if you don't have this the font can become too large. maybe a default of 100vb

<fantasai> I might suggest vmin

kizu: there's a codepen with a custom element that implements this algo

kizu: all css, just some js to update a cq inside

kizu: all examples from this presentation are in the codepen

kizu: thanks to adam argyle for checking if this is viable in chrome, thanks to penelope who asked questions on bluesky, and thanks to roel nieskens

astearns: mixed font-sizes

astearns: similar to the case with non-text elements that are static

astearns: if the content itself has multiple font sizes on a line, how is that handled

<Zakim> astearns, you wanted to ask about mixed font sizes

kizu: if font-size is in 'em' it works as expected

kizu: they'll scale with the rest of the text

kizu: there are some examples of that in my examples

astearns: i think for some, maybe most calculations that's the way to go

astearns: worried about specified font-size that has a calculation with min/max, want to make sure the result doesn't go over the specified max for the font-size calc *or* the resizing calc

kizu: there are some edge caess to consider. i think using the initial font-size for anything complex works for 99% of cases

kizu: if an author wants to do something complicated, i think they can work around it.

florian: i agree this is very desired

florian: and if we need to cut corners in some cases it'll be okay, people will work around

<kizu> Algorithm: https://www.tldraw.com/f/_sxU8eCZDcHbLvnDPMk4P

<kizu> CodePen: https://codepen.io/kizu/pen/QwWVXxQ

<kizu> My slides: https://drive.google.com/drive/folders/1og8QAU1m0QSaqxNGX6rSYUvQhfTy3PIq?usp=sharing (with videos, so not hosted on my site, will later make a pdf)

florian: one question, i think there are two cases (maybe more) where the avaialble inline-size for the line changes based on the height of the line

florian: floats and fragmentation

florian: maybe it's in the algo, but not mentioned in the presentation. what happens if growing the height makes it narrower?

kizu: my example uses CQ so it requirest containment. could require that if we need to.

kizu: don't think we'd actually have a case where containment doesn't work but you want to fit a space

kizu: i think more complicated case is maybe initial-letter

jensimmons: thanks for bringing this to the agenda, been talked about a long time

jensimmons: definitely something authors want, provides beautiful possibilities for headlines/etc

<bramus> +1

jensimmons: it seems like your whole thing assumes the way you want to grow is to increase font-size.

jensimmons: think that's common, but not necessarily only way

jensimmons: maybe people want to keep the font-size but increase a font axis, like make it bolder

jensimmons: should maybe design it to do font-size scaling by default, but another control that lets you specify another control

jensimmons: probably just one, to keep it simple

jensimmons: a lot of examples you showed are classic, but something in those examples is a lot of variation - one line super big, etc

jensimmons: interesting you broke it down between "consistent" and "per-line", but in your per-line it doesn't look like those posters

jensimmons: the amount of variation ends up pretty subtle, not as aesthetically pleasing

jensimmons: so something to think about

jensimmons: authors could force breaks, of course, making the worse rag ever before scaling

<astearns> +1 to having authored forced breaks for larger variation per line

jensimmons: authors would also possibly want to change the font per line

jensimmons: because we're thinking thru the order of operations, think there could be a spot, just before things are made bigger, you've got some pseudo-elements where you could set the font to something else

jensimmons: so then you'd linebreak, swap out fonts at the last minute, then scale to fit

jensimmons: i think if you want to emulate those classic layouts you have to think about this

kizu: for other axises - i was thinking about it, but couldn't come up with an algorithm that worked and was simple

kizu: increasing font-size is just increasing proportional to the available space, with some wrinkles

kizu: some fonts i saw coudl use optical sizing to achieve this effect.

kizu: but don't think we can generally substitute

kizu: other example, like increasing sapcing or using width axis, would be nice

kizu: i think we can start with width and then see if there's any other axises we can depend on

kizu: problem is axises aren't linear. not possible without looping

kizu: we can maybe start with just consistent version and then see if people need the per-line version

kizu: people can split the lines themselves for now, use a wrapper to apply different fonts

kizu: not sure what the blockers are for nth-line

jensimmons: yeah, i get that what you've figured out so far doens't allow the other things to work, but we should think about it

jensimmons: stretch and weight are most important

jensimmons: optical sizing isnt' the way to pursue, i think. it's meant to be a tweak.

jensimmons: and should peg to font-size

jensimmons: but stretch and weight are two important options to make it bigger without changing font-size

kizu: yeah would be nice to have other controls, maybe possible to adjust the algorithm

kizu: but i think when you want to use other controls, having an ability to stretch just font-size would already be very helpful. eliminates one fo the things you need to tackle

kizu: can just adjust your spacing initally, then have the browser auto-adjust the font-size to fit

jensimmons: right, just that variable fonts have already been invented, shoudl push ourselves to make sure it's possible to handle and we're not boxed out of handling that in the future

jensimmons: for second point, your reaction that it could be hard and we should maybe only do consistent, i think that's wrong. we should go for it.

jensimmons: this is something people have been thinking about since the days of cufon

<astearns> each line is the more important version, imo

jensimmons: we should be ambitious and figure it out

jensimmons: especially in the era of responsive design, using manual spans is a hack. letting wrapping happen then embiggening each line by itself is very attractive. just think we need to take it further

iank_: one use-case we want to cover is shrinking, down to a minimum

iank_: say you're on a small-screen device, have a heading at a particular size, want to shrink down to a reasonable minimum size

iank_: think there's details to work out on how the actual scaling works

iank_: just optical sizing doesn't cover all the degenerate cases

iank_: one algo we might land on is effectively doing a transform, no additional glyph selection

iank_: don't want this to be restricted to varaible fonts that do support this feature

iank_: i just don't want us to get into a situation where we're bisecting the inline-size

iank_: i don't think we need to worry about containment here, like what florian brought up. floats are fine, we can just always move forward in the layout.

kizu: for transforms, was wondering if we wanted to do it this way

<florian> [walking forward seems reasonable]

kizu: but if there are non-text elements inside, like px margins, scaling might not look right

iank_: i mean could scale the individual text segments, not necessarily the atomic inlines

kizu: yeah could be good. would ahve to account for optical sizing