23:56:13 RRSAgent has joined #css 23:56:17 logging to https://www.w3.org/2025/11/12-css-irc 23:56:17 RRSAgent, make logs Public 23:56:18 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 23:57:39 present+ 23:58:41 present+ 23:58:50 present+ 23:58:52 present+ 00:00:34 GameMaker has joined #css 00:00:42 nigel_ has joined #css 00:00:53 dholbert has joined #css 00:01:03 present+ 00:01:19 adekker has joined #css 00:02:03 ydaniv has joined #css 00:02:24 kbabbitt has joined #css 00:02:39 present+ 00:03:09 present+ 00:03:23 present+ 00:04:02 present+ 00:05:10 oriol has joined #css 00:05:13 alisonmaher has joined #css 00:05:14 present+ 00:05:16 present+ 00:05:23 present+ 00:05:31 berlysia has joined #css 00:06:21 birtles has joined #css 00:07:04 saku has joined #css 00:07:59 ScribeNick: ydaniv 00:09:02 bkardell has joined #css 00:10:10 fantasai has joined #css 00:11:49 present+ 00:12:53 oops, should have waited until after 9am to invite RRSAgent 00:15:20 present+ 00:15:27 nigel has joined #css 00:15:58 present+ 00:15:59 present+ 00:17:13 (general round of introductions) 00:18:00 on phone can't talk now 00:18:47 cabanier has joined #css 00:19:44 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12815 00:19:44 Topic: [css-color-adjust-1] Wide Review 00:19:44 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12815. 00:20:12 ChrisL: 2 proposed resolutions, to add Alison as editor 00:20:23 ... and second to publish CR snapshot 00:20:34 astearns: can you summraize what happend so far? 00:20:35 karlcow has joined #css 00:21:04 ... do we always do wide review for snapshots? 00:21:07 ChrisL: yes 00:21:14 astearns: any more questions? 00:21:29 alisonmaher: do we do CRD first? 00:21:33 fantasai: no 00:21:50 Snugug has joined #css 00:22:02 RESOLVED: Publish CR Snapshot of css-color-adjust-1 00:22:07 present+ 00:22:40 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11798 00:22:40 Topic: [css-scoping] Scoping of functions, other name-defining at-rules and custom idents 00:22:40 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11798. 00:22:54 present+ 00:23:05 kizu: a lot of issue with naming, everything is mostly global 00:23:16 ... not accessible to shadow DOM 00:23:21 r12a has joined #css 00:23:25 ... not handy for authors of libraries 00:23:37 ... things clash together, different libraries and comps 00:24:01 ... some tools have solutions, like PostCSS, nothing in CSS 00:24:14 ... if you want to build a library you need to handle names yourself 00:24:32 ... this is an issue about brainstorming about what can be done, like scoping 00:24:54 ... if we do it with scoping it will be attached to trees, and this is not good for perfomance in some engines 00:25:01 q+ 00:25:04 ... maybe reuse the ... namespace 00:25:21 ... have some namepsacing for anything nested 00:25:30 q+ 00:25:37 ... there was a question about being able to namespace some of the things 00:25:47 ... maybe use ident() or other 00:26:01 ... maybe expose it via CSSOM, or shadow roots 00:26:27 TabAtkins: this looks good overall 00:26:32 q+ 00:26:36 ack TabAtkins 00:26:37 ... we need to see what things are scoped 00:26:48 ... requires some reviews, but looks fine 00:27:01 ... I think we'll allow namespaces, 00:27:07 adamargyle has joined #css 00:27:09 ... looks like a good approach 00:27:11 present+ 00:27:17 q? 00:27:19 q- 00:27:20 q+ 00:27:32 kizu: also anonymous namespace would be useful for small components if you don't want to share anything 00:27:56 s/allow namespaces/need to allow nested namespaces, which will require chaining the namespace component/ 00:28:01 astearns: I support this, but whatever we call it should probably not be "CSS modules" 00:28:08 Ragvesh has joined #css 00:28:14 q- 00:28:17 present+ 00:28:18 ... to not mistake it with other stuff 00:28:19 ack astearns 00:28:28 +1 to the idea 00:28:28 fantasai: I support just "namespacing" 00:28:42 q+ 00:28:57 plinss: not happy with overloading @namespace 00:29:08 canalun has joined #css 00:29:26 q+ 00:29:33 ... we should define a new namespace, but concept is fine 00:29:35 ack lea 00:29:36 @name-scope or something 00:29:43 lea: are there impl. concerns currently? 00:29:50 ... even tree scoping is not implemented 00:29:55 +1 to some other @rule name 00:30:05 ... when inheriting now values will change? 00:30:10 TabAtkins: purely lexical thing 00:30:19 ... things will bounce from the @-rule 00:30:43 ... custom properties will not, but other things will have {missed} 00:31:01 ack fantasai 00:31:02 ... trying to avoid complexities of that 00:31:24 fantasai: what if the spacing mechanism would work same as @namespace? 00:31:29 q+ 00:31:31 Kurt2 has joined #css 00:31:36 @realm? @prefix? 00:31:39 plinss: my concern is that the original name was used for something else 00:31:51 ... may not be used much anymore 00:31:59 q- (sorry) 00:32:04 q- 00:32:04 fantasai: it's just binding of a name to a string 00:32:22 TabAtkins: it is semantically related but substentialy different 00:32:40 astearns: it would be good to have a new name that doesn't bump up against docs of the old @namespace 00:32:48 Bobby has joined #CSS 00:32:51 ... would be good to have a new one even if hard 00:32:54 ack emilio 00:33:20 emilio: a bit of concern of how it interacts with custom properties 00:33:34 ... you're parsing a value like @keyfarmes name, becomes an identifier 00:33:46 ... if you specify from there it also get queued up 00:34:09 ... but as soon as you do via custom properites, you lose context, like when you apply it 00:34:30 ... I wonder how we'll do it in practice, I fear that recovering context will be hard 00:34:39 ... have an example to show 00:34:47 @namespace foo { @keyframes my-ident { ... } div { --custom: my-ident; animation-name: my-ident; /* works */; animation-name: var(--custom); /* ? */ } 00:34:58 Vinay has joined #css 00:35:03 ... this is one of the things we'll need to figure out 00:35:12 kizu: good thing think about 00:35:19 present+ 00:35:24 ... if you define as property and not [missed] 00:35:32 ... maybe we need somthing more explicit 00:35:35 Could have a function form of the scoped name *as well*, which is processed as substitution function, so eagerly even inside of custom props. 00:35:37 ... for that namespace or another 00:35:51 `scoped-name(foo, my-ident)` 00:35:52 schenney has joined #css 00:36:01 ... maybhave somthing like a namespace function 00:36:14 ... that says this is for this namespace or another 00:36:22 astearns: so let's take that back to issue 00:36:22 q? 00:36:46 ... so we're looking for a resolution to start working on that, taking back to issue? 00:36:49 kizu: yes 00:37:06 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12885 00:37:06 Topic: [css-fonts-5] or [css-text-4] Text Fitting: Which spec to put the feature into? 00:37:06 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12885. 00:37:12 q+ 00:37:30 kizu: initially we resolved that text fitting will be added to CSS fonts spec 00:37:44 ... google thought would be better at CSS text, no idea myself 00:38:06 ChrisL: I weakly agree about using CSS Text 00:38:11 ack ChrisL 00:38:19 fantasai: probably should be a low level spec 00:38:20 ack fantasai 00:38:25 astearns: agree 00:38:28 s/low/new/ 00:38:38 astearns: other concerns? 00:38:56 PROPOSED RESOLUTION: This will be using CSS Text level 5 00:39:01 astearns: objections? 00:39:13 q+ 00:39:13 RESOLVED: This will be using CSS Text level 5 00:39:27 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12887 00:39:27 Topic: [css-fonts-5] Text Fitting: Shrinking and Growing 00:39:27 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12887. 00:39:37 ack tkent 00:40:26 tkent: should we provide a single property? or separate ones? 00:40:26 q+ 00:40:37 ... also will there be a shorthand? 00:40:54 ... [showing slides] 00:41:14 ... a new text-fit property 00:41:35 ... a new text-grow property, and a new text-shrink property 00:41:36 q+ 00:41:43 q+ 00:42:07 flackr has joined #css 00:42:09 astearns: chair hat off, my impression is that the grow version of this feature has the most uses 00:42:12 present+ 00:42:25 ... I see uses for shrink, but don't know if it's something authors will use much 00:42:38 q+ 00:42:53 ... would like a fitting feature that grows first, and consider allowing shrinking later, before we box ourselves, and focus on grow 00:42:54 ack astearns 00:43:11 iank_: we have people that want to use the text shrink specifically 00:43:21 astearns: is taht request documented well? what for? 00:43:37 iank_: they want to contraint an area and reduce things as much as possible 00:43:52 q- 00:43:57 ack kizu 00:44:02 kizu: common cases are when have a number as big as possible and then shrink it 00:44:27 ... initial problem can be cumbersome, I think text-fit is the base option here 00:44:37 +1 00:44:41 q+ to ask how would shrinking interact with stuff like minimum-font-size and other accessibility settings 00:44:44 ... if we have either grow or shrink ... 00:44:56 ... having a single property helps here to simplify here 00:45:05 ... and later allow grow/shrink for more usecases 00:45:25 TabAtkins: I want to understand, when you allow just shrink or grow ... 00:45:46 kizu: whatever font size you have to specify and then it's either growing or shrinking 00:45:55 q+ 00:46:02 ... this allows you to say how much you want it to grow or shrink 00:46:09 ack miriam 00:46:09 +1 to kizu 00:46:25 miriam: sounds to me like use cases are ... 00:46:33 ... I like the simple text fit option more 00:46:45 ... concerned about a11y issues, is there another issue for that? 00:46:52 kizu: there is one, not mentioned here 00:47:06 ... we had concerns about some of the [missed] 00:47:12 Snugug has joined #css 00:47:24 ... mostly related to drawing, if it's unlimited you may need to zoom your text by 200% or more 00:47:49 ... with browser zoom will allow you to grow a lot, but have a limitation of viewport 00:48:30 +1 to worries with shrink accessibility 00:48:30 miriam: I worry about shrink option, if it is able to continue shrinking, would prefer if there was a baseline, and only have a top clamp and bottom open ended 00:48:37 ... so agree with astearns 00:48:50 astearns: kizu mentioned you have more slides? 00:48:51 ack emilio 00:48:52 emilio, you wanted to ask how would shrinking interact with stuff like minimum-font-size and other accessibility settings 00:48:59 tkent: yes 00:49:20 emilio: glad you said that, the whole shrinking thing sounds bad 00:49:42 https://docs.google.com/presentation/d/1ECs9qBS6yJiGy8aYbJ6vz3ph77mI1mnUgWqcBqFNv7k/edit?usp=sharing 00:49:47 ... not so much as an a11y issue, but could shrink the text down to something that can't be used 00:50:01 ... so +1 to start simple 00:50:39 miriam: don't think we should dismiss the rest, there's no guarantee this will always be used on large text 00:50:42 ack florian 00:50:45 ack fantasai 00:50:49 q+ florian 00:51:01 q+ 00:51:03 q+ 00:51:04 fantasai: are we asking for 1 proeprty? or 2? 00:51:10 astearns: it's the one or the 2 00:51:22 fantasai: I think we should go with the 2, and shorthand them 00:52:05 kizu: wanted to mention that text-fit will allow adjusting spacing and fitting, and will be more extensible 00:52:38 ... very hard to solve if we have multiple properties at the same time 00:53:10 fantasai: one way to work around a11y where people have a muinimum font-size, is to always clamp, with an overide keyword 00:53:36 miriam: it's unreliable, people misuse it 00:53:55 q? 00:53:59 Siyaman has joined #css 00:54:06 q- 00:54:13 fantasai: would should do flooring the value by default 00:54:23 q+ 00:54:29 ... your prefered size is not the smallest one, and you should have a declared starting point 00:54:33 ack florian 00:54:41 florian: I think we should go with a single property 00:54:53 ... shrinking is possible, but not all possibilites make sense 00:55:13 s/misuse it by e.g. setting it to 10px so they have a unit that's 10px/ 00:55:20 ... so shows syntax is wrong, if we have a single property it may allow a more sensible combination 00:55:32 ... as for shrinking, useful buy also dangerous 00:55:39 q+ 00:55:52 ... when users try to zoom and grow the text but it doesn't, it's hostile for users 00:56:15 ... we've been talking about font size, but also need to mention letter spacing and others 00:56:36 present+ 00:56:36 ... at some point if you reduce letter spacing too much it's not readable 00:56:55 q+ 00:57:02 ... let's not give up on shrink too quickly, and focus on the grow one first 00:57:16 astearns: we chair hat on, getting into details here 00:57:35 q- 00:57:45 ... 3 separate issues here, and Q is growing, would like to scope it to are we using option A or B (1 or 2 properties) 00:57:48 my worry with only supporting growing is that people will just set `font-size: 0.1px` and grow from there which is sub-optimal 00:57:49 and a vote for option 'a' 00:57:58 ... and the rest we should discuss separately 00:58:03 zakim, close queue 00:58:03 ok, astearns, the speaker queue is closed 00:58:14 +1 iank_ 00:58:14 ack dholbert 00:58:38 dholbert: thinking about dynamically loading content, the grow feature, may force text to grow too much in size 00:58:49 ack lea 00:58:53 ... don't have an easy way to avoid 00:59:10 lea: seems useful to have a customsable min and max 00:59:20 ... to control text size is a separate thing 00:59:51 ... regarding shrink/grow, if you can only grow and specify just min size may not be great for a11y 01:00:08 ... also the slides seem to talk about other stuff that are not text 01:00:17 ... have you considered a unit-based approach? 01:00:35 ... when you see designers they sometime control font size, sometimes letter spacing 01:00:49 Kurt6 has joined #css 01:00:52 (specifically the scenario I'm imagining is if you have a line of text "AAA BBB" that happens to exactly fit, and then some dynamic change happens [e.g. an image loads] and you have to linewrap "AAA" and "BBB" to two lines; then they'd grow to ~2x their initial size. And that sort of change might be a bit jarring) 01:01:04 ... sometimes it's ok to allow letter spacing grow longer, sometimes not 01:01:17 ... what if we had similar semantics to fr? and you could use it in clamp or minmax 01:01:17 dholbert: that is exactly the effect that some authors want :) 01:01:27 q+ 01:01:36 ack ChrisL 01:01:37 ... something along these lines, not well-formed yet 01:01:46 Issue with that is that it would only allow "consistent" growth/shrink, not per-line 01:02:03 ChrisL: wanted to point out when grow text kerning can change, we shouldn't forget these aspects 01:02:08 ack fantasai 01:02:31 s/kerning/kerning, tracking and optical size/ 01:02:36 fantasai: on the syntax front, if it's option A, you want to be able to relate the limit to multiple operations you're doing 01:02:46 ... so I think the syntax needs some more work to allow it 01:02:58 There is a lot, but we can't actually search all of them in a reasonable way. That's why, at least at first, basing it on font-size *only* is a reasonable choice. (It's also nearly the only option that is *guaranteed* to work on any font.) 01:02:59 q+ 01:03:05 ... and +1 to be able to set default font-size and adjust from there 01:03:33 astearns: so deciding on one of these options, is that viable? 01:03:35 q- 01:03:40 kizu: so this is a start 01:04:02 astearns: I think A is better option 01:04:07 zakim, open queue 01:04:07 ok, astearns, the speaker queue is open 01:04:07 ... other comments? 01:04:26 lea: would be great to have library that exposes this and we can observe authors' usage 01:04:33 miriam: there is one, fittext 01:04:43 lea: I know but would like to explore this 01:04:59 astearns: tkent will prototype and we can see how people use it 01:05:01 +1 lea 01:05:08 lea: still not optimal 01:05:11 astearns: agree 01:05:11 Snugug has joined #css 01:05:33 Penny has joined #css 01:05:33 RESOLVED: use text-fit for now 01:05:43 s/lea: still not optimal/lea: if it's behind a flag authors don';t use it, then we ship it and we realize it doesn't serve use cases well/ 01:05:54 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12888 01:05:54 Topic: [css-fonts-5] Text Fitting: Scaling of things based on font-size 01:05:54 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12888. 01:06:10 tkent: this issue is about how other items align 01:06:37 ... we had 3 options: A: all font-relative values are scaled based on font size 01:06:55 q+ 01:06:58 q+ 01:06:58 ... b: nothing other than text should be scaled 01:07:09 ... C: evenrhing should be scaled 01:07:19 ... [shows example in slide] 01:07:45 ... seems complexity is high when used with calc() 01:07:57 ... (regarding to option A_ 01:07:58 r12a has joined #css 01:08:25 q+ 01:08:38 ... B is simple and we can extend later 01:08:42 q+ 01:08:51 ... current impl. in Chrome is based on this 01:08:58 q+ 01:09:13 ... downside is non-text items can't be scaled 01:09:52 ... [shows example in slides] 01:09:54 q+ 01:11:02 ... in option A padding is re-evaluted 01:11:05 q+ 01:11:12 ... [missed] 01:11:19 ack kizu 01:11:25 kizu: I wanted to say there's discussion in the issue 01:11:59 ... Chrome implemented B, works well, the main issue was that I wanted to have option A, don't think it's posisble but would like it 01:12:09 ... don't think we should be limitting to one option 01:12:29 ... also lea mentioned we may want other properties to fit/scale 01:12:54 ... A and B could work in theory, we could implement A later 01:13:08 Snugug has joined #css 01:13:32 ... if we would be able to do it later, we could fix later things that depend on font-size 01:14:03 ... you could scale everything as much and later adjust other things accordingly 01:14:23 ... you could mix and match all things 01:14:39 Bobby has joined #CSS 01:14:55 ... think that combinations of other things should go to separate issue and we should consider them 01:15:10 ... could be something like text-fit [missed] 01:15:38 front-endian-jane has joined #css 01:15:48 ... we don't yet what would be good by default 01:16:12 ... we should start with option B and later continue on A 01:16:28 astearns: on your last point, we don't have an explicit keyword for a default value 01:16:42 ... I'd like to have an omittable dafault like auto 01:16:58 ... in favor of doing B for now, even though A is cool 01:17:11 ... worried that the scaling factor is available to authors 01:17:31 ... some non-text thing that could scale on the line, and have no way of finding out what that was 01:17:45 ack astearns 01:17:51 ack TabAtkins 01:18:14 TabAtkins: similar to what astearns said, this has been done before, don't want to do A until we have some ways to solve it 01:18:38 s/factor is available/factor is not available/ 01:18:39 ... I think there are good use-cases for B, like if your text has an inline image, it sould scale the same way 01:19:06 ack emilio 01:19:06 ... happy with starting with B as default, and have some keyword to allowing it, and later pusure A 01:19:25 emilio: I guess sum() does something similar 01:19:34 s/sum()/zoom/ 01:19:37 -q+ 01:19:58 s/we don't have an explicit/we don't have to have an explicit/ 01:20:06 ... is there a 4th option for doing a slightly better behavior? 01:20:17 ack kbabbitt 01:20:36 kbabbitt: I understand C is stay simple, B is just simple zoom of the text? 01:20:43 q- 01:20:54 iank_: it's not just zoom text, you're changing font-size , not just scale 01:21:05 kbabbitt: so you're basically changing font-size 01:21:11 iank_ :just for text 01:21:27 kbabbitt: was wondering how would that work with text-decorations 01:21:32 ack ydaniv 01:21:42 ydaniv: was wondering; I wasn't able to catch up with everything while scribing 01:21:47 ydaniv: does this work with SVG text? 01:21:52 ydaniv: that' snot just a text node 01:22:10 astearns: I think that should be a separate issue that we consider 01:22:18 ack florian 01:22:22 florian: I think we have to go with B 01:22:39 ... taht said, there are non-simple things we want to do, but not necessarily bound to A 01:22:52 ... proabbly should also work with units 01:23:13 ... but maybe be able to opt-in to other systems, like to grow into something, like the box decorations 01:23:25 treat-image-as-text generic feature? 01:23:25 ... currently only B makes sense for now 01:23:40 fantasai: strongly thins shouldn't go into style computation, like A describes 01:23:59 ... the ablilty to scale and change font-size are both useful, but they are different 01:24:42 ... want to remind that for other stuff like letter spacing, we have a sizing option that allows changing other stuff 01:25:15 ... there are a number of places in text layout where we previously relied only on em's and they resolve later and we needed percentage to do that 01:25:26 ... makes sense to me to use zoom 01:25:50 astearns: just to clarify, you're saying let's not do A for em's, but we have to do A for %'s? 01:26:29 fantasai: it could because it's based on a used-time operation 01:26:50 TabAtkins: the way we do it now is do a one-shot guess, and later scale to fit 01:27:06 ... in that case we would not have an accurate font-size necessarily 01:27:15 fantasai: you could adjust decorations to that 01:27:38 q+ 01:27:41 astearns: I think this would not be effective for authors who wouldn't know what that scale was 01:27:45 ack fantasai 01:28:11 fantasai: if you're zooming text and doubling the size of font, and don't scale the letter spacing with it, it would be very weird 01:28:29 Also text-decoration-thickness: from-font; 01:28:31 ... if it's set in %'s it supposed to match font-size 01:29:31 kizu: doing with one-shot as now and later apply fitting and scaling, as browsers currently apply 01:29:42 ... maybe we could later add a second shot 01:29:56 ... maybe what fantasai said could also work 01:30:02 astearns: one min before break 01:30:12 for the 2-shot TBH i don't think its worth it, but it should be another issue. 01:30:23 florian: maybe separate to 2 issues, we could do with B and check what it applies to 01:30:40 ... maybe would be harder to guess what your sclae would be in a one-shot 01:30:58 +1 to florian 01:31:01 Snugug has joined #css 01:31:03 ... the auto default should deal with text and we need to explore and it should include letter-spacing 01:31:18 PROPOSED RESOLUTION: start only with B, only text is scaled 01:31:40 astearns: any objections? 01:31:49 RESOLVED: start only with B, only text is scaled 01:32:07 s/is scaled/is scaled, "what is text" TBD/ 01:34:28 kzms2 has joined #css 01:35:46 does Canary do what you expected? 01:36:00 front-endian-jane_ has joined #css 01:36:47 Adam_Page has joined #css 01:37:04 front-endian-jane has joined #css 01:40:07 nigel has joined #css 01:40:23 alisonmaher has joined #css 01:41:36 jroque has joined #css 01:41:44 berlysia has left #css 01:45:59 sorvell1 has joined #css 01:46:55 Kurt4 has joined #css 01:48:26 iank_: Close enough for this purpose. I'm not 100% sure if I expect it to trigger fallback when the anchor actually starts to leave the page or just continue shifting, but either way, it's at least doing the same thing for ICB and body{position:relative} 01:49:03 sorvell2 has joined #css 01:49:17 sorvell2 has left #css 01:49:20 sorvell has joined #css 01:50:19 Adam_Page has joined #css 01:51:49 @ian 01:53:45 @iank_ & @TabAtkins — would be nice to look at https://issues.chromium.org/issues/425894800 — I think it is a bit related to some of the issues with fallbacks etc, and looks like a bug, but I am not 100% certain (but it stopped us from continuing experiments with anchor positioning in prod) 01:53:53 Adam_Page has joined #css 01:54:06 nicolo-ribaudo has joined #css 01:54:54 Patrick_H_Lauke has joined #css 01:56:18 @kizu - can you check M144 for me? 01:57:21 kbabbitt has joined #css 01:58:53 @iank_: Yep, just checked in 144.0.7525.3 — still reproduces (although a bit differently than before, but still looks broken) 01:59:03 ok 02:00:29 nigel has joined #css 02:00:29 adamargyle has joined #css 02:00:30 ydaniv has joined #css 02:00:48 nigel has joined #css 02:00:49 GameMaker has joined #css 02:01:21 scribenick: kbabbitt 02:01:33 Topic: Meta 02:01:50 astearns: a proposal for how to deal with scrollbars in non-rectangular displays being discussed in a few minutes in room 402 02:02:05 ... anyone not interested in anchor-pos but would be interested in that case, please go represent us there 02:02:25 berlysia has joined #css 02:02:45 ... we will likely get the people proposing it as group members once it's gone through some process, would be nice to have someone represent today 02:02:55 Topic: anchor positioning 02:02:59 github-bot, take up https://github.com/w3c/csswg-drafts/issues/9408 02:02:59 Topic: [css-anchor-position-1] Allow anchor references to match names in outer tree scopes 02:02:59 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9408. 02:03:02 saku has joined #css 02:03:07 Penny has joined #css 02:03:08 Snugug has joined #css 02:03:11 present+ 02:03:25 TabAtkins: this is an issue where I went ahead and synthesized feedback into a spec edit 02:03:32 ... andruud realized we didn't have a spec edit 02:03:44 ... smal change to how we resolve anchor names and references with shadow trees involved 02:03:49 ... prevoiusly could not reach out in either direction 02:03:56 present+ 02:04:05 ... I've dropped a small tweak in that allows an anchor name to be defined higher up in shadow tree 02:04:11 ... and anchor reference in shadows can refer to that 02:04:24 birtles has joined #css 02:04:25 nigel has joined #css 02:04:26 ... will do standard thing of looking up tree ignoring shadow boundaries until it finds a name 02:04:35 +1 02:04:37 ... satisfies westbrook's use case 02:04:44 +1 02:04:53 ... there is still the other side where you want an anchor name defined deep in a shadow referenceable elsewhere in tree 02:05:01 ... requires more explicit opt-in to be safe in my opinion 02:05:09 +1 02:05:09 ... would like to work on in the future but for now I think spec is in a good state 02:05:21 ... so if there are no objections we can resolve to take these edits 02:05:21 ack kizu 02:05:34 ack fantasai 02:05:34 fantasai, you wanted to ask about other naming 02:05:34 q? 02:05:50 fantasai: could you summarize for the group... we have a variety of name matching behaviors, what's changed? 02:05:58 TabAtkins: previously in the spec, anchor names were tree scoped names 02:06:07 ... carry around identity / style tree they were defined in 02:06:11 Vinay has joined #css 02:06:13 ... anchor names were strict tree scoped references 02:06:21 ... would only match tree scoped names defined in same tree as they were 02:06:25 ... now they are loose tree scope names 02:06:32 ... will match any names in their own tree or higher up tree 02:06:42 ... if trees don't have parent-child relationship they won't match 02:06:59 ... can define in parent component, top level component, any tree will see that 02:07:11 fantasai: did we change how it works for other props? 02:07:28 TabAtkins: we have not right now because we haven't rewritten scoping rules for timelines to match anchors 02:07:38 ... but intention is to keep all those concepts resolving exactly as identically as possible 02:07:46 astearns: do we have that intent written down? 02:07:51 TabAtkins: we resolved on it during breakout in Paris 02:08:08 astearns: do we need CSS operations module or something that collects some of these cross module resolutions 02:08:21 ... we do have space on wiki for design principles, this seems like something that should go there 02:08:23 TabAtkins: seems reasonable 02:08:27 astearns: other comments? 02:08:33 Proposed: Accept the edits 02:08:43 RESOLVED: Accept the edits 02:08:56 github-bot, take up https://github.com/w3c/csswg-drafts/issues/13067 02:08:56 Topic: [css-anchor-position-1] Back-compat of scrollable containing block for all abspos with implicit anchors 02:08:56 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13067. 02:09:18 fantasai: for scrollable containing blocks of a positioned block 02:09:31 ... when you have a scroll container, there's scrollport which doesn't move with scroll 02:09:39 ... local containing block which is ICB equivalent for the scrollport 02:09:51 tantek has joined #css 02:09:54 ... and there's the scrollable containing block which roughly corresponds to entire scrollable area 02:10:17 ... abspos boxes are defined currently if their CB is generated by a scroll container, they reference the LCB 02:10:44 ... if I position something bottom:0, in a scroll container, it will be positioned at the initial scroll position to coincide wuth bottom wedge of scroll part and scroll with container 02:10:59 ... with anchor pos, we have these fallback concepts and other kinds of sizing where exact position of that bottom matters 02:11:07 "fixed" -> size of scrollport, 'outside' the scroller (like fixpos). "local" -> size of scrollport, 'inside' the scroller at top (like ICB). "scrolling" -> size of scrollable content, 'inside' the scroller (this is new and anchorpos automatically uses it sometimes) 02:11:09 ... what's outside the container can affect layout, with try fallbacks or overflow alignment 02:11:25 ... as we add more capabilities to abspos, that edge becomes more present even in cases where you were only referencing top and left corners 02:11:47 ... we discussed this and decided to use the scrollable containing block as the containing block for boxes that have a default anchor element 02:12:10 ... problem with that is that even if you just use normal anchor positioning, boxes that have implicit anchor element now have default anchor element 02:12:19 ... and have now switched into this behavior even if they don't use anchor pos 02:12:26 ... existing page using popover for example with position bottom 0 02:12:33 ... will change behavior from being above the fold to below the fold 02:12:38 ... which is a compat issue 02:12:56 ... bottom 0 still needs to mean bottom of containing block 02:13:03 (popover is `position:fixed` by default so also need `position: absolute` on the popover to trigger the switch) 02:13:37 ... but for purpose of overflow management we need a bigger area 02:13:51 ... my proposal is that if inset is auto, we resolve it to the edge of the scrollable area 02:13:52 q+ 02:13:56 ... rather than the edge of the local containing block 02:14:03 ... and that creates the space we need without triggering overflow 02:14:11 ... and without changing interpretation of a fixed length 02:14:19 s/bottom of containing block/bottom of local containing block/ 02:14:25 ack TabAtkins 02:14:30 TabAtkins: I am with iank_ 02:14:56 ... not liking this particular proposed resolution because it means auto no longer has as stable and obvious thing to resolve to 02:15:04 ... difference between leaving edge as auto and wanting to adjust a little bit 02:15:12 ... suddenly you opt into other interpretation and get a big jump you didn't expect 02:15:26 ... back compat issue is that having any anchor at all is what we resolved to use as a switch 02:15:33 ... some things get anchor ayutomatcially without doing anything 02:15:45 ... just fixing that bit would solve the back compat issue without being overly problematic in the other way 02:15:55 ... my preferrred solution is to explicitly key off non-auto default anchor 02:16:00 ... initial value auto will use implicit anchor 02:16:08 ... add implicit keyword which uses implicit anchor 02:16:18 ... that way you're affirmatively using anchor pos in a similar way to non-auto 02:16:33 ... that way we can add more implicit anchors in the future and it won't switch positioning behavior and be low impact 02:16:43 ... other possibilities iank_ mentioned of using ? anywhere in your insets 02:16:56 ... we rejected doing that for other reasons, don't recall the details 02:17:17 i'm ok with that. 02:17:25 ... would instead propose to add implicit keyword, and key off having anchor and non-initial value for position-anchor property 02:17:39 ack fantasai 02:17:45 fantasai: I have serious problems with that approach 02:17:47 ... 2 problems 02:18:02 ... 1 I don't think a property that controls anchor binding and changes how it matches the binding should have a big effect on layout 02:18:25 ... we're not changing element we're binding to, just changing keyword with exact same behavior, it just has a new side effect of changing how insets are resolved 02:18:29 ... that's really confusing 02:18:43 ... could have a question of whether there's a binding or not but shouldn't affect layout 02:18:51 ... 2, need this to work by default 02:19:04 ... if author needs to opt into ?? by default, they can do so with more obvious declaration 02:19:12 ... so I don't think that's a good plan 02:19:22 ... re: auto and 0 don't resolve to same thing - that's fine 02:19:27 ... if you want 10px of spacing, add a margin 02:19:41 TabAtkins: wasn't that auto and 0 resolve to same, auto is unpredictable value now 02:19:47 ... can't say I want to use current edge but inset a little bit 02:19:50 fantasai: add a margin 02:19:59 ... auto already has a lot of cases where it has an unpredictable value 02:20:05 ... can't say I want to be static position + 10px 02:20:09 ... this is already a feature of auto insets 02:20:31 iank_: for the non dominant edge it's always true you can inset a bit an dit works 02:20:46 ... I was playing around with it and it's very weird if you jump to a local when the right hand side is on the scrolling containing block 02:20:53 ... a lot of people do use insets in this way 02:20:57 ... I just want you in a little bit 02:21:02 ... people will run into jump and not understand it 02:21:06 ... very against that 02:21:13 fantasai: then let's require people to set position-area 02:21:33 TabAtkins: that's saying people should use a no-op property that indicates anchor pos vs the property I'm sating 02:21:43 fantasai: difference is position-area is a layout property 02:21:52 ... whereas position-anchor is how I connect an abspos to its anchor 02:21:59 ... and you want to introduce synonym to initial value 02:22:06 ... where only difference is one has a layout side effect 02:22:10 TabAtkins: like all the other non auto values yes 02:22:16 ... named anchor has same side effect 02:22:18 fantasai: no 02:22:21 TabAtkins: currently it does 02:22:27 ... per current spec it would give you side effect 02:22:47 ... problem is right now if you leave as auto and get explicit anchor, that triggers side effect which has back compat 02:22:48 q+ 02:23:03 ... so if you say implicit anchor and have that trigger 02:23:07 ... [missed] 02:23:43 iank_: previous resolution was to trigger this scrollable containing block behavior off the existence of default anchor 02:23:51 ... set via position-anchor property, not if you use position-area 02:24:01 ... spec is currently mismatched with that resolution 02:24:10 TabAtkins: because position-area only does something when you have a default anchor 02:24:17 ... if we care about position-area, it's a subset of having default anchor 02:24:27 Ragvesh has joined #css 02:24:35 present+ 02:24:37 fantasai: under current resolytion if you set position-anchor to --foo and there's no --foo you don't get behavior? 02:24:40 TabAtkins: correct 02:25:07 ... propose that if you have a default anchor and position-anchor is not default value you opt into the behavior 02:25:48 fantasai: you're saying I want synonym for auto, behaves just like auto, other than it has side effect on contianingh block 02:25:58 ... even though this property has no effect on layout prior to this discussion 02:26:03 ... and we have separate property for that 02:26:18 TabAtkins: we already resolved that if you have position-anchor --foo and --foo exists, that triggers 02:26:25 fantasai: I'm saying that was a bad decision 02:26:34 ... ok with saying you need to change position-area to span-all 02:26:43 ... or changing the way auto insets resolve 02:27:03 ... not okay with having a property whose sole purpose is to create a binding with 2 nearly identical values where one has side effect 02:27:17 astearns: little confused about how this new feature could have back compat issues 02:27:24 Adam_Page has joined #css 02:27:26 ... because you need to set both binding and position-area to get new behavior? 02:27:37 ack astearns 02:27:44 TabAtkins: resolution we had was that if you are using anchor positioning, if your CB is a scroller, you start using scrollable containing block 02:27:53 ... that's a good behavior if you're actyally using anchor pos 02:28:07 ... problem is behavior for "are you using anchor pos" is just "do you have a default anchor" which is given byt the position-anchor property 02:28:17 ... if you specifgy a name and that matches something you're clearly using anchor pos 02:28:26 ... problem that default value auto will look for implicit anchor 02:28:32 ... and there's several sources for that 02:28:44 fantasai: so this would change behavior of any abspos value before pseudo element 02:28:56 TabAtkins: something using 0 will be at bottom of scroller instead of bottom of scrollers' ICB 02:29:06 chrisl: something being accidentally opterd in? 02:29:08 TabAtkins: correct 02:29:29 ... fantasai's preference is to change position-area 02:29:46 ... not super opposed but if you don't care about position-area, it's a little strange to have to turn it on and give it a no-op value just to make your anchor pos resolve 02:29:51 fantasai: not a no-opt, opting you into new behavior 02:29:57 Snugug has joined #css 02:30:06 TabAtkins: my thing is, thing that gives you position-anchor, add another keyword that opts you in 02:30:12 q+ 02:30:13 Could it be both: either `position-area` or an explicit `position-anchor` will opt in? 02:30:15 ... use the fact that it's non-default value as a strong signal 02:30:15 q+ 02:30:23 ... also effectively a no-op since it's behavior of autp 02:30:34 ... but if you're not using position-area in other way you don't need to put that in your styles as well 02:30:35 i'm strongly against setting `position-area` 02:30:46 notbody is going to remember how to do that. 02:30:53 ... don't feel too strongly about which way we go, find position-area a little weird, but proposed thing about auto resolutions I do object to 02:30:56 ack fantasai 02:30:56 fantasai, you wanted to review the position-area value 02:31:04 fantasai: my proposal is switch to using positon-area as signal 02:31:09 ... its initial value is none 02:31:14 ... we have a span-all value which gets you whole 9 grid 02:31:24 ... any non-initial value would give you containign block is entire scrollable area 02:31:43 ... to compensate for anchor functions not using position-area in general ,change interprateation of auto for insets to expand out to sctollable area 02:31:52 ... specific value would go back to previous behavior 02:31:55 ... would be back compatible 02:32:01 ... otherwise you need some explicit signal 02:32:08 q+ 02:32:17 ... TabAtkins is proposing new keyword for position-anchor that will opt you into that behavior 02:32:23 masonf has joined #css 02:32:24 ... I am saying we already have explicit switch 02:32:27 ack miriam 02:32:33 miriam: tend to agree with fantasai here 02:32:37 ... what we are changing is not the anchor but the area 02:32:45 ... so position-area is what makes sense to do that 02:32:52 ... wonder if we can be more explicit? not just span-all 02:33:08 ... span-all has 2 slightly different meanings, can we explicitly say what I'm doing is opting into ... whatever it's called 02:33:16 ... does feel like we're talking about the area, that's what's changing 02:33:22 ... if we can say it more explicitly taht's good 02:33:26 ack fantasai 02:33:26 fantasai, you wanted to react to miriam to respond to that 02:33:32 fantasai: earlier we discussed a proposal to differentiate between these 3 CBS 02:33:33 (what do you mean by "2 slightly different meanings"?) 02:33:44 ... fixed, local, scrollable containing blocks 02:33:54 .... plan to work on switch for those 3 explicitly 02:34:03 ... would affect 9-grid for position-area as well as everything else 02:34:10 ... initially proposed auot to allow anchor pos to just work 02:34:17 ... there will be an ability to explicitly do that 02:34:31 fantasai: span-all aready says use whole 9 grid 02:34:36 ... bounds of that is whole scrollable CB 02:34:52 TabAtkins: was curoius what miriam meant by 2 slightly different meanings 02:34:59 miriam: is that what fantasai just clarified? 02:35:06 TabAtkins: yes we use entire scrollable CB 02:35:29 miriam: if that means that already ... just noting there's a difference between different containers you could consider 9 grid to be part of or offset of, and we're switching from one to another 02:35:36 ... in that case I agree with fantasai straightforwardly 02:36:00 astearns: kind of sounds like we are relitigating the initial design that relied almost entirely on anchor functions and we made a decision to go with position-area instead 02:36:24 ... perfectly happy having the anchor functions trigger on position-area as opposed to the position-anchor property 02:36:41 ... particularyly since position-anchor has defauylt value that authors might find themselves having to work around without making any anchor pos decisions 02:36:56 ... I am probably confused myself but i think I am weakly in favor of fantasai's proposal 02:36:59 TabAtkins: which version? 02:37:06 astearns: using position-area as the trigger 02:37:16 ack iank_ 02:37:23 ack astearns 02:37:27 iank_: don't really like position-area to change the behavior of the insets 02:37:29 [The two variants were a) use position-area or b) use position-area and also reinterpret inset:auto ] 02:37:33 ... you can use anchor pos in 2 different ways 02:37:38 ... position-area or insets with anchor functions 02:37:58 ... when you're working in anchor function mode, having to remember oh it's not working in scroll container, I need to set position-area span-all, no one's going to do that 02:38:05 ... so I strongly dislike that 02:38:13 ... to the point where I'll probably object on API design standpoint 02:38:15 miriam, the 9-grid just divvies up *whatever* the CB is; span-all means "use the whole 9-grid". It doesn't *inherently* say anything about which CB you're using, but it does function as a signal for "i'm using anchor positioning", which is a signal we want to use to automatically opt you into the scrollable CB. (and we have resolution to change 'position' to let you explicitly choose your CB too, but this is just to flip the "default" answer) 02:38:24 ... shouldn't have to care about position-area if just using anchor functions 02:38:40 ... variant could be, if you have a non-implicit default anchor or using position-area, I'd be happy with that 02:38:47 ... doesn't affect popover which is position:fixed 02:38:53 ... unless you change to absolute 02:38:58 ... will affect before, after 02:39:03 ... but not sure of compat of that anyway 02:39:18 ... my preferred solution is non-implicit default anchor, or use position-area property 02:39:22 ack fantasai 02:39:35 fantasai: I think it's a bit weird to have the method of the binding change the layout 02:39:53 ... whether or not there's a binding makes sense, but not method 02:40:13 ... we want people to choose binding depending on whetehr it's presentational or semantic effect, not what layout side effects it has 02:40:33 ... would not expect layout side effects based on choice of HTML or CSS 02:40:51 ... would be nice if anchor pos just worked, why I proposed having auto value of insets resolve to edges of scrollable CB 02:41:02 the issue Ian has with "rely on position-area" is that it means some otherwise-very-similar styles act wildly differently, as he pointed out in https://github.com/w3c/csswg-drafts/issues/12552#issuecomment-3141570111 02:41:04 ... maybe not ideal that inset 10px doesn't get you 10px inset from currently effective scolling container 02:41:07 example: .anchored1 { 02:41:07 position-anchor: --a; 02:41:07 position-area: bottom; 02:41:07 } 02:41:07 .anchored2 { 02:41:07 position-anchor: --a; 02:41:07 top: anchor(bottom); 02:41:08 } 02:41:10 ... but easy to use marcgins if you want spacing 02:41:24 ... [missed] is not an unreasonable thing for auto to do 02:41:33 iank_: I think it is unreasonable, most people use insets rather than margins for htis 02:41:44 TabAtkins: pretty opposed to the auto change 02:41:46 s/[missed]/having auto resolve to a non-zero value/ 02:41:50 ... don't like its magic 02:42:00 astearns: how do we resolve this standoff? 02:42:04 fantasai: hear from more people 02:42:22 astearns: should we take this back to the issue and go through examples? 02:42:40 ... iank_, you said you played with it and it was bad, would be helpful to see what you were playing with 02:42:43 iank_: I can do that 02:43:06 TabAtkins: example in chat, our current resoluytion which relies on default anchor, both of those get scrollable containing block 02:43:15 ... using position-area has a little more magic but for raw positioning they work the same 02:43:24 ... if we only use position-area as switch, these two would be dramatically different 02:43:38 ... using anchor function would most certtainly be overflowing and trigger fallbacks 02:43:45 ... because you'd use the LCB which is above the fold section 02:43:56 ... which is weird because it looks like you're using anchor pos 02:44:02 ... authors have to use no-op position-area value 02:44:15 q+ 02:44:17 ... onlh problme with intiial reasolution is that it has back compat in non anchor pos cases 02:44:58 ... we ideally want to just exclude back compat problem rather than change reoslyutionmore dramatically 02:45:12 ack flackr ; 02:45:15 ack flackr 02:45:24 flackr: do we have evidence that there is a compat issue with changing abspos behavior in this case? 02:45:43 TabAtkins: we don't have examples in the wild, certain it exists, will hapen if anyone has done before element with abspos and bottom 0 containign block scroller 02:45:49 flackr: what's the use case for that? 02:46:03 TabAtkins: if you have ever used anything with bottom inset in CB scroller you will have changed behavior 02:46:07 ... what we did in past will change position 02:46:26 flackr: sizing changes would be bigger issue 02:46:26 TabAtkins: yes for example top0 bottom: 0 02:46:26 ack fantasai 02:46:26 fantasai, you wanted to comment on the example with implicit anchors 02:46:26 ... suddenly you're size of entire scroller 02:46:36 fantasai: back to TabAtkins example he's using position-anchor to connect 02:46:44 ... if you rely on position-anchor that would not exist 02:46:56 ... that's the case that's creating some of the tension here 02:47:05 ... an anchor exists but not using position-anchor property 02:47:06 s/on position-anchor/on the implicit position-anchor/ 02:47:09 ... would be nice if that just worked 02:47:21 ... but what TabAtkins is proposing is that top example would be just position-area bottom since we have ancghor 02:47:33 ... but second example would have to say position-anchor something as well as anchor top anchor bottom 02:47:47 canalun has joined #css 02:47:53 ... would be nice to make that just work, fact ytou have to say position-anchor in order to get your containing block to work is quite weird 02:47:59 ... shouldn't change layout behavior 02:48:20 ... you already have an anchor association, and you're not associating it 02:48:22 TabAtkins: though your proposal ignoring inset ayuto for a bit would still require another line there 02:48:30 ... which is just as much ofa put a no-op in 02:48:39 fantasai: right, that's why I wanted to change interpretation of autop 02:48:47 ... and if you add an extra line, it should be position-area 02:48:59 (and not position-anchor) 02:49:01 TabAtkins: we'll object to changing auto inset behavior in the way that was suggested 02:49:21 ... however what if we go with a non-implicit anchor or a non-none position area 02:49:37 ... that way in the example from iank_ either position-anchor --a or position-area span-all would work 02:49:57 fantasai: don't think it is good for authors to have implicit anchor have different behaviors than explicit anchor 02:50:07 ... don't think method of binding should have effect on layout 02:50:11 q+ 02:50:19 ... if all keywords have special side effect except initial that makes a little more sense 02:51:03 ... don't want to push authors to consider layout effects when trying to decide if they should use explicit or implicit binding, HTML or CSS 02:51:08 q+ 02:51:17 ... that shouldn't be about whether there's a layout effect, only about what is appropriate type of binding 02:51:27 .... also thing it's weird to use binding property as layout switch 02:51:54 ... less objectionable if it's not deciding which binding to use, but using a binding property as a binding switch is still weird and I think confusing 02:52:06 ack miriam 02:52:06 s/binding switch/layout switch/ 02:52:19 miriam: seems like all this is caused by making everything magical without opting in 02:52:24 ... wonder about just having a literal opt-in 02:52:31 ... default of position-anchor is not auto, it's none 02:52:36 ... and you have to set to auto if you want an anchor 02:52:43 q for fantasai: wait, are you okay with "non-initial position-anchor *or* position-area", so using the implicit anchor with position-area switches? because that's totally fine with me 02:52:43 ... or explicitly opt into anchor pos for anything else to work 02:52:46 Snugug has joined #css 02:52:47 ... would be a normal thing in CSS 02:52:57 ... for positon-anchor, real opt-in 02:53:06 ack iank_ 02:53:25 iank_: what was the reason that we didn't want to trigger off anchor functions on insets? 02:53:25 TabAtkins: don't remember and that's a problem 02:53:35 ... we resolved to not do it early in the proposal discussion, year + ago 02:53:40 ... don't recall exactly what the issue was 02:54:04 emilio: don't remember either 02:54:13 TabAtkins: we decided not to do that, don't remember exact reason 02:54:53 emilio: anchor functions ... when you do interleaving, anchor functions resolve to actual piel values at computed style time 02:55:02 ... computed style doesn't have info to tell if there's an anchor reference 02:55:11 ... if you keep magic bit for anchor function, it doesn't round-trip 02:55:22 ... div.style.bottom = gCS.bottom, it goes away, would be bad 02:55:33 ruoya has joined #css 02:55:42 iank_: abspos doesn't reoundtrip insets today anyway 02:55:58 ... does it? 02:56:01 TabAtkins: yeah? 02:56:04 emilio: auto resolves 02:56:05 sin45 has joined #css 02:56:11 I'm being told by someone in WICG that they're looking for CSS representation for the scrollbar feature. I'm not sure I'm the right person to go down and represent the WG, but if no one else is able to do so I will 02:56:15 iank_: shrink to fit vs stretch ... you % will resolve differently 02:56:26 fantasai: won't change % resolution because that's based on CB 02:56:33 ... resolving auto might have some effect 02:56:36 ... anything else should round-trip 02:56:48 will do. 02:56:51 iank_: I would be fine with losing the round-tripping 02:57:09 emilio: pretty unfortunate, this would also be the case even with typed om that doesn't do resolved value shenanigans 02:57:14 ... typed om doesn't resolve auto 02:57:17 ... but does resolve anchor to px 02:57:21 ... due to how anchor is defined 02:57:35 ack fantasai 02:57:35 fantasai, you wanted to suggest using position-area OR position-try 02:57:42 fantasai: the problem we're running into doesn't happen with TabAtkins example 02:57:50 ... problem happens when we add to that example something like position-try 02:58:05 ... so what if we trigger SCB on having either position-area non-initial or position-try non-initial 02:58:10 ... would that solve teh core problem? 02:58:20 iank_: don't think that works because available space is different between 2 examples 02:58:31 .... if it' sleft or right, available space of local CB vs scroillable CB is 2 very diferent things 02:58:35 ... shirnbk to fit will be different 02:58:43 TabAtkins: height % will also be different 02:58:56 fantasai: changing the resolution of % also, a lot of things to trigger based on 02:59:13 ... also you have the case of, if you use anchor func with named anchor vs implicit anchor, you get different layout behavior alos 02:59:28 ... just keying off position anchor is for layout puyrposes is not the right switch 02:59:38 iank_: you get different behavior anyway if you use position-anchor 02:59:42 ... very big layout switch anyway 03:00:02 astearns: can we go back to miriam's suggestion of requiring an opt-in for anchor instead of this implicit anchor behavior? 03:00:10 fantasai: position-area span-all is an explicit opt-in 03:00:21 TabAtkins: problem is, abspos behavior today is straight up broken for most anchor related use cases 03:00:33 ... anything that cares about the space breaks in most cases if you use local CB of your scorller 03:00:43 ... taht's why we want to be forgiing in opting into scrollable CB instead 03:00:46 ... explicit opt in a 03:00:55 ... problem when you have other things that opt into anchor pos 03:01:07 miriam: we have lots of things that opt into grid but you still have to set display grid and that' suyseful 03:01:19 astearns: and we're tying ourselves into knots on all possible triggers for anchor pos 03:01:29 q+ 03:01:38 ... do like simplicity of single property that has to be set to something, that gets you into new anchor pos behavior 03:01:56 TabAtkins: very likely can't key all anchor pos off some new opt-in, been shipped in several browsers for quite a while 03:02:11 astearns: just changing implicit anchor behavior to require an opt-in with the property that has that anchor choice built in 03:02:20 ... taking the implicit anchor and making it an explicit choice 03:02:27 fantasai: initial value of position-anchor should be none? 03:02:27 astearns: yes 03:02:32 miriam: that's what I was saying 03:02:44 iank_: would likely be fine with popver if we did that and adde dposition anchor implicit for that 03:02:55 ... popovers are position fixed by default and don't have this behavior 03:02:57 q- 03:02:59 ... probably fine to be honest 03:03:08 TabAtkins: popover is just a matter of one more line in UA stylesheet, should be fine 03:03:19 fantasai: whole point of defining implicit anchor is so you don't ahve to think about that connection 03:03:28 miriam: disagree, you still don't have to know what the name of it is 03:03:37 ... still useful to get automatic anchor even if you explicitly opt in 03:03:46 flackr: yes, that was main reason it's useful 03:03:54 astearns: of the things we've discussed, I think that's the most promising thing 03:04:13 ... I think we should either resolve on auto anchor selection being a value you have to put in property, or take this back to the issue and move on 03:04:16 TabAtkins: good with first option 03:04:21 fantasai: would like to hear from kizu 03:04:26 iank_: I'm okay with it 03:04:29 kizu: 03:04:35 miriam: I agree with kizu 03:04:47 need demos? need to see something… 03:04:51 kizu: I like the idea of making the position-anchor none by default 03:05:05 ... for pseudo elements you opt in by doing this or you could use implicit keyword inside anchor function as well 03:05:10 ... so you don't have to mention as position-anchor 03:05:11 if it's none by default do we need to use the keyword implicit or is it just auto? 03:05:22 TabAtkins: we would add the implicit keyword as one of the things we put in implicit anchor 03:05:30 ... right now if you omit you get popover behavior 03:05:30 thats a good idea. 03:05:45 fantasai: if we change this behavior to not create binding by default, inital value should be none 03:06:09 default-anchor initial value becomes `none`. `auto` selects an implicit anchor. 03:06:10 astearns: proposed resolution is that the default value of position-anchor is `none` but you can use `auto` to opt in to implicit anchor 03:06:27 fantasai: so we add new value, and change initial value 03:06:39 ... and also add to stylesheet for popver 03:06:43 astearns: any concerns? 03:07:04 fantasai: don't love it but can live with it 03:07:11 TabAtkins: this is my proposal with words changed 03:07:20 fantasai: no it's a little diffreent, we don't have synonyms 03:07:27 astearns: objections? 03:07:47 nt1m: if this new value is new default, why do we need to add to stylesheet? 03:07:55 emilio: popover wants old behavior 03:08:12 fantasai: popover would continue to have implicit anchor you could just use, anything else with implicit anchor you need to opt in 03:08:22 ... :before and after which create a binding will no longer do that 03:08:47 nt1m: we'd be breaking all the demos that apply anchor pos on pseudo elements? 03:08:51 emilio: the ones that don't use position-area 03:09:01 fantasai: we didn't resolve that position-area would also be a switch 03:09:03 [crosstalk] 03:09:15 fantasai: demos that currently use before and after ... 03:09:18 Snugug has joined #css 03:09:21 TabAtkins: not safe to do current behavior 03:09:29 iank_: and I don't think we've shipped before and after behavior 03:09:38 astearns: I hear some reservations but no objections 03:09:52 bts has joined #css 03:10:10 RESOLVED: add none value to position-anchor, make it the initial value, change UA stylesheet for popover 03:10:10 present+ 03:10:42 @astearns The meeting had wrapped by the time I got down there and it was unclear from those who were still in the room whether the topic had been presented or what the results were 03:10:54 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12022 03:10:54 Topic: [css-grid-3] Masonry Switch Syntax 03:10:54 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12022. 03:11:08 fantasai: survey had over 300 responses 03:11:12 ... popular ones are listed in issue 03:11:15 dholbert1 has joined #css 03:11:26 ... top choices include grid-stack, packed-grid stuff 03:11:30 ... also grid-lanes or lane-grid 03:11:37 ... if you merge some options together that was among the top 03:11:38 https://github.com/w3c/csswg-drafts/issues/12022#issuecomment-3488350977 03:11:41 Snugug has joined #css 03:11:43 ... ^ link to top options 03:11:50 ... concerns about stack because of confusion with stacking context 03:11:56 ... people thought pack got confused with density 03:12:13 ... looking at results, TabAtkins alisonmaher and I concluded grid-lanes seemed popular and didn't have downsites 03:12:21 ... also works well for creating a shorthand for this purpose 03:12:25 q+ 03:12:30 ... that's currently what we're thinking is best among surveyed options 03:12:30 q+ 03:12:37 ack alisonmaher 03:12:37 alisonmaher: comment on one of those options 03:12:38 as my own personal top vote, I approve :) 03:12:45 ... do others have ideas on final 2? 03:13:15 ... I'm not opposed to grid-lanes, but one downside I see is we have concept of tracks 03:13:23 q+ 03:13:26 ... if we introduce term for lanes, we'd have both that and tracks, could be confusing 03:13:34 fantasai: we don't expose tracks anywhere, just a spec internal term 03:13:37 ack ydaniv 03:13:40 ydaniv: what about just lanes? 03:13:47 astearns; we already resolved to have grid in value nam,e 03:13:55 TabAtkins: otherwise I'd agree 03:13:55 ack ydaniv 03:14:04 ack oriol 03:14:06 oriol: fantasai was saying it would work well with shorthand, can you clarify? 03:14:20 fantasai: Google proposed a sghorthand tailored to masonry that sets only one axis of grid values 03:14:26 ... they were calling that shorthandmasonry 03:14:38 ... can't use that but grid-lanes would still work for that purpose 03:14:57 astearns: am I correct that the quick part of this is poll between grid-lanes vs masonry-grid as the display value? 03:15:00 q+ 03:15:05 grid-lanes: column repeat(3, auto); 03:15:07 scribe+ 03:15:08 ntim has joined #css 03:15:09 ack kbabbitt 03:15:16 kbabbitt: one thing I discovered 03:15:20 present+ 03:15:23 kbabbitt: in terms of what people are referring to this with... 03:15:32 kbabbitt: "masonry" has been in use since 2009 03:15:34 kbabbitt: In terms of referring, name of masonry has been in use since 2009, so this is what authors have been calling it for a long time 03:15:36 dholbert_ has joined #css 03:15:39 kbabbitt: authors have been using the term for a very long time 03:15:51 kbabbitt: Not objecting, but still preference for grid-masonry 03:16:13 POLL: 1. grid-lanes, 2. masonry-grid 03:16:15 1 03:16:18 1 03:16:20 2 03:16:26 2 03:16:27 1 03:16:28 2 03:16:28 1 03:16:29 1 03:16:31 1 03:16:33 2 03:16:34 1 03:16:37 1 03:16:37 1 03:16:40 2 03:16:42 2 03:16:44 1 (but am flexible) 03:16:45 2 03:16:51 no pref 03:17:07 1 03:17:07 1 or 2 03:17:15 1 03:17:31 1 03:17:38 1 03:17:56 astearns: seeing a 3:2 advantage for grid-lanes, not conclusive but better than we've had up till now 03:17:59 yeah, 14 to 8 or so 03:18:04 about a 3:2 03:18:11 astearns: Proposed: masonry switch will be display: grid-lanes 03:18:16 RESOLVED: masonry switch will be display: grid-lanes 03:18:31 topic: none 03:18:36 topic: guest from AB 03:19:00 Brent: I'm here from the AB and I'm here to help! 03:19:58 Brent: Tell us how the Process has been working for you. 03:20:28 hober: OK if what you're saying isn't about the Process as written, but about your experience of it 03:20:41 q? 03:20:46 q+ 03:20:49 hober: We're looking for the vibes. 03:21:08 ChrisL: Thanks for getting rid of Proposed Recommendation 03:21:29 ChrisL: Amendment process making diffs is painful. 03:21:39 q+ 03:21:42 ChrisL: Impetus was great, but implementation was extremely painful 03:21:45 ack ChrisL 03:22:01 ChrisL: Rechartering, why do we need to do it every 2 years? 03:22:31 ChrisL: It's a lot of work to round up the votes to approve a charter 03:22:38 ack fantasai 03:22:39 ChrisL: Can we just take objections 03:22:40 ack florian 03:22:49 florian: Defer to others. 03:22:56 ... +1 to comment on chartering 03:23:05 ... #2, I would like to see significantly more tooling 03:23:13 ... Many things the Process calls for that indeed should happen 03:23:16 q+ 03:23:25 ... Enables W3C to fulfill its promises 03:23:29 ... But we are undertooled for it. 03:23:51 ... As a spec editor, should be able to just push a button that walks you through figuring out all the things 03:23:59 ... and don't have to spend half an hour reading documentation 03:24:08 ... the problem isn't what we have to do, but doing things manually and unassisted 03:24:17 ... want enough tooling that you don't have to read the process 03:24:28 ... but click your way through doing the right things 03:24:50 astearns: Personally, from my perspective, things are just fine 03:25:00 ... I just can't keep the Process in mind, and rely entirely on ChrisL :) 03:25:10 ... If he says it's a problem, +1 from me 03:25:25 ack astearns 03:25:28 hober: You're not the first chair to say this about their Team Contact 03:25:47 florian: Yes, the "Team Contact" is how we "automate" this, and there are more gratifying things to do than being a human publishing bot 03:26:27 astearns: Any others who tried to understand Process and bounced off like me? Or run into intractable issues? 03:26:39 miriam: +1 to Florian, publishing I get tripped up on command line all the time 03:27:03 Brent: If anyone has spicy takes, reach out to any of us directly. 03:27:11 Brent: Or join us in the Process CG 03:27:34 Brent: There's also a monthly AB-led Member Meeting, you are all invited to that 03:27:53 Brent: Welcome to come and comment on things 03:28:05 Brent: Would like this to be a feedback loop, not just a one-time thing. 03:28:07 canalun has joined #css 03:28:44 Florian: Also, for chartering, timelines for specs might be useful in some groups, in ours it's busywork fiction. 03:29:13 astearns: +1 two-year rechartering and timelines are really dumb for us. Though maybe that's just us, so might not need to change. 03:29:50 Florian: Might not be a requirement, but practice of predicting when our 100+ specs go to REC is silly 03:30:03 hober: Charters have different audiences, and sometimes those audiences need or want different things from them 03:30:23 hober: I might want some things, and lawyers might want some different things. 03:30:31 hober: But point taken about made-up random-number schedules 03:30:54 I have made the request to generate https://www.w3.org/2025/11/12-css-minutes.html fantasai 03:31:03 Topic: Lunch 03:31:16 returning 13:45 JST 03:38:16 nigel has joined #css 03:38:39 nigel has joined #css 03:55:09 nigel has joined #css 04:40:07 alisonmaher has joined #css 04:41:44 kbabbitt has joined #css 04:42:06 kbabbitt has joined #css 04:43:06 bts has joined #css 04:47:54 we will start again as soon as we can, waiting on stragglers 04:49:00 jamesn has joined #css 04:49:55 GameMaker has joined #css 04:50:06 I'm dropping - have fun! 04:50:31 nigel has joined #css 04:50:39 berlysia has joined #css 04:52:27 Patrick_H_Lauke has joined #css 04:54:43 Topic: MDN update from Estelle 04:55:08 saku has joined #css 04:55:21 duerst has joined #css 04:55:33 Estelle: [intro] 04:55:45 Estelle: over past 2 1/2 years i've been working on a new project, completed but not yet announced 04:55:54 Estelle: wanted to talk about it with you 04:55:59 Estelle: scroll-driven animations as an example 04:56:08 Estelle: i'm trying to document each CSS spec as its own landing page 04:56:22 Estelle: 100-ish specs here in the sidebar 04:56:28 Estelle: each spec has its own landing page. versions are combined 04:56:35 GameMaker has joined #css 04:56:40 Estelle: has a brief overview. simple example. 04:56:49 Estelle: not an educational piece tho; a linking piece 04:57:01 Estelle: I noticed CSS specs often had interfaces but they were somewhat hidden 04:57:14 Estelle: so this contains properties/types/functions/etc defined in the spec 04:57:17 Estelle: also a glossary 04:57:23 nigel has joined #css 04:57:26 Estelle: and a guide for some topics 04:57:45 Estelle: "related concepts" for things that are highly linked. can't do scroll-driven animations without animations, keyframes, overflow, we animations api 04:57:46 q+ to ask about explainers and how to communicate the rejiggering we do 04:57:54 Estelle: link to spec, and a "see also" 04:58:04 Estelle: another example, borders and box deco 04:58:10 Estelle: again, brief intro, and example 04:58:17 adamargyle has joined #css 04:58:22 Estelle: all defined props 04:58:33 Estelle: nowhere in MDN do we document things that dont' exist yet. except for here! 04:58:43 Estelle: if there's a new feature, easy to hear about it but not find it 04:58:52 Adam_Page has joined #css 04:58:55 Estelle: we can list it here and note that it's not yet supported 04:59:12 Estelle: that way people can go to MDN and find something not supported 04:59:29 Estelle: pointing out again, the IDL interfaces too 04:59:34 Estelle: just wanted to intro this 04:59:44 q+ 04:59:54 Estelle: I've got a list of things that aren't implemented yet, need more check over since i've been doing this for two years 05:00:06 Estelle: if anyone wants to help create a guide or example, let me know, these pages are all auto-generated 05:00:19 astearns: about explainers. we're trying to be more consistent with having those. 05:00:30 Estelle: I didn't know explainers existed until recently. def would have been helpful 05:00:41 Estelle: we're talking with docs people to help with explainers too 05:00:59 astearns: we also often move stuff around, break properties into a new module or relocate something 05:01:04 astearns: we don't do a great job to communicate that 05:01:15 astearns: should we have some sort of official channel with you? 05:01:32 Estelle: would be helpful if someone communicated that. or a quick PR just to move something. 05:01:49 Estelle: It won't change the BCD so I won't be auto-alerted. 05:02:11 Estelle: in BCD we list all the specs, every property, and list what module it's in. that's auto-genned. 05:02:35 felipeerias has joined #css 05:02:37 scribe+ 05:02:49 TabAtkins: We might resolve one later this afternoon, so that'll be a test case 05:02:59 astearns: the MDN page for a prop links to the spec it's from. will there also be a link to this documentation? 05:03:28 Estelle: on each ref page there's a link to the spec, i'll try to add these too. these aren't reference or educational, just guides to help keep things interconnected 05:03:42 ack astearns 05:03:42 astearns, you wanted to ask about explainers and how to communicate the rejiggering we do 05:03:43 astearns: yeah I could see jumping to the See Also in this guide being easier than scanning the spec 05:03:46 florian: first, looks great 05:03:47 ack florian 05:03:59 florian: you asked for ping when things changed. i'm a user of MDN, never contributed 05:04:28 ydaniv has joined #css 05:04:38 florian: suspect it's fine if I tried to be a contributor, but I ahvne't done it. as a spec editor, would be nice to have a paragraph in our wiki saying "do X to update MDN". better than trying to figure out what to do on my own. 05:04:56 florian: So I'd like just some simple documentation on what exactly to do. suspect it's easy, just don't know what to do yet 05:05:02 q+ 05:05:10 florian: also more generally, what should we know to avoid making your life hard, and what can we do to make it easier? 05:05:56 Estelle: to make life easier, ensure each page is only one spec. like color HDR doesn't belong in the Color page, except in See Also 05:06:00 ack fantasai 05:06:00 fantasai, you wanted to suggest explainers be incorporated into specs wher epossible 05:06:01 present+ 05:06:10 fantasai: re explainers, I think the content should largely be in the module itself 05:06:13 birtles has joined #css 05:06:17 astearns: separate discussion 05:06:25 fantasai: when impractical we should probably publish as a Note 05:06:40 karlcow has joined #css 05:06:52 fantasai: other q, Bikeshed generates an automatic index of properties. are we publishing that to TR? If not, could we? that might help Estelle with auditing. 05:07:09 astearns: sounds good to me 05:07:25 florian: and publishing gives you dated versions so you can diff 05:07:30 TabAtkins: yeah easy 05:07:40 Estelle: florian, where do you want that documentation? 05:07:45 florian: in our wiki is fine. 05:07:47 zakim, close queue 05:07:48 ok, astearns, the speaker queue is closed 05:08:29 Vadim: clarify explainers. I know we plan to do more explainers, goals and non-goals, things like that. short summary. Is that what you meant? 05:08:34 astearns: yes to all. very ill-defined. 05:08:48 q? 05:08:49 Vadim: on MDN we try not to document anything that's not in browsers, not directly practical to devs. 05:08:50 q+ 05:08:52 q- 05:08:52 Adam_Page has joined #css 05:08:56 q+ to comment on explainers 05:09:10 Vadim: devs go to MDN and see stuff and want to use it. So want to make sure explainers are about impls not just ideas. 05:09:25 astearns: we're in process of collecting more explainers that we know exist, they might get integrated into specs or wahtever 05:09:38 astearns: motivating use-cases, why it exists... 05:09:43 Vadim: Yeah that would b euseful 05:09:51 ack plinss 05:10:00 Snugug has joined #css 05:10:25 plinss: it wouldn't be difficult to cron and generate Bikeshed indexes on a daily basis, or just get the data direct from the source. we can automate, better than waiting for someone to tell you. 05:10:45 astearns: Thank you for this summary! 05:10:56 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12602 05:10:57 Topic: [css-gaps-1] Gap decorations next to empty grid areas 05:10:57 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12602. 05:11:07 zakim, open queue 05:11:07 ok, astearns, the speaker queue is open 05:11:44 kbabbitt: in August at f2f we talked a bit about this 05:11:53 kbabbitt: there are use-cases for not wanting decorations on all cells in grid 05:12:06 kbabbitt: [example] an unfilled grid area, don't want the deco crossing it 05:12:25 kbabbitt: [another example] don't want a deco between a filled area and an unfilled 05:12:40 kbabbitt: [another example] multicols, don't want lines between the empty columns at the end 05:12:52 kbabbitt: Elika suggested rule-visiblitity-items and rule-visiblity-self, I went with that 05:13:01 kbabbitt: working thru use-cases, realized just *-items is sufficient 05:13:25 kbabbitt: rv-items sets default over whole container for whether there's a deco in a gap between items when one or both sides is empty 05:13:44 kbabbitt: 'all' draws all decos. 'around' draws around items (between a filled and unfilled) 05:14:10 kbabbitt: 'between' only draws them between two filled (skips filled+unfilled) 05:14:20 kbabbitt: rv-self would let you set exceptions for specific items 05:14:33 kbabbitt: talking to Sam Davis, in our impl rv-self has some additional complexity 05:14:58 alisonmaher: currently gap-decos are set up on the container itself. we just track the segments and don't care about children. 05:15:11 alisonmaher: but if rv-self changed we'd have to rerun layout on the whole container to make it work 05:15:34 kbabbitt: so all the use-cases we have are satisfied with rv-items, either "around" or "between" 05:15:46 kbabbitt: [goes over the examples] 05:15:48 q+ to ask about the first use case 05:16:11 kbabbitt: so my proposal for v1 is to just do rv-items: all | around | between; 05:16:19 Penny has joined #css 05:16:22 kbabbitt: if we get feedback that we need it, we can add "none", and rv-items, if needed 05:16:28 astearns: I think it's fine to start simple and add complexity later 05:16:36 astearns: back in first use-case, you said this is solved with "around" 05:16:51 astearns: in this case, does author want deco to be entire width, or just over the right 2/3? 05:17:18 ack astearns 05:17:18 astearns, you wanted to ask about the first use case 05:17:18 kbabbitt: that's a border actually 05:17:21 ack fantasai 05:17:29 fantasai: this sounds good, looks like we have a path forward if we need it 05:17:46 fantasai: ftr should say "hidden" rather than "none", "hidden" suppresses in other contexts 05:18:14 kbabbitt: so proposed resolution is to introduce just rv-items, with "all | around | between" values 05:18:49 Proposed: Introduce column-rule-visibility-items: [ all | around | between ] and row-rule-visibility-items with same syntax, plus shorthand rule-visibility-items for both directions 05:19:02 +1 05:19:12 excited to use this! 05:19:12 astearns: objections? 05:19:31 RESOLVED: Add 'rule-visibility-items: all | around | between' (plus longhands) 05:19:42 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11814 05:19:42 Topic: [css-gaps] Gap decorations with collapsed gutters 05:19:42 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11814. 05:20:25 kbabbitt: in Grid, when you have repeat(auto-fit, ...), it generates as many tracks as necessary to fill the space, and then will collapse the unneeded tracks if there's few items 05:20:54 kbabbitt: the way Grid is defined, those gaps still exist, they're just between 0-width tracks and overlap 05:21:07 kbabbitt: we previously resolved to suppress all but one. went with table border-collapse rules to choose 05:21:17 kbabbitt: based on comments iv'e gotten since, think that's wrong choice algo 05:21:29 kbabbitt: the scenarios for picking the styles are different from in tables 05:21:55 q+ 05:21:57 kbabbitt: gap-repeat has a repeat() syntax too, and it would be less confusing to just still use that pattern. 05:22:16 kbabbitt: so I'd like to propose we undo the previous resolution and just assign decors to gaps as if the collapsed tracks don't exist 05:22:24 alisonmaher: i support this change, want to give an example 05:22:51 alisonmaher: if you're using gaps to switch between colors, like `repeat(black, gray)`, if you use table rules you could end up with adjacent gap decos with the same color, rather than laternating 05:23:03 alisonmaher: I think authors would find that confusing and would prefer to see the repetition pattern maintained 05:23:07 +1 05:23:08 ack alisonmaher 05:23:12 ack fantasai 05:23:17 fantasai: for cases where we're getting this from repeated tracks this is fine 05:23:33 fantasai: we've discussed collapsing empty tracks in other situations. not sure this approach would work for those cases. 05:23:41 fantasai: but for the existing collapse cases, it's fine 05:24:17 astearns: so you're fine with undoing previous resolution? and figuring out future stuff in the future? 05:24:19 fantasai: yes 05:24:40 astearns: objections? 05:24:47 berlysia has joined #css 05:24:58 Ragvesh has joined #css 05:25:07 RESOLVED: Undo previous resolution. Apply gap-decos *after* collapse (assuming collapsed tracks come from auto-fit, which is currently the only way to do it) 05:25:47 github-bot: take up https://github.com/w3c/csswg-drafts/issues/12899 05:25:47 Topic: [css-grid-3][Masonry] Intrinsic auto repeats mixed with fixed tracks 05:25:47 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12899. 05:26:16 TabAtkins: currently masonry has the ability to do repeat auto-fill with intrinsic tracks in the repeat list 05:26:28 ... you can do it in masonry because we have a heuristic 05:26:32 ... which works great for span 1 05:26:47 ... the spec has some more details but that's the tldr 05:26:53 ... to deal with larger span is not so easy 05:26:59 ... the current way the spec defines it 05:27:12 ... you chop it as if it was made of single-span items 05:27:29 ... so if you have 300px span: 2 you pretend you have two 150px single-span items 05:27:37 ... for some repeats like 100px auto auto 05:27:47 ... it doesn't work that well 05:28:03 ... if this was grid this would work well 05:28:22 ... but with the heuristics it'd make them 150px wide which means that if you 300px is in the first half you get overflow 05:28:34 ... without anything to do about it 05:28:39 ... some suggestions in the issue 05:29:00 ... I think there's a reasonable opinion, if anyone has different ideas welcome 05:29:04 ... preferred option is 05:29:15 ... instead of expanding the repeat once, chop large spans and split 05:29:38 ... we should repeat the tracks as many times as needed to capture all possible ways a spanner could end up 05:29:45 ... then rather than chopping up we group them by span 05:29:52 ... and do the hypothetical calculation 05:30:23 ... then we pretend all span 1 items live in every position and the 2 span items as well, etc 05:30:29 ... with some fixes for perf not to be terrible 05:30:33 q+ 05:30:42 ... and then take whatever comes out of that 05:31:07 ... in the example, it'd result both columns being 200px wide which means regardless of how many times 05:31:22 q+ 05:31:24 ... there's no perfect solution but guarantees no overflow, and quite often you'd get a perfect fit 05:31:42 ... extending the span 1 heuristic to work on span 2 and so on 05:31:49 florian: makes sense but trying to confirm 05:31:50 ack florian 05:32:25 ... if I understand right it has an additional benefit, which is we place actual spanners, the sizing phase would take into account that you could span through gaps 05:32:40 TabAtkins: wasn't super relevant but the chopping already deals with that (subtract the gaps) 05:32:48 florian: ok, seems like a good idea 05:32:56 ack alisonmaher 05:33:27 alisonmaher: I'm supportive, I think it's the best of all the options we could through that. Wanted to mention that that the intrinsic sizes would be different between the columns 05:33:31 ... so you want to take the max 05:34:00 TabAtkins: replied on the thread, you'd need to do two reps so both of the autos have 200px 05:34:18 alisonmaher: If you had 100px auto auto auto you'd still get a 150px in the middle 05:34:28 ... so we still need the max 05:34:31 TabAtkins: I don't think why 05:34:41 alisonmaher: you need this for auto repeat to do the division 05:34:49 TabAtkins: As long as you have a value I don't think so 05:35:30 q? 05:35:31 PROPOSED: Instead of chopping up spanning items, do enough repeats to cover all posibilities and the create hypothetical items for all spans, and do the same process as span-1 items do 05:35:44 q+ 05:36:09 emilio: This smells like potentially quadratic... maybe fine since it's quadratic on number of items in repeat 05:36:18 emilio: how easy is it to end up with a bad layout? 05:36:32 TabAtkins: not quadratic it scales with the number of spans 05:36:40 ... so you scale up with the max scale of the span 05:36:45 Siyaman has joined #css 05:36:47 ... but more of a question of how many distinct spans you have 05:37:04 ... worst would be 1000 items with 1000 different span values 05:37:09 ... but that's very bizarre 05:37:31 ... so I think you could bail out, I don't think it can happen for reasonable markup 05:38:04 emilio: might be worth to put a lower bound on the spec or something? 05:38:57 PROPOSED: Instead of chopping up spanning items, do enough repeats to cover all posibilities and the create hypothetical items for all spans, and do the same process as span-1 items do, with a reasonable lower bound on the spec for how much needs to be supported 05:39:17 florian: would be good for the bound to not be artificially low 05:39:25 RESOLVED: Instead of chopping up spanning items, do enough repeats to cover all posibilities and the create hypothetical items for all spans, and do the same process as span-1 items do, with a reasonable lower bound on the spec for how much needs to be supported 05:39:35 TabAtkins: yeah will take impl feedback into account 05:39:58 github-bot: take up https://github.com/w3c/csswg-drafts/issues/12918 05:39:58 Topic: [css-grid-3][masonry] impact of negative margins on running positions within a track, dense-packing, and alignment 05:39:58 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12918. 05:40:34 GameMaker has joined #css 05:40:34 TabAtkins: q about impact of negative margins on a running position when doing dense packing 05:40:39 ... and alignment 05:40:43 ... some great examples in the spec 05:40:57 ... about item1 gets placed, item2 gets pulled up by the negative margin 05:41:14 ... conclusion was that yes negative margins effectively shrink the size of the item, so they would affect 05:41:27 ... then the question is if this has an effect on dense-packing gaps 05:41:37 https://private-user-images.githubusercontent.com/147667317/499050454-e73953de-23f2-4b74-9601-f1403465b75f.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjMwMTI2MTUsIm5iZiI6MTc2MzAxMjMxNSwicGF0aCI6Ii8xNDc2NjczMTcvNDk5MDUwNDU0LWU3Mzk1M2RlLTIzZjItNGI3NC05NjAxLWYxNDAzNDY1Yjc1Zi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD 05:41:37 1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMTEzJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTExM1QwNTM4MzVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1iYzIwZWZhMTYzYzk1ODYzMDhhNGJlZTFmY2E1OWQyYWMyZDg0YzZhYWM1MmYxNjNiMjZlZjY1NDQ5MGQ1YjU4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.JVa21nv8RU_Od6DZ2OogFxQA699X50EDnve8qy44bsA 05:41:48 https://github.com/w3c/csswg-drafts/issues/12918#issue-3496598507 05:42:08 ... if you scroll at the bottom of ^, final image shows a masonry with a couple gaps 05:42:17 ... new items on the lower gap, but also has a negative margin that pulls it up past the spanner 05:42:24 ... should this reduce the size of the gap in any way 05:42:24 Adam_Page has joined #css 05:42:33 ... we (me and elika) thinks it shouldn't 05:42:41 ... geometrically it lives in the second gap, it's just small 05:42:55 q? 05:42:58 ack emilio 05:42:59 q+ 05:43:00 ... so if you use enormous negative margins you deserve what you get 05:43:01 q+ 05:43:06 ack oriol 05:43:06 ... does it sound reasonable to anybody 05:43:21 oriol: have a question. in masonry we keep placing items to the track is less filled 05:44:03 ... but if the item we're placing has negative margins so that it ends up negative sized, should it be put in the most-filled track? 05:44:24 TabAtkins: for the purposes of running position we should treat the item as zero-sized, if it's negative it wouldn't adjust the running position 05:44:32 oriol: didn't you say the opposite 05:44:48 ... that neg margin would shrink 05:44:59 q? 05:45:05 emilio: What Tab is sayaing is that if the item is 30px 05:45:08 ... [missed] 05:45:10 qq+ fantasai 05:45:19 Tab's proposal makes sense to me, FWIW. 05:45:20 emilio: But if negative margin -1000px, you cap the outer size at zero 05:45:30 oriol: So author sizes are never negative, then it's fine to replace 05:45:50 TabAtkins: I also have a proposal to fix flexbox to prevent flex main sizes from going negative for similar reasons 05:45:57 Penny has joined #css 05:46:40 fantasai: tab's proposal, if you place an item with negative margin so negative that would move the position up you would not adjust the position 05:47:03 ... next item would be placed at the running position, not below the last item 05:47:05 q+ 05:47:10 q+ 05:47:12 ack florian 05:47:27 florian: makes sense to me, not new that negative margins cause overlapping position, maybe they want it 05:47:33 ack alisonmaher 05:47:33 ... so agree with the proposal 05:47:41 alisonmaher: wanted to clarify 05:48:07 ... if you have a running position of 100px, and the negative margin would put it at 80 you put the max 05:48:23 TabAtkins: effectively 05:48:27 ack plinss 05:48:28 alisonmaher: that's different than flexbox and block right? 05:48:36 TabAtkins: yeah but I plan to fix flexbox 05:48:55 plinss: for consistency, if you give it a positive margin that does increase the size 05:49:19 ... so we're making negatives inconsistent right? 05:49:35 TabAtkins: we're not, we are special-casing negative sizes, not margin 05:49:57 fantasai: the running position can only move down 05:50:06 [going through example] 05:50:11 JRJurman3 has joined #css 05:50:34 plinss: ok, I'm good with that 05:51:45 PROPOSED: Negative margins do affect the size of the box for the purpose of dense packing. Negative margins don't interact with any previous gap. Running position only goes down, so if your margin would turn your size negative we treat it as zero for the purpose of running position 05:51:50 +1 05:51:57 RESOLVED: Negative margins do affect the size of the box for the purpose of dense packing. Negative margins don't interact with any previous gap. Running position only goes down, so if your margin would turn your size negative we treat it as zero for the purpose of running position 05:52:22 github-bot: take up https://github.com/w3c/csswg-drafts/issues/12843 05:52:22 Topic: [css-grid-3][masonry] item overflow in a row masonry 05:52:22 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12843. 05:53:18 alisonmaher: if you size the container to min-content in row masonry, we'd run layout for each of the items with the min-content size. When items are actually laid out, they use fit-content, so they end up with two items overflowing the container 05:53:27 ... doesn't happen in grid because tracks constrain the items 05:53:47 ... so fantasai proposed that masonry min-content and max-content size would be the same 05:54:11 ... seems reasonable to me. Only tricky is orthogonal items, 05:54:46 ... the max-content from the perspective of the container is smaller than the min-content 05:54:52 q+ 05:55:01 ... proposal would be that orthogonal items would be min-content size rather than max-content 05:55:09 ... so that we get the max width to avoid overflow 05:55:13 ack oriol 05:55:22 oriol: I'm not following the orthogonal item bit 05:55:29 ... why do you say that min-content > max-content 05:55:41 alisonmaher: I have an example but it's pretty large 05:55:57 astearns: maybe we can resolve on the non-orthogonal behavior? 05:56:08 PROPOSAL: Have the min-content size of the stacking axis of a masonry container be the same as its max-content size (same as the "stacking axis" of block layout). 05:56:46 RESOLVED: Have the min-content size of the stacking axis of a masonry container be the same as its max-content size (same as the "stacking axis" of block layout). 05:56:53 ACTION: Open an issue for orthogonal items 05:57:13 github-bot: take up https://github.com/w3c/csswg-drafts/issues/12573 05:57:13 Topic: [css-grid-3][Masonry] repeat(auto-fill) and minmax() 05:57:13 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12573. 05:57:19 scribe+ 05:58:06 alisonmaher: In the grid spec: 05:58:07 Accoriding to css-grid-2, "For this purpose, each track is treated as its max track sizing function if that is definite or else its min track sizing function if that is definite. If both are definite, floor the max track sizing function by the min track sizing function. If neither are definite, the number of repetitions is one." 05:58:59 The previous resolution: we decided to allow intrinsic auto-repeats in masonry which means that we'll likely want to consider this 05:59:25 s/consider/reconsider 06:00:08 q+ 06:00:18 repeat(auto-fill, auto) is the same as repeat(auto-fill, minmax(auto, auto) 06:00:30 ack fantasai 06:01:00 fantasai: in grid, we don't have the ability to have 2 intrinsic sizes in the min and max 06:01:07 in an auto-repeat 06:01:20 you must have either a min or a max definite size 06:01:53 Penny has joined #css 06:02:06 For the sizes valid in level 2 , we should keep the same grid behavior for masonry in level 3 06:02:28 The case where both are intrinsic is new, and we can do whatever we want 06:02:49 so when we have 2 definite sizes, we get the maximum, makes sense to do the same for intrinsic 06:03:09 We can add a keyword in the future if we want to use the min 06:03:11 GameMaker has joined #css 06:03:25 ack TabAtkins 06:04:15 TabAtkins: I don't like what Elika said, because masonry can assign heuristic values to its intrinsic keywords, we can treat them the same as the fixed sizes regardless of the position 06:04:41 we also shouldn't treat the sizes differently in a mixed intrinsic case vs a double case 06:05:06 when we last discussed, a couple of people agreed, but not fantasai, wanted to wait for miriam's opinion. 06:05:16 it's 3 months later, we should resolve 06:05:49 GameMaker has joined #css 06:05:58 fantasai: The treatment we're deciding on here is not the actual size of the track, this is just an estimate we're using for how many tracks we have 06:06:23 ...once we have the number of tracks, then we will fully resolve the tracks including intrinsic sizes 06:06:53 ...I feel very strongly that for a given track listing, if I do that in grid / grid-lanes, I should get the same number of tracks, for the same set of sizes 06:07:03 TabAtkins: same discussion from August 06:07:28 miriam: it would be good to see demos, intrinsic sizing is sketchy for this 06:07:48 fantasai: there's 2 questions: what to do for existing syntax? what do we do for the new one for double intrinsic? 06:07:55 I don't mind for double 06:07:57 ??? 06:08:16 duerst has joined #css 06:08:26 miriam: in theory i agree, but in practice I haven't seen demos 06:08:35 i don't know why we would choose one over the other 06:08:56 q+ 06:08:58 TabAtkins: fantasai is making an argument for consistency, but i'm also doing the same on the other axis 06:09:09 Elika wants "Grid and Masonry act identically for the syntaxes that are actually valid in both". I want "Masonry always acts the same for intrinsic keywords, regardless of how you use them". 06:09:22 alisonmaher: last time we talked about this, we did a whiteboard, and visuals are really helpful here 06:09:36 That is, `repeat(auto-fill, auto)` works in Masonry (finds a heuristic size, uses that to determine repeats). 06:09:56 q- 06:09:58 miriam: if the argument for consistency is that auto means minmax(auto, auto), then it's more obscure 06:10:01 ack fantasai 06:10:01 fantasai, you wanted to clarify sizing vs counting 06:10:09 JRJurman has joined #css 06:10:27 TabAtkins: that's not the whole reason, is that repeat(auto-fill, auto) has a meaning in masonry, but not in grid 06:10:48 but repeat(auto, auto) has a meaning in masonry that we agree on and is invalid in grid 06:11:02 Table from the August F2F: https://usercontent.irccloud-cdn.com/file/DqXUz9TL/IMG_2299.png 06:11:24 I think it's weird if minmax(0px, auto) acts differently from either of these two, because suddenly it's 0px which is what it is in grid 06:11:28 "which is what it is in grid" as it should be! 06:11:49 miriam: just in terms of determining repeats, not sizes 06:11:59 ack fantasai 06:12:39 fantasai: Tab just said repeat(auto, auto) is invalid in grid, but we're going to make it syntactically useful in grid, and we should give it an useful meaning. If there's no compat concern we should give it a meaning that is consistent across both grid & masonry 06:13:18 topic: break 06:15:08 berlysia has left #css 06:21:56 nigel has joined #css 06:22:30 nigel has joined #css 06:23:27 nigel has joined #css 06:23:48 nigel has joined #css 06:25:55 adamargyle has joined #css 06:26:26 kbabbitt has joined #css 06:30:36 Snugug has joined #css 06:33:56 .masonry { grid-template-columsn: repeat(auto-fill, auto) ; } .item { min-width: calc-size(max(100px, min-content)); } 06:37:40 scribenick: fantasai 06:37:43 Topic: backgrounds and borders l4 06:37:55 Subtopic: FPWD L4 06:37:59 https://github.com/w3c/csswg-drafts/issues/13062 06:38:03 adamargyle has joined #css 06:38:08 topic: https://github.com/w3c/csswg-drafts/issues/13062 06:38:12 github: https://github.com/w3c/csswg-drafts/issues/13062 06:38:32 RESOLVED: FPWD css-backgrounds-4 06:38:46 berlysia has joined #css 06:38:50 Subtopic: [css-backgrounds] allow optional forward slash in `border-*-radius` long hands 06:39:26 fantasai: someone outside the WG wanted to propose we allow / separating the x and y values of border-radius, also in the longhands 06:39:39 fantasai: right now borde-rradius takes 1-4 values, a slash, then 1-4 values. x/y 06:39:48 fantasai: but in the longhands it's just two values, space-separated 06:39:55 q+ 06:39:59 fantasai: they thought it was confusing, wanted to put / in the longhands as well 06:40:16 oriol: This would have been good from the beginning, but now that we're using spaces, but at this point 06:40:38 oriol: It might add confusion, if an author sees the two options, wouldn't be obvious that they mean the same thing 06:40:44 q+ 06:40:45 q+ 06:40:48 oriol: I'm not strongly opposed, but lean against 06:40:52 ack oriol 06:40:54 ack lea 06:41:12 lea: Seems reasonable to me. I could argue that we should have done it originally, it is weird to be different. 06:41:19 lea: I'm in favor of this change. 06:41:26 ack kbabbitt 06:41:36 kbabbitt: I empathize with the author 06:41:50 kbabbitt: but there are other places where we do this, concerned about lack of ocnsistency 06:41:59 ack fantasai 06:42:15 fantasai: in colors we introduced an alternate punctuation 06:42:21 Penny has joined #css 06:42:31 rssagent, draft minutes 06:42:35 fantasai: it's not common to set x/y radius independently in the longhands. it happens, but you're usually using the shorthand, or setting both to same value 06:42:59 fantasai: wrt other places where we use slash, mostly it's places where wer'e combining two longhands and need the / to separate two numbers 06:43:29 fantasai: don't think we have any other example of where a / is used in the shorthand to separate two values, but those same two values in the longhand aren't slash-separated 06:43:47 fantasai: like in background-position, the / separates sizing from offsets. but in the longhands they're separate things 06:43:57 fantasai: so I think the consistency argument here is an overall win for authors. 06:44:12 astearns: Slight concern that we can resolve to make this change but never gets implemented. 06:44:22 astearns: doesn't seem high priority for anyone 06:44:33 astearns: but I'm hearing some slightly more sentiment towards making the change than opposition 06:44:42 astearns: Shall we resolve to change the spec? 06:45:02 oriol: To clarify, we alias at parse time? 06:45:13 astearns: And continue return without slash for comat 06:45:20 fantasai: yes 06:45:28 PROPOSED: Allow forward slash in these properties. 06:45:36 RESOLVED: Allow forward slash in these properties. 06:45:58 Subtopic: [css-backgrounds] `background-clip: content-box` with scrollbar 06:46:26 oriol: If you set background-clip padding-box, it includes the scrollbar gutters 06:46:36 oriol: but spec is unclear about the content-box 06:46:46 oriol: but browser do content-box + scrollbar gutter 06:46:53 oriol: seems weird though 06:47:10 oriol: I would propose to keep spec and browsers are wrong 06:47:23 adamargyle has joined #css 06:47:37 astearns: Opinions from implementers? 06:47:48 emilio: I agree with oriol 06:48:09 Agree, as drive-by webdev opinion. 06:48:52 astearns: so propose to keep spec and add WPT tests 06:49:27 fantasai: overlay scrollbars? 06:49:37 TabAtkins: they have no gutter 06:50:07 PROPOSED: Keep spec. Add tests. 06:50:16 oriol: This is only observable with classical scrollbars 06:50:27 emilio: Tests should be valid in both 06:50:40 ntim: WPT is forcing classic scrollbars already 06:50:52 ntim: We should see if implementers have any objections afterwards 06:50:54 astearns: certainly 06:51:27 RESOLVED: Keep spec. Add tests. Revisit if implementers notice a problem. 06:52:03 Subtopic: [css-backgrounds-4] Computed Value serialization of background-position and its longhands 06:52:34 oriol: Here there's a disagreement in the spec about computed value of background-position 06:52:44 oriol: Shorthand says computed value is length-percentage per axis 06:52:54 (did we skip https://github.com/w3c/csswg-drafts/issues/9083 ??) 06:52:56 oriol: but longhands it includes also a keyword representing the origin 06:53:07 oriol: We need to decide if the computed value keeps this keyword or not 06:53:14 oriol: One way to observe this is with logical keywords 06:53:25 oriol: e.g. background-position-x: x-end 25% 06:53:36 My position on any question of how 'inherit' works for non-inherited properties: that's weird, don't do that. 06:53:45 oriol: If a child inherits this value, does it inherit the x-end 25% as a logical thing, or does it resolve to 75% and then child inherits 75%? 06:54:01 oriol: It's so far only implemented in WebKit, and it resolves the percentage 06:54:01 +1 to WebKit behavior here, I think 06:54:08 oriol: However I propose to keep the keyword. 06:54:22 (as a knee-jerk response, at least) 06:54:33 oriol: It's not absolutely necessary, but it will help with the logical longhands because we want to keep different meanings depending on whether you use a physical longhand or logical longhand 06:54:54 oriol: So that would be the first part, and the rest would depend on whether we resolve on this or not 06:55:30 fantasai: I feel like we need to figure out he resolution of the shorthand/longhands 06:55:43 fantasai: is it possible to... computing it thru is simpler, it gives you a more calculated answer 06:55:58 fantasai: I don't care about inheritance, no reasonable person does "background: inherit", especially thru direction change 06:56:10 fantasai: but if we need it for shorthand/longhand, it's reasonable to keep the keywords around 06:56:28 fantasai: but if we don't need it, I think it's preferable to compute the keyword away 06:56:48 oriol: I think it would be good for the logical longhands, but other way to do it could be an internal flag 06:57:03 oriol: but if we have a keyword, then we already know if it's logical or physical 06:57:30 fantasai: hmm, ok, then in that case let's keep it 06:57:52 oriol: So how do we serialize the resolved value? We're compat constrained to not include it in the existing syntax 06:58:33 fantasai: we would need to drop the keyword for physical ones 06:58:35 present+ 06:59:04 oriol: I checked for gCS on `right 50%` 06:59:31 oriol: WebKit was (at least until recently) including the keyword 07:00:13 fantasai: might be ok to keep keyword in both cases 07:00:18 q+ 07:00:24 fantasai: but we do currently hvae interop on resolving to percentage 07:00:25 q- 07:00:41 oriol: When WebKit added the new keywords they resolve it to percentage 07:00:49 q+ 07:01:04 oriol: We could go for ocnsistency and never include keywords 07:01:12 oriol: Or we could include them for logical, or include them always 07:01:29 ack ntim 07:01:33 ntim: Was it background-size or background-position that had a special rule for omitting one of the two axises? 07:01:49 ntim: there was a difference in prefixed vs unprefixed behavior 07:02:45 it was background-size!! https://github.com/w3c/csswg-drafts/issues/7802 07:03:11 SeeAlso https://github.com/w3c/csswg-drafts/issues/7802 [css-backgrounds] Always serialize 'background-size' and mask-size as two values 07:03:45 nigel has joined #css 07:04:08 fantasai: Maybe we should figure out the logical property cascade and then figure this one 07:04:19 ntim: wpt is consistent, what's the issue? 07:04:24 oriol: The spec contradicts itself 07:04:28 oriol: and we need to decide how to fix it 07:04:39 ntim: If we already have interoperable implementations, that would drive compat 07:04:59 oriol: Also there are new keywords 07:05:07 oriol: Some behaviors are only observable with these 07:06:21 Subtopic: [css-borders] allow multiple borders 07:06:44 lea: Years ago we got a use case from APA around having both white and black borders 07:06:51 lea: to make sure border was visible regardless of colors 07:07:02 lea: We introduced 1-dimensional images and stripes() function 07:07:11 lea: Which in hindsight I think was overengineered 07:07:22 nigel has joined #css 07:07:28 lea: We expanded border-color to accept stripes() and it would curve around the border 07:07:47 lea: So initial motivation was that listifying border-color created some weird issues 07:08:14 lea: because specify border-width: 2px; you could end up with 6px border because it's multiple colors 07:08:32 lea: If we naively listify border colors, you have to specify colors in a weird order that's confusing 07:08:39 lea: These are problems 07:08:47 https://x.com/LeaVerou/status/1985123158370680869 07:08:49 lea: When this issue was opened, I revisited this question 07:08:52 https://front-end.social/@leaverou/115482600983968371 07:08:53 lea: Posted some polls 07:09:03 JRJurman has joined #css 07:09:16 lea: There are 2 author intents: I want to specify width of entire border, or I want to specify width of individual borders 07:09:34 lea: As you can see, overwhelmingly people prefer listifying 07:09:51 lea: but then we'd need to support multiple border-styles 07:10:18 on the other hand: solid, dotted, solid could look excellent 07:10:19 lea: another issue with listifying is, how do we reconcile issue of border-width 07:10:33 lea: honoring that while also being able to say 1px white, 1px black 07:10:50 lea: One idea I had was to have border-width specify width of the total border (as it is today) 07:10:56 q+ 07:10:59 lea: So layout would still be as expected 07:11:14 lea: But if you have a border shorthand specifying multiple border widths, they would dereference a new longhand 07:11:23 lea: where you can specify a list of border widths ando/ro fr 07:11:31 lea: just like in stripes() function 07:11:54 lea: Another concern is that even though this looks nice for simple cases, it makes some other cases more difficult 07:12:05 lea: Actual use cases are overwhelmingly simple 07:12:12 lea: People don't generally do differnet colors on each side 07:12:23 nigel has joined #css 07:12:36 lea: So yes, doing layers around and around would still be awkward, but nobody really needs it 07:12:48 lea: But if can't resolve to that, there are other solutions 07:13:01 lea: Maybe we can listify outline rather than border since it doesn't affect layout 07:13:13 lea: but I don't think stripes is natural 07:13:23 q+ 07:13:23 q+ 07:13:34 ack emilio 07:13:45 q+ 07:13:46 emilio: Whatever solution we come up with, it has to specify width of each border individually 07:13:52 emilio: otherwise you end up with snapping issues 07:13:58 emilio: 3 colors with 2px, it's an issue 07:14:05 emilio: borders snap to pixels 07:14:22 qq+ about snapping 07:14:30 ack about 07:14:30 about, you wanted to react to emilio 07:14:34 q+ 07:14:37 emilio: Need to make sure each stripe is device-pixel sized. Otherwise it looks like crap 07:14:41 ack oriol 07:14:51 oriol: I disagree that stripes() is overengineered. To me it seems simple. 07:14:59 oriol: I like that it allows grouping each side the various colors 07:15:13 oriol: because with multiple border solution you have to specify inner ones, then outer ones, etc. 07:15:21 oriol: it's harder to visualize what colors go to which place 07:15:40 oriol: I also don't like that the styles will always be solid, and need to keep repeating 'solid' for each layer 07:15:48 oriol: with stripes() you only need to specify the style once 07:16:06 TabAtkins: Small question, snapping every color, in existing two-tone borders, do we snap those? 07:16:25 emilio: I think the width is not snapped, but when you paint you snap 07:16:48 ack ntim 07:17:05 ntim: Problem I have with stripes is, naming is indicates that striping is on the other axis ... 07:17:16 ntim: One thing that could be possible is making stripes take sizes 07:17:25 TabAtkins: it already does that 07:17:54 florian: You still have to specify the total explicitly though 07:18:04 have to say `border: 5px stripes(white 1px, black 3px, blue 1px)` 07:18:14 ntim: makes sense 07:18:25 ntim: So I guess my main issue is the axis 07:18:25 can't just say `border: stripes(white 1px, black 3px, blue 1px)` and magically have it know it's 5px wide 07:18:34 ntim: Also a lot of ppl use box-shadow for this use case 07:18:38 (tho we could probably fix that somehow) 07:18:41 q? 07:18:42 q+ 07:18:42 ntim: could we just make that more convenient? 07:18:58 q- 07:19:07 ntim: also easier to implement 07:19:14 q+ to bikeshed and propose "bands" instead of "stripes" 07:19:23 ack miriam 07:19:40 miriam: I'm interested in having a box-shadow approach, but big difference wrt layout 07:19:48 miriam: so stacking multiple borders wouldn't be the same 07:19:50 Adam_Page has joined #css 07:19:52 miriam: might want either or both 07:19:59 miriam: doesn't remove need for multiple borders 07:20:07 miriam: I like the just list them syntax, and disagree that we always want solid 07:20:08 box-shadows all stack on top of each other; people "use box-shadows" by using a wide, fully opaque shadow, then gradually adding narrower shadows. 07:20:20 miriam: def situations where combining dots with solid and dashes could get interesting results 07:20:31 miriam: so not a useless feature 07:20:32 ack lea 07:20:45 lea: box-shadow is what ppl have, but it's a hack 07:20:55 I challenge Miriam to come up with a single example of two-dots that doesn't look horrible. ^_^ 07:21:01 lea: You have to adjust all the lengths because they stack z-axis, not in space 07:21:17 lea: We could use outline, but they are used for focus rings 07:21:36 lea: We could have an outline-inset that goes on the inset 07:21:36 (box-shadow is easier to implement because it would be a parse-time translation) 07:21:43 (TabAtkins / emilio - I just checked `groove`, following up on Tab's question a few minutes ago, and Firefox/Chrome both antialias it, based on a screenshot of `data:text/html,
Hello` on my 150% HiDPI screen on Linux) 07:21:46 lea: A few other things to mention 07:21:55 q+ 07:21:58 I didn't say _every_ combination would look good :) 07:22:06 lea: Current stripes() has indirection issue. I need to add up my stripes. Should be able to specify intent directly 07:22:17 lea: Weird to have two border-width properties, but hope is that weirdness is internal 07:22:20 zakim, close queue 07:22:20 ok, astearns, the speaker queue is closed 07:22:21 but I think dotted, solid, dotted could look great 07:22:28 lea: people will very rarely need to set border-width-foo themselves 07:22:49 lea: listifying also allows to easily set sizes and colors independently, which is useful 07:22:57 lea: wrt snaps, any solution we pick will have this issue 07:23:14 lea: We could skip allowing flexin, but then authors will do it themselves with calc(), so you still have to deal with rounding 07:23:25 lea: so seems better to have author intent directly so we can make intelligent decsions 07:23:37 lea: Oriol mad epoint I made around how it is confusing to specify multiple colors per side 07:23:40 lea: but people generally don't do it 07:23:46 lea: it's not controversial that it's awkward 07:23:47 thanks, dholbert, that's useful to know. and presumably negates emilio's point about needing to snap the stripe colors, then. ^_^ 07:23:48 lea: I agree 07:23:55 lea: but not a confusing thing that people will hit 07:24:03 q? 07:24:06 lea: Also he said you need to specify solid multiple times, that's how this works 07:24:25 lea: but if you wnat to specify once, it's easy, following existing pattern just set border-style after the shorthand once 07:24:38 lea: Wrt confusing stripes() direction that tim mentioned 07:24:44 lea: I agree, it's confusing 07:24:52 lea: Would expect it to work like background clipping 07:25:01 (I disagree that it negates emilio's point; I don't think we want to draw inspiration from how 'groove' is implemented...) 07:25:12 +1 reserve stripes() for something else some other time 07:25:37 ack florian 07:25:37 florian, you wanted to bikeshed and propose "bands" instead of "stripes" 07:25:42 q+ 07:25:46 florian: To extent that name is problem, maybe consider bands() or something 07:26:12 florian: calculating the total is annoying, well, we can introduce an `auto` value 07:26:13 q+ 07:26:21 florian: sum up all the definite lengths 07:26:56 color-sequence? 07:26:58 lea: yeah, it'd be weird to do that with stripes() but with border-width-foo would be fine 07:27:12 s/border-width-foo/border-width-relative/ 07:27:20 oriol: Instead of adding a new auto size, we could say that if you specify border shorthand and you omit the width component then it could automatically take from stripes function 07:27:35 that means we can no longer use `border-color` in the whitelist of properties that don't affect box model 07:27:35 oriol: if you specify in border-color wouldn't be able to, but for shorthand could do it 07:27:50 lea: [comment above] 07:28:08 oriol: wouldn't have an effect, only when setting shorthand 07:28:14 astearns: not hearing consensus, so take to issue 07:29:06 Topic: app-region for draggable app windows 07:29:16 zakim, open queue 07:29:16 ok, astearns, the speaker queue is open 07:29:17 berlysia has joined #css 07:29:38 nigel has joined #css 07:30:03 diekus has joined #css 07:30:12 felipeerias has joined #css 07:30:53 diekus: windows have default ux for moving 07:31:05 ... several APIs to expand the viewport area 07:31:13 ... when api is enabled, can do things like create custom title bars 07:31:17 github: https://github.com/w3c/csswg-drafts/issues/7017 07:31:20 ... but then the default dragable area disappears 07:31:27 ... so propose to specify app-region 07:31:37 mstensho6 has joined #css 07:31:51 ... [shows slides that expands the viewport area, losing the titlebar area] 07:32:06 ... This exists, but no definition of how ti exists 07:32:20 ... And this is the behavior. It's enabled only when default platforms UX is not visible 07:32:28 q+ 07:32:51 ... works for inline and block elements 07:32:58 ... property consumes all pointer events 07:33:02 ... can use it to drag the window etc. 07:33:08 ack oriol 07:33:12 ... won't work if it is overlapped by other elements 07:33:17 ... works even when animating 07:33:47 ... suppose here I have a button in the middle of the window, I set app-region on it, andI can use it to drag the window 07:33:48 q+ 07:34:02 ... propose to spec it in css-ui-4 07:34:03 q? 07:34:05 q+ 07:34:18 ntim: Multiple things to think about 07:34:28 ... what happens if you put no-drag and then child is drag 07:34:34 ... does the property inherit, what wins? 07:34:39 ack ntim 07:34:54 diekus: Depends on which element absorbs the pointer events 07:35:29 ntim: I implemented moz-window-dragging for GTK port, so some prior art 07:35:39 emilio: Gecko has similar property. We don't expose it to Web content 07:35:53 emilio: for PWA cases makes sense 07:36:06 emilio: If you have a native titlebar, is this property expected to work? 07:36:09 diekus: no 07:36:11 q+ 07:36:22 diekus: before you enable window controls overlay, you can define the drag region 07:36:37 emilio: That's weird. E.g. macos has toolbar where you have native titlebar, and toolbar, but the toolbar is also draggable 07:36:51 diekus: I fyou want to create that effect in a PWA you would enable window controls 07:37:01 diekus: It's used to create a custom titlebar 07:37:09 +1 emilio 07:37:10 emilio: Annoying if I have to rebuild a titlebar in order to drag the toolbar 07:37:32 emilio: In Gecko if you drag anywhere in the toolbar, it also take sthe window, not just the titelbar 07:37:54 diekus: you could move from any element you set it on 07:38:00 diekus: but the titlebar would have to be off 07:38:04 emilio: that seems unfortunate 07:38:28 astearns: Is this a -webkit- property? 07:38:34 ack astearns 07:38:35 ntim: It was unshipped from Safari 07:38:36 ack hober 07:38:55 hober: Yeah, it was asserted that it already exists. It's not actually all the things. 07:38:55 ntim: It's only shipping in Chrome apparently 07:39:00 ntim: I don't think app-region is a good name for this 07:39:10 ack ntim 07:39:11 ntim: Could reuse for other things 07:39:24 diekus: agree the name is not descriptive at all 07:39:39 diekus: but do we agree on having the behavior? 07:39:47 q+ 07:39:55 ack fantasai 07:39:59 fantasai: This seems something that should be inherited 07:40:04 ... so that you can put on and off 07:40:16 ack emilio 07:40:22 ... and only affects element you set it on 07:40:34 ... that would solve the toolbar case, as long as it works even with titlebar 07:41:31 maybe just a new touch-action value? 07:41:31 diekus: details in explainer 07:42:08 astearns: Anyone in the room to oppose this feature? Is this not something to work on? 07:42:31 hober: I'd have to ask ppl in the wrong time zone 07:42:46 astearns: Given in one engine, was in anotther, and third has something similar... 07:42:51 hober: unsure it was ever in safari 07:42:55 astearns: Answer seems to be "maybe" 07:43:05 diekus: as long as it's fine overall, I can write the spec text 07:43:38 emilio: fine to work on it. issue on name, inheritance, when it applies 07:43:51 astearns: We'll work on this and decide if it goes into a draft or not 07:44:08 Topic: [css-page] Expose unprintable areas via CSS 07:44:12 present+ 07:44:30 foolip: Issue is unprintable areas 07:44:37 foolip: Original idea was using env() for safe areas 07:44:57 foolip: but a bit unreliable because not dependable depending on how you feed the paper 07:45:04 foolip: so only safe to do is to report the largest margin 07:45:21 foolip: So new proposal, where we have a descriptor on @page and margin boxes 07:45:42 foolip: and new alias for margin called safe-margin which would compute to larger of margin and safe margin 07:45:48 foolip: required to do fallback correctly 07:45:49 q+ 07:46:18 foolip: 3 modes for this: current behavior (no compensation), clamp (largest of the margins), and add (add to existing margin) 07:46:30 foolip: Unsure what the use case for that is, but long discussion with morton + dholber led to that 07:46:30 q+ 07:46:41 q+ 07:46:50 ack florian 07:46:50 florian: I agree that not reliably knowable where things are 07:46:50 florian: unsure that it's never knowable 07:46:56 q- 07:46:57 florian: maybe we can have some flexibility, UA can say it knows 07:47:11 q+ to ask whether there is prior art in print formatters to follow 07:47:29 florian: want to avoid limiting behavior in cases where we could use that knowledge 07:47:49 foolip: You could easily turn page-safe-margin into 4 longhands 07:48:14 foolip: but if nobody wants that, should we really do that, or add it only when someone claims to be able to support 07:48:17 florian: good enough 07:48:20 ack emilio 07:48:29 Proposal - 07:48:30 Add a property / descriptor (the spec seems confused about this terminology) for @page and @page margin boxes: 07:48:33 Name: page-margin-safety 07:48:36 Value: none | clamp | add 07:48:38 Initial: none 07:48:39 (because I scribed it badly originally) 07:48:53 emilio: I'm not sure awhy we need the aliasing thing? 07:49:12 emilio: Adds a weird dependency 07:49:44 emilio: Shouldn't change the descriptor's margin value 07:50:12 foolip: margin by itself would apply to all environments, but if don't need it 07:50:19 emilio: We have @supports for that 07:50:25 foolip: for descriptors? 07:50:30 emilio: Yeah, we have a resolution for that 07:50:32 nigel has joined #css 07:50:47 emilio: Consider you print multiple pages per sheet 07:50:58 emilio: wouldn't you wnat to use the normal margin rather than the page-margin-safety thing? 07:51:15 foolip: This would apply to the 3 edges that apply to the edges 07:51:20 foolip: Some explanation that it only applies to margins adjacent to an edge 07:51:24 foolip: also applies to page margin boxes 07:51:33 florian: there the margin only applies to the one or two sides at the edge of the paper 07:51:43 emilio: but 1cm in the page... the page would be scaled down 07:51:49 foolip: that's why we moved away from env() as a solution 07:51:58 foolip: with this you know both the page size and what the safety is 07:52:09 foolip: scaling doens't make it unsafe again 07:52:38 emilio: if we need both, the override should happen at used-value time 07:52:40 [css-conditional-5] Feature detection for descriptors 07:52:40 https://github.com/w3c/csswg-drafts/issues/2463 07:52:43 emilio: when you access .style ... 07:52:46 foolip: it is 07:53:19 When there are multiple pages per sheet, the UA should already add whatever margin safety it needs around the set of pages, and `page-margin-safety` should do nothing in such cases. 07:53:24 emilio: Mortons proposal for aliasing margin is weird 07:53:46 astearns: I expect that there is prior art in print formatters for this 07:53:52 astearns: might be worth checking what it is 07:53:55 Aliasing is for feature detection. If we can do it `@supports`, that would be much better. 07:54:10 ack fantasai 07:54:13 ack astearns 07:54:13 astearns, you wanted to ask whether there is prior art in print formatters to follow 07:55:13 q? 07:55:15 fantasai: page-margin-safety seems good 07:55:25 fantasai: page-safe-margin seems problematic, just use @supports 07:56:14 florian: [something about individual cases] 07:56:30 fantasai: if we're taking the max, we take the max always. If we want individual controls, we can add them 07:57:33 fantasai: Might want symmetric all around. Or per axis. or each side individually. We can add keywords for these. 07:57:34 (I'm not fully grokking the page-safe-margin proposal, partly because I'm sleepy. :) but I agree with fantasai I think; if we can use @supports, I'm happy with the earlier `page-margin-safety` descriptor) 07:58:09 astearns: Let's have morton change the proposal in response to feedback, and bring it back for adoption 07:58:37 topic: end 07:59:31 berlysia has left #css 08:00:15 Snugug has joined #css 08:00:29 (i.e. bullet point 2 from mstensho's Sep 10 comment seems reasonable, in https://github.com/w3c/csswg-drafts/issues/11395#issuecomment-3278475372 ) 08:01:22 (assuming we get `@supports` working as described there) 08:02:10 (and per whatever prior resolution folks mentioned in the discussion today, about @supports with descriptors) 08:11:12 nigel has joined #css 08:29:54 nigel has joined #css 08:37:27 karlcow has joined #css 08:44:00 duerst has joined #css 08:45:08 Guest43 has joined #css 08:48:17 Penny has joined #css 08:52:50 nigel has joined #css 08:54:57 dholbert has joined #css 10:41:47 Guest43 has joined #css 11:36:47 Guest43 has joined #css 11:43:21 zakim, end meeting 11:43:21 As of this point the attendees have been rachelandrew, miriam, kizu, JanV, dholbert, plinss, Adam_Page, kbabbitt, chrishtr, ydaniv, alisonmaher, oriol, vmpstr, lea, TabAtkins, 11:43:24 ... emilio, karlcow, adamargyle, Ragvesh, Vinay, flackr, noamr, front-endian-jane, kzms, Penny, bts, ntim, hober, foolip 11:43:24 RRSAgent, please draft minutes v2 11:43:25 I have made the request to generate https://www.w3.org/2025/11/12-css-minutes.html Zakim 11:43:31 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 11:43:31 Zakim has left #css 12:49:41 nigel has joined #css 14:00:11 nigel has joined #css 14:38:35 nigel has joined #css 15:11:20 zrhoffman has joined #css 15:27:18 nigel_ has joined #css 16:35:36 dholbert has joined #css 17:14:31 nigel has joined #css 21:18:10 nigel has joined #css 21:35:28 nigel has joined #css 22:24:06 nigel has joined #css 23:15:20 nigel_ has joined #css 23:52:55 saku has joined #css 23:55:12 Zakim has joined #css 23:55:15 karlcow has joined #css 23:55:23 alisonmaher has joined #css 23:55:30 present+ 23:57:58 karlcow_ has joined #css 23:58:14 noamr has joined #css 23:58:29 nigel has joined #css 23:59:06 kbabbitt has joined #css 23:59:12 flackr has joined #css 23:59:36 oriol has joined #css 23:59:39 jamesn has joined #css 23:59:43 present+ 23:59:45 present+ 00:00:12 present+ 00:00:12 schenney has joined #css 00:00:12 kbabbitt has joined #css 00:00:38 dholbert has joined #css 00:01:39 bkardell has joined #css 00:01:46 present+ 00:02:20 ScribeNick noamr 00:02:20 zakim, start meeting 00:02:20 RRSAgent, make logs Public 00:02:21 ydaniv has joined #css 00:02:21 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 00:02:21 present+ 00:02:27 present+ 00:03:00 present+ 00:03:10 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12612 00:03:10 Topic: [css-sizing] Which replaced elements stretch? 00:03:10 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12612. 00:03:31 topic: none 00:04:54 present+ 00:06:02 present+ 00:08:09 present+ 00:08:24 mjackson has joined #css 00:08:35 Patrick_H_Lauke has joined #css 00:08:55 Jxck has joined #css 00:09:29 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12612 00:09:29 Topic: [css-sizing] Which replaced elements stretch? 00:09:29 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12612. 00:10:01 oriol: there are some replaced elements that stretch in the inline axis. the exact mechanism is not clear. I want to discuss in which cases this should happen 00:10:41 masonf has joined #css 00:10:43 present+ 00:10:48 oriol: this happens with replaced elements that don't have natural sizes, e.g. SVG can have natural size with width/height, image gets it from the resources. also a non-degenearate aspect ratio, e.g. natural or from the CSS prop 00:10:50 present+ 00:11:06 berlysia has joined #css 00:11:26 oriol: browsers agree with this, but eg in iframes gecko and webkit ignore the aspect ratio, but it works because iframe doesn't have preferred aspect ratio. can we resolve on those two conditions? 00:11:34 +1 00:11:48 scribe+ 00:11:53 fantasai: consistency seems good? 00:12:00 +1 for consistency 00:12:53 iank_: it happens when there is no aspect ratio and no natural sizing 00:13:06 wendyreid has joined #css 00:13:18 PROPOSED RESOLUTION: spec what browsers are doing. 00:13:19 s/no aspect ratio/non-degenerate aspect ratio/ 00:13:26 RSOLVED: spec what browsers are doing. 00:13:29 RESOLVED: spec what browsers are doing. 00:13:39 karlcow_ has joined #css 00:13:56 iank_: do you want to discuss what this effect? 00:14:07 s/what/which elements use/ 00:14:30 oriol: It matches all replaced elements, but some don't have preferred aspect ratio, e.g. iframe or not-ready video 00:14:39 fwang has joined #css 00:14:40 miketaylr has joined #css 00:15:10 iank_: there is a bug on other browsers to drop natural sizes on video. so that's fine 00:15:13 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11478 00:15:13 Topic: [CSS2][css-position-3] Negative containing blocks and `auto` margins 00:15:13 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11478. 00:16:10 alisonmaher has joined #css 00:16:43 adamargyle has joined #css 00:16:50 Adam_Page has joined #css 00:17:30 oriol: we resolved this issue in Paris. when the inset is big enough so that the containing block is negative, what should happen? browsers seem inconsistent. Servo allows it to have a negative size. We resolved to go with the blink way. but we implemented it in servo we realized that blink it does this for sizing, auto sizing and margin, but for alignment it uses negative size inset-modified containing block 00:17:36 iank_: it's not what's happening in blink 00:18:23 LeoLee has joined #css 00:18:25 iank_: it's a bug in blink. when we clamp the IMCP we have 3 options. adjust end inset, start inset, or both 00:19:06 iank_: we shift the inset based on alignment to be negative 00:19:42 iank_: the other option is to take the dominant side and always do that. blink always has a positive IMCP for alignment 00:20:13 iank_: the other option is just to take the dominant side based on writing mode and direction. I think we resolved on that. 00:21:02 oriol: we resolved on aligning with blink and then I found a case where this is different. no strong opinion 00:21:18 iank_: I am fine with changing this 00:21:18 ack fantasai 00:21:48 fantasai: between blink and resolved behavior, no strong opinion. unlikely people would intentionally run into this. intuition from authoring perspective anyone? 00:22:08 iank_: I want to clamp the negative size to non-negative 00:22:40 astearns: keep resolution and consider it a bug in blink; or amend it slightly to specify blink's current behavior 00:22:43 present+ 00:23:36 PROPOSED RESOLUTION: close with previous resolution accepted 00:23:42 RESOLVED: close with previous resolution accepted 00:23:53 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11799 00:23:53 Topic: [css2][css-tables] Cells spanning collapsed track 00:23:53 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11799. 00:24:02 tantek has joined #css 00:24:22 Jxck has joined #css 00:24:46 oriol: in tables you might have a cell that spans multiple cols/rows. one of them can be collapsed. what CSS2 says is that the area that is intersecting the collapsed track should be clipped. it's weird e.g. when there is text intersecting this 00:25:56 oriol: webkit doesn't implement collapsed tracks. In gecko, in the inline-axis, it would overflow. in the vertical case, in gecko vertical aligment applies first and then it can overflow 00:26:10 oriol: in blink vertical alignment happens after collapsed row, unsafely 00:26:29 oriol: in servo we do something similar in a safe way 00:26:38 oriol: maybe we should decide on something 00:27:01 saku3 has joined #css 00:27:26 q+ 00:27:42 iank_: it was concious decision to relayout at the new width because of the inline overflow case. you have potentially more block size than inline size. it's a tradeoff to try not to overflow inline direction 00:28:46 ack astearns 00:28:51 astearns: I don't like the alignment in blink. I don't have a good idea of what we should do here, but having the content at least start and overflow in the writing mode appropriate ways is better than hoisting at the start of the cell 00:29:20 oriol: we already resolved on on vertical aligning safely. but there is a q of whether vertical alignment should be before/after collapsing 00:29:22 ack fantasai 00:29:56 s/ at the start/ above the start/ 00:30:13 joone has joined #css 00:30:16 fantasai: the original collapse was supposed to not impact layout for perf reasons. tables 25 years ago were very expensive. it's not a good behavior. what people would actually want is to do an extra table layout but that's complicated 00:31:17 fantasai: reflowing the spanning cell would be helpful from a user perspective. overflowing is not great. but we can't reflow everything because of perf/complexity. we should align with blink/servo 00:31:56 iank_: we haven't implemented safe centering. does servo reflow in the inline direction? 00:32:01 oriol: no 00:32:16 Bobby has joined #CSS 00:32:28 iank_: overflowing block is better than overflowing inline 00:32:54 LeoLee6 has joined #css 00:33:32 fantasai: if we go with not reflowing. servo is the most consistent with this. it adjusts the alignment, and will get a good result when fits. blink reflows the spanning cells but not the middle, it's half way this and half way that 00:33:57 fantasai: I think servo's behavior is better here. if we want something that reflows, we should reflow all the relevant rows and columns 00:33:59 +1 00:34:17 mmocny has joined #css 00:34:22 astearns: mild preference to avoid reflow because it's not fixing enough to be worth it, for overflow cases 00:34:46 astearns: a simpler set of specified steps for edge cases that authors are likely avoid 00:34:54 iank_: we have to reflow the collapsed cells 00:35:29 fantasai: you can either removed the collapsed cells and adjust the size. or pretend those cells don't exist and reflow the table. halfway is not great 00:35:50 fantasai: they can set overflow on the cell 00:36:10 iank_: blink behavior keeps text readable if it's in the spanning cell 00:36:29 oriol: my mild concern is that doing the blink behavior of reflowing would have extra perf cost 00:36:56 fantasai: this was designed for large tables of data. there are usually less spanning cells in those tables 00:37:22 q+ 00:37:27 iank_: we can also disallow collapsing when there are spanning cells. you have to collapse all the columns and rows affected 00:37:33 Given the use-case for spanners in this case could be, like, "large header cell describing multiple columns", reflowing the spanner does seem like the right idea. 00:37:38 fantasai: not sure this is viable 00:37:52 s/this/"don't collapse if there's a spanner"/ 00:38:04 kizu: if we add overflow:auto to the spanning cell, it works fine in chrome, in firefox it's just doesn't overflow 00:38:14 emilio: this is a known issue, not related to this 00:38:34 fantasai: main thing is that you have text-align based alignment it gets fixed up 00:38:49 iank_: I would prefer to reflow then 00:38:58 fantasai: we have to reflow then 00:39:35 astearns: two options, to specify servo's behavior that doesn't relayout. the other is to specify blink behaviors (% the alignment bug) that does relayout 00:39:44 fantasai: because of text-align we should probably go with relayout 00:40:07 astearns: it also avoids some overflow 00:40:26 PROPOSED RESOLUTION: go with blink behavior, fixing the alignment bug) 00:40:30 RESOLVEd: go with blink behavior, fixing the alignment bug 00:40:34 RESOLVED: go with blink behavior, fixing the alignment bug 00:40:43 RESOLVED: Spanning cells get relaid out when rows/cols are collapsed 00:40:46 present+ 00:40:53 github-bot: take up https://github.com/w3c/csswg-drafts/issues/3029 00:40:53 Topic: [css-logical-1] Order of inheritance vs. mapping in logical properties 00:40:53 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/3029. 00:41:07 yeah https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=14309 looks broken on FF. 00:41:35 oriol: we resolved on this 5 years ago. when you have an inherit on a logic property, it would inherit from the same logical property, even if the physical mode is different 00:41:46 q+ 00:41:52 oriol: no browser is doing this. everyone resolves logical to physical first and only then applies inheritance 00:41:59 ack kizu 00:42:00 ack kizu 00:42:06 ack fantasai 00:42:36 q+ 00:42:39 ack emilio 00:42:42 fantasai: I can see the argument. I also think it was the right behavior to do. the properties that this affect are not inherited property. not a lot of people do this. I am somewhat inclined to leave current resolution 00:43:07 emilio: strong disagree. it's weird that some css wide keywords you affect some properties but not others 00:44:17 emilio: in implementations conversion to physical happens before inheritence 00:44:54 emilio: I don't see this as being terribly useful 00:45:11 ack kbabbitt 00:45:11 emilio: not sure it's worth it 00:45:40 kbabbitt: agree with emilio. the resolution was sitting for 5 years. there is additional compat risk. lets spec the current behavior 00:45:48 fantasai: ok if we are going with that direction 00:46:13 q+ 00:46:23 ack noamr 00:46:31 fantasai: but disagree there's a compat risk 00:46:50 fantasai: super unlikely to use inherit in a logical property across direction changes even if usage was 90% 00:46:59 noamr: logical properties are complicated enough already, let's keep it simple 00:47:24 PROPOSED RESOLUTION: specify inheritance works on physical properties 00:47:45 q? 00:47:46 emilio: if this affected inherited properties the inherited one would be the physical one 00:48:02 PROPOSED: Logical properties inherit from the parent using physical correspondance 00:48:19 florian: how mad are i18n going to be on this 00:48:39 fantasai: not a big deal I think? you can also, depending on what you're doing, you *want* the physical prop 00:48:51 astearns: let's resolve and find out 00:49:04 RESOLVED: specify inheritance works on physical properties 00:49:21 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11811 00:49:21 Topic: [css-will-change] Should `will-change: transform` establish a containing block for fixed background attachments? 00:49:21 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11811. 00:49:34 ntim has joined #css 00:50:21 oriol: when you set will-change to the name of another property the element would get all the behaviors related to that specify property. in particular, for transform, the spec says that the element establishes a CB for all descendants (abs, fixed, fixed background attachment) 00:50:50 karlcow_ has joined #css 00:51:00 oriol: the first two already apply for the first two. but not for background attachment. in does do this in gecko and blink, and not in webkit 00:51:06 oriol: smfr said this is a webkit bug 00:51:14 oriol: I think should cover this in will-change 00:51:49 oriol: there was a discussion on how to deal with it, e.g. just for transform. 00:51:59 emilio: also the individual transform properties 00:52:23 astearns: does the general statement in the quote match your expectation? 00:52:46 emilio: I think so 00:53:18 q+ 00:53:53 ack emilio 00:53:57 fantasai: all values or just CB/SC creating values? 00:54:10 TabAtkins: don't create a stacking context there 00:54:22 s/don't/do/ 00:54:24 astearns: sounds like we agree about that comment in the last issue 00:55:01 PROPOSED RESOLUTION: If any (*) non-initial value of a property would cause the element to generate a containing block for fixed background attachments, specifying that property in will-change must cause the element to generate a containing block for fixed background attachments. 00:55:32 RESOLVED: If any non-initial value of a property would cause the element to generate a containing block for fixed background attachments, specifying that property in will-change must cause the element to generate a containing block for fixed background attachments. 00:55:41 +1 to the ambiguity around "any" there 00:55:43 scribe- 00:56:12 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12750 00:56:12 Topic: [scroll-animations?] Proposal: Add overscroll gestures with ability to reveal elements 00:56:12 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12750. 00:56:28 present+ 00:56:39 www-archive@w3.org 00:56:45 thanks 00:57:10 present+ 00:58:00 flackr: many apps have swiping gestures to pull in components 00:58:13 flackr: often a directional meaning, menu on left, etc 00:58:20 flackr: in photos, swipe down to dismiss current photo 00:58:30 flackr: common thing devs want to do, they're usually handling this with events 00:58:37 flackr: we think this is very similar to scrolling in UX tho 00:58:56 flackr: movement of finger usually corresponds to movement of a UI component. often chained on a scrolling experience. we already have scroll-snap to talk about sticking 00:59:06 flackr: so we want to explore building this declaratively as an interaction 00:59:11 flackr: have a couple of ideas 00:59:16 flackr: could be CSS or html 00:59:34 flackr: the core thinking is it would be done with an ancestor scrolling area 00:59:42 flackr: you have content, when yous croll past it you pull in other UI 01:00:01 flackr: this creates a natural interaction where you can still access all the content in your scroller, then pull further to get the extra UI 01:00:11 flackr: the extra UI needs to be in one of these "overscroll areas" 01:00:21 flackr: so our proposal lets you say "my menu wants to be in this named overscroll area" 01:01:30 https://docs.google.com/presentation/d/1J7RrjKQQCuqLjxTOTvGWoGmxq2FzVvL00YpEczaRUUo/edit?slide=id.p#slide=id.p 01:01:40 flackr: [shows example of CSS] 01:01:47 mjackson has joined #css 01:02:00 flackr: I mentioned this feels natural to integrate with scorlling 01:02:22 flackr: looking at maps, same action first scrolls in the sheet, then initiates overscroll action to pull in extra content 01:03:22 sorvell has joined #css 01:04:28 fantasai: [question about how slide 7 example is interpreted] 01:04:36 fantasai: what would it mean to say "right: 50%"? 01:04:54 flackr: it would be 50% in view 01:05:30 fantasai: so is the 'right' property what makes it on the left? if I set 'left: 10px; right: 10px;'? 01:05:38 flackr: then there's no overscroll content 01:05:48 theparkagen has joined #css 01:05:54 q+ 01:06:01 q+ 01:06:04 [more qs trying to figure out exactly what the layout model is here] 01:06:08 q+ 01:06:12 flackr: we're open to ideas on how to do it better 01:06:13 q+ 01:06:22 fantasai: what are the use-cases for multiple overscroll into same position? 01:06:24 q- 01:06:30 vmpstr: top bar, then pull to refresh after that 01:06:39 joone has joined #css 01:06:39 vmpstr: you keep going and chain into higher levels 01:06:46 fantasai: how do you know which one is scrolled to first? 01:07:03 vmpstr: [looks at slide] based on scroll areas, they nest 01:07:37 vmpstr: based on order of the names in 'overscroll-area' 01:08:04 q+ 01:08:05 flackr: I have demos based on regular scrollers so you can playl with it 01:08:07 q+ 01:08:12 flackr: we want to make this easier to build 01:08:20 flackr: [explains the demos] 01:08:23 Present+ 01:08:30 flackr: swipe to dismiss has overscroll in three directions 01:08:39 q+ 01:08:47 present+ 01:08:52 flackr: for any of these, we want to make sure there's a way to access the content when you're not on a swipe able device 01:09:08 flackr: some thoughts are based on what people do today in native apps or the web 01:09:20 flackr: maybe if one element creates the area, that element's label can describe the area 01:09:38 flackr: saying "swipe in X direction, you active this component". or maybe it's a button. 01:09:44 flackr: maybe a generic announcement about components. 01:09:54 flackr: on iOS there's a specific announcement about pull-to-refresh 01:10:06 flackr: scroll into view should do what you expect, bringing the area into view 01:10:18 q+ 01:10:21 flackr: a benefit for doing this in HTML is there's a more natural semantic meaning for the area to express 01:10:34 flackr: but there is a pretty tight CSS coupling regardless 01:10:50 flackr: many extensions possible. overlay a backdrop to hide content, so a pseudo for that 01:11:03 flackr: some cases where you want to push content out of view vs overlay content, want a switch 01:11:17 flackr: if you interact with the content you usually want to dismiss the overscroll area, need to define what would cause this 01:11:30 flackr: and some physics things to get right. scrolling is sometimes too easy to engage, maybe some stickiness 01:11:50 ack kizu 01:11:51 keithamus: looks cool and well motivated 01:11:53 ack kei 01:11:55 keithamus: difficult to do today 01:12:10 keithamus: curious, a lot of actions would need to have an equivalent button. a lot of demos show that 01:12:11 q+ kizu 01:12:17 keithamus: like menu has a button as well 01:12:31 keithamus: since engineers will author a button anyway, wonder if we can express this using those button relationships 01:12:50 keithamus: won't always have a button, but could imagine pull-to-refresh where ethe overflow content itself is the button 01:13:00 keithamus: another rpoint, you talk about aria announcements 01:13:16 keithamus: not entirely sure that's necessary (but encourage reaching out to aria), but do think it's very important to get focus right 01:13:21 keithamus: curious about semantics of that 01:13:36 keithamus: abridged: scrolling gestures need an equivalent button, and focus is very important, maybe the most important a11y thing 01:13:45 keithamus: also, overscroll-for in HTML shoudln't have a dash 01:13:46 ack wendyreid 01:14:04 wendyreid: this is very cool, reviewed it during breakout this week 01:14:09 q+ to reply to keith with some context about snap-to-activate 01:14:21 wendyreid: I think this presents some concerns about a11y, most have been identified. but also opportunities to make things a lot better 01:14:47 wendyreid: a challenge, already in native, is to navigate with a screen reader, you have to go thru all the content. bottom nav you have to scroll all the way down. 01:14:57 wendyreid: so I think this gives us the oppo to make shortcuts 01:15:14 wendyreid: something to consider might be - an aria prop called 'aria-flow-to' that gives alternate nav 01:15:24 wendyreid: maybe under implemented because it "sounds good" but unclear how to use it 01:15:31 context for my future comment: snap-to-activate explainer is at https://github.com/WICG/declarative-partial-updates/blob/main/snap-to-activate-explainer.md 01:15:39 wendyreid: but yeah, this definitely sounds like should be in html 01:15:53 wendyreid: really hard when things get abstracted away, when trying to debug this stuff. 01:16:07 ack emilio 01:16:13 emilio: a few qs 01:16:21 emilio: how does this compare to native APIs? 01:16:40 emilio: do you have a quick answer? if not we can chat separately. 01:16:53 if native equivalents have accessibility affordances this would also be useful input 01:16:55 s/'aria-flow-to'/'aria-flowto'/ 01:17:03 flackr: my understanding is the native approach is based on the toolkit, the toolkit usually handles things 01:17:45 noamr: we researched this - the layout is different on native. overflow doesn't exist the same way. instead it creates a stack, can stack to the left and right, up and down, above and below 01:18:06 noamr: the whole model is this stacked transparencies, very different from how CSS works 01:18:13 smfr has joined #css 01:18:18 noamr: but the underlying concept is chained scrollers, and that's the same as css 01:18:42 flackr: in manyc cases, you need to bea ble to access the scrolled content first before you pull in a sidebar 01:18:52 emilio: in your demos you use scrollers, you can see the scrollbars moving around 01:19:13 emilio: so these things don't contribute to scrollable overflow, they're in this overscroll area that you can't normally scroll to...? 01:19:28 flackr: they're in the scrollable overflow of an ancestor *pseudo-element* 01:19:38 flackr: the dev wont' see an element with the scroll offset 01:19:44 emilio: okay so an anonymous scroller 01:19:57 emilio: is that a problem - I wonder how that interacts with the scroll APIs. 01:20:21 emilio: if I scrollIntoView something in the sidebar, it needs to focus and scroll in anonymous views, but there's no scroll event 01:20:44 flackr: ah, forgot to mention we do need to define events for this. because there's implicit snapping, there will be events exposing some of the details 01:21:14 emilio: ok. a bit tricky to figure out how much is done magically with anonymous boxes and custom events, or an HTML element with some default styles... I dunno 01:21:29 emilio: just a bit worried about a lot of anonymous magic that authors need to udnerstand 01:21:34 zakim, close queue 01:21:34 ok, astearns, the speaker queue is closed 01:21:37 q? 01:22:02 emilio: just my first gut feeling is a stacked nav element in HTML, maybe 01:22:07 https://codepen.io/argyleink/pen/gOzPYOj (fwiw, the OS does not offer a button, per Keith's comment, and does have 1 hidden scrollbar, per emilio's comment) 01:22:09 astearns: lets' take this as input 01:22:10 ack adamargyle 01:22:28 adamargyle: posted a link to exploration I did myself, recreating Android ecosystem, very swipey 01:22:36 adamargyle: one hidden scrollbar, some exposed ones 01:22:45 adamargyle: and a button, not common in OSes but it feels nice 01:22:58 adamargyle: I've done research on my own on gesture interfaces, run in script 01:23:04 adamargyle: have a q about axis locking 01:23:13 adamargyle: in Chrome scrolling is very axis locked usually 01:23:28 adamargyle: but swipe to dismiss image gesture is pretty omni-directional 01:23:35 adamargyle: script is often used for the customization people want, for physics and smoothness 01:23:49 adamargyle: I was curious about how much scroll-snap was used, it was a lot in my demos 01:23:57 present+ 01:23:58 adamargyle: especially scroll-snap-stop 01:24:12 adamargyle: interaction with scroll chaining, which doesn't always stop 01:24:21 adamargyle: is there gonna be some kind of overscroll-stop? 01:24:26 adamargyle: also good to hear about events 01:24:39 adamargyle: there was a proposal the other day that was snap-to-tap [?????] 01:24:59 adamargyle: I tap something, that takes it a snap target. noamr presented a swiping that [did something else] 01:25:11 adamargyle: is my focus cursor going to discover these areas? 01:25:30 adamargyle: also, semantic element. with responsive nature of web, difficult because this is very mobile centric 01:25:39 +1 to this being mobile central 01:25:40 adamargyle: in CSS you can do all this on demand, only when needed 01:25:44 mobile centric* 01:25:49 ack noamr 01:26:11 noamr: want to reiterate that we see this as styling, progressive enhancement. shouldnt' change the semantic nature of your page 01:27:07 noamr: so this is tied strongly to CSS. a11y challenges, provide hooks to that. might match *with* an HTML semantic, "this action is an overscroll action", action is in HTML but where it goes to is in css 01:27:13 ack ydaniv 01:27:14 noamr: want to start from that design principle 01:27:31 ydaniv: 1, I'd expect positioning to be done with anchor positioning, feels more natural 01:27:40 ydaniv: could anchor to the viewport 01:27:47 (heads nodding) 01:28:14 ydaniv: 2, what are possibilities to change animation style, in and out? if it's scrolling I guess it's just scroll-snap and maybe a scroll timeline 01:28:32 ydaniv: but if people want to do other things, like coming in as a transparent container... 01:28:38 ydaniv: will that be how to customize? 01:29:14 flackr: back to Adam, we imagine these areas have an implicit snap to edge 01:29:38 flackr: lot of slight extensions to existing features. like don't think this should be axis locked. in a lot of overscrolls you're either constraining to one axis anyway, or just dont' want it locked 01:29:49 flackr: making it possible to un-lock a scroller in general is a feature we want to do 01:29:54 ack kizu 01:30:03 kizu: big things were already mentioned by others 01:30:20 kizu: think for sure we do want to approach this from it being usable without the feature, for a11y, then this is enhancement 01:30:37 kizu: something I saw as a footgun is right:100% might be outside of scrollable area, not accessible otherwise 01:30:55 kizu: so need to think about how it would work by default 01:31:09 +1 to testing it 01:31:18 kizu: I think snap is pretty good, make some areas and then choose them, when the feature is active you position them, but you can still navigate with mouse/etc 01:31:40 kizu: shouldn't rely on authors manually adding a button for non-swiping access, authors often don't add that stuff 01:31:52 ack dbaron 01:31:52 dbaron, you wanted to reply to keith with some context about snap-to-activate 01:31:52 https://github.com/WICG/declarative-partial-updates/blob/main/snap-to-activate-explainer.md 01:32:08 +1 kizu 01:32:26 dbaron: working on a separate but related feature called "snap to activate", which is connected to some of these use-cases 01:32:37 dbaron: at this point not as advanced, wasn't ready to present this week 01:32:43 dbaron: just discussing right now, not concrete proposal 01:32:53 dbaron: but did have a discussion with aria on Tuesday morning. I pasted the explainer 01:33:18 dbaron: to respond to some parts of Keith and Wendy's comments, there are pieces of here that do belong in CSS, and some that belong in HTML. 01:33:28 dbaron: I think snap to activate is probably mostly in HTML (but not fully worked out yet) 01:33:39 dbaron: still early, we've been actively talking to aria 01:34:01 tap to snap example https://codepen.io/argyleink/pen/mdxqOYO 01:34:05 astearns: I wonder if this is something we should have a joint session with aria about 01:34:07 +1 to joint session, maybe AGWG too? 01:34:10 astearns: probably better sooner than later 01:34:28 keithamus: maybe OpenUI too 01:34:36 astearns: let's keep noodling on this, thanks for the presentation 01:35:02 flackr: I think there will also be a lot of sub features that could launch separately, those will be separate issues 01:35:51 github-bot, end topic 01:36:33 nigel has joined #css 01:36:56 nigel has joined #css 01:36:57 Jxck has joined #css 01:44:19 until the top of the hour 01:50:01 alisonmaher has joined #css 01:51:30 ZoeBijl has joined #css 01:53:11 nigel has joined #css 02:01:19 nigel has joined #css 02:03:00 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12594 02:03:00 Topic: [css-view-transitions-2][css-conditionals] Exposing navigation/route matching 02:03:00 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12594. 02:03:04 ydaniv has joined #css 02:03:14 adamargyle has joined #css 02:03:24 dbaron: Noam presented this twice before, in Paris and once at a Telcon since 02:03:39 dbaron: back to use-cases 02:04:00 dbaron: a bunch of what this is about is having styles that are conditional on the currently-active navigation, or current url 02:04:13 dbaron: you might be navigating from URL A to B and want styles that depend on that 02:04:23 dbaron: a bunch of the use-cases are related to VT (but this isn't VT itself) 02:04:30 Penny has joined #css 02:04:47 dbaron: like, if you want to set up a VT between a list and details page 02:05:00 dbaron: so you click the item in the list, it expands to the whole page, VT shows the transition 02:05:05 dbaron: and potentially the reverse 02:05:26 q+ 02:05:33 dbaron: there are other examples like a loading indicator from one thing to another specific thing 02:05:45 dbaron: some times these depend on where you're coming from or where you're going 02:05:57 dbaron: it's tempting to focus on the link you activated to try and do this 02:06:16 Adam_Page has joined #css 02:06:27 dbaron: what we talked about before was conditional rules, conditional on where you're going to or from. we have a spec draft for that 02:06:37 https://wicg.github.io/declarative-partial-updates/css-route-matching 02:06:40 dbaron: Morten has prototyped a bunch of this in chromium 02:06:47 saku has joined #css 02:06:48 dbaron: not sure exactly how in sync the prototype and spec are right now 02:07:06 dbaron: another piece we'd like to add to this is the ability to have pseudo-classes for links that are related to the nav 02:07:07 berlysia has joined #css 02:07:25 dbaron: hopefully will have a proposal soon, been back and forth in discussion. more complicated than I thought at first 02:07:53 https://wicg.github.io/declarative-partial-updates/css-route-matching/ 02:07:53 dbaron: we'd previous talked about this "route map syntax" in HTML, for now we've taken it out 02:08:02 dbaron: but fo rnow we're prototyping b y putting URLs into the css 02:08:11 dbaron: a function represented URL patterns (based on WHATWG spec) 02:08:40 dbaron: what I'd like to get to is getting the group to adopt the draft. there might be qs about where to put it 02:08:53 q+ 02:08:54 q? 02:08:57 ack noamr 02:09:05 noamr: wanted to quote something from a VT user 02:09:10 present+ 02:09:28 noamr: "trying to replace the default cross-fade with directional animations, doing without JS right now is like driving without turn signals" 02:09:41 noamr: today a lot of people are just cross fading, or otherwise not doing something that gives orietnation 02:09:48 noamr: because they'd need JS to actually do it 02:09:50 Maybe less "driving without turn signals" and more "driving without a steering wheel"... 02:10:05 q+ 02:10:07 q+ 02:10:12 noamr: we didn't want to discuss all the open issues here, just want to check that this is a valid use-case and we're going in the right direction 02:10:20 noamr: to adopt the draft as ED and continue form there 02:10:31 astearns: 1, why isn't the JS solution sufficient? 02:10:46 noamr: two reasons. first, this is a styling decision. CSS VT is a styling feature. 02:11:06 noamr: second, perf wise, we're trying to avoid event-driven JS when we can, especially in perf-sensitive places like first paint after navigation 02:11:07 qq+ to comment further on JS 02:11:20 noamr: using JS, now we have to run script before we can show anything. if we can set it tup in advance in CSS, no need for that 02:11:24 noamr: it's also just kinda hard 02:11:34 ack astearns 02:11:37 astearns: I just wonder if we want to wait on more author patterns 02:11:51 noamr: we've already done that, VTs have been out for two years. this *is* the author feedback about the lack. 02:11:59 karlcow_ has joined #css 02:12:21 astearns: my other q was about URL patterns, but your draft answers that 02:12:24 ack kbabbitt 02:12:24 kbabbitt, you wanted to react to noamr to comment further on JS 02:12:29 q+ 02:12:34 kbabbitt: about JS, less that JS isn't sufficient, it's that the more we can move into the engine the better 02:12:44 kbabbitt: some of our perf teams are trying to rip out as much JS as possible 02:12:47 ack lea 02:13:00 lea: I think this is a problem worth solving, authors always talk about how hard routing is 02:13:14 lea: could imagine conditionals in HTML based on the route, use-cases in JS based on the route, etc 02:13:36 lea: tho it seems you don't want the indirection of naming your route. simple cases you just want to match a single route. then complex cases with lots of routes that you want to use names 02:13:46 q+ 02:13:46 lea: so it seems useful to have both, names and anonymous 02:13:59 q+ 02:14:14 lea: since there are use-cases for both, and naming global routes needs coord across the platform, might be useful to do anonymous matching in CSS and then solve route-naming on top 02:14:27 lea: also, someone mentioned @document before, would be interesting to see lessons 02:14:39 ack JakeA 02:14:52 JakeA: @document would have predated URLPattern 02:15:35 qq+ I didn't get to my comment 02:15:36 emilio: it's not particularly complicated to implement, matching a URL can be expensive, but... 02:15:42 qq+ 02:15:44 emilio: I think it just never got enough adoption 02:15:49 (I didn't get to my comment) 02:15:51 emilio: I removed it because it was causing some compat pain 02:16:02 emilio: we still support @moz-document with an empty URL, it detects Gecko 02:16:19 dbaron: the original motivation was for user stylesheets 02:16:39 q- 02:16:50 lea: URLPattern in JS has the nice feature where you can extract features form the URL. down the line, might be useful to think about designing to match parameters and use them 02:17:02 lea: could solve other problems, like SVG Params spec 02:17:52 dbaron: we were actually looking at using URL patterns Params for the pseudo-classes. part of the complicated thing is exactly what to do there, there's multiple things to match between, hard to make ergonomic in CSS. 02:17:56 joone has joined #css 02:18:01 s/you can extract features form the URL/you can extract params form the URL/ 02:18:03 dbaron: part of the reason this isn't ready yet is because I want to figure out the param stuff 02:18:23 dbaron: also doing patterns now and route maps later is already what we're thinking 02:18:29 JakeA: general support 02:18:31 +1 to separating urlpattern() 02:18:41 JakeA: perf, relative to a navigation probably not a huge issue to run a little JS 02:19:00 JakeA: but wrt back/forward navs, if the Vt has any directionality you want to change if it's a back navigation 02:19:07 JakeA: so yes, important to have that doable at a high level 02:19:11 ack JakeA 02:19:11 JakeA, you wanted to react to JakeA 02:19:19 ack fantasai 02:19:19 fantasai, you wanted to ask about integration with navigation 02:19:33 fantasai: I think the draft could use some examples, took a while to figure out what was happening 02:19:44 fantasai: I think overall this looks like a reasonable design for the idea 02:20:01 q+ 02:20:03 fantasai: one thing that through me off was the at-rule being @route, it doesn't declare a route it declares a condition based on the current navigation state of the doc 02:20:17 fantasai: so my suggestion is to use @navigation instead, and use @route in the future as the named routing feature 02:20:20 q? 02:20:41 fantasai: that would also let you have :route() pseudo matching up 02:20:59 fantasai: once I figured out that term confusion it made a lot more sense 02:21:11 JakeA: how would that be different from @document if it supported URLPattern? 02:21:20 q- 02:21:24 fantasai: @document is the current doc, right? but this condition might be the current doc or the active nav 02:21:34 JakeA: I meant about @route 02:21:38 this is a bit like masonry: route is the term of art, but to those not yet inducted into all this it seems very confusing. I still remember how confused I was when I first heard about routes. 02:21:38 fantasai: that's for declaring a named route 02:21:59 fantasai: can later do @navigation route(foo) {...} 02:22:04 route also sounds like root (depending on the speaker) 02:22:23 fantasai: [goes over her :route example again] 02:22:24 `@navigation` sounds like it's about going somewhere, rather than about where you _are_ 02:22:38 q+ 02:22:39 It's about the current state of navigation 02:22:56 So yeah, it *is* about going somewhere 02:23:07 wendyreid: this also means we can do reduced-motion response, people can turn them off easily if they're in CSS 02:23:16 fantasai: that would turn off on the VT side, you can already do that 02:23:27 ack wendyreid 02:23:28 can the common case of back navigation being a reverse of the prior view transition, be a single easy opt in instead of needing to intercept or @route declare the intent which plays keyframes in reverse? seems like something like this could work: 02:23:28 @view-transition { 02:23:28 navigation: auto; 02:23:28 backwards: reverse; 02:23:29 } 02:23:30 ack noamr 02:23:53 ack lea 02:23:54 noamr: I think we had this discussion internally about naming. "route" was a bit of a relic, coming from the HTML history. so this reflects our internal convo 02:24:18 lea: echoing from IRC, agree with changing "route". "route" is a term of art, but people not already familiar with it find it weird/confusing 02:24:28 lea: I was very confused when I first started learning about this 02:24:41 lea: but I also find navigation a bit confusing, sounds like it's about going somewhere or coming from somewhere 02:24:45 q+ 02:24:47 lea: rather than where you currently are 02:24:54 route mapping json seems quite similar w/ speculation rules. 02:24:54 https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API 02:24:56 q+ 02:25:02 lea: Elika said it *is* about coming from somewhere, but I thought this was most about where you are 02:25:10 dbaron: the current proposal has both 02:25:25 ack Jxck 02:25:27 dbaron: the thing we're probably focused on more is the "where are you going", not "where you are", but it can do both 02:25:28 ack JakeA 02:25:29 mjackson has joined #css 02:25:36 JakeA: these rules apply during same-doc navigations too, right/ 02:25:38 noamr: yes 02:25:47 lea: and the rule can be used for other things than VT 02:26:02 ack noamr 02:26:15 noamr: scoping back to what do we need to do to get this into an ED 02:26:26 noamr: we're not trying to figure out these issues today 02:26:35 ack fantasai 02:26:35 JakeA: examples 02:26:37 fantasai: yes 02:26:41 fantasai: add examples, put in ED 02:26:45 +1 fantasai 02:26:52 @navigation (at: urlpattern) { 02:26:52 styles that apply to a page at urlpattern 02:26:52 } 02:26:52 @navigation (from: urlpattern1) and (to: urlpattern2) { 02:26:53 styles that apply when you are navigating from urlpattern1 to urlpattern2 02:26:55 } 02:26:57 @navigation (route: --foo) { 02:27:00 styles that apply when navigation state is --foo 02:27:02 } 02:27:04 q+ 02:27:05 @route --foo { 02:27:07 from: urlpattern3; 02:27:10 to: urlpattern4; 02:27:12 } 02:27:15 a:route(--foo) { 02:27:17 styles for link that go from urlpattern3 to urlpattern4 02:27:20 } 02:27:22 a:route-to(urlpattern) { 02:27:25 styles for link that go to urlpattern 02:27:27 } 02:27:58 JakeA: what's the lifetime of the @navigation rule? especially with a from() 02:28:00 ack JakeA 02:28:05 noamr: directly tied to Navigation API concepts 02:28:17 noamr: navigation.transition have "from" and "to", it's tied to that 02:28:23 JakeA: that doesn't work for cross-document 02:28:36 noamr: I have a proposal to fix that 02:28:46 noamr: the "from" and "to" starts at the navigate event, "to" changes at redirect and swap 02:28:56 noamr: and in the next document, the "to" is only until the first frame 02:29:02 JakeA: makes sense 02:29:04 kush has joined #css 02:29:25 noamr: first frame + view transition 02:29:53 astearns: so details like that in the draft, examples 02:30:57 noamr: so suggesting css-navigation for the ED name 02:31:11 astearns: any objections to doing an ED yet? 02:31:21 q+ 02:31:28 astearns: proposed to start an ED for css-navigation 02:31:40 JakeA: I think most important part of this is back vs forward, that's not part of this yet, right? 02:31:44 noamr: not at the moment 02:31:47 JakeA: okay I think it should be 02:32:45 JakeA: [summarizes what he meant again] 02:33:38 RESOLVED: Start a css-navigation ED 02:34:14 dbaron: https://simple-vt-demos.jakearchibald.com/directional-transition/ - this transition moves differently if you use the back button. I think this is a really common case 02:34:36 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12324 02:34:36 Topic: [css-view-transitions-2] [scoped] What is the layout of the ::v-t pseudo in relation to the scope? 02:34:36 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12324. 02:34:57 vmpstr: in scoped VT, reminder it's about VT running on subtrees, not just the document 02:35:22 vmpstr: setup is roughly the same, you just start the transition on an element, discover names in the subtree, create VT pseudos representing the transitioning parts of the subtree 02:35:40 vmpstr: for document VT we hoist the VT pseudos to the top layer so it can capture the document itself, too, and represent that in its pseudos 02:36:04 vmpstr: so we need an equivalent thing for elements. pseudos should be able to capture the hosting element's decorations/background/etc. can't be a child without it being circular 02:36:17 q+ 02:36:21 vmpstr: so our idea is to have ::v-t pseudo-element be a next-sibling of the VT scope element 02:36:30 vmpstr: and then use anchor positioning to put it over top of the scope 02:36:45 vmpstr: this works pretty well for a lot of cases 02:36:49 vmpstr: one case where it doesn't 02:36:59 vmpstr: if the scope element is rotated or not axis aligned 02:37:05 q+ 02:37:14 vmpstr: anchor spec says the anchor box is the axis-aligned bounding box of the anchor 02:37:18 q- 02:37:22 joone has joined #css 02:37:36 vmpstr: there's a workaround, selfishly hoping the anchor spec can eventually allow positioned elements to be in the same positioned space as the anchor 02:37:48 q+ 02:37:50 vmpstr: so we'd like to go ahead with the current design of it being the next sibling, and just positioning it over 02:37:58 ack ntim 02:38:03 ntim: from an impl pov, a bit worried about making the pseudo a sibling 02:38:13 ntim: might have implications in the Dom tree, sounds tricks 02:38:22 noamr: it's just in the layout tree, the box tree 02:39:41 q+ 02:39:45 q- 02:39:48 q++ 02:39:50 noamr: reproducing the doc VT case where the VT is in the top layer, a "sibling" to the doc 02:39:59 ack + 02:40:04 emilio: is the idea that we don't want this in the top layer? we want it clipped by ancestors? 02:40:07 TabAtkins: yes, absolutely 02:40:22 JakeA: yes, in Shopify days we couldn't use VT in some cases because they wanted a VT on just a small piece of the page. 02:40:51 JakeA: they used VT:none on root to prevent that from animating, but then if they had a tooltip on top it would drop below the top-layer VT stuff, so they made *it* VT as well, whack-a-mole 02:40:52 astearns: doh, hah! 02:41:20 q- 02:41:22 emilio: if you have something in-flow, and you put something out of flow on top of it, that doesn't quite match the in-flow painting order. 02:41:39 emilio: it's painted by the abspos's CB, might be higher up 02:42:08 q? 02:42:10 q+ 02:42:12 TabAtkins: We've had some cases where we want to make it easier to select other containing blocks 02:42:15 TabAtkins: we want to make it easier to select other containing blocks, e.g. your parent 02:42:16 ... in particular, your parent 02:42:48 emilio: let's say you have a thing with overflow: clip and animating something inside of it. now you call startViewTransition on that. you effectively created an abs-pos on top. it would escape the clip 02:43:02 joone3 has joined #css 02:43:26 emilio: clips of any ancestor from the scoped element to the nearest abs-pos 02:43:35 TabAtkins: we want to enable it in the future 02:43:41 emilio: sounds like it's a bit in the air 02:43:44 Adam_Page has joined #css 02:43:59 ack emilio 02:44:04 ack fantasai 02:44:04 fantasai, you wanted to comment on containing blocks 02:44:12 fantasai: I don't think anchorpos is the right solution for this 02:44:18 fantasai: you really do want to change the CB to this element. not by pos:rel, that is disruptive 02:44:22 q+ 02:44:27 fantasai: but we should have some way to say that the scope is the CB for that 02:44:34 https://www.w3.org/TR/css-position-4/#scrollable-cb 02:44:53 fantasai: some points to talk about why not do that. scorlling is one. we recently talked about three CBs generated by a scroller, one is the fixed CB, that's what you want 02:45:06 fantasai: so there are plans to add switches for that, should rely on that 02:45:27 fantasai: for the transform case, when you're contained by the transformed element you're in it so you're transformed with ti 02:45:46 vmpstr: the problem here isn't so much positioning, as trying to capture the effects on the scope itself 02:46:07 q+ 02:46:14 vmpstr: like a filter on the scope, the pixels you capture from that filter have to go into the VT pseudo-element. if that pseudo is also a child of the filter, then you're double-filtered 02:46:23 vmpstr: or circular if you want to prevent that 02:46:31 not being filtered by the element, not being clipped by the element, etc 02:46:39 vmpstr: so it's less positioning, more about not being in the same filter tree/effect tree as the scope 02:46:47 ack ntim 02:46:51 ntim: back to DOM mutations 02:47:04 ntim: say you move the scope element elsewhere in the tree. do you track the pseudo and move it at the same time? 02:47:10 ntim: otherwise you get z-order issues 02:47:51 TabAtkins: moving is a remove/add, so you cancel everything 02:48:01 JakeA: no, new method just moves it directly 02:48:05 ack flackr 02:48:13 noamr: just need to make sure that's an issue we track 02:48:21 ack emilio 02:48:30 flackr: yeah, confirming that this can't be a box child so we don't clip/filter it 02:48:42 q+ 02:48:50 emilio: I wonder, if you make this API parallel to the doc version, the doc version isn't in the doc itself, but the contents of the document 02:48:52 kush has joined #css 02:48:56 [not sure what that means or if I minuted it right] 02:48:59 present+ 02:49:26 emilio: instead of capturing the whole scope, you capture just the contents of the element, then the issue goes away 02:49:36 JakeA: my first draft did that, people just end up creating a wrapper div 02:50:12 vmpstr: we did consider that, but a very common use-case people do is "run on a div, change its background". but that won't work, background is part of the element itself not its contents 02:50:25 vmpstr: so we're really trying to make it so the scope itself is represented 02:51:00 q+ 02:51:08 emilio: I wonder if we could define, rather than a sibling, it's a regular child but define special painting/capturing rules, in a VT the stacking context your box creates is in one place... 02:51:35 emilio: so the pseudo isn't a sibling in the box tree, but in the stacking context sense. one order that's for capturing VT, another for actual rendering 02:51:44 emilio: that solves layout issues, unsure if it adds more complications 02:51:56 emilio: but this is similar to what you do for the doc transition to capture the canvas background/etc 02:52:03 vmpstr: i'm not opposed to that, it's just more magic 02:52:23 vmpstr: it's more *explainable* with anchorpos, while this is pure magic. but I'm fine with that 02:52:39 noamr: initially this was my mental model, an anonymous container that holds the element and the VT pseudos 02:53:14 emilio: yeah, same way you can define the order in which stacking contexts are applied, you can define filter/transform/opacity, etc in a particular order to be correct. can define VT at a particular spot so it's outside the filters but within the element still. 02:53:23 noamr: only thing is it's less explainable in CSS terms 02:53:51 emilio: but still the same as the doc VT, yeah? doc transitions capture the canvas background, that's outside the document element. so I think this matches doc VT more closely. 02:53:59 emilio: if it makes the whole setup simpler should just do it 02:54:14 vmpstr: difficult part would just be describing transforms/etc. doc is affected by less than elements are. 02:54:19 emilio: sure 02:54:25 vmpstr: I think it's doable, just a little awkward 02:54:34 emilio: do you know off top of you head if transform is before or after filters? 02:55:23 emilio: [goes into a little more detail] 02:55:34 emilio: I find that model a bit easier, or more parallel to doc VTs 02:55:38 fantasai: makes sense to me 02:56:05 emilio: like if you apply filter to root, it doesn't just apply to root it applies to whole doc. but doc VT escapes that. 02:56:27 vmpstr: I also need to think through how the VT pseudos can be styled 02:57:05 emilio: same as in doc VT, the pseudo isn't affected by the VT styles 02:57:17 q- 02:57:22 JakeA: btw, it's filter *then* transform 02:57:38 q- 02:57:39 emilio: so yeah that works, transform is applied on top after the VT is already positioned, so it follows along 02:57:49 +1 that sounds like it could work 02:58:01 +1 02:58:16 astearns: so sounds like a different route. Vlad, do you want to explore implication in the issue, or just take a resolution? 02:58:26 vmpstr: might as well resolve, if we have issues we'll bring it back 02:59:07 vmpstr: resolution is to make the VT have a stacking context that's a sibling of the scope stacking context, but painted at a point before transforms/filters. Still a child of the box tree. 03:00:24 emilio: should we enforce the scope to be a CB for abspos? if you start a VT on a staticpos, the insets wont' work 03:00:24 q+ 03:00:32 noamr: it's layout-contained, that already makes it a CB 03:01:22 kush: I was trying to understand - if it's a sibling in the box tree... sorry, a child, but it's painting involves all the content besides itself 03:01:27 kush: does it get the local clips? 03:01:36 emilio: probably not. ancestor clips apply, but on the element itself won't 03:01:39 it should only be affected by the transform of the element 03:02:26 emilio: it'll be a painting layer defined, 03:02:49 kush: q is just if we make it a child of the scope, how many things that are inherited from the scope will have to be handled special 03:03:08 emilio: fair, but all those special things are what you want 03:03:31 kush: right, but we got all those special things for free by making it a sibling, they're manual now that it's a child 03:03:45 emilio: but many other things are easier as a child 03:03:56 vmpstr: what I think we really want is the scope to be the child of the VT 03:04:01 vmpstr: but that's... complicated 03:04:22 astearns: we're at time. should we not resolve yet? 03:04:32 kush: taking resolution seems fine for now, curious about what we'll learn impl wise 03:05:10 kush: i'm on the same side as Emilio, argued for that in my head, but other than moving the pseudo alongside the element, what am I gaining by the child approach rather than sibling? 03:05:51 emilio: you also get abspos CB for free, rather than it escaping all the clips up to its actual abspos CB 03:05:59 +1 03:06:20 astearns: this is details. back to the question. objections to the proposed resolution? 03:06:26 karlcow_ has joined #css 03:06:42 RESOLVED: make the VT have a stacking context that's a sibling of the scope stacking context, but painted at a point before transforms/filters. Still a child of the scope. 03:06:57 Topic: [css-multicol-2] column-height:0 03:07:22 rachelandrew: Noam asked if column-height:0 is allowed. 03:07:31 rachelandrew: not really a reason. Grid floors at 1px 03:07:41 rachelandrew: so probably what we want to do too 03:07:43 q+ 03:07:54 florian: agree. 03:07:59 ack kush 03:08:03 ack florian 03:08:10 florian: so there's no restriction at syntax level, but floor at layout time 03:08:28 q+ 03:08:38 q+ 03:08:38 TabAtkins: We do syntax restrictions all the time, could do 1px+ range which would still be closed range 03:08:44 ack dholbert 03:08:46 There's a precedent for this with the perspective property and perspective() function. 03:09:05 dholbert: I weakly like having column-ehight:0 available for testing, useful for test printing 03:09:13 dholbert: can end up with printing with zero content area 03:09:20 dholbert: we make progress by putting *something* on the page 03:09:35 https://www.w3.org/TR/css-break-4/#breaking-rules 03:09:40 "To guarantee progress, fragmentainers are assumed to have a minimum block size of 1px regardless of their used size." 03:09:55 dholbert: so like *supporting* height:0 03:10:01 ack ntim 03:10:20 ntim: if the restriction is at syntax level, what about calc()? 03:10:38 TabAtkins: Same as we handle 0px today 03:10:40 q+ 03:10:42 TabAtkins: clamp at used value tie 03:10:43 ack fantasai 03:11:03 fantasai: we already have a rule that says fragmentatiners are assumed to have a min block size of 0px, regardless of used height 03:11:15 fantasai: we already have this case if the Multicol container itself has height:0px 03:11:23 fantasai: but each column will assume it's 1px high 03:11:43 fantasai: so we can do this clamp whenever. computed time, used time, or not at all and rely on the fragmentainer always laying out 1px of ontent 03:12:16 s/fragmentatiners are assumed to have a min block size of 0px/fragmentatiners are assumed to have a min block size of 1px/ 03:12:40 astearns: I have concerns with relying on fragmentation module, there are layout concerns that aren't necessarily fragmentation concerns 03:12:48 astearns: i'd rather have things clamped before we start layout 03:12:55 q? 03:12:55 q+ 03:12:59 ack emilio 03:13:17 emilio: we'll have to clamp at used-value anyway, is there any benefit to restricting at syntax time? 03:13:23 emilio: if not i'd prefer to handle it at layout time 03:13:49 fantasai: I think key question is just whether the layout height is 1px, or just the fragmentation height? 03:13:54 florian: I think layout height. 03:14:09 s/min block size of 0px/min block size of 1px/ 03:14:20 florian: even if there's overlap, you can at least see progress 03:14:38 plinss: want to agree with Elika/Emilio, handle it at layout time rather than syntax time 03:15:10 TabAtkins: We have lots of 0px restrictions, it's well-defined 03:15:16 q? 03:15:30 astearns: so clamping to 1px at used-value time? 03:15:30 ack plinss 03:15:31 fantasai: yes 03:15:54 +1 to what plinss said 03:16:05 plinss: I think used-value time is even too early. let it be zero, require progress 03:16:09 +1 to what plinss said 03:16:28 +1 to what dholbert said about what plinss said 03:17:29 fantasai: proposed resolution: allow to be zero, let fragmentation spec ensure progress 03:17:34 astearns: I disagree but won't object 03:17:37 florian: same 03:17:45 plinss: I think that's the right concept 03:18:07 florian: can we poll? we agree it's not syntax time, want to see what our actual pref is 03:18:56 RESOLVED: allow to be zero, let fragmentation spec ensure progress 03:19:07 Topic: [css-multicol-2] `column-wrap`, `column-height` and column balancing 03:19:13 https://github.com/w3c/csswg-drafts/issues/11976#issuecomment-3227424707 03:19:20 rachelandrew: this is about this particular comment, not rest of issue thread 03:19:43 rachelandrew: we resolved, if there's not enough content to fill a column-height, you'll still get the specified height 03:20:06 rachelandrew: Morten points out that this can disable column balancing, if you've got all the height you can put all content in the first column 03:20:13 rachelandrew: think this isnt' what we want 03:20:53 rachelandrew: but it would mimic what happens in normal Multicol; if you've got more space you can still balance 03:21:20 florian: did you suggest that the row stretches to fill the space but the line wouldn't? 03:21:46 rachelandrew: we've got the columns themselves, then the content inside. if you stretch both it disables balancing effectively 03:21:49 rachelandrew: we dont' want that 03:22:32 rachelandrew: I think what we want here is MOrten's Option B 03:22:43 ack fantasai 03:23:27 fantasai: if you run out of space before a spanner... never mind 03:23:38 astearns: objection to going with option b? 03:24:03 florian: there's lots of details in the issue, it's subtle. *if we assume* that what's discussed here in the room is sufficient, then I agree with B. 03:24:13 astearns: If there's re implications we missed, Morten will bring them up 03:24:30 RESOLVED: go with option B (balancing still works) 03:24:46 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12632 03:24:46 Topic: [css-multicol] Clarify the section on Pagination and Overflow Outside Multicol Containers 03:24:46 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12632. 03:25:09 rachelandrew: we've made various resolutions, i'm having to make all the rest of the text makes sense now that we have column rows 03:25:20 q? 03:25:23 rachelandrew: I've written in the issue what's there at the moment and what i'm suggesting 03:25:34 rachelandrew: this is a change in normative text, so getting verified 03:25:48 florian: looks right. we're generalizing the concept, so things need generalization. looks good 03:25:54 JRJurman has joined #css 03:26:18 fantasai: needs better lienbreaks, but otherwise looks good 03:26:45 mjackson has joined #css 03:26:52 proposed resolution: accept Rachel's text/direction 03:26:57 RESOLVED: accept Rachel's text/direction 03:35:48 mjackson has joined #css 03:39:01 Penny has joined #css 03:45:47 nigel has joined #css 03:46:18 nigel has joined #css 04:05:12 topic: lunch 04:05:42 nigel has joined #css 04:07:00 mjackson has joined #css 04:22:19 nigel has joined #css 04:30:08 karlcow has joined #css 04:37:46 bts has joined #css 04:37:57 present+ 04:40:01 bts has joined #css 04:41:34 nigel has joined #css 04:54:14 alisonmaher has joined #css 04:55:16 sakhapov has joined #css 04:56:37 kbabbitt has joined #css 04:59:31 ydaniv has joined #css 04:59:43 tantek has joined #css 05:02:37 scribe+ 05:02:39 Euclid has joined #css 05:02:43 +present 05:02:46 berlysia has joined #css 05:02:52 present+ 05:02:56 sorvell9 has joined #css 05:03:03 nicolo-ribaudo: source maps, does anyone here know what it is? 05:03:07 github: https://github.com/w3c/csswg-drafts/issues/13098 05:03:14 ... recap, mostly for JS but also now for HTML 05:03:31 ... you write some code and then go through build tools 05:03:43 saku has joined #css 05:03:48 diekus has joined #css 05:04:14 JRJurman has joined #css 05:04:32 present+ 05:05:04 zcorpan has joined #css 05:05:14 ... more and more the code you write is now what ends up in the browser 05:05:14 present+ 05:05:26 ... source maps have been around for some time now 05:05:36 ... they are instructions for build tools 05:05:42 s/write is now what/write is not what/ 05:05:53 ... to make sure the code in browser looks like what you wrote in editor 05:06:15 ... there's partial description in a google doc of what it does 05:06:34 ... in ECMA we started defining it, and talking with browser dev teams 05:06:41 ... where is it still problematic 05:06:50 ... evolving the idea 05:07:05 ... maybe you're using SASS or others and they do create source maps 05:07:16 ... we should also try to focus on what can be done in CSS 05:07:25 ... is ti just for build tools? 05:08:05 ... what can we do more for CSS? ... 05:08:19 ... one is nesting, that may be transpiled 05:08:32 ... there are other bunch of build tools features that transpile 05:08:53 ... I'm preseting this here because I think this transpiling may be confusing for authors 05:08:54 the namespacing we just talked about might also be a use case 05:09:01 ... could be great if we could work this out together 05:09:17 ... find if we have dev experience issues 05:09:21 q+ 05:09:35 ack kizu 05:09:36 ... if ppl have opinions 05:09:41 kizu: would be great to have 05:09:54 ... a lot of it is not actually CSS, like comments etc. 05:10:13 ... the source for things in CSS may not be just CSS itself, may come from JSON or JS 05:10:29 ... [examples] 05:10:45 ... also may come from [missed] 05:11:08 nicolo-ribaudo: it's something you can do with source maps ideally 05:11:32 TabAtkins: you mentioned some features, like nesting 05:11:54 ... it's not only transpiling things that can't be, it may be also things from JS, 05:11:59 q+ 05:12:08 ... also there's a lot of source transforms that can't be done 05:12:22 nicolo-ribaudo: to be clear, there's no one with CSS experience 05:12:31 ... so happy to see others for helping out 05:12:33 ack miriam 05:12:49 miriam: because transpiling is in external tools, would be nice to reach out for those tool makers 05:13:29 kizu: tailwind is intreresting, the source is in CSS but tranforms to HTML 05:13:46 nicolo-ribaudo: if you want to see the slides we have contact info there 05:13:49 ... thanks! 05:14:03 q+ 05:14:15 ack emilio 05:14:16 present+ 05:14:44 emilio: you have comment syntax there, is that what would be strandardised? 05:14:46 nicolo-ribaudo: yes 05:14:58 ... there are ppl from FF dev tools on there 05:15:06 astearns: thank you, moving on 05:15:16 present+ 05:15:32 topic: https://github.com/w3c/csswg-drafts/issues/12803 05:15:36 github: https://github.com/w3c/csswg-drafts/issues/12803 05:16:09 fantasai: going back to item flow discussions we had previously 05:16:14 dmangal has joined #css 05:16:17 ... there's been discussion on what the syntax should be 05:16:24 present+ 05:16:33 ... TabAtkins and iank_ said we should not go with what grid does 05:16:47 ... this is blocking impl. work 05:16:57 ... we still need to decide what longhand do 05:17:08 ... we need to underline longhands 05:17:21 s/underline/underlying/ 05:17:26 ... we need to resolve on what they are? what the values are? and shorthands later 05:17:38 ... we have a proposal with counter arguments 05:18:39 ... we have to decide are using grid properties, or minting new ones 05:18:57 ... what are those properties? what are the values? and what they're mapped to? 05:19:08 ... also discussed about "auto" 05:19:26 TabAtkins: I'll present while reusing grid-auto-flow is not correct 05:19:37 ... if you want waterfall layout [missed] 05:19:53 s/waterfall/grid-lane/ 05:20:43 I think 'waterfall' in this case refers specifically to vertical grid-lanes 05:20:48 yes 05:21:03 Steven has joined #css 05:21:04 TabAtkins: to avoid confusion we've referred to waterfall and brick 05:21:28 ... if you have a waterfall layout you have columns, that's also the initial value because it's the most common initial value for grid-lanes 05:21:29 q+ 05:21:38 ... grid-auto-flow initial value is row 05:21:44 ... so we'd need to magic up a new initial value 05:21:48 fantasai: which we planned to do anyways 05:21:50 TabAtkins: not for grid 05:22:07 ... secondly grid-auto-flow, row vs row-reverse, they change whether items autoflow ltr or rtl 05:22:32 ... in grid-lanes a lot of people have the intuition that the primary direction should be the direction where they break ties 05:22:40 ... you'd start rtl again even with a column layout 05:22:48 s/discussed about "auto"/discussed about "auto" initial value for the flow direction, to automatically decide based on the -template properties; but this needs to be renamed (maybe to normal) to avoid conflicts in grid shorthand with 'auto' track sizing/ 05:22:53 ... so if we reuse grid-auto-flow, row-reverse would mean a different thing than in grid-lanes 05:22:58 ... would mean perpendicular axis 05:23:08 Euclid has joined #css 05:23:10 ... because you want columns to be ltr columns and column-reverse to be rtl 05:23:18 ... in grid your default is row / row-reverse 05:23:28 ... if you say column that means top to bottom or bottom to top 05:23:40 almost makes you think we should call it the same thing as in grid… 05:23:43 Adam_Page has joined #css 05:23:47 ... this is due to the distinction between flow direction and track direction. In flexbox and grid they are aligned in masonry they are opposite 05:24:08 q+ 05:24:13 ... so reusing the same terms that mean track / direction in grid but giving the keywords a perpendicular meaning doesn't seem good to learning how these work 05:24:21 q+ 05:24:24 ... it might be if waterfall layout was rows 05:24:27 ... but it's not 05:24:31 ... so we should mint a new property 05:24:38 ... grid-lanes specifically 05:24:50 q? 05:25:01 ... so I think we should do that instead of changing the meaning of specific values in grid-lanes masonry 05:25:04 Euclid has joined #css 05:25:16 astearns: this felt two introductions about two different topics 05:25:22 gorohash has joined #css 05:25:27 ... let's go through the queue and see if we can get some clarity 05:25:33 ack florian 05:25:45 florian: my initial impression was a bit similar to tab in the sense of of course waterfall should be column 05:25:54 ... but looking at it I don't think we're calling it anything 05:26:01 ... we're controlling aspects of the design 05:26:11 ... so sure if you look at it I see columns 05:26:37 ... but even then depending on the property I'm comfortable saying that the flow of the items in a waterfally grid-lane goes by row 05:26:41 ... and that seems fine to me 05:27:06 TabAtkins: if the thing that determines the direction uses rows for masonry which uses grid-template-columns etc for everything 05:27:11 ... I'd formally object to that 05:27:20 florian: just saying that I don't have the same opinion 05:27:30 I agree with Tab it would be super confusing 05:27:32 TabAtkins: I'd formally object to that 05:27:35 ack ntim 05:27:37 ntim: re. flow vs track 05:27:53 s/just saying that I don't have the same opinion/just saying that I used to have the same opinion, but no longer to 05:27:56 ... I think that track direction doesn't really matter, ATs what you experience is the flow direction not track direction 05:28:02 s/longer to/longer do 05:28:36 ... if you really care about track and ?? then you use multicol 05:29:12 ... I'd probably object if we were to consider the track direction was the primary one 05:29:32 ack miriam 05:29:43 miriam: Thanks for not taking into account our opinions 05:29:46 Euclid has joined #css 05:29:55 ... you wanted us to follow up, we did, we disagree with you and now it's a formal objection situation 05:30:04 ... have no power in that situation, that's cool, have fun with it 05:30:22 astearns: I'm with you in the frustration but you can formally object as a member of this group 05:30:38 fantasai: you don't even need to be a member, anyone can literally formally object 05:30:43 ack fantasai 05:30:46 ... I want to present my position and counter proposal 05:30:48 saku has joined #css 05:30:57 ... we think that keeping the properties consistent with grid is better 05:31:26 ... therefore we should use grid-auto-flow, and interpret the values in the same way 05:31:44 ... if you switch display the overall layout would flow in the same direction 05:31:52 ... TabAtkins mentioned that he wants a shorthand 05:31:59 ... and if you write row 200px 05:32:14 grid-lanes: row 100px 200px; 05:32:14 grid-template-columns: 100px 200px; 05:32:19 ... which would be confusing 05:32:26 grid-auto-flow: row; 05:32:35 ... I have several suggestions 05:32:48 ... first one is we've discussed grid-auto-flow initial value would be normal 05:33:01 ... and depending on grid-template-rows/columns we'd pick the correct flow direction 05:33:24 ... whichever one is none picks the flow direction 05:33:50 ... now grid-lanes sets grid-template-{rwos,columns,areas} and grid-auto-flow, ... either to the initial value or something else 05:34:06 ... I suggest changing grid-lanes to instead of `row` being a grid-auto-flow 05:34:15 ... value, we'd change it to `rows` 05:34:25 ... and then set grid-template-rows 05:34:37 my point is and has been that *this* would be a terrible mistake that I can't allow as editor of the spec: 05:34:37 05:34:37 .waterfall { 05:34:37 display: grid-lanes; 05:34:37 grid-template-columns: 100px auto; 05:34:37 column-gap: 1em; 05:34:37 column-rule: thin solid silver; 05:34:38 grid-auto-flow: ROW????!?!? 05:34:38 } 05:34:45 grid-lanes: rows 100px 200px; 05:34:46 grid-template-rows: 100px 200px; 05:34:46 grid-template-columns: none; 05:34:46 grid-auto-flow: normal; 05:35:08 fantasai: I think that resolves the biggest syntactical problem 05:35:24 ... instead of saying what the auto-flow value is, it decides which template prop we set 05:35:32 q+ 05:35:33 ... the shorthand also becomes useful for grid layout 05:35:50 astearns: Is that proposal in the issue? 05:35:56 fantasai: thought of it a bit too late 05:36:03 astearns: we should've deferred this then 05:36:16 Steven has joined #css 05:36:18 ... to give people some time to look at it 05:36:27 fantasai: last part is what about grid-auto-flow 05:36:38 ... currently it takes {row, column, dense} 05:36:51 ... recently we introduced reverse-* 05:36:53 Steven has joined #css 05:37:00 [ row | column ] || dense 05:37:01 ... we think we should have a consistent interpretation 05:37:16 ... I think most people don't need this property on masonry except if you're doing reversing 05:37:31 s/masonry/grid-lanes/ 05:37:35 ... we have row-reverse | column-reverse || wrap-reverse 05:37:52 ... so that's confusing, but also the interpretation of row and columns is confusing 05:38:13 ... so I think it'd be clearer if we named the keywords as primary-direction followed by secondary 05:38:21 ... so grid-auto-flow: row-column | column-row 05:38:45 ... so you can do [row | row-reverse] || [column | column-reverse] 05:38:48 q? 05:38:51 q+ 05:38:56 ... so I think that might be a bit more straight-forward 05:38:56 zakim, close queue 05:38:56 ok, astearns, the speaker queue is closed 05:39:30 +1 for reusing `grid-auto-flow` 05:39:40 ... altogether, main point I want to put forward is that grid-lanes should have a keyword representing the suffix of the template property 05:39:50 ... and we should reuse grid-auto-flow matching grid 05:40:07 ... I think that addresses most of the key points on both sides of the argument 05:40:12 q? 05:40:17 what is primary vs secondary? 05:40:18 For the part with primary direction followed by secondary direction, I'm a bit uneasy that folks will forget what primary/secondary are here (similar to how waterfall is sort-of rows but nobody thinks of it like that) 05:40:19 ack alisonmaher 05:40:24 alisonmaher: +1 to alan, would be useful to see this in the issue 05:40:37 ... I think it's a promising direction 05:40:45 ... but there are a few side effects 05:40:49 yeah, this entire idea is new to me, and I don't think it solves several of the issues. take to the issue. 05:41:01 Is primary the flow direction? and secondary the track direction? 05:41:27 primary is the first direction you go, secondary is the second direction you go 05:41:30 ... afaiu right now `grid-lanes: rows none` you'd get a columns lanes with the template of none 05:41:40 ... which means you can't have a row-based masonry without a track definition 05:41:53 ... we could potentially handle this with some grid-lanes-orientation thing or something 05:41:54 You can, you would use grid-auto-flow, just wouldn't use the shorthand 05:41:59 ... and that'd always tell you which one to use 05:42:13 grid-auto-flow *is* the orientation controlhere. 05:42:20 ... the other one is reusing grid-auto-flow would be a bit weird 05:42:32 Ragvesh has joined #css 05:42:48 present+ 05:42:57 ... so grid-lanes: columns and grid-auto-flow: column, it won't do anything because in masonry you can't have your flow items in the column direction when ?? 05:43:05 Steven has joined #css 05:43:40 fantasai: it can, the default auto-flow chooses based on templates, but non-initial values you get what you asked 05:44:07 JRJurman4 has joined #css 05:44:11 alisonmaher: I think it'd be clear if we had a grid-lanes-flow 05:44:28 ack florian 05:44:38 florian: I understand the proposal is very fresh but I think it's useful to discuss it 05:45:00 ... it came out from the fact that we're at TPAC, this is an issue that needs solving and the ability to talk about this is great 05:45:13 ... even if we don't resolve I think it's important to discuss this to get it unstuck 05:45:24 ... I'd need more time to think about part 3 because that's very fresh 05:45:31 ... 1 and 2 make a lot of sense to me 05:45:41 ... we get around TabAtkins and ntim's formal objection 05:45:51 ... because you use columns to define grid-lane 05:46:14 ... and the low-level controls is mostly automatic but when it's not it does the thing ntim wants 05:46:18 ... but I'm optimistic 05:46:46 astearns: let's discuss this during the break 05:47:24 ... I think throwing around formal objections was inappropriate and unproductive 05:47:33 TabAtkins: was just repeating my words from a few weeks ago 05:48:14 astearns: I hadn't put it on the agenda because I knew we weren't going to get anywhere, but I readded I got told we'd talk about smaller topics 05:48:17 fantasai: we did 05:48:20 zakim, open queue 05:48:20 ok, astearns, the speaker queue is open 05:48:28 astearns: anyways for now hallway conversation, let's go back to mixins for a bit 05:49:06 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12946 05:49:06 Topic: [css-mixins-1] Do we really need the `@contents` parameter? 05:49:06 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12946. 05:50:01 TabAtkins: currently in the spec, mixins can take number of args 05:50:16 ... can also take a nested block, you can sub that in mixin 05:50:26 ... with media query to apply, other reasons as well 05:50:38 ... question here is how to declare how this is done 05:51:19 q+ 05:51:26 ... the current spec is how you declare the argument in the list, you declare the contents in the args list as well 05:51:55 ... some ppl don't see the point of this, other than declaring, current spec doesn't allow other things to do 05:52:01 ... like typing 05:52:14 ... literaly it's just about declaring the contract 05:52:38 ... but enough ppl are not liking this and we'd like to make it be passable all the time, so maybe remove it from args list 05:52:57 ... if you do pass it then allow but doesn't do anything 05:53:14 ... there are suggestions to retain some of it, like to allow passing ony if mixin uses one 05:53:25 ... like for debugging by replacing contents, 05:53:41 ... if we wannt go this way, than not objecting to always alllow passing it 05:53:47 q- 05:53:59 ... so proposing removing it from args list and always allow passing 05:54:10 I was just in the queue to +1 but if there are no objections, there's no point to spending time arguing why the +1 05:54:21 +1 05:54:24 +1 05:54:42 +1 05:54:43 +1 05:54:43 miriam: +1 05:55:05 proposed resolution: remove @contents block from the args list 05:55:32 lea: if you don't use it in the mixin it's empty 05:55:32 q+ 05:55:35 TabAtkins: yes 05:55:46 astearns: seeing approvements 05:55:51 ack kizu 05:56:18 kizu: if you have a mixin with @contents that have some malformed decls inside, if you call it without braces then it's replaced by the content 05:56:22 TabAtkins: correct 05:56:34 lea: would be nice to have [missied] 05:56:54 s/[missed]/fallback specified with @contents/ 05:56:55 s/[missied]/a way to pass default contents to be used when the mixin is used without contents/ 05:57:01 astearns: other things to add? 05:57:06 scribe+ 05:57:09 ... obejctions? 05:57:10 TabAtkins: there is, you just add a block 05:57:26 RESOLVED: remove @contents block from the args list 05:58:07 astearns: objections to always allowing to pass @contents block? 05:58:20 RESOLVED: always allow passing @contents block 05:58:41 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12927 05:58:42 Topic: [css-mixins-1] A var()-based model for mixin parameters 05:58:42 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12927. 05:58:53 TabAtkins: just intro-ing this topic 05:59:09 ... current spec for mixins, for some reasons, it has to handle args to mixins in speciial way 05:59:28 ... can't just use var(), becaue the body is passed to another rule and you don't want to pollute other stuff 05:59:41 ... so I difined a new idea of scope 05:59:49 ... it kanda works, have some issues 05:59:56 ... and we thought of another idea 06:00:35 ... effectively when you apply a mixin, we do a funky inversion where you end up with a lot of anonymous functions in the leaf property values 06:01:00 ... where you have a behavior where they interleave in a nice way 06:01:15 ... so not inventting a new way to invoke funcitons 06:01:42 ... makes it work substantially better, may have some odd implications 06:01:53 ... helps a lot with caching 06:02:12 ... we used YOUTUBE as test case 06:02:38 ... so letting ppl know that we're experimenting with it, very happy about it internally 06:02:40 q+ 06:02:45 q+ 06:02:49 +1 06:02:57 ... if there are no objections, would like to change spec to this new model 06:03:09 lea: based on this summary, not sure what is proposed 06:03:15 ... very hard to say whether we object 06:03:18 +1 to lea 06:03:22 TabAtkins: this is just an intro 06:03:35 ... in the linked issue there are more details 06:03:38 +1 to lea 06:03:49 ack lea 06:03:52 ack miriam 06:04:04 miriam: I think would be helpful to have comments on implications, not just impl. details 06:04:29 TabAtkins: the author facing implications, A: not introducing a new arg for custom funcs and var, they look similar 06:05:00 ... B: this makes variables passed to mixins work better, to some extent 06:05:10 ... in most cases did not work in previous model 06:05:22 q+ to finish my thought 06:05:25 ... there are some limitations still, like how geenric macro works 06:05:43 ... but upshot is, in general case, maybe all, passing variables in should work 06:05:49 ... and same authoring model 06:06:01 ack miriam 06:06:01 miriam, you wanted to finish my thought 06:06:19 miriam: and there are also implications that you can only impact decendants? 06:06:41 TabAtkins: not necessarily, if I want to add a restriction that it acts like it's scoped 06:06:58 Adam_Page has joined #css 06:07:02 ... if you don't apply it then, if you select above or siblings, they may work differently 06:07:15 .. it's a bit of a footgun if you want to allow unscoped mixins 06:07:35 ack fantasai 06:07:35 fantasai, you wanted to ask what impact this has on people using mixins 06:07:35 miriam: will have to look into it more 06:08:01 fantasai: what is the look path for foo variable? 06:08:35 dmangal has joined #css 06:09:12 TabAtkins: similar to custom functions, mixins also introduce hypothetical elements 06:09:38 Vinay has joined #css 06:09:41 ... so if you in the simple cases ... 06:09:41 karlcow has joined #css 06:09:57 fantasai: from the element you apply from? 06:10:07 TabAtkins: this comes to discussion on scoping or not 06:11:27 fantasai: if I take a code block and apply a mixin, if I ask for element foo do I get same element? or looking it up on the applied? 06:11:43 TabAtkins: you first use where you apply, the walk up the tree 06:11:58 astearns: we have this proposal, and impl behind flag you can try out 06:12:05 miriam: we can play with it in canary? 06:12:11 TabAtkins: yea 06:12:19 astearns: moving on 06:12:40 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12671 06:12:40 Topic: [css-mixin-1] How does Shadow DOM influence mixin lookup? 06:12:40 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12671. 06:13:38 GameMaker has joined #css 06:14:32 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12631 06:14:32 Topic: [css-mixins-1] Expose environmental variables inside apply's contents block 06:14:32 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12631. 06:15:05 kizu: this depends on change from env vars to regular vars, moving to env vars simplifies things 06:15:11 look at this example: 06:15:14 @mixin --test(@contents) { 06:15:14 --foo: pink; 06:15:14 @contents; 06:15:14 } 06:15:14 06:15:14 button { 06:15:14 --foo: lightgreen; 06:15:15 @apply --test { 06:15:15 background: var(--foo); 06:15:15 } 06:15:16 } 06:15:37 ... you can use custom props inside, and means that if you define them they are args to the mixin, and will be invisible inside it 06:15:53 TabAtkins: posted an example, mixin that sets foo 06:16:02 ... the element also sets foo 06:16:04 mjackson has joined #css 06:16:23 ... question is which color does it see? the one from the mixin sub?, can mixins shadow vars? 06:16:30 q+ 06:17:05 kizu: in my opinion it's useful, however, if we want to explicitly say differently, when you look at the applied value from the side you don't know which one it will be 06:17:46 ... so either we could either use the one inside, but by default would be more useful to use the one outside, a bit confusing 06:17:57 TabAtkins: in this example it ends up light green 06:18:13 q+ 06:18:13 my intuition would be either use inner, then outer (if inner is absent). 06:18:13 failing that, ignoring both is an option 06:18:20 ... agree it's possible the most obvious thing, content styles look more local, and if you have nested rule 06:18:30 ... you wouldn't want to change behavior 06:18:39 kizu: I think it's actaully pink there 06:19:01 ... because if you use it this way, because it's a registered custom property 06:19:18 https://www.irccloud.com/pastebin/D5y005wZ 06:19:25 TabAtkins: you're right, if the mixin took that var... 06:19:28 @mixin --test(@contents, --foo: pink) { 06:19:28 @contents 06:19:28 } 06:19:28 06:19:28 button { 06:19:28 @apply --test { 06:19:28 background: var(--foo); 06:19:29 } 06:19:29 --foo: lime; 06:19:29 } 06:19:48 sorvell4 has joined #css 06:20:39 miriam: I think you're getting confused between what happens in impl and what we want 06:20:43 TabAtkins: yes, exactly 06:20:58 kizu: hard to tell from where something would come, and need to resolve it in some way 06:21:07 TabAtkins: in this example don't care about impl. 06:21:15 ... so ideally should not be pink? 06:21:18 kizu: yes 06:21:24 ack miriam 06:21:27 `@apply dark-colors { background: var(--from-mixin); }` 06:21:53 miriam: I agree we should with this, but counter for that I know in SASS it's different, where you have a mixin that defines stuff and then you psas a block and want an access to that 06:21:54 +1 miriam 06:22:02 ... but agree that the default case would not be that 06:22:05 `@apply dark-colors using all { … }` maybe? 06:22:18 TabAtkins: in that case this behavior would be supported 06:22:23 miriam: ok 06:22:36 ack astearns 06:22:38 astearns: have an explanation... but now confused 06:23:10 TabAtkins: proposing for this behavior a contents block will see vars defined in the body of mixin, 06:23:20 ... but it will not see ones defiend in args 06:23:46 miriam: in several examples there's an @local 06:24:27 s/have an/had an/ 06:24:28 TabAtkins: a local var acts a like arg but just not listed args list 06:25:09 miriam: in SASS that would not change the outside vars and access the inside, would that be possible? 06:25:15 ... not sure how important 06:25:33 kizu: I opened about this, regarding env vars, how do we access them 06:25:49 TabAtkins: it's still possible for us to add syntax for that 06:26:00 ack fantasai 06:26:00 fantasai, you wanted to ask about the earlier example 06:26:20 fantasai: you had an example before, the contents passed in would have access to sutff in the body, but not parameters 06:26:24 TabAtkins: yes 06:26:40 fantasai: in that case the vars would be part of the output of the mixin 06:27:12 ... so if you wanted a set of vars that put in the mixin, then you would need to overide those say vars on where the mixin is used? 06:27:14 TabAtkins: yes 06:27:30 ... currently yes 06:27:37 It would be really useful for these kinds of issues to have all the possible combinations listed somewhere as a comment on the Github issue. Having to think through the combinations in your head highers the bar to contribution. 06:27:52 miriam: that's what I was saying, we could have extra syntax for that 06:27:55 TabAtkins: yes 06:28:09 astearns: more qs or examples? 06:28:20 TabAtkins: I think we got what we need 06:28:30 ... folks think it's a good behavior, got approvals 06:28:40 kizu: we should resolve after another related issue 06:28:41 I guess one of the advantages of env() was that it could be clearer about what resolves against what 06:29:01 astearns: would like to get detailed examples of what we just talked about in the spec and why it works this way 06:29:07 TabAtkins: yes 06:29:09 +1 astearns 06:29:22 ... I can do that 06:29:47 ntim: I think this issue is hard to reason about, right now trying to think about it and combinations and it's hard 06:29:52 TabAtkins: fair enough 06:29:57 astearns: moving on 06:30:12 (and we should get examples of combinations written on the issue) 06:30:14 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12987 06:30:14 Topic: [css-mixins-1][css-values-5] The inherit() function in custom functions 06:30:14 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12987. 06:30:25 TabAtkins: about custom functions 06:30:51 ... in there, if you write results: inherit, it just makes the function resolve to inherit 06:31:10 ... similar to a var() with a fallback of inherit 06:31:25 ... the behavior is idnetical on purpose 06:31:43 ... but we don't define inherit function to have the same sort of behavior 06:31:50 ... so poposal is let's do that 06:31:57 q+ 06:32:01 s/poposal/proposal/ 06:32:04 ack miriam 06:32:18 miriam: 2 questions, why is that true only about inherit? 06:32:30 TabAtkins: we currently don't have other functions for other keywords 06:32:49 miriam: so question why only inherit gets pass through 06:33:11 TabAtkins: all global keywords gets passthrough unchanged 06:33:26 kizu: css keywords do pass but function not 06:33:39 miriam: we're saying the function doesn't pass through in results 06:33:41 TabAtkins: yes 06:33:49 @function --foo() { result: inherit(--bar); } 06:33:59 TabAtkins: this is the case we're talking about 06:34:21 sorvell1 has joined #Css 06:34:30 ... this is different from inheting a var, the function should work the same way, there are use-cases for both 06:34:39 miriam: how does this interact with last conversation 06:34:51 romain has joined #css 06:35:01 ... the var doesn't inherit from an arg that's passed in 06:35:11 Euclid has joined #css 06:35:20 TabAtkins: if we don't get a special behavior it would get value from the element, like a bare inherit 06:35:36 +1 to the proposed change 06:35:43 astearns: anyone else? 06:35:54 TabAtkins: kizu I suppose you +1 too? 06:35:56 kizu: yes 06:36:43 proposed: in `result: inherit();`, the inherit() is treated the same as a plain `inherit` (passed thru and only resolved on the actual element) 06:37:05 astearns: objectsions? 06:37:19 RESOLVED: in `result: inherit();`, the inherit() is treated the same as a plain `inherit` (passed thru and only resolved on the actual element) 06:37:50 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12161 06:37:50 Topic: [css-pseudo] Add a property to the `CSSPseudoElement` IDL interface to retrieve pseudo argument(s) 06:37:50 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12161. 06:38:02 sakhapov 06:38:32 sakhapov: some context, we have pseudo interface for proxy for pseudo elements 06:38:41 ... this object always exists 06:38:57 ... it's just a proxy element, not a real one, even if you don't render anything 06:39:25 ... when you pass in a selector, can have args, question is how define properties to get the args of the pseudo element 06:39:38 ... in the last comment on the issue I have a suggestion 06:40:01 ... we do .arguments to return a list of args, or just null if none 06:40:08 q+ 06:40:13 q+ 06:40:30 ... so that this returns a normalized text and can round-trip 06:40:48 ... maybe someone has objection to naming? 06:40:53 ack TabAtkins 06:41:14 TabAtkins: I think these are all good, good design, this should be a sequence OM string 06:41:19 ... I'll help to fix 06:41:24 ack emilio 06:41:42 s/should be/can't be/ 06:41:45 emilio: this makes sense but, don't think we should call this an identifier, it's not that, don't have a better idea 06:42:02 ... don't have on arguments vs. parameters 06:42:20 ... do we have a precedent for that? 06:42:23 TabAtkins: don't know 06:42:31 emilio: so could be either way 06:42:46 TabAtkins: I don't know what we do in CSS 06:43:36 css-highlights/css-pseudo/css-view-transitions probably have examples 06:43:39 emilio: bikesheding aside, selector text identfier aside, looks good 06:43:52 ::highlight uses "argument" as well 06:43:55 astearns: what do we use for selector for a rule in CSSOM? 06:44:06 emilio: selector text, might be a better name 06:44:40 sakhapov: question about scroll buttons, whether should be logical or physical 06:44:45 emilio: separate issue 06:45:09 ... I don't know if those things alias eachother, probably discuss separately 06:46:03 astearns: I hear we're agreeing on a typed argument selector text and separate issue for scroll buttons? 06:46:32 s/typed argument selector text/type, arguments, selectorText/ 06:46:57 emilio: if you called .pseudo and pass a selector that could select multiple things should not be allowed 06:47:22 ... the point of these are to get specific elements, so should probably just throw 06:47:36 ... for the logical vs. physical it's a bit tricky 06:47:44 sakhapov: we can discuss separately 06:48:18 Proposed resolution: use type, arguments, selectorText 06:48:37 emilio: arguments seems fine 06:48:46 astearns: kbabbitt said there is precedent 06:48:56 astearns: objections? 06:49:28 sakhapov: for the pseudos only one argument still return a list 06:49:32 "Parameters refer to the variables listed in a function's declaration, defining the input that the function can accept. Arguments, however, are the actual values passed to the function when it is called, filling the parameters during execution." 06:49:49 TabAtkins: currently all have one 06:50:09 ntim: if we have ones without args, 06:50:29 ... I think it's a bad pattern to have multiple args but to point to one thing 06:50:43 emilio: imagine we had a pseudo element for corners 06:51:07 [cross talk] 06:51:40 TabAtkins: arguments is a good name for this sort of thing, we will in the future have an element with multiple args 06:51:52 q+ 06:51:52 fantasai: I think we have it just return a string 06:52:05 TabAtkins: I rather deal with that legacy later 06:52:16 s/I rather/I don't want to have to/ 06:52:20 florian: we've done this before and not fun 06:53:19 q- 06:53:45 TabAtkins: in CSS all concepts that deal with multiple args have comma separation 06:54:07 ntim: I can see in the future using commas and still only point to one thing 06:54:21 TabAtkins: don't see how these concepts are related 06:54:30 ... you can have multiple and none args 06:54:42 fantasai: it's not the parameters to a function, they just look like it 06:55:09 ... we're creating an unneccary API here 06:55:30 ntim: I can see this list becoming an identifier 06:56:24 [cross talk] 06:56:58 astearns: I think we're having difficulyt with hypothetical future stuff here 06:57:25 ... we could go with argument for now to return a string, and in future if we have multiple we have arguments for return an array 06:57:30 TabAtkins: sounds good! 06:57:49 s/sounds good/sounds bad, I hate it 06:58:15 +1 to astearns :) 06:58:19 ydaniv: s/I can see this list becoming an identifier/we could name it "identifier" instead of "argument" 07:00:47 q? 07:00:49 q+ 07:02:16 florian: was thinking this example is more convincing 07:02:27 theparkagen has joined #css 07:03:01 fantasai: question is do we use commas or spaces, and how does that appear on the IDL 07:03:14 JS doesn't offer `.argument` and `.arguments`, with the former letting you avoid writing `[0]` for single-arg functions. 07:03:24 (my point was `arguments.join(",")` is also extra overhead in the future, as much as `arguments.split(",")` is an overhead) 07:03:32 ... we may have a sophisticaed syntax for multiple args, and we're trying to reduce this to whether these are args or not 07:03:50 mjackson has joined #css 07:05:34 ntim: you will need both, in the future you'll need to collapsed string as well 07:05:54 We sometimes use commas to separate arguments, sometimes spaces. If we're trying to avoid parsing things, we should return a list of tokens even when it's space-separated. 07:06:11 astearns: going round and round without any decision 07:06:28 ... show of hands who would object to doing the string thing? 07:06:33 ... seeing plinss 07:06:34 Yes, we use various ways, but we *also* specifically honor comma-separated arguments as something special 07:06:56 in what way? 07:07:04 custom functions, for example 07:07:16 commas separate the arglist into individual var()s 07:08:09 POLL: a) argument string b) arguments array c) neither 07:08:22 kbabbitt7 has joined #css 07:08:22 b 07:08:30 a, c 07:09:00 s/seeing plinss/seeing plinss and tabatkins/ 07:09:06 astearns: objections to use selector text? 07:09:11 kbabbitt7 has left #css 07:09:12 [none] 07:09:36 RESOLVED: Add selectorText to the pseudo object 07:10:05 topic: break 07:10:29 Adam_Page has joined #css 07:17:04 karlcow has joined #css 07:31:20 kbabbitt has joined #css 07:31:52 alisonmaher has joined #css 07:32:22 scribenick: kbabbitt 07:32:35 ydaniv has joined #css 07:33:02 github: https://github.com/w3c/csswg-drafts/issues/12158 07:33:19 JRJurman has joined #css 07:33:22 sakhapov has joined #css 07:33:34 sakhapov: coming back to CSSPseudoELement object 07:33:39 duerst has joined #css 07:33:40 ... it's a proxy for an element 07:33:44 ... but element can exist or not exist 07:33:50 ... and what it means depends on what we discussed 07:34:05 ... for :after it can mean rendered, for :selection it can mean something's selected 07:34:11 ... sometimes we need to know if the thing exists 07:34:21 ... 2 approaches suggested: synchronous exists property 07:34:39 ... second suggestion by noam, pseudo element observer 07:34:45 ... which is a synchronous way 07:34:48 q+ 07:34:51 ... tells you which were added and which were removed 07:34:55 ack florian 07:35:03 ... can use this to add event listeners 07:35:19 ... most use cases I can think of right now are covered by observer 07:35:30 ... for example if you think about scroll markers, you might want stats on which scroll marker has been clicked 07:35:42 ... observer is better for this case becaues it tells you scroll marker has been created 07:35:50 ... I also think there are possible use cases for sync .exists property 07:35:56 ... which I listed in 2nd to last comment in issue 07:36:10 ... first is, might want another event listener which checks existense of pseudo 07:36:13 ... might want sync approach 07:36:26 ... also, point is that observer probably is not suitable for non tree abiding pseudos 07:36:32 ... those are more like states than nodes 07:36:48 ... also some libraries if you use them might want to init first with knowledge of sync existence of pseudos 07:36:54 ... those use cases for now are more theoretical 07:37:03 ... but I think they can be things we might need in the future 07:37:05 topic: [css-pseudo] Add a property to the CSSPseudoElement IDL interface to determine if a pseudo element "exists" 07:37:36 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12158 07:37:36 Topic: [css-pseudo] Add a property to the `CSSPseudoElement` IDL interface to determine if a pseudo element "exists" 07:37:36 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12158. 07:37:40 q+ 07:38:08 sakhapov: I think we should resolve for pseudo element observer 07:38:10 q+ 07:38:11 ... want to hear opinions 07:38:13 ack ntim 07:38:23 ntim: first thought looking at this api is that why don't we just make element.pseudo return null 07:38:29 ... like querySelector returns null 07:38:35 astearns: because we already resolved on having the interface ... 07:38:41 sakhapov: discussions before 07:39:02 emilio: if you do that, you need to synchronously update layout, may wantobserver for pseudeo that doesn't exust yet 07:39:33 ... otherwise if you have a before pseudo that goes away then comes back, you don't want to expose whether underlying psedo ? or not 07:39:40 ntim: exists prop checks for htat? 07:39:46 emilio: but object may not be the same 07:39:53 astearns: successive iterations of same pseudo 07:39:58 ... it's a separate issue 07:40:04 ... given previous resolution we need to decide what to do here 07:40:18 sakhapov: previous discussion was in favor of consistent proxy 07:40:19 karlcow has joined #css 07:40:22 ... good arguments for that 07:40:24 astearns: other comments? 07:40:29 q+ 07:40:30 ntim: disagree with other issue 07:40:34 ... which affects this 07:40:39 ack ydaniv 07:40:44 ydaniv: really like the observer approach 07:40:56 ... but we're doing something specific here with pseudos 07:40:58 where can i find the other issue? 07:41:02 ... maybe we can open something more generic 07:41:13 GameMaker has joined #css 07:41:23 ... last we talked, ? talks about having selector observer when things are added/removed that match a specific selector 07:41:31 ... maybe we want a more generic thing that also works for pseudos 07:41:37 ... or mutation observer that takes selector as filter 07:41:45 ... would like to see if we could consider that 07:42:04 astearns: sakhapov has that been considered? 07:42:18 sakhapov: no, mostly considered sync way, noam is in favor of observer, see use cases for both 07:42:49 ... heard opinions in favor of observer, want to hear in favor of exists property 07:42:52 ack TabAtkins 07:43:08 TabAtkins: while the observer proposal from noam is a little complex to solve this, I think it's pretty well shaped 07:43:12 ... avoiding sync recalc is reasonable 07:43:21 ... agree there might be use cases for sync stuff but can pursue in future 07:43:25 ... support sticking with observer 07:43:27 ack emilio 07:43:37 emilio: 2 things, if we do sync version , I'd rather make it a method than a getter 07:43:47 ... going to do underlying work to update layout tree etc. 07:43:55 ... also some of the use cases feel a bit dubious 07:44:09 ... don't think we want to expose whether spelling error exists 07:44:10 spelling-error 07:44:12 ... or grammar error 07:44:26 Is https://github.com/w3c/csswg-drafts/issues/12159 the other issue? 07:44:28 ... so not clear a lot of these have good answers for those 07:44:35 ... don't know what the right answer for those would be 07:44:53 sakhapov: ? said for privacy reasons we can't expose a number of pseudos 07:45:00 emilio: guess you want to return null when it's a tree state 07:45:03 ... true false or unexposed 07:45:09 sakhapov: there's a table in the issue 07:45:17 emilio: think that's a bad pattern, don't have a lot of nullable booleans 07:45:25 ... proposal for exists was nullable boolean 07:45:29 ... null if we can't answer 07:45:39 TabAtkins: don't think we have any nullable booleans right now 07:45:51 ...given that both null and false are false-y that fits simple test for is it there? 07:46:01 sakhapov: idea behind nullable bool was null = can't tell, false = not there 07:46:08 TabAtkins: both seem false-y to me, seems okay to me 07:46:19 emilio: feels like a lot of these ... for example first-letter, first-line 07:46:25 ... do you need a rule for them to match? 07:46:28 ... same for placeholder 07:46:34 ... could use .matches(placeholder) 07:46:43 ... highlights you know whether you have them because there's a registry 07:46:48 ... spelling error we don't want to expose 07:46:54 ... seems like theres very few where this would be useful 07:47:04 ... guess the observer, I wonder if we could reuse mutationobserver 07:47:09 astearns: that was ydaniv's suggestion 07:47:14 TabAtkins: can you filter a mutationobserver? 07:47:21 emilio: yes, only text changes, only additions, etc 07:47:29 TabAtkins: can you have default off things? 07:47:35 emilio: it's optional spec so potentially 07:47:55 ... also tricky thing with mutationobserver, we don't want to turn on details of when actual element gets createdx 07:48:10 ... seems to me like there's very few really compelling use cases for this given the complexity 07:48:24 astearns: I kind of like the idea of reusing something we already have 07:48:28 ... instead of creating something new 07:48:38 ... wonder if we should take this back to the issue, especially since noam's not here 07:48:47 ... and have him weigh ydaniv's idea against his proposal 07:48:50 sakhapov: sounds good 07:49:00 astearns: you can ping noam to say there's this other idea, and we'll weigh the alternatives 07:49:10 sakhapov: and sync version can be discussed later 07:49:16 astearns: ok, back to the issue 07:49:35 github-bot, take up https://github.com/w3c/csswg-drafts/issues/9702 07:49:35 Topic: Mixing :is() (or equivalent) with pseudo-elements 07:49:35 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9702. 07:49:52 miriam: I want to see this happen 07:50:12 TabAtkins: we've explicitly excluded putting pseudo elements inside :is for a while 07:50:17 ... this is for various selector data model reasons 07:50:29 ... big one is that :is is a pseudo class which is simple selector, and simple selectors do nothing but filter 07:50:49 ... can always take the things matched by a couple of simple selectors, intersect them, and that's what you get when you combine them together 07:51:03 ... if we allowed pseudo elements inside :is, that stops being tryue 07:51:13 ... you can have .foo which selects all .foo, add :is::before 07:51:19 ... and suddenly set of elements is not a subset of .foo 07:51:24 ... it's a completely different set, the befores 07:51:27 ... and that's weird 07:51:35 ... however people want to be able to do that because it's useful 07:51:43 ... both directly in :is and indirectly via nesting 07:51:49 ... useful to split slector and resolve differently 07:52:01 ... so I have a proposal for how to slightly alter the semantics of selectors to make this possible to do 07:52:05 ... in :is and in nesting 07:52:11 ... so that all of the nesting cases work more naturally 07:52:17 ... example that doesn't work well: 07:52:24 .foo { ::before, ::after { :hover { color: red; } } } 07:52:38 ... that example does not work because, while we let first 2 work okay via special case 07:52:54 (I think those all need `&`) 07:52:57 ... as soon as you go past that, before and after get shoved into internal :is 07:53:12 ... and that makes the innermost nested selector invalid 07:53:14 .foo { &::before, &::after { &:hover { color: red; } } } 07:53:15 ... doesn't match anything 07:53:29 ... so the suggested change is, before you match a complex selector unit 07:53:38 ... i.e. compound selector plus pseudo elements 07:53:43 ... (thing between combinators) 07:53:55 ... we grow the set of matched elements by adding all pseudo elements that are... 07:54:04 A > B:is(::before) > C 07:54:06 But does that even work? ::before and ::after don't support :hover: data:text/html, 07:54:16 ... in that example, ignore whether they go left or right, equivalent meaningfully 07:54:23 ... start with elements that match A, combinator takes us to children 07:54:31 ... now we add to that set all pseudo elements of A children 07:54:42 ... then we execute the B:is(::before) 07:55:07 ... that will chop down the list of possible elements to things just matching that 07:55:21 ... then before we move on, we will remove any pseudos that were not explicitly matched by that selector 07:55:38 emilio, ::before:hover is supposed to work per the spec, https://drafts.csswg.org/selectors-4/#pseudo-element-states 07:55:43 ... that last step is required because that selector unit might not have had a pseudo in there, could be :hover applying to a bunch of elements 07:55:48 ... can't keep those in list for compat reasons 07:56:04 ... a number of psuedo classes do work on pseudo elements 07:56:15 ... so, this means my nesting example would work 07:56:19 ... there are a few limitations 07:56:22 q+ 07:56:22 ... listed in issue 07:56:23 q+ 07:56:34 .foo:is(*, ::before, ::after) 07:56:39 ... this selector ^ 07:56:46 ... worked in the old webkit matches 07:56:54 ... would match .foo, .foo::before, .foo::after 07:57:02 ... doesn't match in todays world and will continue to not match 07:57:10 ... because pseudoes are supposed to be re-orderable 07:57:20 astearns: why does that rule invalidate your example? 07:57:21 `::before.foo` 07:57:28 TabAtkins: there are no ::before pseudos that are also .foo 07:57:33 q+ 07:57:46 ... that is not only illegal syntactically but will not match 07:57:50 ... will continue to not match 07:57:53 emilio: but it matches now? 07:57:54 TabAtkins: no 07:58:02 ... only matches .foo, not .foo::before or ::after 07:58:08 ... that selector is illegal right now 07:58:17 q+ 07:58:19 ... won't match what webkit-matches would have matched 07:58:21 q- 07:58:25 q- 07:58:26 ... secondly, building on that same thing 07:58:31 :hover:is(::before) and :is(::before):hover 07:58:34 ... simple selectors in a compound are always reorderable 07:58:40 ... these 2 selectors need to be identical 07:58:47 ... they are in all cases today and should continue to be 07:58:52 ... but that means that these 2 selectors... 07:58:53 :hover::before and ::before:hover 07:58:54 sakhapov has joined #css 07:59:02 q- 07:59:06 ... which are indeed distinct things and select different things, only 1 can be the meaning of those other 2 07:59:10 ... my proposal selects one of these 07:59:12 ... the latter 07:59:16 ... a before which is hovered 07:59:19 ... not the before of a hovered element 07:59:22 I wouldn't expect :hover:is(::before) and :is(::before):hover to be the same 07:59:24 astearns: here we're defining new behavior 07:59:27 Would that change the meaning of .foo { &:hover { &::before {} } }? 07:59:32 emilio: that's channging currint behavior? 07:59:33 TabAtkins: no 07:59:53 `.foo { &:hover { &::before {} } }` 07:59:58 ... the 2 I listed without :is do work today, select distinct elements 08:00:06 ... but the 2 that use :is are illegal today 08:00:10 q+ 08:00:13 ... giving them meaning, both equal to second one 08:00:34 ... those are the only places where this I believe gives potentially unintuitive results 08:00:37 q+ 08:00:42 Or, if not, would it become illegal once you turned it into `.foo, .bar { &:hover, &:focus { &::before, &::after {} } }`? 08:00:45 ... in all other cases this lets pseudos be used in is and gives obvious answers for all these work 08:00:48 q+ 08:00:53 ack emilio 08:00:55 emilio: I'm not quite fond of this proposal 08:00:55 q+ 08:01:09 +1 to emilio 08:01:09 ... it feels like, especially making hover before mean the same as before hover seems super intuitive to me 08:01:22 TabAtkins: if you replace :hover with .foo does it make more sense? 08:01:35 emilio: no, I don't know why reordering preserves the meaning 08:01:50 ... point is you want to preserve that, within a sinple selector, reordering is important 08:01:55 mjackson has joined #css 08:02:09 ... vs doing intuitive thing which I think would be, hover before selects the before of hovered element, before hover does something different 08:02:17 miriam: that argument makes sense until you add :is 08:02:22 ... the is makes them the same thing 08:02:27 emilio: so when you add ... 08:02:43 ::before:is(:hover) 08:02:48 oriol: if you have before and hover without is, they'll be different 08:02:55 and :hover:is(::before) 08:02:56 ... when you add is, reordering them will ? 08:03:02 emilio: don't think that makes sense 08:03:09 ... hover before should not be different from before hover 08:03:17 miriam: I think they should be, 'is' says theyre the same thing 08:03:21 ... not the before on the hover, the ... 08:03:25 emilio: that doesn't make sense to me 08:03:32 ... I get it in that you're using :is 08:03:35 ... but that's so confusing 08:03:40 ... also not what authors would expect. 08:03:52 ... if I have a complex sector, before after, &::before &::after 08:03:58 ... behave the same as if 08:04:06 miriam: distinction will be if it has the & or not 08:04:10 q+ 08:04:21 emilio: in general, pseudos in my mental model are basically a combinator 08:04:23 TabAtkins: correct 08:04:29 emilio: which means making this work is annoying 08:04:33 q- 08:04:53 ... but if you look at it that way, isn't :is ... guess if you do .foo descendant .bar then ... you're not selecting anything hover 08:04:56 ... feels really annoying 08:05:01 ... wouldn't expect that behavior at all 08:05:03 ack lea 08:05:06 :hover:is(> .bar) and :is(> .bar):hover 08:05:08 lea: was about to say +1 08:05:14 ... but this reordering thing is giving me pause 08:05:20 ... might have misunderstood, questions in IRC 08:05:26 1. `.foo { &:hover { &::before {} } }` 08:05:44 ... would that change how it works given it would be composed with is? 08:05:49 TabAtkins: no that would work fine 08:05:57 lea: you said foo hover is before 08:05:58 equivalent to :is(.foo:hover)::before 08:06:04 ... would be equivalent to ??? 08:06:08 ... doesn't that mean it would change? 08:06:21 TabAtkins: the stuff higher in nesting list gets wrapped in pretend :is 08:06:33 ... if you invert these, that would give different behavior than you might expect 08:06:39 ... as written, equivalent to foo hover before 08:06:41 `.foo { &::before { &:hover {} } }` 08:06:43 lea: so if you had this 08:06:48 TabAtkins: that would be equivalent to: 08:06:50 ::before:is(.foo:hover) 08:06:51 s/???/:is(::before):hover 08:06:59 ... not that 08:06:59 :is(.foo::before):hover 08:07:02 ... that 08:07:10 lea: so hover is on before itself? 08:07:11 TabAtkins: yes 08:07:15 lea: same result is same? 08:07:21 TabAtkins: no, hover on foo vs hover on before 08:07:26 lea: you still have a pseudo in there 08:07:34 TabAtkins: this entire thing is confusing by default, I know 08:07:42 ... if we end up not resolving here, that's fine 08:07:46 ... I need to fix this problem somehow 08:07:48 the first becomes :is(.foo:hover)::before 08:07:51 ... I tried another way and everyone hated it 08:08:01 lea: any cases where an is through nesting does something different based on nesting? 08:08:04 the second becomes :is(.foo::before):hover 08:08:05 TabAtkins: sometimes hopefully not often 08:08:08 lea: that's worrying 08:08:16 ... second example 08:08:25 `.foo, .bar { &:hover, &:focus { &::before, &::after {} } }` 08:08:35 ... based on answer to the first, does that change? 08:08:43 TabAtkins: no, it's valid today and does what you expect, won't change 08:08:54 ... will only give new results to selectors that don't select pseudos 08:08:59 ... i.e. pseudo in middle of nesty 08:09:07 lea: problem is once we do this we can't make them work right way 08:09:15 TabAtkins: trying to find *a* way to make them work 08:09:18 q+ 08:09:21 ack astearns 08:09:30 q+ 08:09:42 astearns: is the motivation for this entirely nesting and the bare is behavior just a side effect? 08:09:43 TabAtkins: yes 08:09:49 astearns: no use case for bare is? 08:09:58 TabAtkins: there's use cases but not solving for this solving for nesting 08:10:16 astearns: any back compat issues having some of these either nested or bare is things with pseudos in someone's stylesheet doing nothing suddenly working? 08:10:20 TabAtkins: maybe, hopefully not 08:10:36 astearns: does this fall out of the fact that we defined nesting by referencing is? 08:10:48 ... and if so, can we instead redefine nesting to use an ish-is like thing 08:10:54 ... but sever the tight connectoin between them? 08:10:59 +1 astearns, was wondering about this too 08:11:00 :almost-is() 08:11:03 TabAtkins: does somewhat fall out of the semantics defined in terms of is 08:11:17 ... don't thnk we can define in other terms to get around this iwhtout either getting back to cominatorial problem 08:11:33 q+ 08:11:35 astearns: wondering whetehr we can say, for purpose of nesting, this is the extra behavior you get with pseudos 08:11:38 TabAtkins: maybe 08:11:50 ... would be very frustrating if you could only express certain selectors via nesting 08:11:52 astearns: that's fair 08:11:54 q- 08:12:00 `.foo:is(*, ::before, ::after)` 08:12:01 ack romain 08:12:06 romain: bit confused about one example, in irc 08:12:10 ... don't see why that doesn't work 08:12:12 `.foo:is(.bar, ::before, ::after)` 08:12:19 .. I do but also worry that this second example won't work 08:12:27 ... is it wildcards, or anything in pseudo won't work? 08:12:35 TabAtkins: first one with wildcard totally works 08:12:39 ... will match .foo elements only 08:12:45 ... second one will match .foo.bar elements only 08:12:51 romain: none of the pseudos will match? 08:12:58 TabAtkins: correct ,because no pseudo matches .foo 08:13:06 romain: think that's surprising 08:13:14 ... mixing pseudos in doesn't work 08:13:19 TabAtkins: agree, this is my second try to fix this 08:13:30 romain: that's my main issue with this proposal, it's also very surprising 08:13:35 miriam: this proposal fixes this? 08:13:40 my previous idea was `.foo = (.bar, ::before, ::after)` 08:13:43 emilio: it's meant to 08:13:57 miriam: my understanding was that's the initial problem & what we're trying to fix 08:14:14 romain: what TabAtkins was saying & what I was understanding, you can use pseudos in is, can't mix them 08:14:20 TabAtkins: no right now pseudos in is are dropped 08:14:25 romain: with proposal they become valid 08:14:26 TabAtkins: yes 08:14:34 romain: but only match with only pseudos or only classes 08:14:37 TabAtkins: yes 08:14:44 ... [another case that works I missed] 08:14:57 romain: like astearns's thinking, if we let go of is, is there more we can do? 08:15:03 ... cases written with nesting aren't ambiguous 08:15:07 ... but when written with is, become invalid 08:15:10 ... maybe there's more there 08:15:14 astearns: also not sure 08:15:16 ack oriol 08:15:27 oriol: also share concerns about implications for :is being a bit confusing 08:15:33 ... along lines of what astearns was saying 08:15:40 ... first not the case that & in nesting is defined in spec in terms of is 08:15:47 ... just that definition happens to match same behavior 08:15:56 ... impls use some kind of alias internally 08:16:00 ... but that doesn't have to be the case per spec 08:16:06 ... could say & will match elements OR pseudos 08:16:15 ... don't see that this would introduce any combinatorial explosion 08:16:23 ... with just this change ... impls will not be able to reuse is 08:16:23 +1 oriol 08:16:33 ... but at first glance doesn't seem like a big problem to me 08:16:42 ... not just asking around this direction, want to propose it, seems simpler 08:16:48 TabAtkins: wouldn't cause a combinatorial explosion, correct 08:17:00 ... would cause that some selectos could only be written with nesting, would like to avoid 08:17:12 ... want a syntax that lets us expres ssame things with and without nesting 08:17:14 .foo { ::before, ::after { :hover { color: red; } } } 08:17:17 oriol: I htink it's fine if that's the case 08:17:25 ... maybe not ideal but preferable to making is very confusing 08:17:30 ... could always extend to is in the future 08:17:33 ... or some other syntax 08:17:45 astearns: agree it would be nice to express same things nesting vs not 08:17:52 ... but only if non-nested version is ergonomic and would get use 08:18:10 TabAtkins: example I gave earlier would be totally valid to turn on in nesting but not normal selectors 08:18:29 astearns: if non-nesting way of expressing it is so weird no one will ever use it. would be okay to have it be expressible nested only 08:18:38 miriam: can be expressed without single selector 08:18:45 TabAtkins: any nested selector if you want to expand out, it's fine 08:18:53 q? 08:18:57 ack emilio 08:18:59 I think astearns is saying we shouldn't regress the DX for :is() just to solve the nesting problem, if so +1 08:19:10 emilio: is there any reason we cannot make is do what I think is expected behavior? 08:19:15 q+ 08:19:19 ... not preserve order but feels most intuitive? 08:19:27 ... as long as you're in the rightmost compound, pseudos only match there 08:19:34 ... we don't allow combinators past pseudos 08:19:41 ... they don't have descendants that way 08:19:52 ... from an impl perspective, does complicate stuff quite a bit 08:20:01 ... suddenly selector can match a gazillion pseudos 08:20:05 ... but feasible to implement 08:20:06 ntim: it’s not so much regressing the entire DX of :is(), I just don’t think it’s worth it to create a hard-to-use version of this with :is() 08:20:20 ... I think you would still, other than that weirdness of order representing different things 08:20:30 ... (gives examples) 08:20:41 ... to me that seems more intuitive for authors 08:20:47 ... it's not impossible to implement 08:21:06 TabAtkins: the issue becomes that we don't have a concept in selectors ... would lose group of selectors that covers an element 08:21:25 ... we rely on the fact that compound selectors can't change subject in a few places e.g. :not 08:21:27 emilio: negations and such become tricky, yeah 08:21:38 TabAtkins: we rely on the fact thaqt something in CSS lets us only filter, not filter and change 08:21:49 ... would no longer have that to reach for at syntactical level 08:21:54 ... unfortunate but not killer 08:21:59 emilio: not thing is weird ,agree 08:22:02 ... any use case? 08:22:13 TabAtkins: not pseudo elements, but if pseudos are allowed inside is and can change subject 08:22:18 ... why not relative selectors 08:22:24 ... (examples) 08:22:39 ... at that point we're working on some really shaky foundations 08:22:44 ... a before pseudo is a child of an element 08:22:52 ... if is can change to child, it should be able to change to any child 08:23:04 ... not syntactically ambiguous, would run on same restrictions as nesting 08:23:08 ... need combinator at start to trigger 08:23:17 ... but if we're going in for a penny, might as well go in for a pound 08:23:26 ... use cases for selecting an element and one of its children 08:23:26 q? 08:23:28 ... can do with nesting 08:23:33 .foo { &, & > .bar {...}} 08:23:36 emilio: thinking about ... 08:23:43 TabAtkins: this nesting example is totally fine 08:23:49 ack lea 08:23:49 ... being able to express that with is, why not? 08:24:04 lea: I think the top priority is that nesting needs to have expected semantics in evrey case 08:24:14 ... nice to have multiple ways to express but lower priority 08:24:23 ... if we ship this, will always violate principle of least surprise 08:24:31 ... is there a subset of cases where it does what author expects? 08:24:38 adamargyle has joined #css 08:24:43 ... I think I came up with cases where even terminal pseudos didn't work, not sure 08:24:53 ... I wonder if there's any subset where what TabAtkins is describing is expected 08:24:56 ... maybe scope down to that 08:25:09 ... and continue to keep other cases as invalid until we find a way to deal with them correctly 08:25:21 ... I was also thinking along the lines of what astearns said 08:25:27 ... maybe we can internally rewrite how & works 08:25:45 ... maybe another path is to see if some limited expansion would prevent combintorial explosion 08:26:05 ack plinss 08:26:14 plinss: kind of chasing a red herring and conflating too many things here 08:26:24 ... nesting being defined with invisible is, should be considered an implementation detail 08:26:28 +1 plinss 08:26:31 ... nesting should just work as if a simple substitution 08:26:43 ... combinational explosions okay, that might be behavior you get 08:26:51 TabAtkins: minus specificity 08:26:57 ... other than that I agree 08:27:12 plinss: if we have a problem here with impl detail of nesting, we shouldn't fix that by changing behavior of is 08:27:20 ... don't have a problem with changing behavior with is 08:27:32 ... if you allow pseudos, you should allow combinators, since a pseudo is a combinator 08:27:40 emilio: if it has the outcome of also fixing nesting ... 08:27:49 plinss: if it also fixes a way of impling nesting, awesome 08:27:52 ... don't need to redefine 08:28:03 TabAtkins: What I'm hearing is decent appetite in WG to make nesting work better 08:28:06 +1 08:28:09 ... even if there's some selectors that can't be written without it 08:28:13 ... or causing an explosion 08:28:19 +1 08:28:23 ... and continue to pursue separately how to write without an explosion 08:28:26 ... okay 08:28:30 astearns: is this what you wanted miriam? 08:28:35 miriam: yes 08:28:52 astearns: are we taking back to issue or is there a scoped resolution? 08:29:02 TabAtkins: Proposed: Go ahead and fix nesting, don't worry about non-nesting yet 08:29:10 q+ 08:29:25 ack emilio 08:29:42 PROPOSED: Go ahead and fix nesting for pseudo-elements, don't worry about :is() yet 08:29:44 emilio: this has the issue of effectively getting same semantics as keeping is-like substitution 08:29:50 ... and making is be able to change target to pseudo element 08:29:54 ... would rather investigate that 08:30:01 ... don't think it's hard to prototype, kind of annoying 08:30:07 TabAtkins: don't have to tie together, I just want them tied together 08:30:15 TabAtkins: https://codepen.io/leaverou/pen/ByKKByO?editors=1100 08:30:27 emilio: maybe we can start ... 08:30:42 astearns: does it change your calculation if you account ofr the fact that some aren't happy with the is behavior change? 08:30:50 emilio: want to change is to match what you want for nesting 08:31:01 ... so you can do (example) 08:31:11 TabAtkins: but then I want relative selectors to work 08:31:17 emilio: fair but a bigger extension 08:31:29 plinss: that's the part I'm not clear on what the result is 08:31:40 emilio: I want this... 08:31:45 .foo:is(.bar, ::before, ::after) == .foo.bar, .foo::before, .foo::after 08:31:46 ... to be the same as ... 08:31:55 ntim: I disagree with that 08:32:02 emilio: why? 08:32:08 ... isn't that what people want? 08:32:13 ntim: .foo is not a before pseudo 08:32:19 emilio: don't you want combinators there? 08:32:22 (this is the :-webkit-matches() behavior) 08:32:23 [crosstalk] 08:32:28 .foo:is(.bar, > .baz, > .bar) 08:32:31 plinss: if we put a combinator in is, what does that mean? 08:32:38 ... does combinator go before thing that is is or after? 08:32:41 emilio: what I typed 08:32:45 TabAtkins: yeah that should work 08:32:51 q+ 08:32:52 emilio: would be equivalent to... 08:32:56 `.foo:is(.bar, > .baz, > .bar) == .foo.bar, .foo > .baz, .foo > .bar` 08:33:03 ntim: why do we want to overload is? create a new pseudo class? 08:33:09 q- 08:33:11 emilio: maybe but if we introduce that concept for nesting may as well 08:33:20 TabAtkins: if we do this in pseudo space, no reason not to put it in is 08:33:26 ntim: maybe :with? 08:33:33 ... would make more sense as you read it 08:33:38 ... .foo isn't a before pseudo element 08:33:42 ... and isn't whatever overload 08:33:47 emilio: is this only about naming of is? 08:33:49 ntim: yes 08:33:52 emilio: what about where? 08:34:02 TabAtkins: :is is not meant to be read as "argments are things before" 08:34:11 ... it's "I'm selecting something that's one of these' 08:34:27 plinss: if you give me that explanation and write what emilio did 08:34:39 ... the thing you're selecting is a .baz that is descendant of something that's also .foo 08:34:46 ... so it's .foo.baz, not .foo > .baz 08:34:56 TabAtkins: now you're arguing for accepting my idea as stated 08:35:05 plinss: trying to get an idea of what combinator means 08:35:10 ... emilio's expectation doesn't match mine 08:35:16 TabAtkins: what emilio wrote is 08:35:27 ... the pseudo element version is what :-webkit-matches did 08:35:41 ... if it had a relative selector version as well, it would have same semantics emilio listed 08:35:44 I expect: `.foo:is(.bar, > .baz, > .bar)` == `.foo.bar, .baz > .foo , .bar > .foo` 08:35:45 ... but we don't have to solve this right now 08:35:55 ... could take resolution to fix nesting and figure out how to fix as selector later 08:36:20 plinss: want to clarify that fix nesting means nesting does naive substitution and got combinatorial explosion if that's the result 08:36:24 TabAtkins: as much as possible yes 08:36:41 emilio: I find it weird because then you need to define what specificity of pseudo being there vs not 08:36:45 ... right now is will drop pseudos 08:36:49 ... nesting will right now drop pseudos 08:36:56 s/nesting does/nesting behaves as/ 08:36:56 ... and not consider their specificity in there 08:37:05 TabAtkins: but if you put pseudos as innermost nested it works fine 08:37:08 `.foo:is(> .baz)` reads to me as ".foo which is a child of .baz", so `.baz > .foo` 08:37:13 emilio: you're adding a selector that can select elements in a pseudo 08:37:19 ... would rather make this work in :is 08:37:26 ... don't see any reason not to do it if we're going to have this functionality 08:37:28 TabAtkins: agree 08:37:36 ntim: not saying we shouldn't express it, should be an issue for later 08:37:51 astearns: I think people in the room agree that this should be expressible, just disagree on how to get it done 08:37:57 ... we have agreement on how to make it work with nesting 08:38:09 emilio: would like to preserve the fact that nesting can be expressed in terms of regular selectors 08:38:15 ... answers a lot of questions about how selectors work 08:38:25 ... if you have .foo:is(*)before after 08:38:30 ... .before after don't contribute to specificity 08:38:33 ... with nesting now they do 08:38:42 TabAtkins: they're valid but pseudo elements don't 08:38:51 TabAtkins: do pseudo elements have specificity? I don't think they do 08:39:00 emilio: I think they do, but right now it might not be visible since you can only have 1 08:39:07 ... and it only competes with 1 other pseudo 08:39:29 ... when we implemented nesting, one thing that came up is that browsers do have some kind of ? specificity and they were getting mixed 08:39:42 plinss: I get your desire to have a pseudo class that behaves exactly like this, and support it 08:39:44 ... not usre it should be is 08:39:51 emilio: not sure it should not be is 08:39:54 ... extending where is something new 08:40:05 plinss: not saying we ahve to invent something new, doesn't have to be is 08:40:12 emilio: guess it depends how you read it 08:40:19 ... if I select something that is this or that, that makes sense to me 08:40:27 plinss: is and notion of combinators starts confusing what is is 08:40:29 ... which is th eis 08:40:42 ... is the is before the combinator or is the is after the combinator 08:40:46 ... not sure is is the right thing here 08:40:55 TabAtkins: should be read as thing after combinator, selecting thing matching argument 08:41:08 plinss: you're basically lofting the combinator in front of the thing outside is 08:41:09 TabAtkins: no 08:41:14 plinss: then what does combinator do? 08:41:23 TabAtkins: as if you just threw away other args and just removed the is 08:41:28 ntim: that's not how I read it 08:41:34 TabAtkins: that's how webkit-matches does it 08:41:46 plinss: that interpretation may make sense if you call it matches, not if you call it is 08:41:57 emilio: something we need to decide on is, what specificity these pseudos have 08:42:02 ... some pseudos have class specificity 08:42:07 ... should is have class specificity? 08:42:08 Issue about the specificity of pseudo-elements in nesting: https://github.com/w3c/csswg-drafts/issues/9600 08:42:10 ... something else? 08:42:16 ... that selector can now be matched against ? 08:42:26 TabAtkins: class specificity, say what they have 08:42:29 emilio: only relative ot other v-ts righ tnow 08:42:40 ... needs to be defined in terms of global selector space 08:43:27 TabAtkins: what is the specificity of an element midway down a pseudo stack 08:43:31 ntim: already defined? 08:43:34 TabAtkins: not yet but will become 08:43:43 plinss: for a long time there was a restriction on pseudos, did we relax? 08:43:45 TabAtkins: yes 08:43:54 ntim: vt pseudos have specificity 08:44:15 emilio: but only against each other right now 08:44:23 kbabbitt has joined #css 08:44:27 [missed] 08:44:43 TabAtkins: emilio can you raise that as an issue? 08:44:46 emilio: I think we should implement this in :is, but fine 08:45:00 astearns: consensus by exhaustion? 08:45:48 PROPOSED: Resolve on behavior for nesting, and thinking about non-nesting later 08:45:54 scribe+ 08:46:24 RESOLVED: Resolve on behavior for nesting, and thinking about non-nesting later 08:46:35 mjackson has joined #css 08:47:01 ACTION: Emilio to file issue about specificity 08:47:04 topic: https://github.com/w3c/csswg-drafts/issues/5265 08:47:06 github: https://github.com/w3c/csswg-drafts/issues/5265 08:47:16 github-bot: take up https://github.com/w3c/csswg-drafts/issues/5265 08:47:16 emilio, ignoring request to take up https://github.com/w3c/csswg-drafts/issues/5265 which is already the current github URL 08:48:04 GameMaker has joined #css 08:48:36 oriol: In the marker pseudo, we restrict which props that can be used, because layout is special, and we wanted to avoid browsers doing random things. but there are properties like counter that affect only style and not layout. 08:48:53 ... I have been using it in counter, which is convenient 08:50:20 ... also you can use open-quote/closed-quote in content to increase the quotes, but you can't increase the counters, or the use the symbols increased by the quotes 08:50:27 fantasai had mild objection 08:50:36 +1 08:50:37 oriol: I think we should just allow it 08:51:00 fantasai said she had opinions on this issue 08:51:32 sakhapov: Is the ordering relative to ::before defined? 08:51:37 oriol: yes 08:51:50 q+ 08:51:55 I was concerned that people will get confused about what the counter increment is doing 08:52:01 and not get the results they're expecting 08:52:06 TabAtkins: It's a mystery for me why ::marker pseudo-elements are not fully styleable, but fantasai had opinions 08:52:16 people do that with ::before today and it does indeed work reasonably 08:52:24 emilio: Isn't that because the ::marker layout is not defined? 08:52:36 oriol: but counters don't affect layout 08:53:03 s/::marker layout/outside-marker layout 08:53:12 ntim: can't counters affect layout? 08:53:38 oriol: maybe we should leave it for later if fantasai is strongly opposed 08:53:41 emilio: they affect layout but anything you can put with text you can put on a counter 08:53:43 it's mainly we don't know how the counter is laid out, but to the extent that it contains text it's fine 08:54:13 astearns: i know you said this is mostly a convenience because you can work off the element itself 08:54:25 oriol: for most cases yes, but 08:54:43 mjackson has joined #css 08:55:18 oriol: i have a ::before pseudo, increment the counter, and print it with content, I should be able to do the same in ::marker 08:55:21 fantasai: would you object to us resolving to allow this, or is it more a minor concern 08:55:39 oriol: I thought that it was more straightforward than expected 08:56:03 minor concern, just want to be sure we're not causing more problems than we solve 08:56:53 PROPOSED: allow counter and quotes properties in ::marker, revisit later if there are a lot of problems 08:57:07 fantasai: ^ 08:57:23 objections? 08:57:34 RESOLVED: allow counter and quotes properties in ::marker, revisit later if there are a lot of problems 08:57:53 topic: end 08:59:15 zakim, end meeting 08:59:15 As of this point the attendees have been alisonmaher, oriol, noamr, kizu, flackr, ydaniv, kbabbitt, dholbert, miriam, rachelandrew, vmpstr, emilio, masonf, lea, kzms, adamargyle, 08:59:18 ... dbaron, ntim, chrishtr, Penny, kush, bts, present, diekus, zcorpan, ChrisL, Euclid, dmangal, Ragvesh 08:59:18 RRSAgent, please draft minutes v2 08:59:19 I have made the request to generate https://www.w3.org/2025/11/12-css-minutes.html Zakim 08:59:25 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 08:59:25 Zakim has left #css 08:59:33 The problems I expect aren't on the implementation side. It's on the author side, that people might get some confused output 08:59:57 yes, that was a clear input into our discussion. thanks for following along in irc 09:00:03 Like if you increment on ::marker, but make it not a list-item, then you don't have numbers that you expect 09:00:55 Best practice is to increment on the element itself. 09:00:55 mjackson has joined #css 09:01:01 You're less likely to get into trouble that way. 09:01:26 I have made the request to generate https://www.w3.org/2025/11/12-css-minutes.html fantasai 09:01:32 mjackson has joined #css 09:06:43 mjackson has joined #css 10:00:03 mjackson has joined #css 10:50:28 karlcow has joined #css 11:05:12 mjackson has joined #css 11:38:03 Penny has joined #css 12:03:35 Patrick_H_Lauke has joined #css 12:05:29 Patrick_H_Lauke has joined #css 12:08:03 Penny has joined #css 12:13:31 SimonSapin has left #css 12:41:08 mjackson has joined #css 14:26:05 mjackson has joined #css 14:27:23 castastrophe has joined #css 15:06:57 mjackson has joined #css 16:44:51 castastrophe has joined #css 16:52:22 dholbert has joined #css 19:12:03 github-bot has joined #css 20:06:06 github-bot has joined #css 21:18:58 sorvell has joined #css 22:27:49 Linux_Kerio has joined #css 00:22:32 karlcow has joined #css 03:37:06 croissant has joined #css 03:44:16 Linux_Kerio has joined #css 13:05:00 CSSWG_LogBot has joined #css 18:18:08 nigel has joined #css 18:24:43 nigel_ has joined #css 18:43:12 nigel has joined #css 19:02:35 nigel has joined #css 19:20:46 nigel has joined #css 19:38:18 nigel has joined #css 19:55:19 nigel has joined #css 20:14:28 nigel has joined #css 20:32:28 nigel has joined #css 20:49:23 nigel has joined #css 21:01:44 nigel has joined #css 21:19:51 nigel has joined #css 21:37:19 nigel has joined #css 21:54:28 nigel has joined #css 22:13:58 nigel has joined #css 22:32:53 nigel has joined #css 22:50:56 nigel has joined #css 23:03:08 nigel has joined #css 23:08:29 nigel_ has joined #css 23:27:15 nigel has joined #css 23:46:36 nigel has joined #css 23:58:28 nigel has joined #css 00:04:10 nigel_ has joined #css 00:23:05 nigel has joined #css 00:40:20 nigel has joined #css 00:59:52 nigel has joined #css 01:05:10 nigel has joined #css 01:23:25 nigel has joined #css 01:40:13 nigel has joined #css 01:58:22 nigel has joined #css 02:06:11 nigel has joined #css 02:22:59 nigel has joined #css 02:37:58 nigel has joined #css 02:56:45 nigel has joined #css 03:04:06 CSSWG_LogBot has joined #css 03:07:11 nigel has joined #css 03:24:15 nigel has joined #css 03:42:45 nigel has joined #css 03:59:48 nigel has joined #css 04:08:13 nigel has joined #css 04:27:20 nigel has joined #css 04:45:33 nigel has joined #css 05:04:23 nigel has joined #css 05:09:14 nigel has joined #css 05:25:44 nigel has joined #css 05:44:37 nigel has joined #css 06:03:41 nigel has joined #css 06:10:34 nigel_ has joined #css 06:28:59 nigel has joined #css 06:47:32 nigel has joined #css 07:06:10 nigel has joined #css 07:11:35 nigel_ has joined #css 07:29:54 nigel has joined #css 07:48:42 nigel has joined #css 08:06:31 nigel has joined #css 08:12:37 nigel_ has joined #css 08:30:23 nigel has joined #css 08:49:54 nigel has joined #css 09:08:28 nigel has joined #css 09:27:05 nigel has joined #css 09:44:31 nigel has joined #css 10:01:33 nigel has joined #css 10:20:19 nigel has joined #css 10:38:40 nigel has joined #css 10:50:39 nigel has joined #css 11:07:57 nigel has joined #css 11:24:33 nigel has joined #css 11:33:04 karlcow has joined #css 11:41:33 nigel has joined #css 11:58:31 nigel has joined #css 12:15:25 nigel has joined #css 12:34:14 nigel has joined #css 12:51:37 nigel has joined #css 13:09:16 nigel has joined #css 13:28:40 nigel has joined #css 13:47:23 nigel has joined #css 13:52:59 nigel_ has joined #css 14:10:35 nigel has joined #css 14:30:03 nigel has joined #css 14:46:51 nigel has joined #css 15:05:42 nigel has joined #css 15:24:04 nigel has joined #css 15:39:56 Linux_Kerio has joined #css 15:43:02 nigel has joined #css 16:00:02 nigel has joined #css 16:18:13 nigel has joined #css 16:35:40 nigel has joined #css 16:52:26 nigel has joined #css 17:10:03 nigel has joined #css 17:28:16 nigel has joined #css 17:46:00 nigel has joined #css 18:05:34 nigel has joined #css 18:22:41 nigel has joined #css 18:39:14 nigel has joined #css 18:58:04 nigel has joined #css 19:03:41 nigel_ has joined #css 19:22:38 nigel has joined #css 19:41:12 nigel has joined #css 19:59:23 nigel has joined #css 20:17:17 nigel has joined #css 20:35:00 nigel has joined #css 20:53:33 nigel has joined #css 21:11:39 nigel has joined #css 21:31:15 nigel has joined #css 22:01:58 nigel has joined #css 22:18:55 nigel has joined #css 22:36:52 nigel has joined #css 22:55:58 nigel has joined #css 23:13:53 nigel has joined #css 23:31:04 nigel has joined #css 23:34:21 karlcow has joined #css 23:47:33 nigel has joined #css 00:06:05 nigel has joined #css 00:25:36 nigel has joined #css 00:43:51 nigel has joined #css 00:47:51 nigel has joined #css 01:07:13 nigel has joined #css 01:19:32 Snugug has joined #css 01:26:03 nigel has joined #css 01:39:52 karlcow has joined #css 01:45:37 nigel has joined #css 01:48:58 nigel_ has joined #css 02:06:58 nigel has joined #css 02:25:11 nigel has joined #css 02:44:34 nigel has joined #css 02:49:52 nigel has joined #css 03:07:20 nigel has joined #css 03:16:40 nigel has joined #css 03:33:33 nigel has joined #css 04:08:30 nigel has joined #css 04:25:49 nigel has joined #css 04:45:17 nigel has joined #css 04:52:13 nigel_ has joined #css 05:08:45 nigel has joined #css 05:26:11 nigel has joined #css 05:44:59 nigel has joined #css 05:53:14 nigel has joined #css 06:12:07 nigel has joined #css 06:29:18 nigel has joined #css 06:46:40 Linux_Kerio has joined #css 06:48:34 nigel has joined #css 06:54:13 nigel_ has joined #css 07:12:10 nigel has joined #css 07:31:03 nigel has joined #css 07:49:15 nigel has joined #css 07:54:52 nigel_ has joined #css 08:13:14 nigel has joined #css 08:31:49 nigel has joined #css 08:50:07 nigel has joined #css 09:08:29 nigel has joined #css 09:26:20 nigel has joined #css 09:43:18 nigel has joined #css 10:00:06 nigel has joined #css 10:17:13 nigel has joined #css 10:35:51 nigel has joined #css 10:54:33 nigel has joined #css 11:13:13 nigel has joined #css 11:46:10 nigel has joined #css 12:05:05 nigel has joined #css 12:05:28 nigel has joined #css 12:24:25 nigel has joined #css 12:43:57 nigel has joined #css 12:49:55 karlcow has joined #css 13:01:20 nigel has joined #css 13:18:02 nigel has joined #css 13:35:53 nigel has joined #css 13:44:40 Linux_Kerio has joined #css 13:46:53 nigel has joined #css 14:04:02 nigel has joined #css 14:23:23 nigel has joined #css 14:36:04 projector has joined #css 14:36:34 leaverou has joined #css 14:37:04 Rossen has joined #css 14:37:35 shans has joined #css 14:38:05 sylvaing has joined #css 14:40:32 nigel has joined #css 14:57:40 nigel has joined #css 15:34:09 nigel has joined #css 15:53:18 nigel has joined #css 16:10:35 nigel has joined #css 16:28:14 nigel has joined #css 16:46:55 nigel has joined #css 17:06:23 nigel has joined #css 17:24:21 nigel has joined #css 17:41:20 nigel has joined #css 17:59:19 nigel has joined #css 18:18:33 nigel has joined #css 18:36:50 nigel has joined #css 18:53:19 nigel has joined #css 19:12:13 nigel has joined #css 19:30:19 nigel has joined #css 19:42:40 nigel has joined #css 19:48:16 nigel_ has joined #css 20:04:02 nigel has joined #css 20:21:53 nigel has joined #css 20:23:27 nigel has joined #css 20:55:20 nigel has joined #css 21:15:31 nigel has joined #css 22:51:08 karlcow has joined #css 07:31:25 antonp has joined #css 07:31:27 CSSWG_LogBot_ has joined #css 08:56:44 nigel has joined #css