IRC log of css on 2025-04-01

Timestamps are in UTC.

13:10:14 [RRSAgent]
RRSAgent has joined #css
13:10:18 [RRSAgent]
logging to https://www.w3.org/2025/04/01-css-irc
13:10:18 [Zakim]
RRSAgent, make logs Public
13:10:19 [Zakim]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
13:11:00 [oriol]
present+
13:11:15 [TabAtkins]
ScribeNick: TabAtkins
13:11:16 [jfkthame]
present+
13:11:39 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/11824
13:11:40 [github-bot]
Topic: [css-color-adjust-1] Forced Colors Mode Webdriver Emulation
13:11:40 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11824.
13:12:19 [TabAtkins]
alisonmaher: this proposal is to add a new webdriver extension that keeps track of forced-color-mode emulation state, proposed light/dark
13:12:34 [TabAtkins]
alisonmaher: it forces forced-color-mode if it's not none, and update the ysstem color mappings
13:12:41 [TabAtkins]
alisonmaher: so it's a consistent experience across browsers
13:12:53 [TabAtkins]
alisonmaher: put up a PR, using windows colors currently but we can do whatever
13:13:09 [TabAtkins]
alisonmaher: so do we want to pursue? and not sure about process, if we need webdriver approval or just css
13:13:29 [TabAtkins]
astearns: any webdriver already in?
13:13:42 [TabAtkins]
alisonmaher: none in yet, but the multi-screen stuff has a proposal. i think this'll be the first.
13:13:56 [TabAtkins]
astearns: anyone know how the webdriver folks like to have proposals put together?
13:14:08 [TabAtkins]
alisonmaher: not sure. i looked at other webdriver specs, seemed better to put it in the sepc itself
13:14:12 [TabAtkins]
alisonmaher: we can check
13:14:22 [bramus]
https://drafts.csswg.org/css-viewport/#automation is the webdriver part for viewports
13:14:30 [kbabbitt]
TabAtkins: we took a resolution to put webdriver stuff in our specs a while back
13:14:37 [astearns]
ack fantasai
13:14:39 [kbabbitt]
...suggest we go with this for now and then check with webdriver folks
13:14:52 [TabAtkins]
fantasai: tangential - how are we planning to test the final hookups to ensure it's working?
13:15:07 [TabAtkins]
alisonmaher: when we test this we make the call to set one of the emulation states
13:15:22 [TabAtkins]
alisonmaher: so the expectation would test the emulation's forced colors
13:15:51 [TabAtkins]
alisonmaher: so we coudl use none to check it's not applied, then verify non-none works with different colors
13:16:17 [TabAtkins]
fantasai: slightly different question acutally. we're gonna test this emulation, we can tell things are working as expected.
13:16:42 [TabAtkins]
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*
13:16:48 [lea]
lea has joined #css
13:16:55 [TabAtkins]
alisonmaher: suppose could be thru the media query
13:17:04 [TabAtkins]
fantasai: how do we test the MQ then?
13:17:21 [emilio]
q+
13:17:39 [TabAtkins]
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
13:17:52 [TabAtkins]
fantasai: yeah my point is just that we should have some form of test that'll verify this
13:18:09 [TabAtkins]
florian: as much as we like automated tests, i think there are some things that are impractical to test, and this might be one of them
13:18:13 [astearns]
ack emilio
13:18:35 [TabAtkins]
emilio: similar. this feels like you'd need to tweak an OS setting, assume the browser wants to pay attention to that.
13:18:35 [fantasai]
Even the browser's own testing infrastructure will be an emulation layer
13:18:44 [rachelandrew]
present+
13:18:48 [TabAtkins]
emilio: like, firefox lets you force colors regardless of the OS, that's similar to what we're using in wpt
13:19:03 [TabAtkins]
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
13:19:16 [TabAtkins]
fantasai: yeah, that just seems to be a hole in our testing plan
13:19:25 [jensimmons]
jensimmons has joined #css
13:19:25 [TabAtkins]
alisonmaher: that seems to apply to testing system colors in general
13:19:33 [TabAtkins]
alisonmaher: but this'll cover the rest of the space past that
13:19:41 [TabAtkins]
fantasai: right, i think this is definitely an improvement.
13:19:44 [jensimmons]
present+
13:19:52 [TabAtkins]
fantasai: just be sure not to represent that this covers the whole space
13:19:59 [TabAtkins]
astearns: so are we looking for a resolution to add this?
13:20:08 [TabAtkins]
alisonmaher: yes, and i can do the extra work to double check with the webdriver folks
13:20:12 [TabAtkins]
astearns: and would be easier with a spec in place
13:20:28 [TabAtkins]
astearns: proposed resolution is to accept the PR, and go check with webdriver folks for approval
13:20:30 [TabAtkins]
astearns: objections?
13:20:42 [TabAtkins]
RESOLVED: Accept the PR, check with webdriver folks for approval
13:20:43 [florian]
s/impractical to test, and this might be one of them/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
13:21:01 [TabAtkins]
fantasai: process - forced colors is in CR, so we shoudl make edits in ED, ping webdriver, and then publish an updated CR
13:21:30 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/11462
13:21:30 [github-bot]
Topic: [css-align] `justify-items` and block splitting inline
13:21:30 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11462.
13:22:21 [TabAtkins]
oriol: when justify-self:auto, spec says it should resolve to the value of justify-items of the parent box
13:22:33 [TabAtkins]
oriol: there's one exception - when finding the position of an abspos item
13:22:42 [TabAtkins]
oriol: this implies that "parent box" means containing block
13:22:56 [TabAtkins]
oriol: with one exception - a block inside an inline. the inner block splits the inline
13:23:04 [TabAtkins]
oriol: and the inline does not establisha containing block
13:23:12 [TabAtkins]
oriol: so from which element should we take justify-items, if any?
13:23:22 [TabAtkins]
oriol: taking it from parent inline seems weird to me
13:23:27 [TabAtkins]
oriol: so not fond of the current spec text
13:23:34 [TabAtkins]
oriol: another otpion is taking it from the CB
13:23:57 [TabAtkins]
oriol: or Ian mentioned saying that, currently jsutify-items applies to all elements, we can say it doesn't apply to inline elements
13:24:12 [TabAtkins]
oriol: so if the parent is inline, we'd treat justify-self:auto on the child as "normal"
13:24:20 [TabAtkins]
oriol: no strong opintion, i think spec just didn't consider the case
13:24:23 [astearns]
ack fantasai
13:24:29 [TabAtkins]
fantasai: you're right the spec didn't consider this case
13:24:36 [TabAtkins]
fantasai: i think the intent of "look at the parent" was to do something simple
13:24:41 [TabAtkins]
fantasai: which is why we didn't look at the CB
13:24:54 [TabAtkins]
fantasai: two things that shoudl remain true are...
13:25:02 [TabAtkins]
fantasai: i think we need to ignore anonymous boxes for this purpose
13:25:13 [TabAtkins]
fantasai: for flex and grid they need to look at their parent, for abspos they dont' look at anything
13:25:22 [TabAtkins]
fantasai: for here, probably shoudl do whatever is simplest
13:25:40 [TabAtkins]
fantasai: whether it's look at parent element (doable during style resolution) or look at something else
13:25:42 [flackr]
flackr has joined #css
13:25:43 [TabAtkins]
q+
13:25:46 [flackr]
present+
13:25:50 [astearns]
ack TabAtkins
13:25:54 [fantasai]
TabAtkins: agree with fantasai , we should do the simple thing
13:25:59 [fantasai]
TabAtkins: block-splitting-inlines are weird
13:26:09 [fantasai]
TabAtkins: I would compute to normal, i.e. it doesn't take from it's parent if its parent is inline
13:26:19 [fantasai]
TabAtkins: seems like easiest thing to do
13:26:25 [florian]
q+
13:26:39 [astearns]
ack florian
13:26:44 [TabAtkins]
florian: in agreement, the msot intuitive thing is to walk up the tree until you find a block
13:26:55 [TabAtkins]
florian: but this is a weird situation and doesn't really matter, so going to "normal" seems fine too
13:27:07 [schenney]
schenney has joined #css
13:27:16 [iank_]
i'd prefer "normal"
13:27:16 [schenney]
present+
13:27:19 [TabAtkins]
astearns: so proposed resolution from Tab is to have "auto" compute to "normal" if the parent is inline
13:27:43 [TabAtkins]
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
13:28:00 [TabAtkins]
astearns: and interpreting Ian's comment as agreeing with TAb
13:28:02 [TabAtkins]
astearns: objections?
13:28:28 [TabAtkins]
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?
13:28:54 [ChrisL]
present+
13:29:17 [TabAtkins]
iank_: incorrect, i think we're the only one that *does* respect the parent/child relationship (we get filters correct, for example)
13:29:26 [TabAtkins]
iank_: but i don't think it actually matters that much for this
13:30:10 [TabAtkins]
astearns: so objections again?
13:30:26 [TabAtkins]
RESOLVED: if parent is inline, then justify-self:auto computes to normal
13:30:42 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/11460
13:30:42 [github-bot]
Topic: [css-inline-3] Requiring authors to declare two values for `text-box-edge` is a mistake
13:30:42 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11460.
13:31:08 [TabAtkins]
jensimmons: right now, t-b-e requires an author to specify both values
13:31:24 [TabAtkins]
jensimmons: if they just say "cap" not "cap auto"/etc, then it's supposed to be invalid, but there's not interop
13:31:45 [TabAtkins]
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
13:31:53 [TabAtkins]
jensimmons: i think we should allow declaring just one and make some assumptions
13:32:05 [fantasai]
https://github.com/w3c/csswg-drafts/issues/11460#issuecomment-2769319469
13:32:05 [TabAtkins]
jensimmons: if they declare cap/edge/alphabetic, we assume the other is auto
13:32:44 [florian]
The whole model is indeed complex to understand. I support making easy things easy, and letting authors get what they want without needing to understand the whole thing if we can.
13:32:49 [TabAtkins]
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
13:33:26 [TabAtkins]
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
13:33:36 [fantasai]
+1 to this proposal from me, I think it makes sense to default to auto
13:33:45 [fantasai]
s/default/default omitted values/
13:33:52 [florian]
s/what they want without/what they probably want without
13:33:59 [TabAtkins]
astearns: any concern that each individual value expands to the correct two values differently?
13:34:16 [TabAtkins]
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
13:34:38 [TabAtkins]
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
13:34:59 [TabAtkins]
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
13:35:13 [astearns]
ack fantasai
13:35:31 [TabAtkins]
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
13:35:37 [dholbert]
dholbert has joined #css
13:35:46 [dholbert]
present+
13:35:52 [TabAtkins]
astearns: yeah, this is just a little more complex, since you have "auto" sometimes in first, sometimes in second
13:36:17 [TabAtkins]
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"
13:36:29 [kizu]
q+
13:36:35 [TabAtkins]
jensimmons: question is just if someone is doing ideographic a lot, is "ideographic" alone implying doubled?
13:36:49 [TabAtkins]
florian: doing it both ways makes the most sense by defualt. i agree with the proposal
13:37:04 [TabAtkins]
florian: just give people what they likely want by default without having to udnerstand the whole model
13:37:14 [astearns]
ack kizu
13:37:23 [TabAtkins]
jensimmons: yeah, just should have a default rather than the current bheavior which is invalid, which doesn't do anything
13:37:34 [florian]
s/doing it both ways/doing ideographic both ways
13:37:59 [TabAtkins]
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"
13:38:13 [TabAtkins]
kizu: like "cap a" instead of "cap alphabetic"
13:38:23 [TabAtkins]
astearns: probably fair, but a separate issue
13:38:38 [TabAtkins]
+1 to the proposal
13:38:49 [TabAtkins]
astearns: comments? objections?
13:39:14 [TabAtkins]
RESOLVED: Allow text-box-edge to take a single keyword, expanding as specified in Jen's final comment
13:39:28 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/11472
13:39:28 [github-bot]
Topic: [css-inline-3] text-box accumulation unexpected behavior
13:39:28 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11472.
13:39:44 [TabAtkins]
fantasai: probably helpful to look at the issue examples
13:39:57 [TabAtkins]
fantasai: an author was playing with text-box-trim and was surprised when it cut into a button he'd styled
13:40:32 [TabAtkins]
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.
13:40:53 [TabAtkins]
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
13:41:03 [TabAtkins]
fantasai: so options are we could make authors work around this
13:41:28 [TabAtkins]
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)
13:41:50 [TabAtkins]
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
13:41:56 [TabAtkins]
fantasai: so wanted to check the wg's opinion
13:42:04 [TabAtkins]
jensimmons: if we made the second change...
13:42:24 [TabAtkins]
jensimmons: i could also see this author applying text-box-trim to the button itself to get the text vertically centered
13:42:28 [TabAtkins]
jensimmons: will that get screwy?
13:42:43 [TabAtkins]
fantasai: no, because it'll push to the amrgin edge fo the box *after* the box's position ahs been computed
13:43:05 [florian]
q+
13:43:10 [TabAtkins]
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
13:43:14 [astearns]
ack dbaron
13:43:24 [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.
13:43:34 [TabAtkins]
dbaron: i think from a high level persepctive the result you want makes sense.
13:43:38 [fantasai]
iank_, yes I'm sure
13:43:49 [TabAtkins]
dbaron: tryign to remember how text-box-edge works, waiting for the spec to load
13:44:05 [fantasai]
iank_, I think if the author asked for that extra space, we should give it to them
13:44:12 [astearns]
ack florian
13:44:15 [TabAtkins]
florian: maybe a silly question
13:44:29 [TabAtkins]
florian: would it be an option to go with border edge rather than margin edge? or am i missing something?
13:44:31 [fantasai]
iank_, ... although I suppose maybe it's similar to margin collapsing
13:44:37 [fantasai]
iank_, hmmm
13:44:42 [kizu]
q+
13:44:49 [TabAtkins]
dbaron: i think we're reasonably consistent that waht matters for atomic inlines is their margin edge
13:45:16 [TabAtkins]
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
13:45:32 [TabAtkins]
iank_: becuase if they're being used to simulate a descent, and you're trying to trim the descent
13:45:33 [astearns]
ack kizu
13:45:59 [TabAtkins]
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
13:46:23 [TabAtkins]
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)
13:46:47 [TabAtkins]
astearns: similar question. first option was make the author fix it. if we change the default behavior, can they fix our choice?
13:47:09 [TabAtkins]
fantasai: i think roman's point is correct. if we use the margin edge, author can use negative margin to shift that edge inward
13:47:16 [TabAtkins]
fantasai: but if we use the border edge, author has no control
13:47:52 [TabAtkins]
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
13:48:03 [TabAtkins]
astearns: and that's sufficient to solve this author's issue?
13:48:06 [TabAtkins]
fantasai: i believe so
13:48:12 [TabAtkins]
astearns: objections?
13:48:26 [TabAtkins]
RESOLVED: text-box-trim does not trim further into the linebox than the outermost margin edge of any atomic inlines in the linebox
13:48:40 [dbaron]
(I presume this affects how text-box-trim affects block containers.)
13:48:43 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/11365
13:48:43 [github-bot]
Topic: [css-inline-3] -top/-bottom vs -over/-under
13:48:43 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11365.
13:49:05 [TabAtkins]
fantasai: in 10713 we resolved to add reorderable kewyrods to text-box-edge
13:49:12 [TabAtkins]
fantasai: i didn't edit that into the spec yet because i ran into this issue
13:49:16 [TabAtkins]
fantasai: what keywords do we actually want
13:49:30 [TabAtkins]
fantasai: in horizontal text top/bottom are pretty obvious. we ahve text-top/text-bottom etc
13:49:35 [TabAtkins]
fantasai: when you have vertical it's more interesting
13:49:43 [bkardell]
s/kewyrods/keywords
13:49:56 [TabAtkins]
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"
13:50:19 [TabAtkins]
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?
13:50:35 [TabAtkins]
fantasai: murakami-san proposed we be consistent with top/bottom keywords we have already.
13:50:45 [TabAtkins]
fantasai: i don't have a strong opinion, we just need to resolve on that
13:51:53 [TabAtkins]
florian: so that would be consistent with the opentype naming?
13:52:06 [TabAtkins]
fantasai: so over is sometimes top, sometimes left, sometime sright, depending on WM
13:52:14 [TabAtkins]
fantasai: top in CSS, aside from vertical-align, is always page top
13:52:22 [TabAtkins]
fantasai: but in vertical-align it's the over/udner side
13:52:30 [TabAtkins]
fantasai: which can be left/right
13:53:08 [TabAtkins]
TabAtkins: i was just confused, i thought florian was saying the opentype "top" wasn't always the css "over"
13:53:12 [TabAtkins]
fantasai: no, it's always the same
13:53:24 [TabAtkins]
jensimmons: so everyone's consistent that "top" isn't always top
13:54:08 [TabAtkins]
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
13:54:10 [TabAtkins]
fantasai: yeah we could
13:54:15 [TabAtkins]
florian: don't expect we'll need to tho
13:54:26 [TabAtkins]
astearns: so proposed resolution is we stay with text-top/text-bottom?
13:54:36 [TabAtkins]
fantasai: -top and -bottom for all keywords in this property
13:54:39 [TabAtkins]
astearns: objection?
13:55:04 [TabAtkins]
RESOLVED: use -top and -bottom as the direction suffix for all keywords in this property (referring to over/under)
13:55:25 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/10713
13:55:25 [github-bot]
Topic: [css-inline-3] Allow re-ordering of <text-edge> keywords
13:55:25 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10713.
13:55:43 [TabAtkins]
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
13:55:55 [TabAtkins]
fantasai: #11365
13:56:34 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/2528
13:56:34 [github-bot]
Topic: [css-fonts-4] Feature for making text always fit the width of its parent
13:56:34 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/2528.
13:56:40 [TabAtkins]
kizu: i have some slides
13:57:27 [TabAtkins]
kizu: [presents slides]
13:57:40 [TabAtkins]
kizu: this issue was opened back in 2018
13:57:59 [TabAtkins]
kizu: therea re many libraries that try to do this effect
13:58:09 [TabAtkins]
kizu: lots of typography examples in the real world, but it's not on the web
13:58:27 [TabAtkins]
kizu: i wrote two articles about some pure-css techniques
13:58:42 [TabAtkins]
kizu: these were my most popular articles, so clearly people want these features
13:59:00 [TabAtkins]
kizu: here's an example of text sizing to fit its container
13:59:21 [TabAtkins]
kizu: here's another example, obviously it's "fit to inline space", not necessarily width
13:59:43 [TabAtkins]
kizu: fitting text is complicated, this is why we didn't ahve it for a long time
13:59:50 [TabAtkins]
kizu: my workarounds are hacky, as usual
13:59:57 [TabAtkins]
kizu: but it's possible.
14:00:02 [TabAtkins]
kizu: there are no loops, it works
14:00:11 [TabAtkins]
kizu: want to talk about some complexities
14:00:19 [TabAtkins]
kizu: first issue is optical sizing
14:00:43 [TabAtkins]
kizu: generally when we size text the size is proportional to its font-size, but opsz also lets the font respond to its size
14:01:04 [TabAtkins]
kizu: see in this example, the change is non-linear. can even change the glyphs itself
14:01:15 [nigel]
nigel has joined #css
14:01:35 [TabAtkins]
kizu: another example, in cSS there can be fixed-size elements on the line, margins or letter-spacing, etc.
14:01:44 [TabAtkins]
kizu: so just getting text width and calcualting a ratio doens't work
14:01:58 [TabAtkins]
kizu: there are some cases you can't solve
14:02:22 [TabAtkins]
kizu: but we don't necessarily need to solve these, okay for them to be broken. i have some ideas to minimize issues tho
14:02:39 [TabAtkins]
kizu: one idea is when we first size the text, we freeze some values
14:02:54 [TabAtkins]
kizu: this is the most complex part, but i don't think obscure cases should prevent us from solving common ones
14:03:05 [TabAtkins]
kizu: common cases are straightforward, and fixed-size elements are solvable
14:03:14 [TabAtkins]
kizu: i wont' go thru full details but here are a few
14:03:16 [TabAtkins]
kizu: timing
14:03:43 [TabAtkins]
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
14:03:47 [TabAtkins]
kizu: this could be configurable
14:04:08 [TabAtkins]
kizu: with freezing...
14:04:18 [TabAtkins]
kizu: might need to render the text up to four times, but not more, to handle frozen sizes and optical sizing adjustments
14:04:48 [TabAtkins]
kizu: in the first step we render as normal, then freeze the nonlinear dependencies. later renderings we use those frozen sizes
14:05:33 [TabAtkins]
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
14:05:40 [TabAtkins]
kizu: for the API, a few options
14:05:48 [TabAtkins]
kizu: think we should start from font-size
14:06:03 [TabAtkins]
kizu: font-size is our minimum size. this lets us do wrapping and balancing.
14:06:40 [TabAtkins]
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
14:06:53 [TabAtkins]
kizu: and it's more accessible, font can't get too small to read
14:07:04 [TabAtkins]
kizu: so no scaling down
14:07:22 [TabAtkins]
kizu: a proposed proeprty is text-grow: <text-grow-type> || <max-font-size>
14:07:33 [TabAtkins]
kizu: <text-grow-type> = none | consistent | per-line
14:08:02 [TabAtkins]
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
14:08:11 [TabAtkins]
kizu: per-line change each line independently, after wrapping
14:08:14 [astearns]
q+ to ask about mixed font sizes
14:09:01 [TabAtkins]
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
14:09:12 [fantasai]
I might suggest vmin
14:09:34 [TabAtkins]
kizu: there's a codepen with a custom element that implements this algo
14:09:43 [florian]
q+
14:09:45 [TabAtkins]
kizu: all css, just some js to update a cq inside
14:09:53 [jensimmons]
q+
14:09:55 [TabAtkins]
kizu: all examples from this presentation are in the codepen
14:10:24 [TabAtkins]
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
14:10:37 [TabAtkins]
astearns: mixed font-sizes
14:10:41 [iank_]
q+
14:10:48 [TabAtkins]
astearns: similar to the case with non-text elements that are static
14:10:56 [TabAtkins]
astearns: if the content itself has multiple font sizes on a line, how is that handled
14:10:58 [astearns]
ack astearns
14:10:58 [Zakim]
astearns, you wanted to ask about mixed font sizes
14:11:07 [TabAtkins]
kizu: if font-size is in 'em' it works as expected
14:11:24 [TabAtkins]
kizu: they'll scale with the rest of the text
14:11:42 [TabAtkins]
kizu: there are some examples of that in my examples
14:12:10 [TabAtkins]
astearns: i think for some, maybe most calculations that's the way to go
14:12:36 [TabAtkins]
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
14:13:00 [TabAtkins]
kizu: there are some edge caess to consider. i think using the initial font-size for anything complex works for 99% of cases
14:13:19 [TabAtkins]
kizu: if an author wants to do something complicated, i think they can work around it.
14:13:20 [astearns]
ack florian
14:13:27 [astearns]
q+
14:13:28 [TabAtkins]
florian: i agree this is very desired
14:13:37 [TabAtkins]
florian: and if we need to cut corners in some cases it'll be okay, people will work around
14:13:44 [kizu]
Algorithm: https://www.tldraw.com/f/_sxU8eCZDcHbLvnDPMk4P
14:13:44 [kizu]
CodePen: https://codepen.io/kizu/pen/QwWVXxQ
14:13:44 [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)
14:13:47 [ntim]
ntim has joined #css
14:13:58 [TabAtkins]
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
14:14:03 [TabAtkins]
florian: floats and [another case]
14:14:04 [ntim]
present+
14:14:17 [TabAtkins]
florian: maybe it's in the algo, but not mentioned in the presentation. what happens if growing the height makes it narrower?
14:14:34 [TabAtkins]
kizu: my example uses CQ so it requirest containment. could require that if we need to.
14:14:48 [TabAtkins]
kizu: don't think we'd actually have a case where containment doesn't work but you want to fit a space
14:14:49 [kbabbitt]
s/[another case]/fragmentation/
14:14:59 [TabAtkins]
kizu: i think more complicated case is maybe initial-letter
14:15:03 [astearns]
ack jensimmons
14:15:17 [TabAtkins]
jensimmons: thanks for bringing this to the agenda, been talked about a long time
14:15:29 [TabAtkins]
jensimmons: definitely something authors want, provides beautiful possibilities for headlines/etc
14:15:31 [bramus]
+1
14:15:46 [TabAtkins]
jensimmons: it seems like your whole thing assumes the way you want to grow is to increase font-size.
14:15:53 [TabAtkins]
jensimmons: think that's common, but not necessarily only way
14:16:07 [astearns]
q- (same point as jen)
14:16:08 [TabAtkins]
jensimmons: maybe people want to keep the font-size but increase a font axis, like make it bolder
14:16:10 [astearns]
q-
14:16:28 [TabAtkins]
jensimmons: should maybe design it to do font-size scaling by default, but another control that lets you specify another control
14:16:32 [TabAtkins]
jensimmons: probably just one, to keep it simple
14:16:37 [ChrisL]
q+ to agree with jen
14:17:05 [TabAtkins]
jensimmons: a lot of examples you showed are classic, but something in those examples is a lot of variation - one line super big, etc
14:17:28 [TabAtkins]
jensimmons: interesting you broke it down between "consistent" and "per-line", but in your per-line it doesn't look like those posters
14:17:48 [noamr]
q+
14:17:50 [TabAtkins]
jensimmons: the amount of variation ends up pretty subtle, not as aesthetically pleasing
14:17:54 [TabAtkins]
jensimmons: so something to think about
14:18:11 [TabAtkins]
jensimmons: authors could force breaks, of course, making the worse rag ever before scaling
14:18:19 [astearns]
+1 to having authored forced breaks for larger variation per line
14:18:21 [TabAtkins]
jensimmons: authors would also possibly want to change the font per line
14:18:54 [TabAtkins]
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
14:19:13 [TabAtkins]
jensimmons: so then you'd linebreak, swap out fonts at the last minute, then scale to fit
14:19:33 [TabAtkins]
jensimmons: i think if you want to emulate those classic layouts you have to think about this
14:20:04 [TabAtkins]
kizu: for other axises - i was thinking about it, but couldn't come up with an algorithm that worked and was simple
14:20:15 [TabAtkins]
kizu: increasing font-size is just increasing proportional to the available space, with some wrinkles
14:20:27 [TabAtkins]
kizu: some fonts i saw coudl use optical sizing to achieve this effect.
14:20:35 [TabAtkins]
kizu: but don't think we can generally substitute
14:20:47 [TabAtkins]
kizu: other example, like increasing sapcing or using width axis, would be nice
14:20:58 [TabAtkins]
kizu: i think we can start with width and then see if there's any other axises we can depend on
14:21:15 [TabAtkins]
kizu: problem is axises aren't linear. not possible without looping
14:21:38 [TabAtkins]
kizu: we can maybe start with just consistent version and then see if people need the per-line version
14:21:53 [TabAtkins]
kizu: people can split the lines themselves for now, use a wrapper to apply different fonts
14:21:58 [TabAtkins]
kizu: not sure what the blockers are for nth-line
14:22:17 [florian]
q?
14:22:20 [TabAtkins]
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
14:22:27 [TabAtkins]
jensimmons: stretch and weight are most important
14:22:38 [TabAtkins]
jensimmons: optical sizing isnt' the way to pursue, i think. it's meant to be a tweak.
14:22:42 [TabAtkins]
jensimmons: and should peg to font-size
14:22:58 [TabAtkins]
jensimmons: but stretch and weight are two important options to make it bigger without changing font-size
14:23:04 [ChrisL]
q?
14:23:31 [TabAtkins]
kizu: yeah would be nice to have other controls, maybe possible to adjust the algorithm
14:23:54 [TabAtkins]
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
14:24:06 [florian]
q+
14:24:09 [TabAtkins]
kizu: can just adjust your spacing initally, then have the browser auto-adjust the font-size to fit
14:24:34 [TabAtkins]
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
14:24:56 [TabAtkins]
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.
14:25:05 [TabAtkins]
jensimmons: this is something people have been thinking about since the days of cufon
14:25:06 [astearns]
each line is the more important version, imo
14:25:16 [TabAtkins]
jensimmons: we should be ambitious and figure it out
14:25:53 [TabAtkins]
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
14:26:15 [astearns]
ack iank_
14:26:33 [TabAtkins]
iank_: one use-case we want to cover is shrinking, down to a minimum
14:26:56 [TabAtkins]
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
14:27:06 [TabAtkins]
iank_: think there's details to work out on how the actual scaling works
14:27:15 [TabAtkins]
iank_: just optical sizing doesn't cover all the degenerate cases
14:27:29 [TabAtkins]
iank_: one algo we might land on is effectively doing a transform, no additional glyph selection
14:27:43 [TabAtkins]
iank_: don't want this to be restricted to varaible fonts that do support this feature
14:28:05 [TabAtkins]
iank_: i just don't want us to get into a situation where we're bisecting the inline-size
14:28:34 [TabAtkins]
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.
14:28:45 [TabAtkins]
kizu: for transforms, was wondering if we wanted to do it this way
14:28:49 [florian]
[walking forward seems reasonable]
14:28:59 [TabAtkins]
kizu: but if there are non-text elements inside, like px margins, scaling might not look right
14:29:17 [TabAtkins]
iank_: i mean could scale the individual text segments, not necessarily the atomic inlines
14:29:31 [TabAtkins]
kizu: yeah could be good. would ahve to account for optical sizing
14:30:27 [RRSAgent]
I have made the request to generate https://www.w3.org/2025/04/01-css-minutes.html fantasai
14:30:35 [TabAtkins]
TabAtkins: Ian, I think you've been confused here - optical sizing isn't part of the proposal. it's just something that applies *when* you scale the size, if a font doesn't use it there's no issue
14:30:50 [TabAtkins]
kizu: my proposal does a few passes, applies optical sizing at one point then freezes it.
14:31:03 [TabAtkins]
kizu: currently four layouts, can skip them if there's no optical-sizing/etc
14:31:03 [iank_]
teams just crashed for me - but i don't think that all the cases are covered by the number of passes.
14:31:16 [jensimmons]
Yes, optical sizing just goes along for a ride when font sizing is made bigger or smaller. And it should do so here. Optical sizing is not designed to be _the mechanism_ for making a font bigger / smaller (in general, not just for this purpose).
14:31:43 [TabAtkins]
ChrisL: agree with Jen, but i'd like to elaborate
14:31:55 [TabAtkins]
ChrisL: given we already have variable fonts and they're becoming widespread, we shoudl design this primarily for variables
14:32:06 [TabAtkins]
ChrisL: many things you can do with varaible that you can't do with, like, only 3 fonts
14:32:18 [TabAtkins]
ChrisL: should just give reasonable results where you dont' have a variable font
14:32:30 [TabAtkins]
ChrisL: agree that size is one thing authors want to change, but the width and weight are other things
14:32:36 [TabAtkins]
ChrisL: not sure they'd want to just pick one
14:32:41 [TabAtkins]
ChrisL: can imagine setting breakpoints
14:32:55 [alisonmaher]
\me fantasai unfortunately the way that it was set up with the mics, it wasn't possible, but even so, the video camera in the room only shows people in the chairs closest to the front of the room
14:33:01 [jensimmons]
q+
14:33:03 [astearns]
ack ChrisL
14:33:03 [Zakim]
ChrisL, you wanted to agree with jen
14:33:03 [TabAtkins]
ChrisL: in terms of capabilities, people ahve wanted this for ages, convinced we should add but not sure exactly the details
14:33:18 [TabAtkins]
ChrisL: this isn't bisection, just accounting for changes, optical-sizing when applied can adjust the size a little again
14:33:29 [TabAtkins]
ChrisL: limited number of passes, not infinite looping
14:33:29 [jensimmons]
Yeah, maybe we don't want to limit it to one variable axis. Perhaps we could add a mechanism for setting a ratio between them — 33% font-stretch + 66% font-weight
14:33:43 [jensimmons]
or whatever the author wants, their ratio
14:33:44 [TabAtkins]
kizu: might want to think further about variable axis, but maybe could be a seaprate feature
14:33:58 [ChrisL]
qq+
14:34:08 [TabAtkins]
kizu: could say in css "for this font, from Xpx to Ypx change this axis in this way". used similar to optical sizing
14:34:22 [TabAtkins]
kizu: i think this might just be a separate feature then
14:34:44 [TabAtkins]
astearns: time check, we're supposed to be on a break now. emptying queue
14:34:48 [astearns]
ack ChrisL
14:34:48 [Zakim]
ChrisL, you wanted to react to ChrisL
14:35:04 [TabAtkins]
ChrisL: that feature does exist on opentype, a "composite" axis you declare in the font
14:35:04 [jensimmons]
I disagree with what Roman just said, that everything should be tied to font size & we grow/shrink font-size in order to change the axis
14:35:04 [TabAtkins]
ChrisL: %s of various other features
14:35:19 [TabAtkins]
ChrisL: you can expose controls you want users to have, the width/etc are low-level.
14:35:21 [astearns]
ack noamr
14:36:00 [TabAtkins]
noamr: i wonder how much of this is seeking something more like svg scaling, just scaling the path as-is
14:36:15 [TabAtkins]
noamr: svg text can fit to width, just icky right now
14:36:30 [TabAtkins]
noamr: so i wonder if these are separate features so you don't need to deal with all the font complications
14:36:53 [astearns]
ack florian
14:36:56 [TabAtkins]
kizu: i'm not familiar with how it works in svg, can't answer
14:37:01 [dholbert]
dholbert has joined #css
14:37:06 [TabAtkins]
florian: folloiwng up, agree size isn't the only thing we want to vary
14:37:16 [TabAtkins]
florian: okay with starting on size as long as th eproperty opts in
14:37:31 [TabAtkins]
florian: in the example, max-font-size looks a bit special, we'll need other min/maxes
14:37:43 [TabAtkins]
florian: so we should design the syntax so we can give constraints on everything we want to do
14:37:51 [TabAtkins]
florian: but can start with the subset
14:37:58 [ChrisL]
The SVG one is underspecified and is purely geometric scaling
14:38:15 [TabAtkins]
florian: following up on Jen's line-by-line wanting extreme line differences, maybe when we turn this on we do different linebreaking
14:38:19 [noamr]
Yes, I think in some cases what people seek is geometric scaling
14:38:30 [TabAtkins]
florian: authors can also work around it, can use hidden <br> that are non-hidden by an @supports
14:38:51 [TabAtkins]
florian: annoying, but when it's for a very specific heading or something, we have workarounds
14:38:52 [astearns]
ack jensimmons
14:39:12 [TabAtkins]
jensimmons: agreeing with Chris, taking back my smaller thinking, probably is good to have a mix of axises
14:39:41 [TabAtkins]
jensimmons: probably should have a font model where we grow or shrink, but author can set up what that means. different %s of font-size/weight/stretch/etc
14:40:02 [TabAtkins]
jensimmons: and if the author wants 100% font-size or whatever, they can get it
14:40:12 [TabAtkins]
jensimmons: important to design so if you don't want font-size to change at all it doesn't change
14:40:21 [Kurt]
Not quite the same behavior, but SVG also has textLength https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/textLength
14:40:46 [TabAtkins]
astearns: since that could be quite complex, and we want to allow that sort of complexity, would it make sense to be able to express how you want things to resize in a @font-face rule?
14:40:56 [TabAtkins]
astearns: that then applies in this property, go segment-by-segment to figure out what's allowed by the font being used
14:41:23 [TabAtkins]
ChrisL: not sure that's the right palce for it, can see doing various controls depending on what space is available. @font-face makes it generic for all uses
14:41:37 [jensimmons]
I also do not think the SVG thing is a solution. Font designers have carefully made text that looks fantastic at all sorts of sizes. Just growing text like it's an image ignores all of this work that's in the font.
14:41:44 [TabAtkins]
florian: base don how you combine and limit the axises, need some room in the property to accommodate it. starting simple but going more complex.
14:42:00 [TabAtkins]
astearns: so i'm hearing lots of feature requests, but no opposition to try and solve this.
14:42:09 [TabAtkins]
astearns: should we have a resolution to start this in an ED?
14:42:19 [TabAtkins]
TabAtkins: Fonts 5?
14:42:34 [TabAtkins]
fantasai: not Inline. Maybe Text, but I think Fonts is best
14:42:38 [TabAtkins]
ChrisL: Yes, Fonts
14:42:52 [TabAtkins]
astearns: roman, are you volunteering or do you want someone else?
14:42:58 [TabAtkins]
kizu: never written spec before, could collab
14:43:24 [TabAtkins]
astearns: proposed resolution is to start working on this in Fonts 5, and we can open individual issues once there's some starting text
14:43:30 [TabAtkins]
astearns: objections?
14:43:42 [bkardell]
+1
14:43:54 [TabAtkins]
RESOLVED: Start work on this in Fonts 5 and begin incubating.
14:44:04 [TabAtkins]
astearns: appointing Romas as co-editor of Fonts 5
14:44:16 [TabAtkins]
ChrisL: was going to entrap him but I'm okay with him going straight into it
14:44:24 [TabAtkins]
RESOLVED: Roman as co-editor for Fonts 5
14:44:30 [noamr]
jensimmons: it depends, sometimes authors want to animate the scaling in a way that fits in a particular box without changing anything but the geometry, using the text as something more decorative. I agree that it doesn't solve *everything* and that solving it on the font level is a lot more powerful
14:44:30 [TabAtkins]
github-bot, end topic
14:44:35 [TabAtkins]
<br dur=16min>
14:45:09 [bramus]
s/jensimmons: it depends/@jensimmons, it depends
14:45:57 [noamr]
ha yes sorry, I wasn't scribing: )
14:54:53 [lea]
ChrisL: https://github.com/w3c/csswg-drafts/issues/10573#issuecomment-2769649221
14:59:09 [ydaniv1]
ydaniv1 has joined #css
15:02:32 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/11609
15:02:32 [github-bot]
Topic: [css-borders-4] Resolve on range for `superellipse` parameters
15:02:32 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11609.
15:03:41 [TabAtkins]
noamr: this and the next issue will resolve togheter
15:03:53 [TabAtkins]
noamr: smfr and i have been working hard on the details for corner-shape. several questions to resolve
15:04:00 [TabAtkins]
noamr: one is about the superellipse paramter
15:04:22 [TabAtkins]
noamr: as you might recall, we have corner-shape keywords, but can also give it a number via a super-ellipse function
15:04:37 [TabAtkins]
noamr: in the spec righ tnow, the number gives the exponent of the curvature
15:04:45 [TabAtkins]
noamr: there was a proposal to use the log2 of that
15:05:17 [TabAtkins]
noamr: if i go all the way to concave, k=0, log2=-inf
15:05:25 [TabAtkins]
noamr: middle, bevel, k=1, log2=0
15:05:39 [TabAtkins]
noamr: full sharp convex, k=inf, log=inf
15:05:45 [TabAtkins]
noamr: round, k=2, log2=1
15:05:52 [TabAtkins]
noamr: squircle, k=4, log2=2
15:05:58 [TabAtkins]
noamr: there's a table in the issue
15:06:12 [TabAtkins]
noamr: so the log2 version goes from -inf to inf, and maybe a bit more friendly
15:06:19 [TabAtkins]
noamr: k version goes 0-inf
15:06:29 [astearns]
https://noamr.github.io/squircle-testbed/corner-visualizer/corner-animation.html
15:06:37 [TabAtkins]
noamr: advantage of k version, when people talk about super-ellipses in other contexts they're usually talking just about the k version
15:06:45 [TabAtkins]
noamr: but i don't feel strongly about either
15:06:46 [TabAtkins]
q+
15:06:52 [astearns]
ack TabAtkins
15:07:13 [fantasai]
TabAtkins: I do feel strongly that the log2 version is better here, because the shapes are symmetrical across the bevel
15:07:40 [Francis_Storr]
Francis_Storr has joined #css
15:07:50 [fantasai]
TabAtkins: It also makes the range of useful values more reasonable. Going out to log2=10 makes it effectively a sharp corner, and the range past there is infinite
15:07:59 [fantasai]
TabAtkins: Same thing applies in negative direction.
15:08:06 [fantasai]
TabAtkins: This is easy to work with.
15:08:21 [fantasai]
TabAtkins: in the straight K version, sharp corner is a non-obvious fraction slightly above zero...
15:09:01 [fantasai]
TabAtkins: Symmetry really helps out with usability. Can put a note in the spec that k in academic papers is usually different, but for authors they won't care. We should prioritize usability for authors, and log2 variant gets us there
15:09:06 [TabAtkins]
fantasai: +1
15:09:09 [bramus]
+1
15:09:22 [TabAtkins]
noamr: literature could be Figma, for example
15:09:29 [TabAtkins]
noamr: author tooling can expose it too
15:09:30 [ydaniv3]
ydaniv3 has joined #css
15:09:31 [Kurt]
q+
15:09:36 [astearns]
ack Kurt
15:09:45 [TabAtkins]
Kurt: does this mean specifcying infinity you need to use calc()?
15:09:55 [TabAtkins]
noamr: no, can just have an infinity keyword
15:10:01 [TabAtkins]
noamr: that's in the spec right now for positive infinity
15:11:04 [TabAtkins]
noamr: i think people are okay with this not aligning with other tools i'm okay with going with log2
15:11:12 [TabAtkins]
s/think people/think if people/
15:11:22 [TabAtkins]
astearns: so it sounds like proposed is to use log2 range?
15:11:28 [TabAtkins]
jensimmons: would like to know what smfr thinks?
15:11:38 [TabAtkins]
noamr: he's commented on the issues, he doesn't have a strong opinion
15:11:55 [TabAtkins]
q+
15:12:13 [fantasai]
TabAtkins: There's an interpolation issue later on...
15:12:14 [lea]
weak agree for the log2 version from me too
15:12:36 [fantasai]
TabAtkins: Other reason I really like log2, when we do interpolation, making sure that works symmetrically requires doing log2 anyway
15:12:42 [fantasai]
TabAtkins: so exposing more directly to authors is a good thing
15:12:52 [TabAtkins]
noamr: yeah, the interpolation function si clsoe to log2
15:13:24 [TabAtkins]
astearns: so it sounds like people are moderate to weakly in favor of log2
15:13:29 [TabAtkins]
fantasai: i think tab's arguments are convincing to me
15:13:35 [TabAtkins]
astearns: so proposed reoslution is to use the log2 range
15:13:45 [TabAtkins]
RESOLVED: Use the log2 range for the superellipse parameter
15:13:56 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/11608
15:13:56 [github-bot]
Topic: [css-borders-4] Interpolation of `corner-shape` superellipsis
15:13:56 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11608.
15:14:00 [dholbert]
dholbert has joined #css
15:14:06 [TabAtkins]
noamr: this shoudln't be contentious
15:14:14 [TabAtkins]
noamr: let me show how it interpolates
15:14:52 [TabAtkins]
noamr: the interpolation takes the "half corner", th emiddle point, put it on the diagonal line and interpolate *that*. work backwards to get the superellipse parameter
15:15:51 [TabAtkins]
noamr: otherwise any interpolation in the paramter space itself would spend too much time in the extreme values
15:16:01 [fantasai]
TabAtkins: This does sound like the most reasonable interpolation method
15:16:14 [TabAtkins]
astearns: any indication from Simon?
15:16:20 [TabAtkins]
noamr: he did this visualization.
15:16:29 [TabAtkins]
noamr: everything i'm presenting here I worked together with Simon
15:16:31 [TabAtkins]
ack
15:16:31 [astearns]
ack TabAtkins
15:16:48 [TabAtkins]
fantasai: TAb, you mentioned the "effectively square" is 10 or so on both sides
15:16:51 [TabAtkins]
fantasai: above 10
15:17:03 [TabAtkins]
fantasai: it basically doesn't do much?
15:17:34 [TabAtkins]
noamr: it's basically equivlanent unless your screen is enormous
15:17:48 [TabAtkins]
fantasai: should we declare that 10 gets rounded to a sharp corner?
15:18:13 [TabAtkins]
fantasai: so the CSS range is effectively -10 to 10?
15:18:23 [TabAtkins]
astearns: if your shape is very large you might get a jump
15:18:48 [TabAtkins]
noamr: shouldn't have it as part of interpolation
15:18:57 [TabAtkins]
noamr: the animation would appear to be faster in the middle if we did that
15:19:45 [TabAtkins]
noamr: in the current chrome prototype we *do* clamp to 10/-10, it makes the math easier
15:19:51 [TabAtkins]
noamr: but not sure it's useful in the specs
15:20:19 [TabAtkins]
fantasai: the reason it might be useful is, it's harder for the authro to know that to get an actually sharp corner they need to use a much bigger value
15:20:51 [fantasai]
TabAtkins: The interpolation behavior defined here is that we don't interpolate the parameter, we interpolate the diagonal line.
15:21:00 [fantasai]
TabAtkins: so you get a linear interpolation through the diagonal space
15:21:40 [fantasai]
TabAtkins: so you get a visually smooth value instead of changing speed
15:21:53 [fantasai]
fantasai: Would it make sense to make that the parameter?
15:22:01 [fantasai]
TabAtkins: No, because then squircles and other common values would be weird numbers.
15:22:11 [TabAtkins]
noamr: yeah, round is sqrt(2)/2
15:22:18 [TabAtkins]
astearns: any other comments/question?
15:22:50 [TabAtkins]
astearns: so proposed is we interpolate linearly across the corner diagonal and compute the parameter backwards from that
15:22:52 [TabAtkins]
astearns: objection?
15:23:01 [TabAtkins]
RESOLVED: interpolate linearly across the corner diagonal and compute the parameter backwards from that
15:23:17 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/11607
15:23:17 [github-bot]
Topic: [css-borders-4] naming of the "not curved" (90deg convex) keyword for `corner-shape`
15:23:17 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11607.
15:23:32 [TabAtkins]
noamr: right now this value is named "straight", but i dont like it
15:23:44 [TabAtkins]
noamr: this is when we treat it as a non-rounded rect
15:23:50 [TabAtkins]
noamr: other proposals are "square" or "none"
15:23:54 [TabAtkins]
noamr: or "rect"
15:24:05 [smfr]
smfr has joined #css
15:24:08 [TabAtkins]
noamr: i think in the issue consensus was for "square"
15:24:12 [TabAtkins]
astearns: and Simon prefers square
15:24:30 [fantasai]
TabAtkins: Prefer square to straight. Straight sounds like it means bevel.
15:24:34 [TabAtkins]
astearns: any concerns over choosing square?
15:24:47 [fantasai]
RESOLVED: Use square for opposite of notch
15:25:08 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/11610
15:25:08 [github-bot]
Topic: [css-borders-4] Specify how borders are rendered for `corner-shape`
15:25:08 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11610.
15:25:35 [TabAtkins]
noamr: this has been a lot of work
15:25:44 [TabAtkins]
noamr: how detailed does this need to be in the spec?
15:25:55 [TabAtkins]
noamr: there's an intricate algorithm to make the corner appear consistent
15:26:34 [TabAtkins]
noamr: like if you have two adjacent scoops, we want them to cut into each other
15:26:48 [TabAtkins]
noamr: top-right and bottom-right both "scoop 50%"
15:27:04 [TabAtkins]
noamr: the outer border follows the shape math. the inner borders can overlap
15:27:29 [TabAtkins]
noamr: don't have a clear idea of how to do this in the spec, but maybe we wnat to say that the border thicknesses need to be consistent at the start and end
15:27:40 [TabAtkins]
noamr: border overlap does not constrain the radius
15:27:46 [TabAtkins]
noamr: and are clipped by the outer radius
15:27:59 [TabAtkins]
noamr: so you can create shapes that fold into themselves
15:28:15 [astearns]
ack fantasai
15:29:20 [TabAtkins]
fantasai: I think the behavior you're takling about is that we determine the radiuses per the formula, we shape the outer border edge, then we shape the inner border edge to match by offsetting the endpoints of the corner shape (where it connects to the straight part of the border) by insetting those normal to the curve, and using that to inperolate the inner line, then clipping the inner curve
15:29:33 [TabAtkins]
fantasai: so you don't get overlapping
15:29:42 [TabAtkins]
fantasai: i do think we need to spec it
15:30:08 [TabAtkins]
noamr: also, for very high or low curvatures, outside of 1/-1, we adjust the inner curvature
15:30:28 [TabAtkins]
noamr: in this example, the inner and outer have a differnet superellipse value to make the thickness appear consistent
15:30:57 [TabAtkins]
noamr: so question is to what extent is needed to specify
15:31:15 [TabAtkins]
fantasai: need to specify as far as getting the same math, so impls can match.
15:31:29 [fantasai]
fantasai: Can allow for approximation, but we need interop here
15:31:44 [fantasai]
TabAtkins: Should be testable in WPT with some amount of pixel fuzziness
15:32:23 [fantasai]
TabAtkins: Is your inner ellipse calculation similar to the interpolation, where you get the diagonal width correct and then figure out the superellipse param?
15:32:33 [TabAtkins]
noamr: not exactly, it creates a vector... it's not just moving the lines, the superellipse needs the same center too
15:32:40 [TabAtkins]
noamr: it's all similar math
15:33:09 [TabAtkins]
noamr: i create a line perpendicular to the hull (two straight lines snug to the superellipse) and make something perpendicular to that
15:33:14 [TabAtkins]
noamr: i can't use the half corner here
15:33:54 [TabAtkins]
noamr: i think the important bit here is if we're okay with the behavior here, that the border width doesn't affect the outer-radius shape
15:34:02 [TabAtkins]
noamr: so it stays the same as for normal rounded rects
15:34:07 [TabAtkins]
fantasai: i think that makes sense
15:34:08 [TabAtkins]
+1
15:34:27 [fantasai]
TabAtkins: In particular, getting the star shape is a desired behavior
15:34:55 [fantasai]
PROPOSED: Radii are resolved for the outer shape just as for rounded-rect
15:35:22 [fantasai]
RESOLVED: Radii are resolved for the outer shape just as for existing border-radius rounded-rect shapes
15:36:03 [fantasai]
fantasai: inner radius gets clipped as soon as it hits any side or other corner
15:36:36 [fantasai]
PROPOSED: Inner radius gets clipped as soon as it intersects the inner edge of any adjacent side/corner
15:36:47 [smfr]
q+
15:36:48 [fantasai]
s/radius/radius curve/
15:36:56 [TabAtkins]
(exact details matter when the borders are partially-transparent, fwiw)
15:36:58 [fantasai]
PROPOSED: Inner curve gets clipped as soon as it intersects the inner edge of any adjacent side/corner
15:37:07 [astearns]
ack smfr
15:37:18 [TabAtkins]
smfr: i think we do radius cosntraints for existing round rects, we shirnk so they dont' join on the inside?
15:37:26 [TabAtkins]
fantasai: no, it's the outer curve we care about
15:37:42 [TabAtkins]
smfr: just want to make sure we have consistent behavior
15:37:52 [TabAtkins]
fantasai: right, we just now resolved to be consistent with the outer radius.
15:38:18 [TabAtkins]
fantasai: you don't really have the problem the inner radius for curves
15:38:35 [TabAtkins]
fantasai: the current formula onlya pplies to the outer radius
15:38:44 [TabAtkins]
fantasai: and as a consequence the inner radius doesn't intersect
15:38:52 [TabAtkins]
fantasai: but it's the outer radius that's controlled by border-radius
15:39:06 [fantasai]
RESOLVED: Inner curve gets clipped as soon as it intersects the inner edge of any adjacent side/corner
15:39:25 [fantasai]
PROPOSED: smfr and noam to spec the math that makes the inner curve look good
15:39:49 [fantasai]
RESOLVED: smfr and noam to spec the math that makes the inner curve look good
15:40:04 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/11662
15:40:04 [github-bot]
Topic: [css-borders-4] Interaction of single-path `border-shape` with non-uniform `border-width`
15:40:04 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11662.
15:40:22 [TabAtkins]
noamr: similar demo here
15:40:26 [TabAtkins]
noamr: was discussed last f2f
15:40:32 [TabAtkins]
noamr: border-shape is not the same as corner-shape
15:40:40 [TabAtkins]
noamr: border can be any path or any two paths
15:40:58 [dholbert]
dholbert has joined #css
15:40:59 [TabAtkins]
noamr: question is how/if this should interact with border-width and border-color
15:41:05 [TabAtkins]
noamr: i foudn some use-cases where i think it should
15:41:12 [TabAtkins]
noamr: that's what's on the screen
15:41:19 [TabAtkins]
noamr: things that are *like* a box but a little off
15:41:30 [TabAtkins]
noamr: this is almost a rectangle, but with slanted lines and a curved bottom
15:41:46 [TabAtkins]
noamr: and maybe the author would want the four sides of the box to take width and color from border-*
15:42:03 [TabAtkins]
noamr: what i do here is i take each segment of the path and check its slope
15:42:11 [TabAtkins]
noamr: if takes from the side it's closest to
15:42:30 [TabAtkins]
noamr: so for any clockwise ship that's pseudo-rectangular, it'll attempt to do the right thing
15:42:44 [TabAtkins]
noamr: it doesn't work great with beziers that are a little crazy
15:43:07 [dholbert]
dholbert has joined #css
15:43:07 [schenney]
schenney has joined #css
15:43:07 [flackr]
flackr has joined #css
15:43:07 [noamr]
noamr has joined #css
15:43:07 [ydaniv]
ydaniv has joined #css
15:43:07 [github-bot]
github-bot has joined #css
15:43:07 [kizu]
kizu has joined #css
15:43:07 [alisonmaher]
alisonmaher has joined #css
15:43:07 [kbabbitt]
kbabbitt has joined #css
15:43:07 [Kurt]
Kurt has joined #css
15:43:07 [jbroman]
jbroman has joined #css
15:43:07 [keithamus]
keithamus has joined #css
15:43:07 [tusf]
tusf has joined #css
15:43:07 [jcraig]
jcraig has joined #css
15:43:07 [cmp]
cmp has joined #css
15:43:07 [foolip]
foolip has joined #css
15:43:07 [dbaron]
dbaron has joined #css
15:44:17 [TabAtkins]
noamr: another option i looked at is the split curves at the inflection point, where it changes direction
15:44:25 [TabAtkins]
noamr: then beziers can feel a bit more accurate
15:44:47 [TabAtkins]
noamr: but from my experiments so far, this would be more understandable for authors. to not split. they can split if they want to.
15:44:58 [fantasai]
TabAtkins: So if I understand...
15:45:02 [smfr]
can't hear tab
15:45:26 [fantasai]
TabAtkins: For each path segment, you look at just the start and end point. Find the line between them. Identify that with one of the four sides depending on its angle.
15:45:45 [fantasai]
TabAtkins: That's why this purple one is identified with bottom
15:46:01 [fantasai]
noamr: Right, this is identified with the bottom edge because clockwise path
15:46:12 [TabAtkins]
noamr: a lot of shapes and authors won't need this, their shape isn't boxy at all
15:46:22 [TabAtkins]
noamr: but then they could jsut give it a uniform border-wdith and color and they wouldn't get this effect
15:46:34 [astearns]
ack fantasai
15:46:58 [smfr]
q+
15:47:02 [TabAtkins]
fantasai: so one concern i have here is, by being tied to the direction of the path, if you flip the path (which you might want to do if you're respondign to writing direction) you'll associate the bottom with the top/etc
15:47:06 [TabAtkins]
fantasai: which probably isn't intended
15:47:18 [TabAtkins]
fantasai: i wonder if there's a way to do this that doesn't carea bout CW vs CCW
15:47:31 [TabAtkins]
noamr: we always work on the CW version of the path. if the path is CCW we reverse the order first
15:47:41 [TabAtkins]
noamr: if it's got subpaths we do it for each subpath separately
15:47:49 [astearns]
ack smfr
15:47:50 [TabAtkins]
noamr: each subpath, we make it clockwise, then check each segment
15:48:04 [TabAtkins]
smfr: something elika just reminded me of is animations
15:48:19 [TabAtkins]
smfr: if you evaluate the path association live, you could have colors flickering as the path changes
15:48:32 [TabAtkins]
noamr: yeah ifyou're animating the path, you probably want uniform border colors
15:48:42 [TabAtkins]
noamr: but when you're close to a box you probably do want this.
15:48:56 [TabAtkins]
smfr: my concern here is just, i foresee some ugly paths coming out of this
15:49:11 [TabAtkins]
smfr: we spent a lot of time getting corner-shape to look nice, but it seems like this wouldn't
15:49:18 [TabAtkins]
noamr: i think that's generally the case for border colors
15:49:41 [fantasai]
TabAtkins: I think we should have a way to manually associate colors and segments, but I think this is probably the most correct default assignment
15:49:48 [fantasai]
TabAtkins: if you do just want uniform colors, you can set uniform colors
15:50:02 [fantasai]
TabAtkins: There's space open for a border-shape-colors property to associate with the segments
15:50:11 [fantasai]
TabAtkins: that would allow consistent coloring across an animation
15:50:12 [Hoch]
Hoch has joined #css
15:50:12 [smfr]
q+
15:50:20 [fantasai]
TabAtkins: We shouldn't require authors to spec by default
15:50:20 [astearns]
ack smfr
15:50:28 [TabAtkins]
smfr: this isn't just about colors tho, right? it's also width
15:50:38 [TabAtkins]
TabAtkins: yes, but i think same argument applies
15:51:01 [TabAtkins]
smfr: i haven't played with this too much, but my suspicion is some paths it'll give okay results, others bad, potentially flickery if animated
15:51:13 [TabAtkins]
smfr: question is just if authors want this, versus just specifying the two path version
15:51:40 [fantasai]
TabAtkins: I want to avoid requiring 2-path version as much as possible. It's unusable for hand authoring.
15:51:49 [fantasai]
TabAtkins: Shouldn't be requiring it for simple shapes.
15:51:54 [TabAtkins]
smfr: i think that's okay, many shapes will be tooling in the long run
15:52:05 [TabAtkins]
smfr: it's possible take one shape and make minor edits to get the inside shape
15:52:22 [fantasai]
TabAtkins: If doing just a quadrilateral, it's not impossible to offset and get inner shape
15:52:39 [fantasai]
TabAtkins: but in that case I just want this sort of adjustment: give each side a width. That's what border-width does for me.
15:53:05 [fantasai]
TabAtkins: In a large section of common cases, this will give good behavior. And for more unusual cases, we can either have manual overrides or have authors use 2-path version.
15:53:49 [TabAtkins]
astearns: simon, are you concerned enough about this that you'd prefer just having something radically simple for single-path version that doesn't do any widths and colors? that requires using two-path or manual override for something else?
15:54:00 [TabAtkins]
smfr: i'm not sure. i think i'd like more time to experiment
15:54:02 [astearns]
ack fantasai
15:54:11 [TabAtkins]
fantasai: i think i'd probably +1 that
15:54:24 [TabAtkins]
fantasai: ther'es four options in the original comment here, what was your analysis of those four?
15:55:03 [TabAtkins]
noamr: uniform border width (option 1), we can always achieve by ignoring the other borders. i think people would just be confused why their border-bottom isn't being used
15:55:09 [TabAtkins]
noamr: but we coudl always do it, it's simplest
15:55:39 [TabAtkins]
noamr: option 2 (cutoff points with interpolation), it's bascially this (the current demo) but the cutoff points are determined by the segment
15:55:59 [TabAtkins]
noamr: when i tried it, it gave worse results than using the slope
15:56:16 [TabAtkins]
noamr: rotated shapes in particular
15:56:28 [TabAtkins]
noamr: option 3, point-by-point tangent, we don't know how to implement it
15:56:38 [TabAtkins]
noamr: great api in theory, really complicated.
15:56:48 [TabAtkins]
noamr: need to convert this into an inner and outer path
15:57:10 [TabAtkins]
noamr: closest i got to that was splitting a bezier, like i showed, at inflection points or something
15:57:28 [TabAtkins]
noamr: so you'd have the path as a bunch of smaller segments and then connect from there
15:57:31 [TabAtkins]
noamr: but that would be even more jittery with animations
15:57:48 [TabAtkins]
noamr: authors can achieve it thesemvles by splitting segments into pieces
15:58:15 [TabAtkins]
noamr: so option 4 is the nearest border. if you have a small rectangle close to the right, you'd get all the right-width styles, doesn't look right.
15:58:28 [TabAtkins]
noamr: the slope version i think gives the best results when the shape has some relationship with a box
15:58:39 [TabAtkins]
astearns: any other comments?
15:58:40 [fantasai]
fantasai: thanks
15:58:52 [TabAtkins]
noamr: i think we can leave it unresolved for now, if simon isn't sure about it
15:59:10 [TabAtkins]
astearns: yeah some more examples, looking at things that approximate rectangles less
15:59:24 [TabAtkins]
noamr: yeah, my intention wasn't necessarily to resolve, but to open people's minds to the topic
15:59:29 [TabAtkins]
astearns: okay, take it back to the issue
15:59:36 [TabAtkins]
github-bot, end topic
15:59:43 [TabAtkins]
<br dur=1h>
15:59:52 [jfkthame]
present-
15:59:55 [TabAtkins]
astearns: will have a short presentation on an idea for declarative animations, then get into forms
15:59:56 [smfr]
present+
16:02:40 [Linux_Kerio]
Linux_Kerio has joined #css
16:06:16 [Linux_Kerio]
Linux_Kerio has joined #css
17:01:12 [alisonmaher]
alisonmaher has joined #css
17:01:58 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/12029
17:01:58 [github-bot]
Topic: [css-animations-2] Add declarative syntax for starting an animation in response to an input event
17:01:58 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12029.
17:02:55 [TabAtkins]
szager: This is very rough sketch, not prepared to depend every details
17:03:06 [TabAtkins]
szager: responsiveness is important part of good perf, always a struggle
17:03:16 [TabAtkins]
szager: big part is input events require main-thread processing
17:03:30 [TabAtkins]
szager: if you're familiar with Core Web Vitals, something we emphasize is interaction to first paint
17:03:53 [TabAtkins]
szager: looking at IMP measurements in the wild, at higher percentiles main-thread processing >50% of that first response delay
17:04:07 [TabAtkins]
szager: so we want to solve, how can we provide visual repsonse to input events without main thread processing
17:04:19 [TabAtkins]
szager: so i think this proposal is in-line with compositor-driven animations
17:04:27 [TabAtkins]
szager: we set up the animation in advance then hand it off to the compositor
17:04:46 [TabAtkins]
szager: i'll say, my terminology is chrome-specific but i think the principles apply to everyone, they'll be implementable for everyone
17:05:05 [TabAtkins]
szager: so we create an animation on the main thread, then trasnfer it to compositor thread if possible, and it can run smoothly after that
17:05:22 [TabAtkins]
szager: in that spirit, we shoudl be able to do that (set up in advance) but rather than a time delay, say we'll start when we detect an input event
17:05:32 [TabAtkins]
szager: currently in web platform, input events are only dete3ctable on main thread
17:05:50 [TabAtkins]
szager: but this declarative syntax lets us analyze that and enact that on the compositor thread before it even hits the main thread
17:06:04 [TabAtkins]
szager: so the result is we cut out the main-thread processing entirely when we start processing an input event
17:06:23 [TabAtkins]
szager: big risk up front - this is a predictive model, like thread scrolling or composited animations
17:06:45 [TabAtkins]
szager: we're predicting that, if the main thread weren't blocked, it would say we shoudl run this animation. this can be wrong - the main thread might try to cancel it but it's blocked
17:07:04 [TabAtkins]
szager: in composited animations, the downside of the prediction being incorrect isn't important
17:07:10 [TabAtkins]
szager: in this it could be a bit more consequential
17:07:21 [TabAtkins]
szager: someone could click on something, animation starts immediatley suggesting the click was received
17:07:38 [astearns]
q+
17:07:41 [TabAtkins]
szager: and then eventually when we flush the rendering and actually deal with the input, it could just stop
17:07:51 [TabAtkins]
szager: could be weird for the user to see this inconsistent animation
17:08:00 [TabAtkins]
szager: so that's biggest risk i think. should keep our eyes on it
17:08:13 [TabAtkins]
astearns: couple question
17:08:31 [TabAtkins]
astearns: are you at all worried about having multiple things trigger off of a user interaction, and have the animation kick off long before any secondary effects on the main thread?
17:08:40 [astearns]
ack astearns
17:08:49 [flackr]
q+
17:08:54 [smfr]
q+
17:08:54 [TabAtkins]
szager: at least for chrome, our devrel, we always push to give a visual response asap
17:09:13 [TabAtkins]
szager: so our guidacne is to start the animation *immediately*, and only once that's actually running should you do your business logic
17:09:28 [ydaniv]
q+
17:09:37 [TabAtkins]
szager: so there's always a risk that main-thread processing will invalidate what we're starting. This isn't a replacement for main-thread handling.
17:09:46 [TabAtkins]
szager: we're just taking that first step (kick the animation immediatley) and making it declarative
17:09:55 [TabAtkins]
szager: so the rest of the model is the same
17:10:03 [TabAtkins]
astearns: that's helpful
17:10:06 [emilio]
present+
17:10:19 [TabAtkins]
astearns: the other thing is, a concern about having some user events with this preemptive animation, and other where they're not
17:10:37 [TabAtkins]
astearns: there are several user inputs in a row, some trigger fast and others are slow, and the reaction to user events is out of order
17:10:45 [astearns]
ack flackr
17:11:01 [TabAtkins]
flackr: in case people ahven't recognized this, thi si sperfectly analogous to scrolling
17:11:15 [TabAtkins]
flackr: in that you can set up a scroll on the compositor that is invalidated by a scrollTo in the next frame
17:11:22 [TabAtkins]
flackr: so it's not new, and i think this is a reasonable explanation
17:11:26 [TabAtkins]
flackr: some more cmplications tho
17:11:37 [TabAtkins]
flackr: some event types are only generated if other types aren't preventDefaulted
17:11:43 [TabAtkins]
flackr: like click can be canceled by down/up
17:11:58 [TabAtkins]
flackr: so we need to either restrict to primary events, or do something else
17:12:09 [kurt]
kurt has joined #css
17:12:10 [TabAtkins]
flackr: also, the user interacts with what they see, they're not in the new frame yet
17:12:42 [TabAtkins]
flackr: so this does feel better. i click on what i see, th enext frame can certainly move it or whatever, but maybe we should do hit testing in the frame the user is seeing rather than the positions that dom modifications see
17:12:47 [TabAtkins]
flackr: maybe we should explore that
17:13:04 [TabAtkins]
szager: the idea of doing event hit testing based on last displayed content has been proposed a millino times, it's a can of worms.
17:13:09 [TabAtkins]
szager: i like the idea, but it's a breaking change
17:13:20 [TabAtkins]
szager: but that's the only thing i don't like about it. in every other respect it's better i think.
17:13:28 [TabAtkins]
szager: don't know that i want to conflate that with this project tho
17:13:36 [TabAtkins]
szager: other point about non-primary events
17:13:51 [TabAtkins]
szager: the reason we can do this project in chrome is events arrive on compositor before they hit the main thread
17:14:04 [TabAtkins]
szager: but we only have limited insight into the input targetting
17:14:09 [TabAtkins]
szager: our hit-testing is non-canonical
17:14:22 [TabAtkins]
szager: so like we can't do a strict determination fo the event target until we hit the main thread
17:14:28 [TabAtkins]
szager: so that's a source fo inaccuracy
17:14:41 [TabAtkins]
szager: part of this project would be to see ho wmuch more hit-testing capability we need to add to our compositor thread
17:14:49 [TabAtkins]
szager: and think it would be a simlar process for other browsers
17:15:08 [TabAtkins]
szager: end-gaem of that process is doing precise hit-testing on compositor thread from the msot recently displayed content
17:15:20 [TabAtkins]
szager: so it's in that arena. dont' wanna commit to that huge breaking change now, but want to explore that some
17:15:34 [TabAtkins]
flackr: secondary events are not sent to the compositor, they're generated in blink as part of primary event
17:15:51 [TabAtkins]
flackr: we'd need to add special processing, compositor only see mouseup/mousedown, we synthesize click on main
17:16:11 [TabAtkins]
szager: i think chrome could do this, yes. no hard proposal yet. question is how much functionality do we need on the compositor.
17:16:24 [TabAtkins]
flackr: my point is, we always have the option to say some event types are triggered on main
17:16:47 [TabAtkins]
szager: i'll say, this proposal doesn't need to involve compositor thread. as-is it could be done entirely on the main thread
17:17:03 [TabAtkins]
szager: the compositor is an optimization. it's the point of this feature, yes, but it could just run on the main
17:17:14 [TabAtkins]
szager: so we can start from the baseline of makign it work right without compositor optimizations
17:17:41 [TabAtkins]
szager: and then this is a predictive model, we find as many scenarios as possible that we can do on the compositor. can't define the boundary yet, and it probably changes over time, and could vary between brwosers
17:18:01 [TabAtkins]
szager: but i think the design of the api, i always kept in mind making it possible to add the optimizations after the fact
17:18:07 [TabAtkins]
flackr: i think we agree
17:18:23 [TabAtkins]
flackr: hit-testing on the previously-seen thing is something that gives consistency with what the user sees and what they expect
17:18:32 [TabAtkins]
flackr: so i think it does make sense exploring
17:18:46 [TabAtkins]
szager: i agree in every state except compat. so if this is a compat anchor i don't want to be tied to it.
17:18:46 [astearns]
ack smfr
17:18:58 [TabAtkins]
smfr: this feels more consequential than scrolling as to getting it wrong.
17:19:13 [TabAtkins]
smfr: you can't do precise hit-testing, and aren't running inputs properly
17:19:20 [TabAtkins]
smfr: so you dont' know if something else canceled
17:19:26 [TabAtkins]
smfr: this is important for things like iframes
17:19:35 [TabAtkins]
szager: in chrome we do do precise hit-testing for iframes
17:19:51 [TabAtkins]
smfr: in webkit, if there's a clip path overlapping the iframe, we can't do precise hit-testing on our compositor
17:20:09 [TabAtkins]
smfr: so you say we kick it off on the compositor and then cancel it if the real event doesn't fire
17:20:14 [TabAtkins]
smfr: so what happens with animation events?
17:20:24 [TabAtkins]
szager: we wont' fire animation events until animation start has been affirmed on the main thread
17:20:29 [TabAtkins]
szager: so no ordering changes
17:20:39 [flackr]
qq+
17:20:44 [TabAtkins]
szager: one place that might look different is start time, but in terms of order animationStart event happens at normal position
17:20:53 [TabAtkins]
szager: i agree with everything you're saying about iframe security/etc
17:21:05 [TabAtkins]
szager: so i'll point back to, this can be done on the main thread.
17:21:09 [pdr]
pdr has joined #css
17:21:18 [TabAtkins]
szager: we considered a broader syntax, but decided to keep it narrow and just use animation-trigger to keep it simple
17:21:27 [TabAtkins]
szager: so can do it all on main, then judiciously move to compositor thread
17:21:33 [astearns]
ack flackr
17:21:33 [Zakim]
flackr, you wanted to react to smfr
17:21:44 [TabAtkins]
flackr: we can pick and choose the precise cases where we're completely or reasonably confident that we have the target correct and it wont' be stopped
17:21:58 [TabAtkins]
flackr: so it's possible to do it in a way that's correct save for extreme dom modification
17:22:15 [TabAtkins]
szager: it's true that compositor hit testing isn't authoritiative, but in chrome the compositor thread is aware *when* it's not authoritative
17:22:25 [TabAtkins]
szager: then we defer to the main thread, like if there's a clip path
17:22:45 [TabAtkins]
szager: so if there's an important decision to be made, we can push off the optimization. hopefully others can too.
17:22:47 [astearns]
ack ydaniv
17:22:58 [TabAtkins]
ydaniv: this sounds very interesting
17:23:15 [TabAtkins]
ydaniv: i was also worried about what simon mentioned, regarding stopPropagation, but if it's considered then good
17:23:22 [TabAtkins]
ydaniv: had a lot of questions about api
17:23:38 [TabAtkins]
ydaniv: but most important is probably 3rd question i wrote on the issue
17:23:52 [TabAtkins]
ydaniv: this is also very desired with transitions, but then it's not thru animation api but thru selectors
17:24:00 [TabAtkins]
ydaniv: that maybe goes back to css toggles, which is sorta deceased
17:24:11 [TabAtkins]
ydaniv: wonder if this is something we coudl marry with a state pseudoclass
17:24:19 [TabAtkins]
szager: one of our early ideas was a pseudo-state
17:24:31 [TabAtkins]
szager: we went thru it and the difficulty... it's probably most similar to :active
17:24:44 [TabAtkins]
szager: but looking deep into it, we don't know where the start/stop of the pseudo-state is.
17:24:58 [TabAtkins]
szager: this is a discrete event, not a toggle back and forth between two states
17:25:15 [TabAtkins]
szager: can't just analyze the dom and styels and say "we know we're in this state". it's ephemeral and it's gone
17:25:37 [TabAtkins]
szager: so it just doesn't seem to be a good match to pseudo-states, anything toggleable
17:25:50 [TabAtkins]
szager: this isn't even like viewport visibility, where you're either in or out. this is immediate.
17:26:07 [Di]
Di has joined #css
17:26:20 [TabAtkins]
szager: i foudn the best mental model is element.getAnimations.play(), like that. once that line is executed, you can't detect that it happened, you just know the animation is now playing. no idea how it started.
17:26:59 [TabAtkins]
szager: so just the idea of a state that toggles on or off doesn't seem to be the right model for this
17:27:17 [TabAtkins]
ydaniv: so this moves to the second question, if this state is transient, how will this work with different types of triggers?
17:27:33 [TabAtkins]
ydaniv: there we have "alternate" types... the state is in the animation then
17:27:35 [flackr]
qq+
17:27:50 [TabAtkins]
szager: right, i think if the state is the namation state, you can pause/play from there
17:28:06 [TabAtkins]
szager: if you explicitly call .play() on the animation, the input event could pause that animation
17:28:08 [astearns]
ack flackr
17:28:09 [Zakim]
flackr, you wanted to react to ydaniv
17:28:14 [astearns]
zakim, close queue
17:28:14 [Zakim]
ok, astearns, the speaker queue is closed
17:28:35 [TabAtkins]
flackr: having thought a lot about animatin-trigger, they have a thing that happens when the triggered state goes from outsdie->inside or reverse. i think each occurence of a discrete event woudl be a transition similarly.
17:29:02 [TabAtkins]
flackr: and what the trigger does depends on what trigger's state. "state" woudl pause/unpause, "alternate" would play it backwards/forwards, etc. each has a defined meaning already
17:29:24 [TabAtkins]
szager: yeah, since triggers are defined in terms of transition events, it works cleanly with inputs as long as the state lives in the animation
17:29:37 [astearns]
ack pdr
17:29:37 [TabAtkins]
flackr: right. currnently it's a state transition that toggles it, but that's not required
17:29:48 [TabAtkins]
pdr: quick comment on original question,a bout mixing fast and slow properties
17:29:57 [TabAtkins]
pdr: animation lets us build on the existing infrastructure
17:30:15 [TabAtkins]
pdr: if you ahve a layout-affecting property in an animation, it can already pull the whole animation out to main thread
17:30:36 [TabAtkins]
pdr: with animations you define up front the things that are affected, while with selectors it's open-ended
17:30:44 [TabAtkins]
pdr: so i think animation approach works iwthin those problems
17:30:55 [TabAtkins]
astearns: thank you for the introduction, let's flesh out the details more
17:32:02 [astearns]
zakim, open queue
17:32:02 [Zakim]
ok, astearns, the speaker queue is open
17:32:03 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/9830
17:32:03 [github-bot]
Topic: [css-forms-1] Names of <input type=range> / <input type=checkbox switch> pseudo-elements
17:32:03 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9830.
17:32:23 [TabAtkins]
ntim: i put the issues in order of expected speed
17:32:56 [TabAtkins]
ntim: we originally resolved on the speudo-elements for range, switch, and meter/progress to have ::slider-* prefix
17:33:16 [TabAtkins]
ntim: but we realized it might be better to drop the slider prefix for authoring
17:33:24 [jarhar]
jarhar has joined #css
17:33:25 [TabAtkins]
ntim: since writing "slider-" might not be convenient
17:33:32 [TabAtkins]
ntim: so wanted to see people's thoughts
17:33:33 [TabAtkins]
q+
17:33:40 [astearns]
ack TabAtkins
17:34:10 [fantasai]
TabAtkins: I would prefer to keep the "slide-" prefix. I don't think it's very long. But it groups these clearly related pseudos together semantically -- and also in alphabetically ordered lists.
17:34:11 [lea]
q?
17:34:23 [lea]
q+
17:34:23 [fantasai]
astearns: Would you keep that for <meter> and <progress> also?
17:34:29 [fantasai]
TabAtkins: Fine with that. It's sliding.
17:34:51 [fantasai]
TabAtkins: To the extent that <meter>/<progress> have a thumb.
17:34:55 [TabAtkins]
fantasai: it might not be something you can grip, but it might be something styleable
17:34:56 [astearns]
ack lea
17:35:06 [TabAtkins]
lea: i have a weak preference towards not prefixing
17:35:17 [TabAtkins]
lea: not just for verbosity, but just when do you group related pseudos together
17:35:29 [TabAtkins]
lea: we're already talking about meter/progress, but what about switch?
17:35:45 [TabAtkins]
lea: if you don't prefix, it's up to the author to group or separate them
17:35:58 [ntim]
q+
17:36:16 [TabAtkins]
lea: while if we decide how to prefix them, doing the oppsoite requires more complexity. locks us in as we have more elements with a shared structure
17:36:21 [astearns]
ack ntim
17:36:49 [TabAtkins]
ntim: more context, webkit implemented switch control. it always felt odd to write `switch::slider-thumb`/etc
17:37:00 [TabAtkins]
ntim: they're a slider to some extent, but it felt weird
17:37:19 [TabAtkins]
lea: so case in point, it's not the future we'll reach it, we're already there
17:37:36 [emilio]
Slight preference for keeping `::slider-` fwiw, but...
17:37:39 [fantasai]
TabAtkins: Switch looks like a slider. You're sliding it back and forth.
17:37:51 [astearns]
q+
17:38:07 [bkardell]
q+
17:38:22 [fantasai]
TabAtkins: If you have a thumb and track etc. then you're describing a slider.
17:38:32 [fantasai]
TabAtkins: these concepts are taken from the slider hierarchy of controls
17:38:36 [fantasai]
lea: Meter and progress?
17:38:39 [fantasai]
TabAtkins: yes. The value slides.
17:38:48 [bkardell]
q-
17:39:03 [TabAtkins]
astearns: the argument against taking the slider prefix off is that thumbs and tracks could possiblly be other things
17:39:15 [TabAtkins]
astearns: would it make sense to use another prefix, like ::ui-track?
17:39:20 [astearns]
ack astearns
17:39:23 [TabAtkins]
fantasai: scrollbars are also UI and they have thumbs and tracks too
17:39:24 [bkardell]
q+
17:39:29 [astearns]
ack bkardell
17:39:57 [fantasai]
bkardell: This doens't apply to the scrollbar thumb
17:40:10 [fantasai]
TabAtkins: e.g. prefixed ::scrollbar-thumb and ::scrollbar-track
17:40:21 [fantasai]
TabAtkins: a ::ui- prefix would be confusing, thos eare also ui
17:40:39 [fantasai]
bkardell: If we name them generically, would they apply to those thumbs and tracks, too?
17:40:50 [astearns]
::form-thumb?
17:41:04 [fantasai]
meter and progress aren't form inputs...
17:41:23 [TabAtkins]
bkardell: [directing question to Lea]
17:41:35 [TabAtkins]
lea: my argument depended on the idea that you coudl speialize them with the rest of the selector
17:41:49 [TabAtkins]
lea: if there's a way to do that for a scrollbar, then sure, but if there isn't we definitely need a prefix then
17:41:59 [TabAtkins]
lea: you need the ability to target both - generic and specific
17:42:08 [ntim]
q+
17:42:14 [astearns]
ack ntim
17:42:30 [TabAtkins]
ntim: clarifying - right now there's no specified ::scrollbar-thumb or track, and that's intentional.
17:42:47 [TabAtkins]
bkardell: the reason i asked is sometimes these also change over time what our mental model is
17:42:58 [TabAtkins]
bkardell: some video players have thumbs and tracks
17:43:31 [emilio]
Wouldn't that be a `<progress>`?
17:43:33 [TabAtkins]
bkardell: you were saying if you squint at this control it looks like a track, but i think if you look at it another way it might not be...
17:43:37 [lea]
I think a core eigenquestion is: could the same element have two types of tracks/thumbs?
17:43:50 [TabAtkins]
ntim: i think this is where Lea's argument applies, the author can always specify the selector before the pseudo-eleemtn to be specific
17:44:03 [TabAtkins]
ntim: if the author puts `input::thumb` you know it's not for a video
17:44:21 [TabAtkins]
lea: a core question we could ask is if we think the same element could have two types of thumbs/tracks?
17:44:33 [TabAtkins]
lea: a slider with two thumbs, certainly, but those are of the same type of thing
17:44:43 [TabAtkins]
ntim: we can add a functional version of the pseudo at that point to target idnviidual ones
17:44:52 [TabAtkins]
ntim: straw poll?
17:45:11 [astearns]
ack fantasai
17:45:26 [TabAtkins]
fantasai: i think we should think aobut this - it's not just thumb/track, we also have fill, and possibly other things
17:45:38 [TabAtkins]
fantasai: if these are pseudos we are dedicating to this purpose, that takes those names away from anything else
17:45:46 [TabAtkins]
lea: do we have a list of the names?
17:45:59 [TabAtkins]
fantasai: so far "thumb", "track", "fill"
17:46:10 [emilio]
There's also the benefit of typing `::slider-` and seeing all of them together in your editor :-)
17:46:14 [TabAtkins]
ntim: there's another issue to add something for color-swatch
17:46:29 [TabAtkins]
bkardell: "ruler" or "meter", the tick marks
17:46:59 [astearns]
1: keeping the slider- prefixes for thumb and track
17:47:10 [astearns]
2: just use thumb and track
17:47:44 [TabAtkins]
fantasai: i think we need to amke sure the prefix is consistent for all the parts, eithe rprefix all or none
17:47:52 [TabAtkins]
fantasai: if we think prefixing some is okay and others aren't we ahve a problem
17:48:17 [TabAtkins]
astearns: yes we need to think as a whole, but don't know that it's a bad result to have some as a prefix and some aren't, because some might be generic enough to not need one
17:48:28 [ydaniv]
+1 to lea
17:48:35 [TabAtkins]
lea: if we don't prefix these we can still name individual ones better
17:48:39 [TabAtkins]
STRAW POLL TIME
17:48:43 [ntim]
2
17:48:43 [TabAtkins]
1
17:48:46 [ydaniv]
2
17:48:47 [lea]
2
17:48:47 [smfr]
1
17:48:48 [astearns]
1
17:48:49 [noamr]
1
17:48:49 [kurt]
1
17:48:49 [emilio]
1
17:48:49 [ChrisL]
2
17:48:51 [bkardell]
1.5
17:49:04 [oriol]
1
17:49:04 [alisonmaher]
1
17:49:06 [rachelandrew]
1
17:49:07 [kbabbitt]
1
17:49:13 [schenney]
1
17:49:15 [kizu]
1
17:49:18 [lea]
s/we can still name individual ones better/we can still name individual ones better, e.g. we may decide `::track-fill` is a better name than `::fill`. That's not prefixing, just good naming./
17:49:28 [bkardell]
q+
17:49:31 [bkardell]
q-
17:49:41 [noamr]
We have `:active-view-transition-type`, I think `:slider-fill` is short
17:49:50 [dbaron]
emilio: I like the autocomplete aspects of the ::slider prefix.
17:49:59 [TabAtkins]
I think slider-fill is *too* short, based on precedent. we need longer words
17:50:10 [bkardell]
q+
17:50:14 [TabAtkins]
astearns: looks like prefixes are winning
17:50:21 [TabAtkins]
ntim: okay, prefixes are in the previous resolution
17:50:32 [TabAtkins]
bkardell: each of those controls are sliders currently
17:50:40 [TabAtkins]
bkardell: so nothing changes in terms of what the pseudo-element applies to
17:50:43 [lea]
q+
17:50:49 [astearns]
ack bkardell
17:50:50 [TabAtkins]
ntim: it would apply to switch, range, meter, and progress
17:50:50 [bkardell]
2
17:51:24 [bkardell]
since that is generic behavior, I think 2
17:51:30 [TabAtkins]
lea: if we keep these prefixes it makes it harder to use descreptive names, becuase it's already long
17:51:48 [TabAtkins]
lea: i think "fill" is confusing, "slider-fill" is still confusing, but "slider-track-fill" would be too long
17:52:21 [TabAtkins]
astearns: so we'll take a resolution to keep the prefixes, based on straw poll
17:52:29 [TabAtkins]
astearns: if we have better argumetns in the future we can revisit
17:52:38 [TabAtkins]
astearns: proposed reoslution is keep slider prefixes and close the issue
17:52:40 [TabAtkins]
astearns: objections?
17:52:52 [TabAtkins]
RESOLVED: Keep the slider-* prefixes and close the issue
17:53:19 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/11837
17:53:19 [github-bot]
Topic: [css-forms-1] Pseudo-element, structure and styles for `<input type="color">`
17:53:19 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11837.
17:53:31 [TabAtkins]
ntim: pseudo-elements for color input
17:53:43 [TabAtkins]
ntim: there's a proposal for ::color-swatch
17:53:51 [TabAtkins]
ntim: is everyone happy with this?
17:54:05 [TabAtkins]
TabAtkins: this represents the little rectangle of color in the input
17:54:20 [lea]
q+
17:54:30 [TabAtkins]
ntim: yeah. we can't use the element itself because we support alpha on the color, and want to be able to display the checkerboard behind the swatch to make that visible
17:54:32 [astearns]
ack lea
17:54:42 [TabAtkins]
lea: in a color input you can link to a data list
17:54:51 [TabAtkins]
lea: would these swatches have the same pseudo element?
17:55:23 [TabAtkins]
ntim: this is just the main input element, not the picker
17:55:35 [fantasai]
The in-page component of the control
17:55:35 [TabAtkins]
ntim: not all the browser have the same UI for the picker right now too
17:55:55 [TabAtkins]
astearns: so resolution is to use ::color-swatch as the name for the in-page representation of the chosen color
17:56:31 [TabAtkins]
astearns: comments or questions?
17:56:37 [TabAtkins]
astearns: objections?
17:56:46 [TabAtkins]
RESOLVED: Use the name ::color-swatch
17:56:54 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/5914
17:56:54 [github-bot]
Topic: [css-pseudo] ::checkmark proposal for radio & checkbox controls
17:56:54 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5914.
17:57:08 [TabAtkins]
ntim: next is naming the checkmark pseudo
17:57:17 [TabAtkins]
ntim: this is in the draft spec, but no reoslution yet
17:57:30 [TabAtkins]
ntim: the ::checkmark is the part that represents the indicator in the radio or checkbox
17:57:39 [TabAtkins]
TabAtkins: the check itself, or the dot on the radio
17:57:42 [emilio]
q+
17:57:53 [astearns]
ack emilio
17:58:01 [TabAtkins]
TabAtkins: iirc there was discusison about using ::before for this, but we decided to use a specialized pseudo instead
17:58:20 [TabAtkins]
emilio: i'm assuming the tree is well-defined, a specialized pseudo seems fine
17:58:26 [astearns]
ack fantasai
17:58:28 [TabAtkins]
ntim: oh, this is also to indicate the selecto <option>
17:58:50 [TabAtkins]
fantasai: need to clarify where these occur in the pseudo-tree. i think it makes sense between ::before/after, not befor ethe ::before
17:58:51 [emilio]
q+
17:59:04 [TabAtkins]
ntim: we shoudl split that to a separat eissue. the current position was i think designed for <option>
17:59:09 [astearns]
ack emilio
17:59:22 [TabAtkins]
emilio: i was thinking this would be an element-backed pseudo-element, but if they're not...
17:59:30 [TabAtkins]
emilio: if they were element-backed, they'd be between before/after
17:59:40 [TabAtkins]
emilio: if they're not... is this auto-generated content pseudo?
18:00:05 [TabAtkins]
ntim: in current spec it says ::checkmark is before ::before. that's specifically for <option>, where you want to put text between the checkmark and the option text
18:00:26 [TabAtkins]
ntim: so i'm just asking for a resolution to make sure this exists for radio/checkbox as well
18:00:36 [TabAtkins]
ntim: we can work thru its details after
18:00:36 [astearns]
ack dbaron
18:01:00 [TabAtkins]
dbaron: i was a little surprised about what emilio said, don't think element-backed implies a position relative to ::before/after
18:01:17 [TabAtkins]
emilio: if they're a real element in a shadow tree, it shoudl... we could define that it doesn't, but it woudl be weird.
18:01:29 [TabAtkins]
dbaron: yeah i guess so
18:01:38 [TabAtkins]
dbaron: not sure it *should* be this way. we might need to make that work at some point
18:01:49 [TabAtkins]
emilio: maybe, or maybe we could make this a gencontent thing like ::before/after
18:01:54 [TabAtkins]
emilio: we can punt to another issue
18:02:12 [TabAtkins]
astearns: yes, so this issue is just whether ::checkmark should be the name for checkbox/radio
18:02:30 [TabAtkins]
astearns: comments on the name, and it's application to checkbox/radio?
18:02:50 [fantasai]
[tab and fantasai +1 to the proposal]
18:02:57 [TabAtkins]
RESOLVED: Use ::checkmark for checkbox/radio
18:03:08 [TabAtkins]
astearns: do we need someone to open an issue to define its relationship with ::before/after?
18:03:09 [dbaron]
(and that's in addition to option, I assume)
18:03:11 [TabAtkins]
ntim: yeah, i will
18:03:32 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/11330
18:03:32 [github-bot]
Topic: [css-forms-1] Should `::slider-track` always precede `::slider-fill`?
18:03:32 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11330.
18:03:49 [TabAtkins]
ntim: so should ::slider-track always be before ::slider-fill?
18:04:02 [TabAtkins]
ntim: track is the track itself, fill is the progressed part
18:04:14 [TabAtkins]
ntim: current draft defines fill to be a child of the track, not a sibling, so this might not apply
18:04:26 [TabAtkins]
ntim: this was Ana Tudor's conclusion too
18:04:48 [TabAtkins]
TabAtkins: so if we stick witht he current spec, where fill is a child of track, it's moot?
18:04:49 [TabAtkins]
ntim: yes
18:04:59 [TabAtkins]
astearns: ah it's in the draft but without a resolution?
18:05:14 [emilio]
q+
18:05:15 [TabAtkins]
ntim: yes. we have a resolution on the *thumb* being a sibling of the track, but nothing on where the fill lives
18:05:34 [TabAtkins]
bkardell: i went back and forth on a bunch of these with Ana
18:05:43 [fantasai]
So <slider><::track><::fill/></::track> <::thumb/></slider> ?
18:05:53 [TabAtkins]
bkardell: so the proposal is that fill is a child of the track?
18:05:54 [TabAtkins]
ntim: yes
18:06:11 [TabAtkins]
ntim: Ana's rationale was if you apply a padding to the track you want to push the fill in
18:06:25 [TabAtkins]
fantasai: i think that makes sense, and once it's a little more drafted we should ask Ana for a review
18:06:40 [astearns]
ack emilio
18:06:51 [TabAtkins]
emilio: isn't this unrelated to where it goes in the tree?
18:07:06 [TabAtkins]
emilio: i think OP is whether you shoudl always nest the pseudo, but that's unrelated to where they are in the tree
18:08:21 [TabAtkins]
TabAtkins: ah indeed, this issue is aobut how you spell the selector. i agree that we shoudln't require `::slider-track::slider-fill`. We can just allow `::slider-fill` and still have it be a child of the track in the dom tree.
18:08:28 [TabAtkins]
ntim: if we can resolve on the tree position that's nice too tho
18:09:23 [TabAtkins]
ntim: becuase that affects this still, siblings *wouldn't* nest
18:09:49 [TabAtkins]
TabAtkins: not necessarily. they really are independent. nesting is just useful if we need to scope things, like in a few VT bits. But you don't need to do a full chain of VT pseudos.
18:10:19 [TabAtkins]
emilio: so reoslution should be originating element of ::slider-fill is the input element, not the ::slider-track
18:10:38 [TabAtkins]
astearns: objections?
18:10:56 [TabAtkins]
RESOLVED: The originating element of ::slider-fill is the input element, not the ::slider-track.
18:11:08 [TabAtkins]
astearns: and we can also take a resolution on the fill being a child of the track in the pseudo tree
18:11:20 [TabAtkins]
bkardell: coudl we put it off for a bit?
18:11:24 [TabAtkins]
ntim: we can always revisit.
18:11:53 [TabAtkins]
fantasai: can we just resolve and say that if Ana has another opinion we reopen?
18:12:06 [TabAtkins]
astearns: so proposed reoslution is that fill is a child of the track in the pseudo-tree
18:12:11 [TabAtkins]
astearns: objections?
18:12:28 [TabAtkins]
RESOLVED: The slider-fill is a child of the slider-track in the pseudo-element tree
18:12:39 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/11486
18:12:39 [github-bot]
Topic: [css-forms-1] Should `appearance: base` inherit more text-related properties?
18:12:39 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11486.
18:13:03 [TabAtkins]
ntim: so this is about inheriting more text-related properties in apperance:base
18:13:15 [TabAtkins]
ntim: a few months ago i was playing with custom select in chrome, a few text properties weren't inherited
18:13:21 [TabAtkins]
ntim: think wa sfixed in chrome, but no formal resolution
18:13:35 [TabAtkins]
ntim: elika and i also discussed taht transform, align, and indent should not be inherited and should probably reset
18:13:41 [TabAtkins]
ntim: any other thoughts on this?
18:13:51 [TabAtkins]
TabAtkins: what are the properties we're adding?
18:13:54 [TabAtkins]
ntim: there's a list in the issue
18:14:03 [TabAtkins]
ntim: text-shadow, text-rendering, letter-sapcing, word-spacing, text-auto-space
18:14:14 [TabAtkins]
ntim: and resetting text-transform, text-align, text-indent
18:14:24 [emilio]
q+
18:14:29 [TabAtkins]
TabAtkins: those all make sense to me
18:14:33 [astearns]
ack emilio
18:14:39 [TabAtkins]
emilio: do other form controls inherit any of these?
18:14:59 [TabAtkins]
ntim: this is just for appearance:base, font and color already inherit
18:15:29 [TabAtkins]
emilio: seems okay, a bit concerned about adding more dependencies from appearnce to random properties, in terms of causing confusion
18:15:35 [TabAtkins]
emilio: but not objecting, if you think it's better that's okay
18:15:41 [TabAtkins]
emilio: i'd just prefer to not do it if possible
18:16:04 [TabAtkins]
ntim: the reason i filed this issue is i was doing a website and i wanted to put some inputs in a table, and wanted them to be transparent in the table, and table styles to inherit into them
18:16:25 [TabAtkins]
ntim: just like a div
18:16:45 [TabAtkins]
emilio: right. i don't know if introducing such strong differneces between base and auto will be a positive or negative in practice
18:17:04 [TabAtkins]
emilio: like, this *is* something you can do today and it's already confusing for authors, adding more could be unfortuante
18:17:32 [TabAtkins]
ntim: appearnce:base is kinda a chance to reset things and give authors a better behavior. basically the same behavior you get from a div on the page
18:17:48 [TabAtkins]
emilio: but we're not *really* restarting, right, this value already exists
18:18:10 [astearns]
ack dbaron
18:18:11 [TabAtkins]
emilio: so i'm just not convinced it's much of a net benefit, but i don't want to block. just concerned it'll be more confusing than not
18:18:25 [TabAtkins]
dbaron: almost a side comment, in support of text-indent and text-aling
18:18:41 [TabAtkins]
dbaron: in some sense the logic of text-indent and text-align might have been better if they applied to a BFC rather than being inherited
18:18:57 [TabAtkins]
dbaron: so it kinda makes sense to inherit those onto things that are likely to be blocks but reset on things likely to be inline-blcoks
18:19:04 [emilio]
q+
18:19:07 [TabAtkins]
dbaron: becuase you usually don't want them to inherit into inline blocks
18:19:08 [emilio]
q-
18:19:17 [TabAtkins]
dbaron: you probably don't want these to leak into the inline-block
18:19:27 [TabAtkins]
dbaron: so given standard form styling, i think this makes sense
18:19:28 [astearns]
ack fantasai
18:19:37 [TabAtkins]
fantasai: +1 to what dbaron just said, that's a core part of the logic
18:19:45 [emilio]
q+
18:20:05 [TabAtkins]
fantasai: and the reason for blocking text-transform, unless the author specifically wants tex-ttransform to take affect, it's confusing to the user if what they see and what they type aren't the same. so authors should be explicit about this
18:20:17 [TabAtkins]
fantasai: for the rest, i agree with Tim that the conceptual model for appearance:base is blending with the rest of the page
18:20:32 [TabAtkins]
fantasai: and inheriting anything that affects text styles - not just font, but spacing and such as well - makes sense
18:20:33 [astearns]
ack emilio
18:20:46 [TabAtkins]
emilio: jsut clarifying, resetting those isn't really a behavior change
18:20:55 [TabAtkins]
emilio: so we're in agreement there, and i generally agree with dbaron's points too
18:21:10 [TabAtkins]
emilio: the behavior change is inheriting a bunch of new stuff (not resetting them, as we do today)
18:21:13 [TabAtkins]
emilio: but i don't object
18:21:28 [TabAtkins]
emilio: if we could explain it just via CSS it woudl be nicer
18:21:39 [TabAtkins]
emilio: but this feels very cosmetic, easy to do if you need/want
18:21:45 [TabAtkins]
emilio: i'd rather avoid the UA magic to get there
18:21:54 [astearns]
ack fantasai
18:22:30 [TabAtkins]
fantasai: if you think about appearance:normal, we're taking the OS appearnce and pulling it into the page. for appearance:base, we're blending it into the page.
18:22:50 [TabAtkins]
fantasai: the styles we've set up - using currentcolor, a transparent bg, etc - achieves this
18:23:05 [TabAtkins]
fantasai: having some things not apply is confusing for that mental model, and might not always be immediately noticeable
18:23:19 [TabAtkins]
fantasai: as for style changing, we alreayd have to apply different props based on base or auto anyway, this is just another on the list
18:23:35 [fantasai]
emilio, it's more magic from your point of view, but less magic from the author's point of view :)
18:23:55 [TabAtkins]
ntim: so proposed resolution is we should inherit [the properties listed in the issue] and reset [the other properties listed in the issue]
18:24:10 [emilio]
q+
18:24:15 [TabAtkins]
fantasai: in other words we inherit text-tasnform, text-aling, and text-indent, and inherit everything else as normal
18:24:29 [astearns]
ack emilio
18:24:44 [TabAtkins]
emilio: do we mention cursor? unsure that should be inherited.
18:24:53 [TabAtkins]
emilio: would rather go with an explicit list
18:25:17 [TabAtkins]
fantasai: for white-space we should set it to 'pre', spaces should be visible since it's in the value
18:25:33 [TabAtkins]
fantasai: for cursor, not sure what it normally does for text inputs, if it's different form the rest of the page we should set it accordingly
18:25:59 [TabAtkins]
astearns: dont' think emilio was saying we should make a decision on those two properties, just because there are more complexities with styles, we should resolve on just this finite list of properties
18:26:24 [TabAtkins]
emilio: yeah, i agree on those properties. in practice we only need to inherit some things that are reset by the UA stylesheet.
18:26:54 [astearns]
ack dbaron
18:26:54 [fantasai]
PROPOSED: Reset text-indent, text-align, and text-transform to initial values; set white-space to pre; and inherit all other text properties mentioned in the issue
18:27:33 [dbaron]
I think the proposal is to inherit text-shadow text-rendering letter-spacing word-spacing text-autospace and to reset text-transform text-align text-indent
18:28:09 [TabAtkins]
PROPOSED: text-shadow, text-rendering, letter-spacing, word-spacing, text-autospace all inherit, and text-transform, text-align, text-indent are reset
18:28:28 [TabAtkins]
astearns: objections to these 8 properties?
18:28:36 [TabAtkins]
RESOLVED: text-shadow, text-rendering, letter-spacing, word-spacing, text-autospace all inherit, and text-transform, text-align, text-indent are reset
18:28:40 [hoch]
hoch has joined #css
18:28:46 [TabAtkins]
astearns: a follow-on reoslution would be to have appearance:base set white-space:pre
18:28:58 [TabAtkins]
ntim: that might be no change from current state?
18:29:22 [TabAtkins]
dbaron: think it differs on control
18:29:44 [TabAtkins]
astearns: another issue, then
18:29:52 [TabAtkins]
github-bot, take up https://github.com/w3c/csswg-drafts/issues/12019
18:29:52 [github-bot]
Topic: [css-forms-1] continue to refine principles for appearance:base controls
18:29:52 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12019.
18:31:21 [TabAtkins]
dbaron: i want to talk thru a single reasonable small example of one case where a bunch of these principles interact with each other
18:31:28 [TabAtkins]
dbaron: i didn't quite agree with what the principles were telling me to do
18:31:36 [TabAtkins]
dbaron: i expect others might have the same feeling, but want to check
18:31:44 [TabAtkins]
dbaron: i also think the example is interesting on its own. Ian pointed it out to me.
18:32:04 [TabAtkins]
dbaron: the current spec has this list of design principles for base appearance
18:32:14 [TabAtkins]
dbaron: I think Jen made them?
18:32:20 [TabAtkins]
jensimmons: we collaborated inside Apple
18:32:54 [TabAtkins]
dbaron: one realtively simple example is a button element
18:33:17 [TabAtkins]
dbaron: here's three pieces of markup. if there's no styles on the button, you get these appearances
18:33:41 [TabAtkins]
dbaron: principle 3 says they shoudl pass 100% of wcag criteria
18:33:52 [TabAtkins]
dbaron: looking at wcag, they say the size of a pointer input is at least 24x24 pixels
18:33:57 [TabAtkins]
dbaron: these buttons are not all that size
18:34:00 [TabAtkins]
dbaron: so that's a problem
18:34:19 [TabAtkins]
dbaron: i propose a small change on this - the wcag text has an explicit exception for if the control came from the UA
18:34:31 [TabAtkins]
dbaron: i think principle 3 should not allow us to use these UA exceptions
18:34:50 [TabAtkins]
dbaron: in other words, we should be meeting the WCAG criteria as if we were author styles
18:34:59 [TabAtkins]
dbaron: so what if we give the button some min sizes
18:35:05 [TabAtkins]
dbaron: this is what's in the stylesheet today
18:35:17 [TabAtkins]
dbaron: can get a min size in both axises
18:35:48 [TabAtkins]
dbaron: this seems to fix our wcag problem
18:35:54 [TabAtkins]
dbaron: back to the principles
18:36:19 [TabAtkins]
dbaron: we're now doing some things specific to certain controls and not others, so that's not great consistency
18:36:34 [TabAtkins]
dbaron: another princpile is resilient to being placed in other contexts, like put into a grid/flex
18:36:52 [TabAtkins]
dbaron: so say we have a flex container, with a button child and some other bigger stuff
18:37:03 [TabAtkins]
dbaron: we have thise min-size styles....
18:37:13 [TabAtkins]
dbaron: before we added the min-size styles this did more or less what we wanted
18:37:24 [TabAtkins]
dbaron: but now that we have min-size we get overlap. it overrides min-size:auto
18:37:33 [TabAtkins]
dbaron: but we didn't really want to do that, it's important for flex/grid
18:37:54 [TabAtkins]
dbaron: a fundamental issue, and i think it'll come up multiple times, is we want to build a thing where it gets an intrinsic size from several sources
18:38:10 [TabAtkins]
dbaron: we want it at least this big, and also at least this big, and also at least this big, and one of those is the intrinsic size
18:38:13 [TabAtkins]
dbaron: can we do better?
18:38:17 [TabAtkins]
dbaron: we can do terrible things
18:38:24 [TabAtkins]
dbaron: [hacky grid description]
18:38:42 [TabAtkins]
dbaron: but that's a complete disaster per the principles
18:38:52 [TabAtkins]
dbaron: hugely complicated, devs would have to understand it all to override it
18:38:57 [TabAtkins]
dbaron: i think we can do better
18:39:08 [TabAtkins]
dbaron: slightly better solution to fix this problem is to use calc-size()
18:39:24 [TabAtkins]
min-block-size: calc-size(auto, max(24px, 1lh, size))
18:39:45 [TabAtkins]
dbaron: a bit better, it works in flex, it satisfies wcag, it's a single declaration that can be easily overridden
18:39:54 [TabAtkins]
dbaron: but it's still not great, pretty complicated expression in this default stylesheet
18:40:09 [TabAtkins]
dbaron: if the dev wants to replace a piece they have to look it up and figure out how to tweak it
18:40:27 [TabAtkins]
dbaron: so i think this is *better* for the principles, not *great* on easy to override but better than hacky grid solution
18:40:41 [TabAtkins]
dbaron: does this count as consistent across controls? maybe, depends on what we do for other controls
18:40:52 [TabAtkins]
dbaron: my feeling is this is the least bad thing so far
18:41:04 [astearns]
q+
18:41:44 [jensimmons]
q+
18:41:50 [TabAtkins]
dbaron: other than the thing i said earlier about the wcag rule, one other thing i felt about applying these rules to this case, rule 5.4 was more important than many other options. list implies it's less important to 4.2, which bothers me. the other parts of 4 and 5 are probably fine, but these two particular rules bother me.
18:42:10 [TabAtkins]
astearns: yeah, this is exactly waht the princpiles are for, to encourage this analysis
18:42:18 [TabAtkins]
astearns: whether we adjust the ordering, this is cool, thank you
18:42:34 [TabAtkins]
astearns: probably are gonna be some exceptions, justification for something moving up in some cases but not necessarily for all
18:42:40 [TabAtkins]
astearns: that said i'm not against reordering
18:42:45 [astearns]
ack astearns
18:42:49 [astearns]
ack jensimmons
18:42:50 [TabAtkins]
jensimmons: i agree
18:43:25 [TabAtkins]
jensimmons: interesting that the title of the issue is "continue to refine", makes me think the question at hand is change the principles. but i think this is the whole point of the principles, they're not marching orders, they're a framework to have discussions quickly
18:43:47 [TabAtkins]
jensimmons: and i think you're right, they do contradict sometimes, and i want to have a godo discussion about buttons, and other things
18:44:06 [TabAtkins]
jensimmons: i didn't write these myself, we've discussed with tim, elika, anne, the dto, etc
18:44:24 [TabAtkins]
jensimmons: we did not keep the convo in the oven to continue to bake to the point where the default ua styles are at all done
18:44:35 [TabAtkins]
jensimmons: we pulled those out as early as we felt like we could
18:44:55 [TabAtkins]
jensimmons: i think they're deceptively simple, like "oh we just need to decide on rounded corner, colors" and it's easy
18:44:58 [TabAtkins]
jensimmons: but yeah, it's not
18:45:18 [TabAtkins]
jensimmons: one advantage of appearance:auto form controls is that, regardless fo brwoser, if the page does nothing for them, the controls work.
18:45:26 [TabAtkins]
jensimmons: and the default appearance:base controls don't work
18:45:31 [TabAtkins]
jensimmons: so i agree there's a lot of room to grow
18:45:32 [ntim]
q+
18:46:09 [astearns]
ack fantasai
18:46:47 [TabAtkins]
fantasai: i think we maybe want to add the word "approximate" as in "approximate order of descending imporantace". this isn't meant to be strict 3 always wins over 4. like usual, balancing act about how much you're violating one vs the other, etc
18:46:59 [TabAtkins]
fantasai: i don't midn too much if we flip 4 vs 5, don't think there a strong ordering between those two
18:46:59 [astearns]
ack ntim
18:47:00 [jensimmons]
I should also say I don't think bikeshedding the design principles for a long time is a good use of time. We should work on the styles, and hold the design principles loosely.
18:47:08 [TabAtkins]
+1
18:47:09 [fantasai]
+1
18:47:16 [jensimmons]
q+
18:47:18 [TabAtkins]
ntim: the ua styles defined in the spec very much need refining
18:47:24 [iank_]
q+
18:47:33 [TabAtkins]
ntim: about the specific examples, min-size, i think that came from a PR from Joey that was applied to select
18:47:45 [TabAtkins]
ntim: so I just took it and applied it to the spec
18:47:54 [fantasai]
s/the spec/butotn
18:48:00 [fantasai]
s/butotn/button/
18:48:06 [TabAtkins]
ntim: so yeah, i'm curious to have more discussion about styles
18:48:17 [astearns]
ack jensimmons
18:48:27 [TabAtkins]
jensimmons: [saying what she typed in IRC]
18:48:57 [TabAtkins]
jensimmons: we're all busy, we can probably largely skip over this and just work ont he controls, and change the principles later
18:49:01 [TabAtkins]
jensimmons: as long as they're not blocking us
18:49:09 [Di]
Di has joined #css
18:49:20 [TabAtkins]
dbaron: i think that idea is fine. particularly if we take elika's suggested edit for "approximate order"
18:49:29 [astearns]
ack iank_
18:49:29 [TabAtkins]
dbaron: and i do intend to give more feedback on the stylesheet, that'll happen over time
18:49:47 [TabAtkins]
iank_: one high-level thing, in this stylesheet we shoudl be very careful when changing the size proeprties to a fixed size
18:50:06 [TabAtkins]
iank_: even a radio or checkbox with width:1ch, that has sublte effects in grid/flexbox related to stretching
18:50:11 [TabAtkins]
iank_: so keep auto as much as possible
18:50:16 [ntim]
q+
18:50:19 [TabAtkins]
iank_: I think the calc-size() solution is pretty good
18:50:22 [astearns]
ack ntim
18:50:35 [TabAtkins]
ntim: so it sounds like next steps is to start prototyping the ua styles, and to add the word approximate
18:51:00 [dbaron]
Proposed resolution #1: spec that order of principles is approximate
18:51:14 [TabAtkins]
astearns: so suggesting no particular resolution just yet? or is there something in this analysis you'd like to adopt currently?
18:51:24 [dbaron]
Proposed resolution #2: say that principle about WCAG AA standards can't use "UA styles" exceptions
18:51:26 [TabAtkins]
ntim: i think we shoudl adopt "approximate" to the princple wording
18:51:39 [TabAtkins]
astearns: david gives some proposed reoslutions
18:52:04 [TabAtkins]
astearns: proposed resolution 1, objections?
18:52:15 [dbaron]
Proposed resolution #3 (maybe more controversial): Adopt the calc-size() expression for the stylesheet.
18:52:18 [TabAtkins]
RESOLVED: Say "approximate order" for the principles
18:52:27 [TabAtkins]
astearns: proposed resolution 2, objections?
18:52:57 [TabAtkins]
RESOLVED: Specify that 'base' styles can't lean on the "UA Styles" exception in WCAG criteria, they're treated as author styles for this purpose
18:53:01 [fantasai]
Edited first resolution in https://github.com/w3c/csswg-drafts/commit/455c7774eb357f4e5a942ec22559a02f8798edc5
18:53:13 [TabAtkins]
ntim: for proposal 3, i think we need to prototype and get some feedback first
18:53:28 [TabAtkins]
ntim: not against it, just want to try it out first
18:53:39 [astearns]
ack fantasai
18:54:08 [TabAtkins]
fantasai: i just want to reraise Ian's point that it might make sense to just lean on 'auto' as much as possible, because it give sus the best default sizing behavior in a variety of contexts
18:54:22 [TabAtkins]
fantasai: it might not always be the most ideal for every case, but it'll often get us good results in common cases
18:54:31 [fantasai]
fantasai: and it won't break things
18:54:44 [TabAtkins]
TabAtkins: tho use of calc-size() gives us the auto behavior *and* lets us still tweak things
18:54:54 [TabAtkins]
dbaron: one brief example of something it might break
18:55:02 [TabAtkins]
dbaron: this style in the UA sheet is for select and button
18:55:17 [TabAtkins]
dbaron: if you have an empty option in select, which might not be uncommon in select as the default option
18:55:36 [TabAtkins]
dbaron: but right now, without those minimums, the empty option will shrink the width *and* the height, and that's kinda weird
18:55:55 [TabAtkins]
ntim: so you want to apply this to select as well? we could resolve it now if needed
18:56:16 [TabAtkins]
dbaron: i think the calc-size() would be an improvement on the current design, yes. but we don't need to resolve on it right yet.
18:56:17 [miriam]
present+
18:56:28 [TabAtkins]
astearns: for time, we won't resolve on this right now. we need to break
18:56:37 [TabAtkins]
ntim: could dbaron file an issue for fixing the select behavior?
18:56:38 [TabAtkins]
dbaron: yes
18:56:43 [TabAtkins]
github-bot, end topic
18:56:47 [TabAtkins]
<br dur=19min>
19:03:18 [alisonmaher]
alisonmaher has joined #css
19:15:15 [github-bot]
Topic: [css-forms-1] Password visibility toggle
19:16:43 [fantasai]
ntim: MSFT Edge ships a password visibility toggle. It's an icon that reveals the password in plain text
19:17:08 [ntim]
https://github.com/w3c/csswg-drafts/issues/11845#issuecomment-2760207097
19:17:20 [fantasai]
ntim: I proposed adding a standardized pseudo for this
19:17:32 [fantasai]
kbabbitt: The Edge feature is a vendor extension, would like to standardize
19:17:46 [fantasai]
kbabbitt: We tried to implement in Blink , but ran into compat problemns
19:18:02 [fantasai]
kbabbitt: Would like sites to be able to opt into it
19:18:29 [fantasai]
kbabbitt: One change I might want to suggest ot Tim's proposal is the `display: block` but can leave to future discussion
19:18:51 [fantasai]
ntim: Thoughts?
19:19:09 [fantasai]
dholbert: Is this the first case where appearance:base provides a component not available in default styled component?
19:19:18 [fantasai]
ntim: The button would always be present in the pseudo-element tree
19:19:29 [fantasai]
ntim: Just, depending on 'appearance', the default 'display' would be different.
19:19:42 [fantasai]
astearns: But some implementations don't have this button at all?
19:20:09 [fantasai]
dholbert: feels strange that 'appearance:base', at least visually, *adds* something.
19:20:19 [fantasai]
dholbert: it does seem like a nice way to go back and add something that should have been there in the first place
19:20:43 [fantasai]
dholbert: website with existing control might be surprised to get the new control when applying 'appearance: base'
19:21:11 [dbaron]
(as a user, I want reveal buttons on all password fields whether or not the site wanted it)
19:21:23 [astearns]
+1 dbaron
19:21:25 [fantasai]
fantasai: I'm not too worried about that particular scenario. 'appearance: base' causes changes, should be checking your site to see if you're happy with those changes
19:21:34 [dbaron]
(particularly when entering passwords on my phone)
19:21:44 [lea]
agreed with fantasai
19:21:46 [fantasai]
ntim: I wanted to leave 'appearance: auto' to the UA, to match platform conventions. And some platforms don't have this button.
19:22:06 [fantasai]
ntim: I have less strong opinions about 'appearance: none'; but for compat we might want to hide it by default.
19:22:23 [fantasai]
lea: This pseudo would not be present if the UA doesn't implement the functionality
19:22:31 [fantasai]
ntim: Ideally it would be present in all the UAs.
19:22:42 [lea]
q?
19:22:43 [lea]
q+
19:22:47 [fantasai]
ntim: Just that in 'appearance: auto', up to UA whether to show or not
19:22:57 [fantasai]
ntim: but in 'base' it's consistent -- always get the button by default
19:23:12 [fantasai]
lea: 2 things. Whether impl has password reveal or not. And whether visible or not.
19:23:23 [fantasai]
lea: if impl doesn't impl, then pseudo shouldn't exist
19:23:33 [astearns]
ack lea
19:23:43 [fantasai]
ntim: Problem with different UAs doing different things is lack of consistency. Not interoperable.
19:23:58 [fantasai]
ntim: developer tests in one browser, works; other browser doesn't work, this is bad
19:24:02 [lea]
q?
19:24:09 [lea]
q+
19:24:21 [fantasai]
ntim: If they start by building site on browser without password reveal, and add a custom one, and suddenly a browser changes to add by default -- now have double reveal icons, also not great
19:24:32 [fantasai]
ntim: So we want to be consistent at least for 'appearance:base'
19:24:37 [astearns]
ack fantasai
19:25:01 [TabAtkins]
fantasai: if the UA doesn't implement the reveal button, then obviously it should not claim to support the pseudo
19:25:13 [TabAtkins]
fantasai: but we're saying that all UAs *should* implement this, it's a required part of the spec
19:25:29 [TabAtkins]
fantasai: and to match paltform conventions, appearnace:auto (the default), the UA would be able to hide the reveal
19:25:45 [TabAtkins]
fantasai: but the pseudo exists and is implemented
19:26:27 [TabAtkins]
fantasai: and Tim is proposing that in the defaults, appearance:auto gives you platform convention, appearance:none has it turned off for compat, and appearance:base has it turned on. this makes it obvious to authors that it exists in the first place.
19:26:32 [astearns]
ack lea
19:26:37 [TabAtkins]
fantasai: otherwise it's more likely that authors will design a custom version that they dont'a ctually need
19:26:43 [lea]
No objection to hiding it in auto if the capability is implemented. I don't think there is a precedent where UAs must add something even for standards they don't implement. E.g. what does a UA do if they actively oppose a certain standard? Still implement the pseudo? What about pseudos that were added after appearance: base? Of course the trees will be different.
19:26:56 [dholbert]
(For reference, I've got screenshots of double 'reveal' icons from when Firefox tried to ship a reveal icon by default (for `appearance:auto`) a few years back: https://bugzilla.mozilla.org/show_bug.cgi?id=1754086 . Based on experience there, I think backwards-compat definitely likely requires UAs to hide the button with `appearance:auto` and `appearance:none`)
19:27:28 [TabAtkins]
fantasai: it's a violation fo the css spec to treat syntax as valid for a featur eyou don't support
19:27:38 [TabAtkins]
lea: oh, i thought that's what tim was proposing
19:27:39 [TabAtkins]
fantasai: nope
19:27:44 [TabAtkins]
lea: sorry, misunderstood
19:27:49 [fantasai]
astearns: Are we resolving on Tim's proposal?
19:27:53 [bkardell]
s/ featur eyou / feature you /
19:27:58 [fantasai]
astearns: further litigate details in future?
19:28:16 [fantasai]
ntim: Add also to make visible by default, not in the comment.
19:28:30 [fantasai]
astearns: proposed to adopt Tim's proposal, and define it as visible in 'appearance: base'
19:28:50 [kbabbitt]
q+
19:28:51 [fantasai]
ntim: Might want to decide on a name. `::reveal` or `::reveal-icon`
19:29:04 [fantasai]
ntim: Many pseudo elements in the current draft that are -icon
19:29:10 [lea]
q+
19:29:11 [astearns]
ack kbabbitt
19:29:12 [dholbert]
q+
19:29:28 [astearns]
ack lea
19:29:33 [fantasai]
kbabbitt: prefer ::reveal because similar to MS-prefixed version, but no objection either way
19:29:44 [fantasai]
lea: How does someone detect whether the password is revealed or not?
19:30:03 [fantasai]
fantasai: This doesn't tell whether revealed or not, just is a pseudo-element for the icon
19:30:03 [hoch]
hoch has joined #css
19:30:17 [fantasai]
lea: I suspect in many cases authors will want to style the icon differently based on whether in revealed state or not
19:30:23 [fantasai]
lea: we should decide names together
19:30:41 [jensimmons]
+1 for not deciding in isolation!
19:30:42 [fantasai]
ntim: so :reveal?
19:30:47 [astearns]
ack dholbert
19:30:51 [ntim]
:revealed
19:30:54 [lea]
`:revealed::reveal` then doesn't really work
19:31:00 [fantasai]
:password-show :password-hidden
19:31:09 [dbaron]
+1 to `:revealed` as a pseudo-class name
19:31:13 [fantasai]
dholbert: So having computed value of 'display' depends on computed value of 'appearance'
19:31:39 [fantasai]
dholbert: I don't like computed value dependencies very much... defer to emilio
19:31:47 [fantasai]
dholbert: action at a distance is not great
19:31:59 [fantasai]
dholbert: but maybe it's fine
19:32:04 [astearns]
ack fantasai
19:32:19 [TabAtkins]
fantasai: since we have a bunch of -icon we should be consistent and use ::reveal-icon
19:32:30 [TabAtkins]
fantasai: for the pseudo-class, hadn't thought of it before
19:33:25 [fantasai]
PROPOSED: Adopt a pseudo-element representing the password reveal icon control. Make it 'display: none' by default in 'appearance:none'; match platform convention in 'appearance:auto', and displayed in 'appearance:base'
19:33:53 [fantasai]
(Name TBD)
19:33:59 [fantasai]
PROPOSED: Adopt a pseudo-element representing the password reveal icon control. Make it 'display: none' by default in 'appearance:none'; match platform convention in 'appearance:auto', and displayed in 'appearance:base'. Name TBD.
19:34:06 [fantasai]
RESOLVED: Adopt a pseudo-element representing the password reveal icon control. Make it 'display: none' by default in 'appearance:none'; match platform convention in 'appearance:auto', and displayed in 'appearance:base'. Name TBD.
19:34:44 [github-bot]
Topic: New property to control the direction of slider controls
19:35:20 [fantasai]
ntim: input[type=range], meter, progress, switch all currently follow writing mode and text direction
19:35:39 [fantasai]
ntim: If you're in vertical writing mode, it will be vertical and the text direction specifies whether goes top to bottom or bottom to top
19:36:03 [fantasai]
ntim: Desire to make this independent of the writing-mode and text direction, because in some cases you want the direction of the slider to be physical rather than logical
19:36:23 [fantasai]
ntim: For example, temperature. Classically increase bottom to top. Not dependent on writing mode.
19:36:43 [fantasai]
ntim: There's an existing proposal on the draft for a property called `slider-orientation` with some values
19:36:56 [fantasai]
ntim: 'auto' for using text direction, and some physical values.
19:37:03 [fantasai]
ntim: not sure if that's the right design, so wanted to ask for input
19:37:16 [astearns]
ack fantasai
19:37:22 [lea]
q?
19:37:32 [TabAtkins]
fantasai: i think there's two fundemantel question
19:37:38 [TabAtkins]
fantasai: one question is what values to give this properity
19:37:51 [TabAtkins]
fantasai: but more fundamental, how is this interacting with the styling of the elements within the slider
19:38:01 [lea]
q+ if we create a new property, this is much broader than sliders
19:38:03 [TabAtkins]
fantasai: we've ahd fairly simple interactions, like appearance with display
19:38:07 [lea]
q+
19:38:08 [TabAtkins]
fantasai: it's a realtively straightforward mapping
19:38:14 [bkardell]
q+
19:38:20 [TabAtkins]
fantasai: but this would ahve to change padding/etc, a lot of properties, based on the value on the slider
19:38:31 [TabAtkins]
fantasai: so it's a lot more complicated
19:38:31 [TabAtkins]
fantasai: than we get on previous things
19:38:42 [TabAtkins]
fantasai: so what's the mechanism by which this works, and is that a mechanism we want to adopt?
19:38:55 [TabAtkins]
fantasai: if yes, then slider control orientation would need a bunch of values. id' suggest both physical and logical values
19:39:02 [TabAtkins]
fantasai: we can come up with a set of keywords, that's not a problem
19:39:04 [astearns]
ack lea
19:39:23 [fantasai]
lea: I don't have an opinion yet about whether to introduce a new property.
19:39:28 [fantasai]
lea: but if we do, this is a lot broader than slider. This problem comes up with many elements.
19:39:38 [fantasai]
lea: e.g. selects. can have a select list that's horizontal.
19:39:56 [fantasai]
lea: But mainly this comes up a lot in components. Very common to have a component with both horizontal and vertical orientation options
19:40:08 [astearns]
ack bkardell
19:40:18 [fantasai]
lea: so if we have this property, can we make it more generic than sliders?
19:40:43 [fantasai]
bkardell: Any thoughts on Anne's comment about whether this belongs in HTML?
19:40:57 [Di]
Di has joined #css
19:41:22 [fantasai]
dbaron: I think some of it is presentation. Or at least associated with direction and writing mode
19:41:37 [fantasai]
dbaron: at least it seems that way
19:41:47 [astearns]
ack fantasai
19:41:53 [dbaron]
s/some/at least some/
19:41:57 [TabAtkins]
fantasai: I think a lot of hte use-cases dictating the direction are presentational
19:42:03 [TabAtkins]
I agree
19:42:14 [TabAtkins]
and other aspects of semantics do come from CSS at times
19:42:26 [ntim]
q+
19:42:28 [fantasai]
astearns: Can the presentational aspects be overridden using existing properties, or do we need a new property for this kind of switching behavior?
19:42:34 [astearns]
ack ntim
19:42:53 [fantasai]
ntim: Elika's question about existing margins/paddings/etc. as we change orientations makes a lot of sense
19:43:04 [fantasai]
ntim: One thought is maybe we should have a shorthand for writing-mode and direction?
19:43:12 [fantasai]
fantasai: No, we don't want to do that.
19:43:26 [TabAtkins]
fantasai: we used to have that and got rid of it, because it's a bad idea
19:43:36 [fantasai]
(This is because writing-mode is presentation, and direction is content description)
19:43:41 [TabAtkins]
ntim: so the new property we come up with, shoudl it affect the ocmputation of th elogical properties?
19:43:53 [fantasai]
ntim: Or should we have some other mechanism?
19:43:53 [bkardell]
s/ th elogical / the logical
19:44:06 [TabAtkins]
fantasai: it's not just margins and paddings, it's width, flex-direction, etc
19:44:25 [TabAtkins]
fantasai: we need to define the internal layout details, and slider orientation would change all of these
19:44:36 [TabAtkins]
fantasai: in some cases we don't have physical equivalents, like flex is always logical
19:44:45 [TabAtkins]
fantasai: it's complex
19:45:02 [fantasai]
s/complex/complex to map from a slider-orientation value to e.g. flex-direction/
19:45:14 [fantasai]
astearns: I'm hearing a lot more questions than answers, let's take back to the issue
19:45:35 [fantasai]
Topic: Values and Units
19:45:57 [fantasai]
TabAtkins: I think all three of the first issues are resolved by our resolution to adopt mix() and map()
19:46:01 [fantasai]
TabAtkins: can double-check
19:46:12 [github-bot]
Subtopic: [css-values-5] Should all interpolation functions have a mixing version?
19:46:29 [fantasai]
TabAtkins: Lea raised this issue.
19:46:45 [fantasai]
TabAtkins: We previously had give color-mix() two syntaxes, and Lea asked if we need to be consistent with other mixing and interpolation things.
19:46:53 [fantasai]
TabAtkins: our conclusion was, yes, we should, all of the functions should be paired
19:46:58 [fantasai]
TabAtkins: and we resolved on that in the other issue
19:47:09 [fantasai]
lea: That was when they had the same function name
19:47:28 [fantasai]
TabAtkins: yes. Now we have mix() matching color-mix() and map() doing new thing
19:47:50 [fantasai]
TabAtkins: I think we can close this as obsoleted by the interpolation issue
19:47:59 [oriol]
What's the issue for map()?
19:48:24 [fantasai]
https://github.com/w3c/csswg-drafts/issues/6245
19:48:39 [fantasai]
lea: This is a different issue than we discussed earlier
19:49:13 [fantasai]
lea: especially now that we don't have mix() version of all things, question is do we still need mixign functions?
19:49:25 [fantasai]
lea: We have color-mix() for colors, but do we need e.g. calc-mix()?
19:49:52 [miriam]
q+
19:49:55 [fantasai]
TabAtkins: The same motivation for mix colors at different weights, might want to do with other types of values: images, lengths, etc.
19:50:00 [fantasai]
lea: so it's a weighted average
19:50:13 [fantasai]
TabAtkins: exactly. mix() functions do weighted averages, and map() does interpolation scales
19:50:21 [fantasai]
lea: I guess
19:50:36 [fantasai]
TabAtkins: Proposal in 6245 is that all of the relevant functions have both mix() and map() variant
19:50:47 [fantasai]
lea: OK, I guess fine
19:50:50 [astearns]
ack miriam
19:51:13 [fantasai]
miriam: Other use case requested that this helps with is being able to interpolate a font size between 2 values and follow an easing curve, so mix() gives you easing curve that you get with calc
19:51:20 [fantasai]
lea: but interpolation function is different. this is separate
19:51:37 [fantasai]
TabAtkins: interpolation function lets you interpolate between 2 values (possibly along a chain of values)
19:51:45 [fantasai]
TabAtkins: but that's different from mix()
19:52:02 [fantasai]
RESOLVED: Close as retracted by OP
19:52:23 [github-bot]
Subtopic: [css-values-5] Accept more than 2 values in `*-mix(<progress>, ...)` and `progress()` notations
19:52:35 [fantasai]
TabAtkins: This was about allowing more than 2 values to be mixed together.
19:53:04 [fantasai]
TabAtkins: resolution from https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2685746280 addresses this request
19:53:05 [oriol]
q+
19:53:37 [astearns]
ack oriol
19:53:40 [fantasai]
TabAtkins: Will need edits to colors to allow color-mix() to have more than 2 values
19:53:49 [fantasai]
oriol: When we were discussing what value should be with multiple values
19:53:58 [fantasai]
oriol: Lea was saying you would pick the two values and interpolate them
19:54:06 [fantasai]
oriol: another option would be weighted value among all values
19:54:10 [fantasai]
oriol: I'm not sure how these map
19:54:34 [fantasai]
TabAtkins: mix() all do weighted average, and map() does chained interpolation pairs
19:55:01 [fantasai]
ChrisL: Not totally clear that I understand about chained pairs
19:55:12 [fantasai]
ChrisL: color-mix() says if you don't specify either you have 50%
19:55:16 [fantasai]
ChrisL: you want to allow more than 2?
19:55:24 [fantasai]
ChrisL: if none is specified, you divide 100% by number?
19:55:27 [fantasai]
lea: yep
19:55:32 [fantasai]
ChrisL: Specify some but not all?
19:55:40 [fantasai]
TabAtkins: Split remainder among unspecified ones
19:55:48 [fantasai]
lea: and scale down sums above 100%
19:55:53 [fantasai]
ChrisL: will need to expand tests
19:55:56 [fantasai]
lea: expand but not change
19:56:12 [TabAtkins]
fantasai: should we keep this open to track edits for color-mix()?
19:56:29 [fantasai]
astearns: objections to updating color-mix() to match the plan for other mix() functions?
19:56:40 [fantasai]
RESOLVED: Update color-mix() to accept N arguments.
19:56:58 [github-bot]
Subtopic: [css-values] Alternative, weighted mean syntax for `calc-mix()`
19:57:20 [fantasai]
TabAtkins: crissov wanted a weighted average function
19:57:29 [fantasai]
TabAtkins: which is doing exactly what he requested (other than differences in grammar)
19:57:44 [fantasai]
TabAtkins: Weighted mean of calc() values, and interpolation thing, both are possible now with resolution to https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2685746280
19:58:03 [fantasai]
RESOLVED: Close issue as resolved by https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2685746280
19:58:05 [masonf]
masonf has joined #css
19:58:28 [github-bot]
Subtopic: [css-values-5] if() conditions with calc() comparisons
19:58:48 [fantasai]
TabAtkins: if() function lets you specify several types of test. MQ, CQ, supports Q
19:58:53 [fantasai]
TabAtkins: style Q
19:59:06 [fantasai]
TabAtkins: Would be useful to be able to do generic numeric comparisons, so e.g. could do var and number
19:59:23 [fantasai]
TabAtkins: You can currently do that by style query, but would be nice ot be able to inline the value
19:59:36 [fantasai]
TabAtkins: so suggest to allow simple numeric comparisons. Comparison operator in the middle. Just like MQ.
19:59:42 [fantasai]
TabAtkins: question about how to spell it
19:59:43 [miriam]
we haven't resolved on range comparisons for style queries, it's on the agenda
19:59:49 [fantasai]
TabAtkins: Suggest to use naked parens
19:59:59 [lea]
q+
20:00:09 [TabAtkins]
flex-flow: if( (100vw > 200px): row ; else : column; );
20:00:10 [fantasai]
TabAtkins: could come up with a name for this test, make it a function if ppl object to bare parens / have a good function name
20:00:25 [astearns]
ack lea
20:00:34 [oriol]
q+
20:00:35 [fantasai]
lea: We control the grammar.. couldn't we just put inline?
20:00:45 [fantasai]
TabAtkins: it's ambiguous because we allow boolean operators
20:01:08 [fantasai]
lea: If you don't use boolean operators, could we drop parens?
20:01:24 [fantasai]
TabAtkins: You do need brackets even then, to handle future expansion.
20:01:36 [fantasai]
TabAtkins: if you put anything unknown, e.g. new unit, you don't want to invalidate the entire declaration
20:01:46 [fantasai]
TabAtkins: you want to catch it by the general-enclosed production
20:02:05 [fantasai]
TabAtkins: That way "x or y" if x is new syntax, it's false, and y is true, test passes
20:02:11 [fantasai]
lea: Could we define [missed]
20:02:19 [fantasai]
TabAtkins: not in general case, because you don't know the bounds of an arbitrary new syntax
20:02:36 [ondrejkonec]
ondrejkonec has joined #css
20:02:42 [fantasai]
TabAtkins: we're ok with defining ourselves into matched brackets, but without explicit boundary it imposes too much grammatical ambiguity
20:02:52 [fantasai]
lea: any cases where it wouldn't be ambiguous?
20:03:05 [fantasai]
lea: e.g. dimension cmp dimension. Or replace one of those with a var. These are the most common cases.
20:03:25 [fantasai]
lea: I would argue that over 90% of use cases will fall into that category
20:03:44 [fantasai]
TabAtkins: I don't want to try and burden us with the fact that all future CSS value design in all contexts has to live under this restriction due to if()
20:03:56 [fantasai]
lea: I'm suggesting to have the parens for most cases, but carve out a subset of cases that don't require it
20:04:11 [fantasai]
TabAtkins: that still runs us into future ambiguity problems. E.g. can't use ':' because that's delimeter
20:04:25 [fantasai]
astearns: not necessarily. lea's saying that we can possibly drop parens for a subset of thing, but require them in other situations
20:04:30 [fantasai]
astearns: so that would require parens
20:04:39 [astearns]
ack oriol
20:04:46 [fantasai]
TabAtkins: Would need to learn weirdness of our parsing limitations. Try to avoid that when possible
20:04:52 [dbaron]
(I think it might also require 2-pass parsing.)
20:05:13 [fantasai]
oriol: Some values are resolved at used value, not computed value, e.g. length vs percentage.
20:05:18 [fantasai]
oriol: that would always resolve as false
20:05:25 [TabAtkins]
width: if( (100% > 200px): max-content; else : stretch; );
20:05:39 [fantasai]
TabAtkins: in this example, the percent depends on available space which is not known until layout time
20:05:44 [fantasai]
TabAtkins: but needs to replace for computed value
20:05:54 [emeyer]
emeyer has joined #css
20:05:57 [fantasai]
TabAtkins: at the moment, I think only thing we can do is treat this comparison as false, because can't resolve at computed value time
20:06:14 [fantasai]
TabAtkins: alternative would be to also define a calc() conditional thing, and have it resolve into that calc() expression
20:06:22 [fantasai]
TabAtkins: but that would be a lot of extra complexity for this case
20:06:27 [lea]
q+
20:06:30 [fantasai]
TabAtkins: I think this is a not-great situation no matter what we do
20:06:35 [fantasai]
TabAtkins: so current idea is to just call it false
20:06:44 [astearns]
ack lea
20:06:58 [fantasai]
lea: Right now there are ways to use min()/max()/clamp() for this
20:07:06 [fantasai]
lea: seems weird if doesn't have same machinery
20:07:33 [fantasai]
TabAtkins: yes, but we're mixing 2 different classes of functions. This is arbitrary substitution function, can do anything, but has to be fully resolved before inheritane.
20:07:53 [fantasai]
TabAtkins: we cannot inherit an unresolved substitution function
20:08:08 [fantasai]
TabAtkins: e.g. var() has to be resolved by computed value time. This is the same thing.
20:08:33 [lea]
q?
20:08:39 [TabAtkins]
fantasai: instead of making those always false, can we state them as always invalid? same effect but then CSS devtools can flag them as wrong?
20:08:44 [lea]
q+ or possibly have an unknown state
20:08:46 [lea]
q+
20:08:50 [TabAtkins]
fantasai: then authors won't be as confused
20:09:10 [fantasai]
TabAtkins: sure, we can have devtools flag that as a problem
20:09:12 [astearns]
ack lea
20:09:28 [fantasai]
lea: If we must have that sort of thing, it doesn't seem right to evaluate as false. What if we had an unknown state?
20:09:41 [fantasai]
TabAtkins: We do have 3-value algebra in MQ, so ...
20:09:49 [fantasai]
lea: So would want to style it differently.
20:09:49 [kizu]
`catch: `
20:10:04 [fantasai]
TabAtkins: you don't want the test to be false, but not-test to be true, 3-value logic we have handles that
20:10:10 [fantasai]
TabAtkins: so yes, makes sense
20:10:16 [fantasai]
TabAtkins: So treat these as unknown, yes
20:10:31 [fantasai]
fantasai: so like I said, invalid / uknown
20:10:49 [alisonmaher]
alisonmaher has joined #css
20:10:51 [fantasai]
astearns: So should we resolve to adopt the wrapped-in-parens version of this with 3-value logic?
20:11:15 [fantasai]
PROPOSED: Add numerical comparisons wrapped in bare parens, use 3-value logic for incomparable comparisons
20:11:24 [fantasai]
astearns: People can open separate issues for refinements
20:11:38 [fantasai]
astearns: e.g. for dropping parens in some cases, or evaluating different timing
20:11:46 [fantasai]
astearns: any more comments or concerns?
20:11:58 [fantasai]
RESOLVED: Add numerical comparisons wrapped in bare parens, use 3-value logic for incomparable comparisons
20:12:34 [dbaron]
(I'm also a bit hesitant about the bare parens syntax...)
20:12:50 [github-bot]
Subtopic: [css-values-5] Introduce nth-item()
20:13:20 [fantasai]
TabAtkins: we already accepted random-item() function, which takes a list and resolves to an item in the list randomly
20:13:41 [fantasai]
TabAtkins: proposal is to pair this with nth-item(), which is the same, but not random -- you give an index into the list
20:13:55 [fantasai]
TabAtkins: This allows you to have sets of properties controlled by a single variable
20:13:59 [fantasai]
TabAtkins: among othe things
20:14:11 [fantasai]
TabAtkins: Now that we have numerical comparisons, this could be done with if()
20:14:31 [fantasai]
TabAtkins: But nth-item() seems useful as a smaller syntax, and because it's directly analogous to random-item()
20:14:35 [kizu]
+n to this
20:15:06 [lea]
+n from me too :D
20:15:11 [miriam]
+1
20:15:21 [TabAtkins]
`random-item(fixed .1, a, b, c, d)` returns the first one, for example
20:15:27 [miriam]
+foo
20:15:35 [fantasai]
astearns: objections?
20:15:48 [fantasai]
lea: Does it cycle?
20:15:55 [fantasai]
fantasai: good question
20:16:06 [fantasai]
RESOLVED: Add an nth-item() function. Cycling TBD
20:16:31 [github-bot]
Subtopic: [css-values-4] `<integer>` grammar terms and `<number>`-returning functions
20:16:55 [fantasai]
TabAtkins: currently our math functions like calc(), sin() etc.
20:17:17 [fantasai]
TabAtkins: If they return a non-integer value, but required to return <integer>, we automatically round to nearest integer
20:17:55 [fantasai]
TabAtkins: If you a are a function that returns a number, but not a math function, currently invalid to use in <integer>
20:17:56 [miriam]
+1
20:18:01 [kbabbitt]
+0.9
20:18:05 [lea]
+calc(infinity)
20:18:05 [fantasai]
TabAtkins: Let's just call that valid.
20:18:15 [fantasai]
TabAtkins: This will not change literal number usage.
20:18:16 [bkardell]
+a
20:18:21 [fantasai]
TabAtkins: (that's been invalid for 30 years)
20:18:42 [fantasai]
TabAtkins: But this allows number-returning function to be used anywhere.
20:19:02 [fantasai]
astearns: If you have a custom property that is defined to be <integer> and you set its value with these, that works
20:19:07 [fantasai]
lea: yes, that works
20:19:24 [fantasai]
astearns: But if you have a custom property not defined as an integer, and set it using one of these math functions, does that get rounded?
20:19:31 [fantasai]
astearns: because not defining var()
20:19:39 [fantasai]
TabAtkins: var() will do substitution, and then we resolve the math
20:20:01 [fantasai]
astearns: We don't expect compat issues here?
20:20:02 [lea]
lea has joined #css
20:20:26 [fantasai]
TabAtkins: I think only example of non-math function defined to return a <number> is sibling-index() and sibling-count()
20:20:30 [fantasai]
fantasai: That's a spec error!
20:20:51 [oriol]
The spec is right, they return an <integer> already
20:20:58 [fantasai]
TabAtkins: But we could have them in theory. We made some up, but dropped them.
20:21:14 [fantasai]
TabAtkins: So we can fix this problem for anything we do in the future.
20:21:48 [fantasai]
PROPOSED: Functions that return a <number> will be rounded to an <integer> when used in <integer> context.
20:21:57 [fantasai]
oriol: Seems reasonable
20:22:02 [fantasai]
RESOLVED: Functions that return a <number> will be rounded to an <integer> when used in <integer> context.
20:22:50 [github-bot]
Subtopic: [css-backgrounds] Always serialize 'background-size' and `mask-size` as two values
20:23:32 [kbabbitt]
kbabbitt has joined #css
20:24:16 [fantasai]
ntim: -webkit-background-size, if you put a single value, has a different meaning than single value on standard background-size
20:24:27 [fantasai]
ntim: in -webkit-background-size, the value duplicates
20:24:35 [fantasai]
ntim: whereas in background-size we default to auto
20:24:41 [fantasai]
ntim: that's slightly different behavior
20:25:02 [fantasai]
ntim: Right now 2 engines serialize single-value form to one value, but WebKit serializes as 2 values due to this ambiguity
20:25:09 [fantasai]
ntim++
20:25:39 [fantasai]
ntim: spec says "use shortest form that doesn't introduce ambiguity"
20:25:54 [fantasai]
ntim: because of -webkit-background-size quirk, suggest to serialize as 2 values
20:25:57 [astearns]
ack fantasai
20:26:10 [TabAtkins]
fantasai: I'm on the record as saying that defaulting to auto was a mistake, i'm sorry. we should have duplicated the value
20:26:31 [TabAtkins]
fantasai: historical context is we didn't really have stretch images back then. seemed important to preserve the aspect ratio, but that was the wrong behavior in hindsight
20:26:36 [TabAtkins]
fantasai: i'm in support of serializing two values
20:26:49 [TabAtkins]
fantasai: if it was web compatible i'd prefer to change the defaulting behavior too
20:26:52 [TabAtkins]
fantasai: but probably can't do that
20:27:07 [jensimmons_]
jensimmons_ has joined #css
20:27:31 [TabAtkins]
astearns: so we'd be amking an execption to the shortest-serialization-principle for this property, to always serialize to two values
20:27:38 [TabAtkins]
astearns: objections?
20:27:59 [TabAtkins]
ntim: also for mask-size
20:28:14 [fantasai]
s/stretch/stretchy/
20:28:21 [TabAtkins]
RESOLVED: background-size and mask-size both always serialize to two values, as an explicit exception to the shorthest-serialization principle
20:28:35 [TabAtkins]
fantasai: can we do an httparchive to see if anyone uses single-value background-size?
20:28:51 [TabAtkins]
TabAtkins: use counters seem plausible
20:29:01 [TabAtkins]
fantasai: how do we do that?
20:29:07 [TabAtkins]
lea: we contact the httparchvie people and ask them
20:29:18 [TabAtkins]
astearns: maybe someone should document how to make a request
20:29:42 [TabAtkins]
lea: i'm contacting the person i've previousl gotten to help, think he's pulled back some but maybe he can point us to who to ask
20:29:57 [fantasai]
ACTION: Contact httparchive to check usage of single-value background-size
20:30:07 [github-bot]
Subtopic: [css-logical] Interpretation of two values in logical border-X-Y-radius properties for vertical writing-mode is illogical
20:30:29 [fantasai]
oriol: Wrt border-radius properties
20:30:39 [fantasai]
oriol: They accept 2 values, the horizontal and vertical components
20:30:47 [fantasai]
oriol: This works well for physical properties
20:30:56 [fantasai]
oriol: But then we added the logical longhands that share a computed value with them
20:31:08 [fantasai]
oriol: Since the logical and physical properties share a computed value, the ordering needs to be the same
20:31:19 [fantasai]
oriol: Which implies that the logical properties use physical ordering, which is quite nonsensical
20:31:26 [fantasai]
oriol: In the issue I proposed 2 possible ideas
20:31:34 [fantasai]
oriol: one would be turning each one of these longhands into a shorthand
20:32:07 [fantasai]
oriol: then we could map in the right way
20:32:21 [fantasai]
oriol: though we would be adding 8 new physical longhands and 8 new logical longhands, so a lot of properties
20:32:29 [fantasai]
oriol: another idea would be to make the computed value more complex
20:32:37 [fantasai]
oriol: Instead of just 2 length-percentages, we could add an optional flag
20:32:49 [fantasai]
oriol: this wouldn't be in the grammar of the properties, so authors wouldn't be able to specify it
20:33:02 [miriam]
q+
20:33:10 [fantasai]
oriol: but we would store this flag based on whether the value came from logical or physical properties
20:33:19 [fantasai]
oriol: And then the browser could serialize accordingly as well
20:33:29 [fantasai]
oriol: this would avoid adding new properties
20:33:37 [fantasai]
oriol: of course both of these ideas may suffer from web-compat
20:33:46 [fantasai]
oriol: so we may need to check
20:34:04 [fantasai]
oriol: If we say that for the logical ones the first component is inline and second is block, then that matches what happens with a horizontal writing mode
20:34:17 [fantasai]
oriol: even though it wouldn't match other properties like grid properties, which are block component first
20:34:24 [fantasai]
oriol: but that might be better for web-compat
20:34:46 [fantasai]
oriol: if we do it this way, in cases where authors specify two values that differ in vertical writing mode, may change
20:34:53 [astearns]
ack miriam
20:34:55 [fantasai]
oriol: could do a counter
20:35:01 [fantasai]
miriam: I want to solve this.
20:35:08 [fantasai]
miriam: we have a bigger issue about all logical shorthands and how to solve those
20:35:15 [fantasai]
miriam: current plan on that issue which is stalled for years
20:35:36 [fantasai]
miriam: but also to start with making sure we have all the longhands, and solve some shorthands for logical properties across the board
20:35:41 [fantasai]
miriam: I would like to see this solved along with the others
20:35:51 [fantasai]
miriam: if this is the one that starts it, great, let's move it forward
20:36:03 [astearns]
ack fantasai
20:36:23 [TabAtkins]
fantasai: i think adding 16 new longhands to control the individual components of each corner is overkill
20:36:31 [TabAtkins]
fantasai: i dont'; think anyone wants to cascade those independently
20:36:38 [TabAtkins]
fantasai: so preference is second option, an internal flag
20:36:52 [TabAtkins]
fantasai: i don't think this does anything to solve the larger problem of merging physical and logical shorthands, that's independent
20:37:00 [TabAtkins]
fantasai: tho i'd like to sovle that too
20:37:07 [miriam]
q+
20:37:14 [TabAtkins]
fantasai: so i think having an internal flag and having UA use the flag to reorder for serialization is good
20:37:22 [TabAtkins]
astearns: more detail on why it's a seaprate problem?
20:37:37 [oriol]
I agree they are different problems
20:37:44 [TabAtkins]
fantasai: the thing we're stuck on the most is how do you have a shorthand syntax like 'margin' that sets both physical and logical longhands
20:37:54 [TabAtkins]
fantasai: what syntax will tell you whether you're setting physical or logical
20:37:58 [TabAtkins]
fantasai: but we're not tackling that here
20:38:06 [TabAtkins]
fantasai: each of the properties here are either physical or logical
20:38:22 [TabAtkins]
fantasai: there's a confusing bit internally, we're storing physical pairing in a logical proeprty, that's what's causing the problem
20:38:28 [TabAtkins]
fantasai: so i think the second option is the correct one
20:38:28 [astearns]
ack miriam
20:38:34 [TabAtkins]
miriam: i understadn the distinctions
20:38:39 [TabAtkins]
miriam: don't know there's a dsitinction in the solutions
20:38:50 [TabAtkins]
miriam: some of the other proposals also involve a logical flag in some way
20:38:57 [TabAtkins]
miriam: i'm curious if these will interfere
20:39:01 [TabAtkins]
fantasai: i don't think they would
20:39:15 [TabAtkins]
fantasai: one of th ekey blockers is figuring out the syntactic flag and where it might occur
20:39:25 [TabAtkins]
fantasai: but the author, at some point, has to indicate they're doing logical instead
20:39:35 [TabAtkins]
fantasai: this isn't a case of that, we already know what the author is setting (it's in the name)
20:39:42 [TabAtkins]
fantasai: we just need the browser to internally store the correct info
20:40:12 [TabAtkins]
fantasai: and just to be clear, this is a magic flag not exposed to the author. can't read or write it, just an internal browser accounting mechanism
20:40:53 [TabAtkins]
astearns: so Oriol's proposal is to make the computed valu emore complicated, but this isn't exposed?
20:41:00 [TabAtkins]
fantasai: yes, not getCpomputedStyle() value, that's the serialization
20:41:14 [TabAtkins]
fantasai: we just use this flag to know how we should serialize
20:41:28 [TabAtkins]
astearns: do we have other instances where we have details not represented in the property
20:41:44 [fantasai]
fantasai: I believe we do, I feel that we have discussed this kind of thing before
20:42:01 [TabAtkins]
oriol: in webkit, i did something like this for -webkit-border-image
20:42:13 [TabAtkins]
oriol: when i made it a shorthand it sets one fo the standard longhands into a value that can't be represented by its grammar
20:42:26 [TabAtkins]
oriol: it has some special layout behavior, and in serialization you produce the empty string
20:42:38 [TabAtkins]
oriol: not sure about other browsers
20:42:58 [TabAtkins]
astearns: so proposed reoslution is to go with option 2?
20:43:00 [TabAtkins]
fantasai: yes
20:43:08 [TabAtkins]
astearns: objections
20:44:06 [TabAtkins]
RESOLVED: Adopt option 2 (an internal flag to track whether the value was set by the logical property or the physical one, and use that serialize propertly)
20:44:44 [TabAtkins]
fantasai: Oriol mentioned that because the current behavior is a physicla mapping in a logical property, in most of our logical properties we have block axis first, inline second. but in physical properties we ahve horizontal first and vertical second
20:45:02 [TabAtkins]
fantasai: so in horizontal writing mode, if you write `A B`, depending on whether it's physical or logical it'll map to opposite axises
20:45:21 [TabAtkins]
fantasai: because we've been using the physical ordering in these logical properties, it means currnetly for English they match.
20:45:28 [TabAtkins]
fantasai: aka it's "inline block" order
20:46:16 [TabAtkins]
fantasai: so there's a bit of compat issue. if we want to match existing behavior as closely as possible, with the understanding that these proeprties are super rarely used in a way that exposes this (elliptical corners)
20:46:41 [TabAtkins]
fantasai: if it's used widely enough (enough people doing elliptical radiuses using logical properties), we'd have to make an exception for the border-radius proeprties and have them take this inline-block ordering
20:46:55 [fantasai]
TabAtkins: We're trying to get logical ones to match our normal block-then-inline ordering
20:47:01 [fantasai]
TabAtkins: but chance that compat might restrict
20:47:18 [fantasai]
astearns: another archive query?
20:47:21 [fantasai]
TabAtkins: counter?
20:47:39 [fantasai]
fantasai: Could do archive query. Because vertical text x elliptical curves is so rare we can ignore
20:48:02 [fantasai]
ACTION: Check for use of elliptical border-radius in logical longhands
20:48:13 [dbaron]
are they implemented
20:48:51 [TabAtkins]
oriol: they're implemented, chrome metricss say 11%
20:49:05 [fantasai]
TabAtkins: no way, that's impossible
20:49:22 [fantasai]
TabAtkins: those things also get triggered by feature tests so... need to look into it
20:49:52 [oriol]
https://chromestatus.com/metrics/css/popularity#border-start-start-radius
20:50:50 [github-bot]
Topic: [css-position] overlay property UA sheet is not enough.
20:52:05 [fantasai]
TabAtkins: I think for this issue we should resolve to "figure out how to fix this". But it absolutely was an unintentional allowance.
20:52:15 [fantasai]
TabAtkins: overlay property, which allows things to leave top layer, is only settable on a few things
20:52:42 [fantasai]
TabAtkins: by default, UA stylesheet has 'none !important'. Can only use in transition property, can't actually set the property
20:52:49 [fantasai]
TabAtkins: But UA stylesheet only uses *
20:52:53 [fantasai]
TabAtkins: which leaves out pseudos
20:53:00 [fantasai]
TabAtkins: We don't have a way to generically refer to pseudo-elements
20:53:08 [oriol]
q+
20:53:21 [fantasai]
TabAtkins: So leave it open to figure out the solution, but we should resolve that this is unintentional and author's can't set it on pseudo-elements
20:53:26 [astearns]
ack oriol
20:53:37 [fantasai]
oriol: In another issue, 7346, we resolved to add some kind of ? to work on it
20:54:06 [fantasai]
oriol: syntax that would allow using *:<<* and this would select all pseudo-elements that are originated and would selected all possible pseudo-elements
20:54:07 [TabAtkins]
`:>>` being the "pseudo-tree combinator"
20:54:09 [fantasai]
oriol: we could use it here
20:54:13 [oriol]
*, * :>> * { overlay: none !important }
20:54:30 [fantasai]
oriol: more work to do but it's something
20:54:33 [astearns]
ack fantasai
20:54:51 [TabAtkins]
fantasai: can we just resolve here that the ua stylesheet must apply this to * and to all pseudos? and let the ua figure out how to do it
20:55:18 [TabAtkins]
astearns: we have in the past discussed whether it should be possible to express something in the UA stylesheet that cna't be expressed in author land, and decided that it's bad
20:55:33 [TabAtkins]
fantasai: you can do it in author land, just list all pseudo-elements explicitly. we just shoudln't be maintaining that list.
20:55:45 [fantasai]
astearns: proposed that overlay: none !important also applies to all pseudos
20:55:55 [fantasai]
RESOLVED: UAs must apply 'overlay: none !important' to all pseudo-elements
20:56:00 [fantasai]
Topic: Drafts Server
20:56:26 [fantasai]
jensimmons_: For ppl trying to get to drafts.csswg.org lately
20:56:42 [fantasai]
jensimmons_: it's been ... 40% of the time nothing will load, and 20% loads very very slowly
20:56:56 [fantasai]
jensimmons_: also noticed similar behavior on the wiki, which made it hard to figure out this meeting logistics!
20:57:01 [fantasai]
jensimmons_: It feels to me that we've had conversations about this before
20:57:11 [fantasai]
jensimmons_: what we need to do is decide to move everything from whereever it is to a new service
20:57:24 [fantasai]
jensimmons_: I don't know policies at W3C, not sure why we're not on the same servers as rest of W3C
20:57:37 [fantasai]
jensimmons_: but let's fine someone with $10/month and move to a new server, one that has built-in protections against DDOS
20:57:44 [lea]
q+
20:57:52 [ChrisL]
q+
20:57:56 [fantasai]
astearns: There are new problems with AI crawlers that not everyone has solutions for yet
20:58:06 [fantasai]
TabAtkins: all these are hosted by plinss, so all on the same servers
20:58:20 [fantasai]
TabAtkins: W3C doesn't host arbitrary stuff. most people put on GH and call it "good enough"
20:58:38 [fantasai]
TabAtkins: plinss said before what the reason was for drafts that we couldn't just have static files sitting somewhere
20:58:44 [lea]
q-
20:58:52 [fantasai]
TabAtkins: something has to go through a database lookup or track something in a database, and that's what spammers are causing problems with
20:58:59 [fantasai]
TabAtkins: if just static files, it's easy to serve
20:59:04 [fantasai]
TabAtkins: but I forget what the reasoning is
20:59:06 [astearns]
ack ChrisL
20:59:13 [fantasai]
ChrisL: This is actually W3C's fault
20:59:22 [fantasai]
ChrisL: Goes back to when we were hosting our own tests
20:59:33 [fantasai]
ChrisL: We would have enormous amounts of tests
20:59:43 [fantasai]
ChrisL: They told us not to keep so many copies of the test files
20:59:54 [fantasai]
ChrisL: So HP, at the time, offered to host stuff for us so we could do whatever we wanted
21:00:11 [fantasai]
ChrisL: We also had an elaborate build system because we were making multiple variants on the tests (that are no longer needed)
21:00:24 [fantasai]
ChrisL: and also a build system for the specs
21:00:48 [jensimmons_]
q+
21:00:50 [fantasai]
ChrisL: At this time a lot has progressed on the tooling side in the meantime
21:01:08 [fantasai]
TabAtkins: Major benefit of plinss's system is that you can request drafts as of particular date
21:01:13 [astearns]
zakim, close queue
21:01:13 [Zakim]
ok, astearns, the speaker queue is closed
21:01:14 [fantasai]
TabAtkins: I think that's the main thing.
21:01:24 [fantasai]
TabAtkins: if you didn't ask for history, didn't hit a database, was static files
21:01:39 [fantasai]
ChrisL: There was also a mercurial mirror etc. Again, we don't need that we don't need anymore
21:01:42 [fantasai]
TabAtkins: that's gone now
21:01:56 [astearns]
ack fantasai
21:01:56 [Zakim]
fantasai, you wanted to respond to "good enough"
21:02:04 [TabAtkins]
fantasai: on the topic of "hosted on github", that's actually now a process violation
21:02:21 [TabAtkins]
fantasai: anything a group is using is supposed to be hosted at a url where, if the service goes down, systeam can spin something up
21:02:46 [astearns]
ack jensimmons_
21:02:48 [TabAtkins]
fantasai: that doesn't mean we can't reuse w3c infra now, or use github underlying our own domain, but we can't just use github.io
21:03:04 [TabAtkins]
jensimmons_: yeah, you can def use github as a host and use a custom domain, takes two seconds
21:03:22 [TabAtkins]
jensimmons_: i used to run my own webdev shop, and watched hosting change drastically over several decades
21:03:33 [TabAtkins]
jensimmons_: so the situiation that existed last time we looked at this probably has changed yb now
21:03:34 [ChrisL]
For this week btw, uptime 68.46% outages 32 downtime 2 days
21:03:46 [TabAtkins]
jensimmons_: peter has been super awesome for a long time, just think it's time for a change
21:03:58 [TabAtkins]
jensimmons_: [describes Pantheon]
21:04:16 [TabAtkins]
jensimmons_: if we reach out to Pantheon, think they'd do it for free for us
21:04:34 [TabAtkins]
astearns: i think we shoudl continue talking about this, but will close the meeting for time
21:04:41 [TabAtkins]
astearns: see everyone in the morning
21:06:19 [fantasai]
[discussion about proxy strategies\
21:07:37 [fantasai]
[discussion about wiki stuff]
21:11:57 [fantasai]
[discussion about website stuff]
21:12:56 [dbaron]
:q
21:24:00 [dbaron]
Does reaching the drafts via https://w3c.github.io/csswg-drafts/css-values-5/ etc. produce a different set of redirects then getting there from https://drafts.csswg.org/css-values-5/ ?
22:36:16 [dgrogan]
dgrogan has joined #css