08:01:50 RRSAgent has joined #css 08:01:54 logging to https://www.w3.org/2024/06/11-css-irc 08:01:54 RRSAgent, make logs Public 08:01:55 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 08:02:33 present+ 08:02:42 present+ 08:02:48 present+ 08:03:29 alisonmaher has joined #css 08:03:54 present+ 08:04:10 present+ 08:04:47 jarhar has joined #css 08:04:51 present+ 08:04:57 masonf has joined #css 08:04:58 Oriol Brufau, Igalia 08:04:58 present+ 08:05:04 Alison Maher, Microsoft 08:05:06 kbabbitt has joined #css 08:05:07 present+ 08:05:11 matthieud has joined #css 08:05:16 present+ 08:05:49 Florian Rivoal, Invited Expert 08:06:07 Matthieu Dubet, WebKit (Apple) 08:06:08 Rachel Andrew, Google Chrome 08:06:08 Alan Stearns, Adobe 08:06:11 Ian Kilpatrick, Google Chrome 08:06:15 Kevin Babbitt, Microsoft 08:06:16 Roman Komarov, Invited Expert 08:06:20 Joey Arhar, Google Chrome 08:06:22 present+ 08:06:25 Yehoatan Daniv, Wix 08:06:29 Rune Lillesveen, Google 08:06:48 Bramus, Google Chrome 08:07:20 lwarlow has joined #css 08:07:22 Eric Meyer, Igalia 08:07:32 khush has joined #css 08:07:43 present+ 08:08:02 present+ 08:08:22 present+ (irc-only for most of the morning tho) 08:09:00 andruud has joined #css 08:09:05 scribenick: emeyer 08:09:11 present+ 08:09:14 github-bot, take up 6900 08:09:14 emeyer, I can't comment on that because it doesn't look like a github issue to me. 08:09:22 github-bot, take up https://github.com/w3c/csswg-drafts/issues/6900 08:09:24 Topic: Republishing Tasks Permathread 08:09:24 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6900. 08:09:31 btw, I can hear Alan great, but not whoever else is talking right now 08:09:58 fserb has joined #css 08:10:21 florian: Would like to republish css-contain-1 08:10:47 …When we maintain a rec as a rec and want to change but aren't sure if we're ready, we can put in informal notes about how we want to change it 08:11:14 …As these things mature, they fulfill all criteria and the notes come out 08:11:34 …We're at the point of those having been addressed 08:11:35 present+ 08:11:50 present+ 08:11:57 andreubotella has joined #css 08:12:02 …There are three changes still proposed, which if we all agree to, we can reissue the rec 08:12:11 astearns: Any questions or comments? 08:12:38 …Proposed resolution: We request a updated recommendation, with the three proposed changes folded in 08:12:52 …No objections; we are resolved 08:12:56 present+ 08:14:26 I have no objections to the current order, if elika is happy with it 08:14:44 RESOLVED: We request a updated recommendation, with the three proposed changes folded in 08:14:58 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10182 08:14:58 Topic: [css-anchor-1] position-visibility show/hide animations 08:14:58 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10182. 08:15:42 andreubotella4 has joined #css 08:16:01 TabAtkins: While doing implementation work, Philip noted authors probably want to animate elements disappearing and reappearing 08:16:12 …How do we do it? Philip proposed properties for that 08:16:33 …My proposal is to have position visibility change the computed value, and key off of that to do transitions 08:16:44 q+ 08:16:50 …Either of these are potentially doable, but Roma has a comment just posted 08:17:16 ack kizu 08:17:19 kizu: The only thing I think we don't have is an entry animation 08:17:27 …There's no way to hook on to when that fires 08:17:53 TabAtkins: That's reasonable, and it points to a larger use case which is the ability to trigger an animation on a transition starting 08:18:10 …That seems generically useful for several cases and would avoid needing new properties 08:18:31 fantasai: Making that happen would let you control the flip point, but it won't give you the ability to animate things like color without JS 08:18:38 ack fantasai 08:18:49 TabAtkins: Correct; doing more would require other things, but this seems like a big enough request for us to do 08:18:51 present+ 08:19:08 bkardell_ has joined #css 08:19:21 q+ 08:19:30 …I've thought about ways to trigger state properties and would be willing to defer animation in order to consider that, but I could see us doing this for properties now and considering the generic solution later 08:19:32 ack futhark 08:19:43 futhark: Isn't this quite simlar to the overlay property for popovers? 08:19:52 present+ 08:20:04 TabAtkins: The reason we mess with the overlay state is so it stays consistent across things that can't be described in the CSS 08:20:04 una has joined #css 08:20:11 present+ 08:20:33 TabAtkins: Did we just trigger off a DOM state? 08:20:41 futhark: Yeah, but we don't have that possibility here 08:20:53 q+ 08:21:25 TabAtkins: I could go dig up my old notes, but do we want to defer this for a little while to make a more informed decision? 08:21:27 ack kizu 08:21:37 kizu: I think we can defer 08:21:42 q+ 08:21:51 ack bramus 08:22:20 bramus: Want to mention that a lot of authors have been aasking to trigger view transitions on a state change, such as clicking on an input 08:22:35 q+ 08:22:40 TabAtkins: Good point - we might be able to rely on subscribing to a transition, but that might be a frame delay 08:22:43 ack khush 08:23:04 khush: Since you said it's a state transition, I was thinking of exposing it as a pseudo-class 08:23:21 …The only thing is, you dn't want anyone to put in a position change 08:23:52 TabAtkins: We can't generally do an allow/block list due to circular references, but you can certainly already cause those with :hover 08:24:23 …We consider that acceptable, so it would probably be okay to not restrict and assume authors won't do things that make the experience awful for their users 08:24:52 astearns: Sounds like we're going to defer for now, evaluate a more general solution, and decide if the general solution can be implemented in time 08:25:17 TabAtkins: Should we resolve to do this and leave them open as hooks for later? 08:25:34 fantasai: I think that's a good idea, but I'd want to ensure that will work with inheritance 08:25:35 s/this/visibility/ 08:25:40 s/do this/do the visibility:strongly-hidden thing/ 08:25:47 …Probably want a better word than strongly hidden 08:25:52 TabAtkins: That sounds reasonable 08:26:34 TabAtkins: Proposing that when position visibility hides something, it does so by causing the visibility property to compute to a new forced-hidden value 08:27:01 q+ 08:27:12 "Making an element strongly hidden makes it act as if it and all of its descendants were visibility: hidden, regardless of what their actual visibility value is." 08:27:20 ack ydaniv 08:27:20 astearns: My question is: can authors use this forced-hidden value? 08:27:25 s/forced-hidden/force-hidden/ 08:27:27 s/forced-hidden/force-hidden/ 08:27:30 q+ 08:27:35 ydaniv: If we have a value, we could do it with container style queries, right? 08:27:49 ack kbabbitt 08:27:53 TabAtkins: Yes. I'm not super familiar with the limitations on style queries but it should still be available 08:28:13 kbabbitt: What's the interaction between this and !important on a descendant 08:28:17 container style queries query the parent of the element you're styling, so it's not quite ideal, but could do some stuff with it 08:28:33 TabAtkins: If your ancestor is force-hidden, you're force-hidden 08:28:41 …It's a display: none without blowing away the boxes 08:28:51 …So they still take up the space 08:29:16 fantasai: We might want a value that keeps the boxes but doesn't display them 08:29:31 TabAtkins: Maybe 08:29:40 s/might/might also/ 08:29:47 astearns: Anyone who would prefer to wait and digest before resolving? 08:29:59 s/doesn't display them/takes them out of flow/ 08:30:27 s/of flow/of flow while not displaying them (more similar effect to display:none)/ 08:30:29 Proposing that when position visibility hides something, it does so by causing the visibility property to compute to a new forced-hidden value 08:30:41 "force-hidden" 08:30:53 astearns: RESOLVED: when position visibility hides something, it does so by causing the visibility property to compute to a new force-hidden value 08:31:07 RESOLVED: when position visibility hides something, it does so by causing the visibility property to compute to a new force-hidden value 08:31:28 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10049 08:31:28 Topic: [css-anchor-position] Nailing down the position-try-options "flip" behavior 08:31:28 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10049. 08:31:55 https://drafts.csswg.org/css-anchor-position-1/#swap-due-to-a-try-tactic 08:32:03 TabAtkins: Elika brought this up to bring it to WG attention 08:32:37 …As far as I know, this all is good and it works as expected in Chrome 08:32:47 …Happy to tweak as necessary if anything is wrong 08:33:04 ack fantasai 08:33:05 fantasai: Do we flip the safe area sides on the end function 08:33:25 …If you stick this into a `left` property, does it get flipped to the `right` property? 08:33:47 s/end/env()/ 08:34:23 TabAtkins: Great question; right now, we already substitute variables and I think the answer is we substitute pre-flipping 08:34:41 …So what ever it resolves to on the left, it resolves to that and is flipped to the right 08:34:59 …This is what you want for vars, but for env() specifically, we could do something different if we need to 08:35:20 …I'm not certain what the ideal behavior would be, whether we want to do that before or after 08:35:41 …In general, env() is used fairly little, so we should be able to experiement and change if need be 08:35:50 astearns: Any other comments? 08:36:09 fantasai: I note that the margin properties are only mentioned in an example 08:36:28 TabAtkins: They don't need to be mentioned otherwise because it refers to the list of position-try properties and margins are on the list 08:36:44 astearns: Woiuld you like a resolution from the WG? 08:37:02 fantasai: Could or not, but I wanted to bring to the WG's attention that this is happening 08:37:22 astearns: So please take a look at this, and fantasai please look at where the swapping should happen 08:37:42 fantasai: I think it should happen before, but I'm not sure 08:37:43 TabAtkins: We'll open another issue for that 08:37:51 s/not sure/not sure it's implementable/ 08:38:13 andreubotella has joined #css 08:38:27 github-bot, take up https://github.com/w3c/csswg-drafts/issues/9356 08:38:27 Topic: [css-anchor-position-1][css-display-4] Anchor Positioning and Display Order 08:38:27 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9356. 08:39:20 kizu: I noticed sometimes we might want to only change behavior from one anchor element to another 08:39:26 q+ 08:39:42 …Mostly for cases like side notes and other things that are not covered by the popover API 08:40:22 …Given the API probably handles the most common cases, this may not be so pressing, but in a reading-order future, we might want to allow authors to make changes 08:40:40 ack una 08:40:41 q+ 08:41:35 una: I agree that with popovers you're covering tab-navigation as expected 08:41:49 …I agree we do need an implicit anchor relationship 08:42:03 …This feels like an HTML thing 08:42:16 …You also have other examples in that post that show the need 08:42:25 …I think an anchor attribute would be best 08:42:25 ack TabAtkins 08:42:47 TabAtkins: Agreed; my major objection here is that anchoring can be used for lots of things and we can't reliably determine a relationship 08:43:03 …That's a complex and manual enough example that I don't think we can do this reliably 08:43:13 …Good announcement behavior is important 08:43:20 q+ 08:43:30 …The HTML AAM opened their own issue on this, and they're talking about how to bridge with us 08:43:55 …My proposal is that for the anchor positioning spec, we close with not changes but we keep working with other groups to figure out the solution, which is needed 08:44:05 ack fantasai 08:44:19 fantasai: Agree with Una that this will need markup support, and it should be something in the HTML 08:44:31 …The control is going to need to invoke a bunch of accessibility bindings 08:44:43 And then if there's an anchor attribute, that'll establish the "implicit anchor element" for anchor post, which'll mean authors don't have to repeat themselves in CSS 08:44:49 …But I don't think ARIA is the right approach, even though we'll rely on it underneath whatever markup there is 08:45:11 q+ 08:45:13 …If we want authors to be able to use these, it should be sufficient that they'd be willing to use it instead of CSS 08:46:00 ack masonf 08:46:01 …We shouldn't change things now, but I think we should keep this open until we get the information on what will be used so we can put it in the spec 08:46:13 s/sufficient/sufficiently convenient/ 08:46:19 masonf: +1 to HTML markup, like popover does 08:46:24 s/change things now/change the spec normatively/ 08:46:42 …Switching tab ordering between layout order and DOM order is trickier than it sounds 08:47:04 …There has been some pushback on the anchor attribute in general, so we might want to bring this up with the WHAT WG 08:47:05 ack una 08:47:09 s/instead of CSS/instead of CSS. For example, in CSS we have the ability to scope patterns so that you don't have to create unique identifiers for every instance of a repeated pattern; that needs to be available in HTML also/ 08:47:17 una: There's new reasoning to have the anchor attribute 08:47:32 …I really think something like popover feels like the most seamless solution 08:47:42 s/should be something in the HTML/should be something in the HTML. And also should allow anchoring either before or after the element./ 08:47:56 …Handling multiple anchors like on Wikipedia is super annoying to do solely throught CSS 08:47:57 ack fantasai 08:48:13 fantasai: I think the anchor attribute as currently specced is not going to be enough 08:48:24 …It only works with IDs, for example 08:48:43 …So dealing with repeated patterns on a single page doesn't work 08:48:58 …It also needs to be able to anchor an element before or after the element 08:49:16 …The current proposal doesn't hook into accessibility bindings, so it will have to do that 08:49:49 una: In the authoring process, if they have a new tooltip it will probably get a new ID, so I don't think having to do that here would be a major barrier for authors 08:50:06 fantasai: If CSS is significantly more convenient, then they'll use that 08:50:16 …Right now they do it because there are no other options 08:50:30 s/do it/use IDs/ 08:50:31 …We just need to design a syntax so we can extend in that direction 08:51:04 astearns: Soundsl ike we're going to keep this issue open, but for now will pursue a markup-based solution that can hit all the issues raised here 08:51:25 astearns: Moving on… 08:52:02 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8895 08:52:02 Topic: [css-anchor-1] Allow anchoring to a particular fragment 08:52:02 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8895. 08:52:42 TabAtkins: It was raised that there's several possible boxes of an anchor that could be anchored to 08:52:56 …Spec says the axis-aligned bounding box of fragments 08:53:25 …This is reasonable most of the time, but there are probably cases where we want to anchor to other boxes, like the margin box 08:53:46 …There's plenty of space in the syntax to declare which box or fragment you want to anchor to 08:54:09 …There are some proposed values like first and last; I might want first-fragment and last-fragment to be more clear 08:54:12 +1 to longer keyword for first/last fragment 08:54:18 q+ 08:54:26 …We would still default to the current behavior 08:54:38 q+ 08:54:42 …Does this sound like something reasonable to pursue? 08:55:25 astearns: Box keywords, absolutely; not so convinced about fragments 08:55:31 ack astearns 08:55:49 TabAtkins: If something's split across a column-break, you probably want to pick one of the two fragments at some point 08:55:50 q+ 08:55:54 q+ 08:55:56 ack iank_ 08:56:07 iank_: Just making sure this is grounded in use cases 08:56:15 TabAtkins: Are any of the boxes a problem? 08:56:21 ack iank_ 08:56:32 q+ 08:56:37 iank_: Inner boxes like content and padding, but implementations tend to ignore the existence of scrollbars 08:57:03 …In CSS shapes, browser get the padding box wrong when there's a scrollbar 08:57:20 …Fine to have these values, but just want to make sure people are asking for them first 08:57:47 TabAtkins: Border and margin are the most obvious to have, and I don't like subsetting, but I'm okay with it to the extent that values are working well 08:58:02 iank_: Generally, padding-box and content-box of everything is broken with respect to scrollbars 08:58:19 ack fantasai 08:58:52 fantasai: I think a major use case for fragments is sometimes people want to put a doohickey at the beginning or end of an inline that can wrap to multiple lines 08:59:06 …I expect this would be used a lot when does against inline boxes 08:59:21 …Tab's CSS Day demo showed these box values would be valuable 09:00:11 …Content and padding are not as useful for a lot of use cases, but you could use them to place things on top of an anchor, like a "New" banner in the corner of some content 09:00:42 ack kizu 09:01:04 kizu: With wrapping inline elements, JS tooltips have this problem as well 09:01:38 ack una 09:01:38 …Wrapping through columns is the same case, but would we want to attach to whole column fragments? 09:02:02 una: I think anchors are confusing to authors 09:02:15 s/anchors/fragments/ 09:02:50 TabAtkins: I don't think we've really exposed fragments to authors; let's open an issue about terminology, or continue in this one 09:03:09 ack khush 09:03:19 khush: When we did view transitions, this came up there as well 09:03:29 https://github.com/w3c/csswg-drafts/issues/8339#issuecomment-1470268830 09:03:36 …It would be nice if we had a generic syntax to deal with other cases of fragments 09:03:59 …I vaguely recall us talking about being able to put this in selectors 09:04:12 iank_: No no no 09:04:14 TabAtkins: Good to know 09:04:52 fantasai: Back to margin/border box keywords, we also need to be able to specify this for the default anchor 09:05:14 …IN our exploration last July, position-anchor was a shorthand that let you include name and box 09:05:17 lea has joined #css 09:05:23 …Not sure what to do with the fragments case 09:05:26 present+ 09:05:32 q? 09:05:35 …What do authors call it when a thing splits across lines? 09:05:35 ack fantasai 09:05:35 fantasai, you wanted to point out for margin-box etc need to add it to default anchor 09:05:53 itsy-bitsy-splitsy-box 09:06:37 https://fantasai.inkedblade.net/style/specs/css-anchor-exploration/#anchor-positioning 09:06:57 TabAtkins: I suggest we resolve to add margin-box and border-box keywords to anchor functions and position-anchor, and I'll open an issue about padding-box and content-box keywords, and we resolve to do something with fragmentation but we need to figure terminology 09:06:57 position-anchor -> position-anchor-name + position-anchor-box 09:07:31 astearns: A general fragmentation thing would be useful, but in this case, do we only want to have access to the first and last fragments? 09:07:36 fantasai: Yes 09:07:40 TabAtkins: Yes 09:07:58 astearns: Any objections to the first resolution? 09:08:01 (silence) 09:08:16 RESOLVED: add margin-box and border-box keywords 09:09:07 fantasai: We need to also resolve to add these to anchor-position property 09:09:31 s/keywords/keywords to anchor functions/ 09:09:34 s/anchor-position/position-anchor/ 09:09:43 …We probably want to split those into longhands position-anchor-name and position-anchor-box 09:09:50 …Any objections to adding those? 09:09:53 (silence) 09:10:36 RESOLVED: add properties position-anchor-name and position-anchor-box as longhands of position-anchor 09:20:26 I have made the request to generate https://www.w3.org/2024/06/11-css-minutes.html fantasai 09:21:21 s/ARIA is the right approach/asking authors to use ARIA markup directly is the right approach/ 09:21:33 Topic: Break 09:21:39 projecto- has joined #css 09:22:02 s/information on what will be used/information on best practices/ 09:22:09 leaverou_ has joined #css 09:22:33 s/the current proposal doesn't hook/Lastly, the current proposal doesn't hook/ 09:23:10 Rossen- has joined #css 09:23:40 shans_ has joined #css 09:24:11 sylvaing_ has joined #css 09:28:42 khush has joined #css 09:28:56 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8398 09:28:56 Topic: [cssom] How safe is it really to shorthandify properties? 09:28:56 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8398. 09:29:25 fantasai: We often want to extend CSS by turning an existing proeprty into a shorthand 09:29:33 …There are compatiobility problems with that 09:30:04 …This shows up in ennumeration of CSS style declarations, which is only supposed to ennumerate longhands 09:30:29 TabAtkins: We have some compatibility issues with turning anything into a shorthand 09:30:40 …A few APIs only care about longhands 09:30:57 …Sudden losses of properties cause bugs in people's programs 09:31:09 …We saw this with white-space and another one that escapes me 09:31:29 …Chrome got some bugs reported and ended up implementing a third, worse behavior 09:31:34 Seems like the appropriate solution is to fix these APIs, not to stop shorthandifying properties. Shorthands not showing up in these APIs (when they could be serialized) is a common author pain point. 09:31:47 …we prefer not to do that again, especially for things like positoin 09:31:56 (were you thinking of vertical-align as the other one?) 09:31:56 …We suspect position is un-shorthand-able 09:31:57 q+ 09:32:46 we did shorthandify something really old (overflow) without that much pain, right? 09:32:55 q+ 09:32:59 …David, you're right, it was vertical-align 09:33:06 alisonmaher has joined #css 09:33:16 …Emilio, I don't know how much pain there was with overflow 09:33:21 emilio, that was expanded out a very very long time ago; we just expanded the shorthand to allow two keywords recently 09:33:37 florian: Were you going to explain how to work around this with that behavior? 09:33:49 (I think overflow was a shorthand in WebKit from very long ago.) 09:33:49 TabAtkins: No, we really don't like it, and we don't want to do it any more 09:33:54 ack lea 09:34:27 lea: Seems like we should fix the APIs, not stop fixing CSS 09:34:39 q+ 09:34:48 …Shorthands not showing up in APIs is a perpetual author pain point 09:34:58 +1 to that 09:35:45 oriol: Don't completely agree with Lea 09:35:54 q+ 09:35:58 ydaniv has joined #css 09:36:08 …if you ask for a shorthand, you get a list of all the longhands, which seems normal 09:36:24 …I think it's duplicated information to have both shorthands and longhands 09:36:33 q+ 09:36:33 …From Tab, I have concerns about duplicating things 09:36:51 …Inline styles can be modified by CSSOM and that concerns me 09:37:02 q+ 09:37:04 ack oriol 09:37:29 …If you remove some longhands, keeping the shorthands would be broken, so there would need to be checks to avoid that 09:38:51 …If you're iterating longhands from end to beginning, and removing some, that would mess up indexes and you could end up going out of bounds 09:39:10 …Depending on what the author is doing, the application can break 09:39:12 q+ to say the current design is clearly problematic, and these don't seem like dealbreakers, just like the usual design decisions we need to make with every feature. And they certainly don't prove that we shouldn't even explore that avenue. I don't see how removing shorthands when the longhands are removed is that different from adding longhands when a shorthand is specified, it's not like what the author specified is preserved exactly 09:39:47 ack una 09:40:07 una: An example of where shorthands add confusion is recently we implemented transition-behavior with discrete value 09:40:11 transition-behavior: allow-discrete 09:40:35 …The transition acutally overrides the longhand 09:40:56 …This is one example where we'd let authors opt in, but we can't do that now 09:41:06 q- 09:41:06 …Shorthands aren't always better and can add confusion 09:41:57 ack florian 09:41:59 s/discrete/allow-discrete 09:42:47 florian: Need to think about this further, but for these APIs that care about the difference between short and longhands 09:43:10 kizu has joined #css 09:43:11 …If the values in use can be represented through the shorthand, then we include the shorthand only in the serialization 09:43:24 …If not, then we'd include the longhands only in the APIs 09:43:46 emilio: That causes really weird behavior 09:44:07 …The set of anuimated properties can become longer, and would change longstanding behavior 09:44:21 …You would maybe expect the four margin longhands, but suddenly you just get margin 09:44:34 …This would make computing the length of the ennumerator difficult 09:44:47 TabAtkins: I presume this would only apply for the handful of properties we list out 09:45:13 florian: I think emilio's point is good; there are a bunch of proeprties we can't do this for 09:45:24 …But could it work if we scoped it to certain properties? 09:45:42 …We could let existing proeprties continue to act as is, but open up new behaviors 09:45:59 dbaron: I think a bunch of this is going in a direction that's not the problem we need to address 09:46:09 …This is more about ennumeration and not about serialization 09:46:11 ack fserb 09:46:35 fserb: I'm confused about the scope of the question, whether it's about ennumeration or is it more generic? 09:46:54 florian: I think if you could serialize as the shorthand, you would do that; if you can't, then you wouldn't 09:47:03 ack fantasai 09:47:03 fantasai, you wanted to discuss minimal compat fix 09:47:11 fantasai: I think as Tab said, we can't do this for all proeprties 09:47:34 …For transition stuff, perhaps we could include both shorthand and longhand safely 09:48:06 …For the ennumeration, we'd keep a list and if the longhands can be represented as a shorthanded value that's one of the values that are legacy-constrained 09:48:18 q+ 09:48:29 …If the longhands have extra values that can't be represented in that limited syntax, we ennumerate the longhands 09:48:54 alisonmaher has joined #css 09:49:07 …So for white-space, if you gave it some new unrecognized value, then you'd ennumerate the longhands 09:49:37 dbaron: My understanding of the ennumeration problem is that there's no concern whatsoever about the values 09:50:07 …I believe the problem is that if you do a JS ennumeration through CSSOM, it gives you a list of every longhand property in CSS 09:50:16 q+ 09:50:18 …It doesn't matter what's been specified, it's just a list of everything 09:50:29 …I think we've fixed the serialization problems 09:50:52 …We have problems with mechanisms that let you ennumerate weverything in CSS, which have no value depends at all 09:50:59 ack dbaron 09:50:59 s/depend/dependence/ 09:51:17 …It's possible there are other problems here, but does anyone think I was wrong about that? 09:51:21 TabAtkins: No 09:51:42 ack lea 09:51:42 lea, you wanted to say the current design is clearly problematic, and these don't seem like dealbreakers, just like the usual design decisions we need to make with every feature. 09:51:45 ... And they certainly don't prove that we shouldn't even explore that avenue. I don't see how removing shorthands when the longhands are removed is that different from adding 09:51:45 ... longhands when a shorthand is specified, it's not like what the author specified is preserved exactly 09:52:13 q+ dbaron 09:52:16 lea: Back to what Oriol was saying, we know the CSSOM is problematic 09:52:45 …We need to explore some of these avenues to see if what we come up with, we need to check if it will make things worse or better 09:53:11 …Authors specifying shorthands and getting back longhands is just as confusing as making shorthands disappear when longhnads disappear 09:53:20 q+ 09:53:27 …Authors almost never intend to get back the entire list of of all properties 09:53:35 These enumerations are used by some tooling, that's who reported compat bugs 09:53:53 …If authors ask for a border, they can't get any shorthands, they have to get a very specific longhand 09:54:06 dbaron: In specified declarations, we do only enumerate specified longhands 09:54:18 oriol: If you ask for the border, you get the border, you get the serialized values 09:54:29 …I do agree with dbaron, this isn't a value problem 09:54:31 ack oriol 09:54:32 It's only getComputedStyle() which returns all longhands 09:55:20 …If you change the value of a longhand or a shorthand, a shorthand stops being serializable 09:55:29 …This would make things unreliable 09:55:58 ack florian 09:55:59 lea: I was just writing that parts of the CSSOM seem to have improved 09:56:14 florian: I'm not approaching this as serialization, I agree it's about ennumeration 09:56:45 …It may be this is a bad idea, but I think all the cases you mentioned about ennumeration, they all depend on contexts where you could go on to get the value 09:57:05 …If there isn't the notion of being able to ask, then what I propose would become impossible 09:57:26 …If you can go on to ask about the values after you ennumerate, then this linkage can be made 09:58:02 …In order to preserve shorthands as standalone properties, this would introduce a dependency, and has the downside that the set of properties and their indexes would change 09:58:11 +1 to florian 09:58:13 …Itæs a tradeoff, but it might be a worthwhile tradeoff 09:58:37 ack dbaron 09:58:53 dbaron: I think from the JS perspective, what Oriol is suggesting would be really strange 09:59:19 …I admit I haven't paid a ton of attention to JS engine optimizations, but back when I did, there was much done based on type inference 09:59:47 …Making an object have different properties means now CSS style isn't really a type, it's hundreds of types 09:59:51 iank_: It changes the shape 10:00:05 dbaron: We're talking at the boundary of the CSSOM and JS 10:00:16 florian: Not quite undoable, but very near> 10:00:21 dbaron: Yes 10:00:36 fantasai: So you're saying this thing we're ennumerating always returns every property in CSS? 10:00:40 dbaron: Yes 10:01:01 …If you use an ennumeration in JS to ask what all the fields in a CSS style are, you get all the CSS properties 10:01:12 fantasai: And ennumerating the short and longhands would break in what ways? 10:01:19 +1 to dbaron 10:01:23 q? 10:01:27 ack emilio 10:01:31 dbaron: If we could do it, that might work, but I don't know if that would break anything 10:01:37 emilio: I don't know if that's true 10:01:39 s/short and longhands/shorthands in question and their longhands/ 10:02:28 q+ Not sure I understand what's strange from a JS perspective. Enumerating objects whose properties have dependencies between them is pretty common? Also, is the proposal to *only* include shorthands? I thought it was to include both… 10:02:32 q? 10:02:34 …When you ennumerate specific CSS declarations, you get the longhands that are specified in that declaration 10:02:36 s/ but very near>/ but very weird? 10:02:46 q+ 10:02:59 … .length is how many longhands you have in there 10:03:07 https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%20style%3D%22margin%3A%202em%22%3E%0A%3Cscript%3E%0Afor%20(var%20i%20in%20document.body.style)%20%7B%0A%20%20document.write(i%20%2B%20%22%3Cbr%3E%22)%3B%0A%7D%0A%3C%2Fscript%3E 10:03:17 iank_: I believe dsome of our compatibility problems came from ennumerating 10:03:20 emilio, see above testcase 10:03:33 emilio: Preserving shorthands in specified styles is a relatively big change, but seems doable 10:03:37 q+ 10:03:41 …Doing it in getComputedStyle is a bit tricky 10:03:58 dbaron: I don't think that's the issue 10:04:19 dbaron: I think it was (for i in document.body.style) 10:04:20 dbaron's demo with values: https://codepen.io/leaverou/pen/KKLXqBw?editors=1111 10:04:26 emilio: A lot of things we've been discovering have been different 10:04:50 ack lea 10:05:04 lea: ASking David what is weird from the JS perspective 10:05:14 …Is the proposal to remove longhands? 10:05:32 dbaron: I'm not sure what you mean by dependencies and if there was a proposal 10:05:46 …I think maybe it was to include shorthands in a place that only has longhands 10:05:48 q+ 10:05:54 `for (let i in document.body.style) { console.log(i) }` does include shorthands 10:05:58 (In Gecko at least) 10:06:00 TabAtkins: That appears to be a requirement of whatever we settle on 10:06:12 jarhar has joined #css 10:06:13 ack florian 10:06:17 q+ 10:06:19 florian: I think we effectively have three proposal to consider 10:06:32 …1. Sometimes don';t include longhands 10:06:39 What I was proposing was to include *both* longhands and shorthands. 10:06:44 emilio, it doesn't include "font" in the url I gave above 10:07:02 …2. The list of properties you ennumerate depends on the actual values 10:07:16 …3. For a subset of properties, list both the shorthands and longhands only 10:07:35 …You'd have to make it a subset because there are historical properties where doing that would break things 10:07:52 dbaron: it does for me? (the codepen console eats it because too many properties) 10:07:57 fserb: This is just about the ennumeration? 10:08:00 florian: Yes 10:08:03 s/dbaron:/dbaron, 10:08:07 emilio: Open the browser console 10:08:22 …I suspect alternative 3 is the simplest, but I don't know if it's possible 10:08:47 ack iank_ 10:08:58 ack IanK 10:08:58 IanK, you wanted to clarify what exactly the problems are that we're running into 10:09:03 fantasai: Ian, what are the problems and what are we trying to solve? 10:09:10 iank_: I'd have to go back and see what we found 10:09:18 emilio, oops, you're right -- they're in a very strange order! 10:09:19 lea, `{ let found = false; for (let i in document.body.style) { found = found || i == "font" } console.log(found) } ` logs true here 10:09:20 …I worry that optoin 3 would open a separate can of worms 10:09:31 astearns: We could resolve on opening that can of worms to see what we find 10:09:38 q? 10:09:39 emilio: Yes, that's what I'm noticing in Chrome too. Then what's the issue? 10:09:42 qq+ 10:09:52 q+ 10:10:02 dbaron, See above? ^ 10:10:16 [note to scribe to keep lea/emilio chat as a side-converstaion, not as corrections to the minutes] 10:11:00 ack fserb 10:11:04 fserb: Can someone speak to the use case here? 10:11:14 …What's the use case for ennumeration? 10:11:21 ok, yeah, chrome and gecko both seem to include shorthands in enumeration... I'm not sure what the issue is 10:11:48 …What do we care about, and what do we not? 10:12:11 florian: I'm not approaching this as any particular use case, but from the place where thaere are cases where it's useful 10:12:27 …But things are not posisble with how we do ennumeration now 10:12:38 for...in just does the normal JS thing, right? I thought we were talking about for...of 10:12:42 fserb: This works when we query the properties, yes? 10:12:43 dbaron, my understanding is that `style.cssText = "font: ...;"; [...style].includes("font")` is `false`, but that's the same `.length` bit that I commented above 10:12:49 q+ 10:13:25 …There is a thing about people getting confused, but I would argue having both would make people more confused 10:13:38 +1 that having both is just more confusing 10:13:49 …If you want just a sense of properties, having to do the extra work of knowing the shorthand means you can't get the bag of properties 10:14:09 florian: The way I'm thinking about this is not about what makes sense in theory but what we can do that doesn't break compaibility 10:14:10 oriol, so yeah, my understanding is that what you said is correct, but that might be solvable in different ways depending on whether compat issues are in the specified style and computed styles 10:14:30 q+ to say This discussion makes me think we also need a data structure that allows authors to read what is a shorthand of what. Also relevant to this future TAG principle: https://github.com/w3ctag/design-principles/issues/300 10:14:40 …So I had a question to Ian, earlier, what kind of can or worms were you talking about? 10:14:52 …Did you mean there are some properties where changing this breaks things? 10:14:58 ack florian 10:14:58 florian, you wanted to react to IanK 10:15:01 …Or is this more about the API shape itself? 10:15:15 antonp has joined #css 10:15:18 zakim, close queue 10:15:18 ok, astearns, the speaker queue is closed 10:15:38 iank_: My thesis at the moment is that properties that have been around since time immemorial is more likely to have author depending ont he ennumeration 10:15:45 …Things that are more recent, much less likely 10:15:55 q- 10:16:19 …What we had to do with white-space was a lot more extensive 10:16:55 florian: So I propose for all properties that exist, we do what we've been doing, but for any new property or newly shorthanded properties, we list both shorthand and longhand 10:16:58 emilio, here's the actual testcase (thanks to Ian): https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%3E%0A%3Cscript%3E%0Avar%20cs%20%3D%20getComputedStyle(document.body)%3B%0Afor%20(var%20i%20%3D%200%3B%20i%20%3C%20cs.length%20%3B%20%2B%2Bi)%20%7B%0A%20%20document.write(cs%5Bi%5D%20%2B%20%22%3Cbr%3E%22)%3B%0A%7D%0A%3C%2Fscript%3E 10:17:04 …Is that something we can do, whether or not we should? 10:17:05 I think I have a proposal, if this is for the computed style 10:17:10 andruud: Would that help? 10:17:18 In terms of API design, that seems like the worst of all worlds. How are we supposed to explain this to authors? 10:17:30 …In the position case, we don't touch that since it's been around since forever? 10:17:59 florian: No, if we shorthandify that, we would do the new thing, but we don't do it to things like margin 10:18:23 andruud: Can we research this can of worms without opening it? 10:18:28 iank_: I don't know 10:18:30 q? 10:18:43 q+ 10:18:57 astearns: I've closed the queue since I'm not hearing consensus or conclusions 10:19:21 emilio: We need to distinguish the computed and specified styles 10:19:51 …We can have a shorthand list and the only thing we need to make sure is the whole longhand space can be represented by the shorthand 10:20:00 iank_: I think it depends on how it's being used 10:20:06 +1 most of my concerns are about non-computed styles, since you can modify them 10:20:47 emilio: I propose that if this is about the computed style, we can do this easily 10:21:00 …If this is about the specified style, that's a bigger change 10:21:16 …When the CSS parser parses white-space, it ends up with a bunch of longhands 10:21:26 …We could make it not do that, but that would be a big change 10:21:32 q- 10:21:39 …Having a flag on a shorthand would be trivial-ish? 10:21:55 ack emilio 10:22:05 dbaron: Ian and I have been test casing and one of the things I said earlier was wrong 10:22:17 …`i in foo` is wrong for where the compatibility exists 10:22:32 …it's more in `i to length` 10:22:46 …The ennumeration order has the shorthands first and then the longhands 10:23:11 …The problem may be computed-style only 10:23:19 The `white-space` compat problem we encountered was that `for(s of getComputedStyle)` was missing `white-space`. 10:23:31 ack lea 10:23:31 lea, you wanted to say This discussion makes me think we also need a data structure that allows authors to read what is a shorthand of what. Also relevant to this future TAG 10:23:32 …Again, we probably need more test cases to be sure we're talking about the right thing. 10:23:35 ... principle: https://github.com/w3ctag/design-principles/issues/300 10:23:48 lea: I think we have consusensus we don't want to stop shorthandifying properties 10:24:00 …Breaking properties into BC/AD seems like the worst solution 10:24:10 …Exceptions make APIs really hard to explain 10:24:35 …By principle of least surprise and assuming most authors use lookup instead of ennumeration, we could make changes 10:24:51 …We could really use methods that allow authors to ask what is a shorthand of what 10:25:00 +1 to introspection of shorthand/longhand relationships 10:25:15 …This is also compatible with the TAG future design principle of allowing introspection 10:25:21 You can currently know what is a shorthand of what with the current API. The proposals here would break that. 10:25:43 astearns: Sounds like we need more tests and finding the smallest can of worms we can open 10:25:47 s/Exceptions make APIs really hard to explain/How are we supposed to explain this to authors? I'd much rather add one-off exceptions, but I'm not convinced we even need to do that./ 10:25:53 fantasai: There was also an issue around transition events 10:26:00 dbaron: I think that's the harder half 10:26:16 …That said, I think we made the easy half hard by talking about what it is instead of solving it 10:26:22 …And I also think we still don't know 10:26:23 s/We could really use methods that allow authors to ask what is a shorthand of what/There should be a data structure for authors to read what is a shorthand of what, so that if they're doing some complicated thing they at least can figure out what is happening, which is incredibly tricky right now (I’ve tried to do it!)./ 10:26:42 astearns: Leaving this for now 10:27:13 github-bot, take up https://github.com/w3c/csswg-drafts/issues/9827 10:27:13 Topic: [css-anchor-position]: Question: Why is anchor-size() only valid in a sizing property? 10:27:13 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9827. 10:27:35 jarhar has joined #css 10:27:55 TabAtkins: An author asked why the anchor-size() functions were only allowed in sizing functions 10:28:08 …It was the obvious restriction at the time, but there are use cases to allow it elsewhere 10:28:24 …At minimum, we should be able to relax this to match the list allowed in position-try 10:28:39 …Ian can talk more about the reasoning in that restriction 10:28:40 q+ 10:28:44 zakim, open queue 10:28:44 ok, astearns, the speaker queue is open 10:28:53 q+ kizu 10:29:01 …Roma had questions, but I don't understand them 10:29:17 …anchor-size is a size, but the function has to stay specific to the inset properties 10:29:26 ack kizu 10:29:27 …Let's talk about what properties should allow anchor-size() 10:29:51 kizu: In my experiments, I often wanted to use not just the anchor size, but the anchor itself 10:30:29 TabAtkins: Given that anchor size is a difference between two anchors, being able to provide two anchors and get the distance between them sounds doable 10:30:40 fantasai: We should take that as a separate issue 10:30:53 TabAtkins: Ian, could you talk about this? 10:31:20 iank_: I think it's basically the same as if we start messing around with the bits of abspos elements 10:31:26 …It starts to break a lot of optimizations 10:31:37 …I think the insets are fine, with no issues 10:32:02 futhark: I would assume this has the same limiations 10:32:37 TabAtkins: The restriction on not touching the any bits is related to not using it in padding 10:32:54 …I presume it's acceptable to do for paint-time properties like clip-path and background properties 10:32:59 …Is that accurate? 10:33:08 iank_: I'm not sure 10:33:40 …There are some things we think of paint things that do bleed into layout and I'm a little concerned about 10:33:47 TabAtkins: Example? 10:34:17 iank_: There's stuff in inlines and stuff for when we calculate overflow contributions, and then all the table internals may influence layout 10:34:37 …That's a small smattering; I'd need to talk with folks 10:34:42 ack fantasai 10:35:01 fantasai: Having it apply only with the properties of position-try is a nice consistent thing to understand 10:35:12 …I think for now, starting with those properties is reasonable 10:35:27 iank_: Anders, any reason that would be bad? 10:35:37 futhark: That seems sensible, yes 10:36:00 TabAtkins: Yeah, we could start with that list and then look to see what we might add to that 10:36:22 fantasai: I don't want to add to that because position-try doesn't participate in the cascade properly 10:36:26 q? 10:36:34 q+ 10:36:38 …If we want to style more properties conditionally, we need a more generic solution to that problem 10:36:38 q+ 10:36:49 s/add to that/add properties to @position-try/ 10:37:14 TabAtkins: That is a thing we can deal with later, we can use the list from position-try for now and open a new issue to discuss further onward 10:37:31 iank_: I think we're all in agreement about adding anchor-size to the set in position-try 10:37:46 …I think there's a different solution space for the wider problem 10:38:03 ydaniv: What about transforms? Is it possible to include them? 10:38:03 ack ydaniv 10:38:24 TabAtkins: That falls into the wider problem, but I agree this would be useful for transitions 10:38:29 ack una 10:38:31 …Add it to the list of future discussion 10:38:42 una: Is there a plan forward for generic styling properties? 10:38:58 …There are so many things authors want to adjust based on position and other things 10:39:10 …This general problem keeps coming up in various contexts, of which this is one 10:39:34 …Would really like to have a place to talk about the wider problem instead of hitting it in smaller problems 10:39:43 fantasai: Tab wanted to do that in level 2 10:39:53 iank_: I don't think we should do that with position-try 10:40:04 q? 10:40:05 q+ 10:40:15 fantasai: We all do want to solve the problem, but it's not going into level 1 10:40:21 una: So we'd do that in 2? 10:40:50 fantasai: This isn't actually that problem, and I'd rather have a solution rather than confusing authors by throwing properties onto a pile 10:40:52 q? 10:41:08 …We need to have some kind of an answer that makes sense as to why a thing can be used for one property but not another 10:41:15 s/onto a pile/onto a pile one by one/ 10:41:43 florian: We all want to solve the bigger problem some day, so the question is, does this immediate solution depend on the longer-term solution? 10:42:17 s/depend on the longer-term solution?/depend on the longer-term solution? if not (and it seems not), then let's not discuss the bigger problem _now_. 10:42:48 TabAtkins: propose to add anchor-size() into the values of properties that take lengths on the list of position-try, and tackle the wider problem later 10:43:10 astearns: Any comments or objections? 10:43:13 (silence) 10:43:28 RESOLVED: add anchor-size() into the values of properties that take lengths on the list of position-try 10:44:24 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10314 10:44:24 Topic: [css-anchor-position] Resolution of percentages: area or track? 10:44:24 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10314. 10:44:37 andruud has joined #css 10:45:04 fantasai: (goes to chalkboard) 10:45:25 khush has joined #css 10:45:30 fantasai: This is about percentage resolution on inset properties 10:46:09 …Here's an acnhor, inside a container 10:46:16 nicole has joined #css 10:46:25 …For the inset area, we create a 3x3 grid 10:46:40 …You can address this by saying in which grid box an anchor should live 10:47:14 …Let's say we put the anchor positioned element in `bottom span right` 10:47:26 s/bottom span right/bottom span-right/ 10:48:23 …Let’s say I want to draw a box in that area that's positioned with its left at 50% minus some amount, say 30px 10:48:51 …We could create an anchor centerline, but that's only narrowly useful 10:49:11 …When we designed the inset area, we said 100% left would align with the right edge of the anchor 10:49:25 …For the inset properties, the percentage is relative not to the container, but to the track on that side 10:49:33 s/say 30px/say 30px. The issue is that the 50% is relative to the entire span, when I want it only to be the center/ 10:49:37 …That gives you an easy way to do a lot of positions 10:50:05 q+ 10:50:16 q+ 10:50:21 q+ 10:50:30 ack florian 10:50:33 q+ 10:51:11 …Tab pointed out this is inconsistent with inset elsewhere, which is relative to the containing block instead of the tracks 10:51:40 q? 10:51:43 q+ 10:51:54 q+ 10:52:37 fantasai's proposal: left: calc(50% - 30px) where percentage is relative to the track on that side 10:52:56 una: In this case, 100% doesn't mean the whole containing area, just the track? 10:52:58 fantasai: Yes 10:53:11 ack andruud 10:53:22 andruud: Did you consider a unit like container size query? 10:53:22 alternate proposal: left: calc(anchor-size() * 0.5 - 30px) where percentage is relative to the entire size of the positioned element's containing block 10:53:33 fantasai: No, percentages seemed natural here 10:53:42 (I have a specific rebuttal for that point) 10:54:04 andruud: It seems weird that this changes meaning for different sides 10:54:15 …You said you could solve this with anchor-size()? 10:54:23 fantasai: That was Tab's proposal 10:54:40 s/alternate/TabAtkins/ 10:54:40 andruud: A unit would give you that 10:55:07 TabAtkins: I'm more strongly on, this is not how percentages work anywhere else in CSS 10:55:26 q? 10:55:28 …The consistency of always going off the containing block means you can use them and have an idea of what they will mean 10:55:34 q+ 10:55:46 q+ to comments on units vs percent 10:55:54 …Changing this in left and right in this situation and making them distinct from all other percentage uses in incredibly confusing 10:56:01 q+ 10:56:15 …Using anchor-size() or coming up wihth a new unit are more preferable for me 10:56:27 ydaniv has joined #css 10:56:29 ack nicole 10:56:32 q+ 10:56:44 q+ 10:56:47 nicole: Clarification about the diagram: the direction of the arrows is meaningful 10:57:08 s/meaningful/meaningful?/ 10:57:30 fantasai: Yes, it inidicate the left property refers to the leftmost track and right to the rightmost 10:57:31 ack miriam 10:57:34 kizu has joined #css 10:57:38 miriam: I kind of like the unit idea 10:57:59 …If you're spanning all, does left give you left and right give you right and there's no access to the middle? 10:58:02 fantasai: Yes 10:58:13 miriam: And 150% would be consistent to the track, not the container? 10:58:16 fantasai: Yes 10:58:20 ack TabAtkins 10:58:47 (is there a way to use cq* units here?) 10:58:54 TabAtkins: The proposal means left: 100%; right: 100%; would fill the containing block, but left: 150%; right: 150% would not 10:59:18 s/right: 150%/right: 50%/ 10:59:27 ack una 10:59:38 una: I feel like as an author, I prefer consistency 10:59:49 …I probably wouldn't use span-right here 10:59:58 …If I did 100%, I would expect it span across both tracks 11:00:11 …This adds complexity if I change positions 11:00:42 …Because this conflicts with my understanding of percentages, it would be harder than using anchor-size() or some other approach 11:00:57 …This feels like it simplifies some use cases and complexifies other use cases 11:00:59 ack fserb 11:01:28 fserb: Was thinking about what would happen if the choice was the other one 11:01:55 q+ to ask about % on width/height/margin/padding properties 11:02:04 …So if it was bottom span-left, you could only percent from the right? 11:02:38 …Or if you spanned the whole thing, what would happen? 11:02:59 fantasai: left: 50% would be halfway across the left track, and right: 50% would be halfway across the right track 11:03:12 In that example, with 50%, the tooltip isn't centered. 11:03:17 More on the "this is inconsistent" drumbeat: this means you can't invert the property you're using with the `calc(100% - N)` math 11:03:40 fserb: And in other proposals, percentages would be relative to the whole area? 11:03:43 fantasai: Yes 11:04:00 ack bramus 11:04:07 Also would this break/behave differently than translate: 50%? 11:04:29 bramus: Looking at the data between the code you have at the bottom of the drawing, and then comparing to the other code, I don't see a big delt between them 11:04:31 translate: 50% is relative to the item, not the CB, so that's already different 11:04:43 …If you do the thing on the left, then you aren't changing the meaning of percentages 11:05:00 …The proposal seems very confusing 11:05:19 …If percentages were used here, I would expect them to resolve against the inset area 11:06:06 more inconsistency: this means that `inset: 0; inset-area: bottom span-right;` is different from `left: anchor(right); right: 0; top: anchor(bottom); bottom: 0;` - right now there is no difference between these (save for a bit of error-correction when the anchor is outside the CB) 11:06:19 fantasai: To take a simpler example, if I wanted to put a pin over the anchor with its base in the middle of the anchor, it would be `inset-area: center span-top; bottom: 50%` 11:06:37 bramus: You could also do inset size * 0.5 11:06:44 q? 11:07:49 fantasai: The alternative would be `inset-area: center span-top; bottom: calc(anchor-size()*0.5)` 11:07:55 s/inset size * 0.5/anchor size * 0.5 11:08:04 ack florian 11:08:04 florian, you wanted to comments on units vs percent 11:08:13 ydaniv has joined #css 11:08:26 florian: At least in the two-column case, we can get what we want without new stuff using verbose syntax 11:08:34 …Maybe we could use it for the three-column cases? 11:08:48 …But if we want a compact syntax, we need something new 11:09:02 …The proposal for a new unit makes me feel strange 11:09:19 …You'd end up with a unit that's easy to understand why you don't want it 11:09:29 …It wouldn't mean anything in most properties 11:09:41 q+ about the usage 11:09:49 …It's odd to have percentage meaning change, but it's useful 11:10:12 …In sets of related properties, percentages don't always do the same thing 11:10:18 q+ 11:10:19 q+ TabAtkins to comment about the usage 11:10:29 …It's stronger here, but it's not completely new 11:11:05 …It takes getting used to, but there's no alternative usage of percentage that makes sense, and explaining what a new unit does in situations where it doesn't apply also seems confusing 11:11:23 astearns: Is this analagous to positoining something inside a grid unit that spans tracks? 11:11:41 fantasai: Yes, but in that case I think it's a lot less clear what you want to result 11:11:54 astearns: I disagree, with my chair hat off 11:12:06 florian: Even if it's going to cause inconsistency? 11:12:11 q- 11:12:14 qq+ 11:12:22 astearns: I don't think it's any less inconsistent than the alternative 11:12:25 ack florian 11:12:25 florian, you wanted to react to florian 11:12:27 ack astearns 11:12:42 florian: I don't see it as an inconsistnecy because we already define per-property what it means 11:12:57 s/what it means/what percentages means 11:13:27 ack ydaniv 11:13:41 ydaniv: Agree with Florian; we already define percentages differently in different contexts 11:14:03 q+ 11:14:04 …We made some things simple with ranges, but lost some things that way as well 11:14:06 lwarlow has joined #css 11:14:36 fantasai: If you did end up with a use case where you needed to resolve against the whole inset area, you could use the anchor functions and do a lot of math 11:14:45 …So we do have an escape hatch 11:15:14 q+ 11:15:21 …In the set of things people are going to do, are the use cases of the using whole inset area more or less common than using tracks 11:15:38 …I suspect the whole inset area would be extremely rare 11:15:55 …I'd ask people to come up with examples and then decide what you feel more comfortable with 11:15:58 Also left:anchor(50%) already centers on the anchor, fwiw. 11:16:08 You need some more effort to center on the side tracks 11:16:09 ack kbabbitt 11:16:14 kbabbitt: For the use case presented here, I don't understand why you need bottom span-right 11:16:40 …Couldn't you just set the left at 50% - 30px and then let the positioned element overflow? 11:17:04 fantasai: You can do that, but by default, if you're in the center track you're aligned with respect to the center track 11:17:22 …So if you overflow, you'd overflow in both directions 11:18:37 q+ 11:18:41 miriam: This would also impact position-fallback, right? 11:18:44 fantasai: Yes 11:18:53 zakim, close queue 11:18:53 ok, astearns, the speaker queue is closed 11:19:39 kbabbitt: In a case where you are spanning all the bottom tracks, how do you hit the case where you want to be 50% of the center track? 11:20:02 fantasai: You wouldn't try to do that 11:20:28 kbabbitt: So your goal is to grow both directions, or to grow one direction or the other, and that informs your choices? 11:20:31 fantasai: Right 11:20:36 ack TabAtkins 11:20:36 TabAtkins, you wanted to comment about the usage 11:20:37 q+ 11:20:44 TabAtkins: Two things from me… 11:21:20 …Any argument about left and right percentages being not useful to the whole containing block I think apply exactly equally to margin-left and -right 11:21:33 fantasai: I'm not sure I would use percentage margins here 11:21:41 …I suppose you'd want something more consistent 11:21:57 …It's worth noting all margins resolve against the inline axis 11:22:13 ydaniv has joined #css 11:22:35 TabAtkins: Second note, the main obvious use case is positioning with relation to the center of the center track 11:22:44 fantasai: Yes 11:23:19 TabAtkins: If you put a percentage in the anchor() function, you get the placement you want 11:23:33 …`left: anchor(50%)` puts an edge right in the middle of an anchor 11:23:40 fantasai: Would that work with the inset properties? 11:23:46 TabAtkins: Yeah, it doesn't care about that 11:23:57 …It should automatically work 11:24:12 …In the cases you need something more precise, leaning on math is fine 11:24:21 …For the center ones, we can already do it 11:24:54 fantasai: So you're saying `left: anchor(50%)` would address this situation 11:25:17 astearns: Is that simplfication enough for you to withdraw the option you were presenting, Elika? 11:25:22 fantasai: I think so 11:25:34 ack una 11:25:38 astearns: Provisionally we might resolve this a closed, no change, but let's go to the queue 11:26:06 una: My main question is, are we seeing cases where developers run into percentage confusion? 11:26:25 fantasai: I don't think so, the question is more how easy can we make it to do the common cases? 11:26:42 una: I get that, but what if you want something that spans 90% of both tracks? 11:26:59 fantasai: You could put margin: 10% 11:27:26 s/margin: 10%/margin: 5%/ 11:27:41 una: So that wouldn't apply to the margins, just the insets 11:27:44 fantasai: Yes 11:27:50 ack bramus 11:28:26 bramus: I like the anchor() fix, but the main thing is you want access to the anchor block and inline sizes, so maybe in the future a unit would be useful; no need to resolve now 11:28:27 ack fserb 11:28:31 dholbert has joined #css 11:28:43 fserb: I think having usint that behave differently on the same axis are weirder 11:28:46 present+ 11:28:59 s/usint/units/ 11:29:15 lol 11:29:43 …I question that I cannot find a use case for the total size 11:29:54 …If you don't change, they aren't good for expressing anything 11:30:17 …For folks who don't like the percentages, is that a use case fo 30% of the total thing? 11:30:56 una: If you had a big block of text inside the positioned element, and you want to make it readable with a percentage margin, this is an example that you wouldn't have something small like this 11:31:10 fantasai: So something like a really long footnote 11:31:11 una: Yeah 11:31:22 fantasai: I think if you want spacing, margin is appropriate 11:31:40 una: Right, but if the percentages are different between margins and insets, that's weird 11:32:12 Nicole Sullivan: Having a lever over how things grow, that would be useful 11:32:24 fantasai: I think we have the right controls, but I'm willing to talk that through 11:32:31 astearns: Can we resolve close, no change? 11:32:38 fantasai: I think that works 11:33:24 RESOLVED: Close with no change 11:33:35 Topic: lunch 11:36:00 When's lunch over, 3PM? 11:36:22 emilio: 2:35 pm 11:36:33 Cool, ty lea! 12:15:48 zrhoffman has joined #css 12:36:09 alisonmaher has joined #css 12:37:28 lwarlow has joined #css 12:39:40 kbabbitt has joined #css 12:40:00 jarhar has joined #css 12:40:06 ydaniv has joined #css 12:40:19 khush has joined #css 12:40:20 present+ 12:40:27 fserb has joined #css 12:40:34 present+ 12:40:41 present+ 12:40:41 present+ 12:40:49 Topic: [cssom-view] Bring the segments property into visual viewport 12:41:57 what is alexis's username? if i dont have anything ill just say "alexis" 12:42:33 scribenick: jarhar 12:42:59 alexis: one of the gaps we have is support for layout in pop? and making content is not on the full section, and there was work done in the past by ms for css ??? and its already part of the media query 12:43:06 kizu has joined #css 12:43:20 alexis: the bottom section of the screen, bringing parity to support the functionality in the javascript world 12:43:33 alexis: lets say youre in a canvas or a game, you cant necessarily use css so in the past we used ??? and css and javascript, that was the PR in the bug 12:44:01 zakim, open queue 12:44:01 ok, astearns, the speaker queue is open 12:44:03 alexis: requesting approval to add this feature to the ??? spec, and there were a couple questions raised 12:44:06 andreubotella has joined #css 12:44:19 alexis: i went to great lengths to show how were not exposing anything new 12:44:28 s/???/CSSOM view? 12:44:28 alexis: there was a question about iframes and media queries 12:44:54 alexis: there was a question about whether this should be part of ???, and WPT support and webdriver support for us to test this 12:45:12 alexis: we need webidl support 12:45:20 alexis: thats basically it, im here for questions 12:45:43 +1 to this in general (i've been bad about supporting this issue) 12:46:39 alexis: the css viewport segment as well as the viewport - as well as the second compnent of visual viewport are in origin trial, we are seeing feedback on this feature, went through tag reviews 12:46:41 q+ 12:47:03 ack astearns 12:47:14 astearns: i wonder whether we could resolve on adding this to the cssom view spec, and create separate issues for each of the things that you got in your summary 12:47:30 astearns: we dont have to figure out if it has to be aprt of the visual viewport api, but if its in a draft you might get more traction on individual issues 12:47:45 alexis: yes, i would like to resolve this at some point 12:47:45 q+ 12:48:26 ack bramus 12:48:52 bramus: i havent read into what is in the spec, but im confused right now. do the segments expose the various viewports or the visual viewport? 12:49:03 alexis: they are multicol subdivisions of the visual viewport 12:49:27 alexis: for fullscreen, its logical subdivision of the visual viewport. im not sure if fingerprinting was an issue 12:49:42 alexis: that includes also figuring out the resolution of laptop 12:49:55 bramus: what about window.visualViewport? it doesn't get affected by page zoom 12:50:10 alexis: the only thing that would take into account is the scale factor of the device, thats the only thing we do 12:50:55 bramus: there is an issue 8709 where it was mentioned to have somtehing like window.viewport eventually, and maybe you should work on that where we expose the viewport. you have to postfix somewhere, we could tackle both in one go 12:51:06 bramus: and then you have segments as you described here 12:51:55 alexis: the reason it was there is that i wasn't the original author editing there, but because the visual viewport ?? are basically equivalent for intersection 12:52:10 alexis: so thats why it was built that way, it was visually speaking you see two segments, thats probably why it was put there in the first place 12:52:27 alexis: i agree with you, its not a window property 12:52:45 miriam: can we take the resolution alan suggested and then open issues? 12:53:12 bramus: we might want to move this somewhere 12:53:33 astearns: we would only be stuck if people started implementing and we got web content that relies on it. we need to have some draft text to be working on it 12:53:36 q+ 12:53:41 astearns: this will help us get more attention 12:53:52 alexis: if we move it then i will have to redo the origin trial 12:54:39 alexis: ??? css api as well as the js api, implementing a full fledged support on your app, 12:54:48 alexis: at some point we will ship the rest of the pieces 12:55:09 alexis: implementation in chromium, origin trial just for that js api, we are already late in terms of spec 12:55:21 alexis: speaking as an implementor, not as the spec side of things 12:55:39 ack flackr 12:55:57 flackr: this isnt an objection to this proposal, but that got me thinking about what pinch zoom means 12:56:07 flackr: im wondering if we need some better way to have multiple viewports 12:56:14 flackr: would you want to pinch zoom a segment of the display? 12:56:23 flackr: you probably dont want it to move content on one segment to another segment 12:56:34 alexis: true, but pinch to zoom implementation is stuck to the page 12:56:52 alexis: i see what you mean but then we are going to an implementation complexity thats crazy 12:57:00 alexis: do i want to zoom the app? or one section only? 12:57:14 flackr: im just trying to figure out if we could design it any way we wanted then where would we end up? 12:57:33 alexis: then how would we do this in css? theres the css part we have ??? so how would you... 12:57:41 flackr: this isnt an objection to your proposal, i think its fine 12:57:57 flackr: i was just throwing out the idea that maybe we should think of a css way or js to define viewports within your viewports or something like that 12:58:09 flackr: im not objecting to exposing what we have 12:58:26 alexis: but my question about pinch to zoom: what happens if you pinch to zoom? ok then dont change 12:58:34 flackr: you would be zooming into a particular viewport not the root visual viewport 12:58:49 alexis: the concern with the visual viewport - what happens with escape popover? 12:58:54 flackr: the device scale factor doesn't change 12:59:04 alexis: so we would not change anything, we would not expose the viewport 12:59:16 alexis: its not aligned for contet, but its the same for any page thats out of viewport 12:59:34 flackr: the visual viewport api is exposing the visual viewport, but the thing youre trying to expose is outside of that, the full browser viewport 12:59:49 alexis: one possible implementaion would be for me to resnap these values to one is visible and one is pinch to zoom right? 12:59:56 flackr: i dont know how that would work i would need to see an example 13:00:10 alexis: with pinch to zoom any portion is what i can see after the pinch to zoom 13:00:12 flackr: yes 13:00:22 alexis: lets see i pinch to zoom, ok i understand what you mean yes 13:00:46 miriam: are we ready to take a resolution or do we need to take this back to the issue? 13:01:08 bramus: what i would like to see and from peopple at apple would be: if you did window.viewport or window.??? would we add some more things to that 13:01:26 s/window.???/window.visualViewport 13:01:30 flackr: right now windows kind of our container for this kind of thing 13:01:35 flackr: would it make sense to have more things on window? 13:01:45 window.viewportSegments? 13:01:48 bramus: maybe this would be our opportunity to correct some things from the past and ??? 13:02:04 s/and ???/and group it under window.viewport 13:02:12 fantasai: i dont know much about this model 13:02:28 fantasai: the one thought in myu head was about what coordinate system these are in, whether its zoomed coordinates or not and how does that related to other objects thats attached to 13:02:34 s/this model/the CSSOM/ 13:02:39 alexis: right now its ??? its just the device pixel value 13:03:04 bramus: you have the viewport, you draw a line in the middle, and the visual viewport still bounces around, you can show parts of various segments because its a subsection of the entire viewport 13:03:16 fantasai: wouldnt you and an author want segments of the entire viewport not the visual viewport? 13:03:19 flackr: yes 13:03:26 bramus: i think thats what we currently have 13:03:34 emilio: but in css pixels not device pixels? 13:03:35 q? 13:03:41 fantasai: where is that defined? 13:03:47 alexis: right now the visualViewport property 13:03:49 fantasai, https://github.com/w3c/csswg-drafts/pull/9285#discussion_r1376720482 13:03:56 alexis: proposal to add a property in the visualViewport object 13:04:16 fantasai: where are we representing the segments in terms of the overall viewport? 13:04:31 fantasai: which object in js right now tells me that the hinge or whatever is 40% through the viewport? 13:04:44 flackr: my understanding is that its just css properties 13:05:05 alexis: you have two media queries that tells you the orientation and then you have css hover and variables that sets you each of the segments, including the width height in x and y 13:05:10 alexis: for each of the segments 13:05:16 fantasai: and those are required to the layout viewport 13:05:21 https://drafts.csswg.org/css-env-1/#viewport-segments 13:05:35 fantasai: so what youre wanting to add is a method to access this information with rspect to eh visual viewport 13:05:48 alexis: yes and being able to use this in js without css in the first place like canvas 13:05:56 flackr: its not with respect to ??? its respect to the viewport 13:06:08 fantasai: whats the use case with knowing that this is with respect to teh visual viewport since we are doing the layout viewport 13:06:22 flackr: there has been confusion, this doesnt belong in the ?? api 13:06:32 fantasai: then it doesn't belong on the visualViewport object 13:06:37 bramus: that was my point 13:06:38 alexis: but where then 13:06:40 s/???/visual viewport/ 13:06:45 bramus: id say window.viewport 13:06:50 s/??/visual viewport/ 13:07:00 bramus: and a way in javascript to get the small viewport height and the ??? viewport height 13:07:16 fantasai: does window.viewport exist already? and you want to create this that represents the visual viewport? that seems reasonable 13:07:50 fantasai: then i think the way forward here is to sketch out what this object would look like and include the segments information as well as the other information that bramus is mentioning 13:08:00 This would probably be a good option to fix https://github.com/w3c/csswg-drafts/issues/5260 13:08:08 alexis: if you need help to sketch out then whats the work ??? i would need help on writing the dom 13:08:15 did I hear bramus volunteer to do that? 13:08:20 miriam: we could take a resolution that this is the path forward 13:08:25 bramus: i would take a stab at that 13:08:32 alexis: we can connect offline bramus if you want 13:08:54 fantasai: proposed resolution: define the segments on a new layout viewport object on window tbd 13:09:05 miriam: any objections to that proposed resolution? 13:09:18 RESOLVED: define the segments on a new layout viewport object on window tbd 13:11:08 github-bot, topic https://github.com/w3c/csswg-drafts/issues/2312 13:11:08 Topic: [CSS2] How do zero-width floats affect subsequent content 13:11:08 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/2312. 13:11:20 emeyer has joined #css 13:11:44 s/since we are doing the layout viewport/since pretty much everything is laid out wrt layout viewport?/ 13:11:44 oriol: this is an issue about floats. the issue that we have with floats is that fiwe have line boxes that come after floats they need to be shortened, same thing happens with block level elements that establish a formatting context 13:11:57 oriol: this question is what happens if the float has a width of zero or a height of zero or negative because of margin box 13:12:16 oriol: i started ?? web browsers in servo and they didnt get much agreement, i recommend looking at the last comment in this issue 13:12:40 oriol: basically the only case that is defined in the spec in css2 is just related to line boxes. it says that if a float has a height of zero or negative, then this shouldn't shorted line boxes 13:12:49 oriol: turns out that blink does not respect that, does the opposite 13:12:55 oriol: gecko obeys it. webkit obeys it 13:13:15 oriol: but yeah i would like to define what should happen in these cases. we should resolve that these cases should be consistent, whatever it should be 13:13:20 oriol: it would make sense for them to be the same 13:13:45 oriol: about the specific behavior, although its inconsistent with content-visibility because for that we observe for that it has an area of zero but it insertects the screen 13:14:03 oriol: im currently leaning maybe to what firefox is doing, which is that if a lfoat is zero pixels wide we allow overlapping that thing 13:14:28 oriol: it coudl be possible o handl the zero case - we could avoid overlapping that , but it would make it tricky with the zero case, so we could align with gecko. maybe others have thoughts 13:14:37 iank_: whats the issue with the negative case? 13:15:07 oriol: in the negative case we have the end of the float coming before the beginning. its tricker to define what it means to overlap that thing. if your element is before the beginning and after the end, maybe of the values in the middle 13:15:17 oriol: typically you dont consider it an intersection 13:15:49 iank_: i dont think thats a novel problem, we have overconstrained cases where one edge is befoe the other, and we just take the dom ? edge, i dont think the negative case is particuarly complex 13:15:58 oriol: i dont have a strong opinion here i think its simpler to go with firefox 13:16:12 oriol: what i think is that we should at least be consistent between shnortening line boxes and block elements in the formatting context 13:16:24 iank_: do all the engines respect clearance with zero area floats? how does that work? 13:16:38 table mics just cut out 13:16:40 oriol: for claranace its the block case, and then do you mean 0px wide or tall? what did yousay? 13:16:55 iank_: either. what happens with clearance in any of the case? 13:17:08 s/claranace/clearance/ 13:17:21 oriol: i didnt specifically test fo rthe clear property, but if you have a block level element aht is avoiding floats you move it downwards using clearance 13:17:27 iank_: no they dont. its a different mechanism 13:17:32 oriol: the spec says that its clearance 13:17:36 iank_: the spec says a lot of things 13:17:44 oriol: i didnt try using the clear property 13:18:00 ack dbaron 13:18:18 dbaron: i just wanted to say that i agree with your principle that the lines going around floats and blocks going around floats in the inline direction should be consistent with whic floats they ? and which floats they dont 13:18:41 dbaron: you made another argument in the comment about zero width floats and zero height floats. widths of floats and heights of floats do different things 13:18:56 oriol: trying to be consistent seems like a good thing but yeah we could decide to do it different 13:19:18 iank_: specifically with there s a case where you can get ne wformatting context to overlap floats with negative margin. ill quickly draw it 13:19:54 iank_: so this is your formatting context and youve got a left float 13:20:08 iank_: and then you creat another block that is inset with amargin the same width as that float 13:20:20 iank_: if you have a new formatting context with a negative margin it will overlap that float 13:20:40 iank_: where this gets interseting is if you have this case but the float lives here instead then the nbew formatting context will avoid it 13:20:52 iank_: and so what happens when you shrink this down to zero which behavior do you get? 13:20:57 iank_: because then these two cases are the same 13:21:06 oriol: but are you suare about the empty margin it will float? 13:21:12 iank_: yes i have cuased regressions due to this 13:21:19 iank_: its the most annoying thing in the world 13:21:23 iank_: everyone does this 13:21:31 iank_: these two cases become the same when you go to zero 13:21:51 iank_: i think ill prefer this - youll just check that if youre at the edge, then youre not allowed to prorude into the negative space 13:22:21 q+ to say that the most annoying thing in the world should have a spec issue added for it 13:22:22 iank_: so thats one quirk that needs to be considered 13:22:53 iank_: if you have a negative margin here, from this point the new formatting context point of view it can jsut see this. it doesn't see that float and it can just protrude into it 13:23:01 iank_: thats the hand wavy thing thats not in the spec 13:23:11 astearns: i just want to say that we should have a spec issue for this 13:23:19 iank_: theres lots of things in the css2 spec that don't exist 13:23:25 ack astearns 13:23:25 astearns, you wanted to say that the most annoying thing in the world should have a spec issue added for it 13:23:46 iank_: clearance - the spec says that htings clear but i think that they just wrote that because they wanted to ship it down but didnt have a good way of saying that, but clearance works idfferently in most ? 13:24:16 iank_: i would test that as well. that is likely going to have compat like - ill be sad if we ignore floats geometry but then dont ignore clearance for example, we might ahve compat with clearance and zero area things if that makes sense 13:24:38 iank_: people will create zero width things because they dont want a thing to show up at all but want to move it down without margins. i think wikipedia 13:24:51 iank_: if you test explicit clearance that would be good in test cases 13:25:26 oriol: so its your argument tah things with explicit clearance should be consistent with the case where we have a block that is avoiding floats without explicit clearance 13:25:49 iank_: maybe? like if we are going to - i suspect that all engines might behave the same with explicit clearance with zero area floats 13:25:54 iank_: but we should check that i might be wrong 13:26:11 iank_: so if thats the case, then yeah we could still for gemotry purposes ignore floats but that might be a bit weird 13:26:38 iank_: ?? what you tried with servo and blink and it wasnt too difficult. you have two valid things that do correct things but then when it goes to zero you have to choose a behavior 13:26:59 oriol: you would prefer that we would not allow overlapping flaot that is zero pixels tall or wide? 13:27:04 s/??/I think I tried/ 13:27:42 iank_: i would prefer it t overlap with zero width because at least the way that wedected this internally because the new formatting context is doconsidring the area here. if my left edge is here then im allowed to retreat into it. if youre trying to block on a zero width float, ? and so you cant detect it easily, 13:27:55 iank_: if you go down the path where you respect zero width floats ? 13:28:04 iank_: thats just from an implementation complexity point of view 13:28:16 iank_: is this opportunithy the full width? then allow it top protrude left and right 13:28:31 iank_: if you have a float on the right then you want it to protrude out this side and this side 13:28:43 nicole: and thats only if the floated thing is zero width? 13:28:55 iank_: yeah but it happens today also with regular things with width that line up with this boundary 13:29:09 nicole: in believe you but when im trying that im not seeing it 13:29:15 iank_: i can quickly chalk one up 13:29:35 nicole: i couldnt get it to work in a codepen 13:29:45 nicole: it was different in safari and chrome, didnt try firefox yet 13:29:50 https://codepen.io/stubbornella_old/pen/ExzwbNy 13:29:55 https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12813 13:30:13 iank_: youve gotta inset the inner block ? inset the width of the block by the float 13:30:46 iank_: the red formatting context overlaps the line ? in all browsers 13:30:49 iank_: which is great we have compat 13:30:52 iank_: yay! 13:30:59 iank_: oh the spec needs updating 13:31:15 fantasai: lets record a very clear resolution 13:31:21 miriam: whats the path forward? 13:31:48 oriol: i guess we could resolve that the two cases, line box and block should be consistent. if different browsers are doing different things they are consistent except blink in some cases 13:31:50 iank_: which case? 13:32:22 oriol: when you have 0px wide float in an independent formatting context, webkit sometimes avoids it and sometimes doesnt. for text i coudlnt get it to avoid the float 13:32:32 iank_: so webkits inconsistent but link is ok? 13:32:43 s/link/Blink/ 13:32:53 oriol: webkit is a bit self inconsistent i woudl say. in the case of zero pixels wide floats browsers are inconsistent 13:33:11 oriol: for zero pixels tall floats, blink is different from webkit and gecko since its avoids overlapping them against the spec 13:33:37 iank_: test cases for explicit clearance would help 13:34:16 iank_: i think your august 9 2023 comment is the triggerint that behavior tha ti just described 13:34:33 iank_: except that blink is avoiding the horizontal lines 13:34:50 oriol: i think that your case here is different because the float isnt zero or relative, the margin belongs to the other element 13:35:19 iank_: i think your august 9 comment is the same because all browsers today you iknow like if theres a zero width float here then all browwers alllow a new formatting context to overlap and intrude it because its on that edge 13:35:32 iank_: is the start of the opportunity the same as the available space? then allow it to go over otherwise not 13:35:47 iank_: thats i think like - i suspec tht at all browsers are doing this case by default 13:35:58 iank_: the only thtnig thats different is that blink when theres a float like this will try to avoid that 13:36:04 q? 13:36:12 iank_: but i suspect that if you hadd clearance then browsers all might clear that for example. i could try .... 13:36:34 oriol: i guess you are saying that we should allow oferlapping flaots that are zero px wiwde except with clearance, all browsers agree except webit sometimes 13:36:44 iank_: what would be the resolution? 13:36:59 oriol: floats that are zero px wide are negative should not shorten line boxes or shift blocks that are independent 13:37:04 iank_: that might not be true though 13:37:29 iank_: i think thats only true in engines if they are on the edge of the available space. its possible to create a zero width float that isnt on the edge of the available space, you might get different results in different engines there 13:37:44 oriol: in the case i was trying it was not the edge and it was only webkit that was inconsistent 13:38:00 oriol: if yiou look at the last comment in the issue 13:38:17 oriol: for text all browsers agree 13:38:57 oriol: iank_: i think they are - they all avoid it if its a new formatting context 13:39:18 iank_: if its a block formattig context, then gecko and blink are still not avoid it, and webkit sometimes does and sometimes not 13:39:38 iank_/oriol/s 13:39:41 https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12815 13:39:46 oriol: it should be the first table of images in the last comment - in gecko and blink they overlap 13:40:21 iank_: the test case i just pasted everyones avoiding it right? 13:40:25 oriol: in what browser? 13:40:27 iank_: all browsers 13:40:40 Doesn't look like it? 13:40:53 iank_: or maybe everyones avoiding the ? 13:41:05 oriol: not sure if i should put my laptop in the ? or something becuase im not sure we are talking about the same thing 13:41:12 s/the ?/the cyan/ 13:41:41 (that 'the ?' is for iank's last scribed comment^) 13:42:08 iank_: i think theres at least two passes of test cases that lead to ? layout 13:42:22 iank_: one is explicit clearance with all interactions 13:42:33 flackr: im presenting firefox safari and chrome 13:42:49 oriol: so this is the text case which i guess i was using a smaller container because it seems like its ? on the side 13:42:58 iank_: i took the line test case and then just added anew formatting context 13:43:11 iank_: the line and the formatting context behave differently across browsers 13:43:28 iank_: i think that there maybe more ? that we wil need to consider 13:43:50 oriol: so what i was referring to beforehand in this case is that we have this orange float that is zero px wide and then the blue box is overlapping it 13:43:59 oriol: in this case i only saw a different behavior in webkit 13:44:11 oriol: for the text case... 13:44:27 oriol: the text is overlapping the magenta float 13:44:41 iank_: there might be a sublte difference between those two cases 13:44:55 iank_: i think test cases that we need - feel more comfrotable making a decision 13:44:59 iank_: new formatting context ? 13:45:08 nicole: and which were the various combinations? 13:45:19 iank_: basically if youve got a zero width fl-oat and then youre clearing htat zero width float what hpapens? 13:45:36 iank_: cause that will have different interactions. zero widht and height float 13:45:51 iank_: and then - we can deviate there but i suspect that explicit clearance and zero width and zero height wecan't change 13:46:02 iank_: and then what do we do based about clearance based on that 13:46:26 oriol: i guess, what im getting from you is that in this case we want to be able to overlap zero px wide floats but if theres explicit clearance we shoudln't 13:46:28 iank_: yes 13:46:45 iank_: css2 lies a lot. theyre 2 different mechanisms 13:47:06 iank_: the clearance is the way that - they walk through the entire list of floats and then pick and offset and thats different than this gemoetry calculation 13:47:16 oriol: i think ? to different things, so we could resolve on that 13:47:24 iank_: but then what are the - whats the different thing 13:47:28 bts has joined #css 13:47:41 oriol: if you have explicit clearance you could avoid zero px wide, you would be allowed to overlap them 13:47:53 iank_: overlapping only happens interoperably when ? is on the edge of the available space 13:48:04 iank_: it might be different ifyouave got a szero width float and a container with negative margin 13:48:14 s/? to /explicit clearance and no explicit clearance are two / 13:48:17 iank_: now that float is sitting in the middle of the space and now that calculation doesn't apploy anymore 13:48:45 oriol: i didn't see a difference in webkit but in the other browsers firefox and blink they seem to allow overlapping zeropx wide floats in all the cases i tested without explicit clearance 13:48:52 iank_: maybe? id like to see the test cases 13:49:00 miriam: if we take this back to the issue can we document test cases? 13:49:02 iank_: yeah 13:49:16 oriol: im fine with going back to the issue, resolution about line boxes and independent blocks consistent would make sense? 13:49:23 iank_: i dont think theyre consistent 13:49:32 iank_: ive got a test case here where theyre doing different things in all browsers and theyre rendering the same 13:49:36 oriol: ok you can pause this issue 13:49:54 miriam: resolve to close no change? 13:50:07 oriol: not closing no change but deferring until we can continue the discussion in the issue? if we lead to some agreement then we can move on 13:50:18 iank_: yeah this area its common cases thats constrained by that 13:50:27 iank_: im pretty sure i know most of them 13:50:36 oriol: there are cases where browsers are doing different things so i guess compat is not that improtant? 13:50:57 iank_: sure but i dont think you can say that ? where there are cases that are different 13:51:04 miriam: so if we take this back to the issue we need to document compat constraints and then what other test cases are needed 13:51:14 s/?/they are the same/ 13:51:30 iank_: explicit clearance test cases of zero area then zero width zero height being on the availabl espace boundary and not being on the availba espace boundary since theyll be slightly different behaivors there 13:51:40 iank_: and then i think there are differences between line box and new formatting context 13:52:06 miriam: sounds like were taking it back to the issue? 13:52:08 iank_: yep 13:53:10 Topic: [css-position] Static position of abspos top layer elements inside fixed pos. 13:53:28 relative static position of absolute positions, fixed 13:53:45 emilio: This is the case where the static position of the abspos that depends on something laid out after it 13:53:49 emilio: annoying because cyclic 13:54:01 emilio: it seems what Blink does is making the static position at the end of the HTML element or something? 13:54:07 emilio: so mostly ignored 13:54:12 emilio: Gecko [missed] 13:54:18 emilio: And WebKit does something else that's incorrect 13:54:37 emilio: Tab's proposal is to ignore static position in top layer 13:55:15 iank_: I believe what happens is we reparent the top layer boxes in the box tree 13:55:34 iank_: so it's a box tree construction effect, not a layout effect 13:56:03 emilio: Conceptually they're reparented anyway because abspos 13:56:22 iank_: Blink doesn't have the concept of a static positoin placeholder like Gecko does 13:56:33 iank_: so as if you moved the placeholder and the thing during box tree insertion 13:56:54 emilio: Think it's best to ignore the static position 13:57:02 iank_: I think we've defined it to be, this happens at box tree time 13:57:08 iank_: or is it defined as something not that? 13:57:15 emilio: in Gecko we have two boxes for this element 13:57:24 emilio: but conceptually the abspos box (primary box) does get reparented 13:57:39 emilio: the static position, conceptually to me, is the position it would have if it wasn't abspos and thus not in top layer 13:57:49 iank_: but if this gets reparented during box tree... 13:58:12 iank_: when you insert abspos into tree in Blink, we don't reparent to the containing block. It sits whereever it lives 13:58:25 q+ 13:58:25 emilio: but it gets laid out and painted in a different order 13:58:34 emilio: behavior Blink has is super weird, so prefer to ignore it 13:58:41 iank_: you could just reparent the static position box to the same place? 13:58:46 emilio: yeah but I think it's super weird 13:58:54 iank_: but that's what the spec says? 13:59:07 emilio: I think that depends on whether the spec meant to include the static pos 13:59:22 iank_: staticpos is spec fiction 13:59:37 ack futhark 13:59:46 futhark: Spec currently says "rather than generating boxes as usual, generate boxes as sibling of root element" 13:59:50 futhark: so spec says what we do 13:59:55 futhark: if that's not what we want, then we need to change the spec 14:00:12 emilio: I'm not opposed to close no change and test+clarification in the spec but... it does feel a little unusual 14:00:50 emilio: idk if that would cause issues, because then when destroying boxes you cannot reach ... if you remove an element in the DOM, can't reach descendant elements that are top layer 14:01:01 emilio: prefer to behave as regular abspos, parented to the relevant containing block 14:01:11 emilio: I'm fine with either behavior 14:01:35 fantasai: Could someone describe the situation that crfeates a cycle? 14:01:46 s/crfeates/creates/ 14:02:10 fantasai: The top layer escapes the fixedpos to go into the top layer? 14:02:17 emilio: Right. 14:02:27 ack fantasai 14:02:41 fantasai: Why is the top layer element not asbpos? 14:03:00 emilio: Top-layer things escape their usual containing block rules 14:03:14 iank_: Right, they get lumped on the end of the list for the ICB 14:03:36 iank_: The difference at the moment is Gecko doesn't do this well 14:04:05 iank_: In Gecko the placeholder isn't reparented so you need to lay out a second level of top layer thing to get the correct static position 14:04:12 fantasai: They're both top layer? 14:04:26 iank_: They're both direct descendants of the ICB 14:04:44 fantasai: I agree with Emilio it's super weird to reparent them and have them at the end of the static HTML element 14:04:58 fantasai: I suspect what the spec meant is similar to what happens with fixed position 14:05:12 fantasai: They wanted to make sure it would be painted on top 14:05:31 iank_: Pulling into a separate list at the ICB level achieves what's needed 14:05:38 fantasai: Yeah, the answer is just very weird 14:06:14 q+ 14:06:36 …I agree with Emilio that the static position of the element being at the end of the HTML element is super weird even if that's easy or what the spec currently says 14:06:45 ack futhark 14:06:53 s/super weird/super weird from an author's PoV/ 14:07:38 https://drafts.csswg.org/css-position-4/#top-styling 14:07:51 > Unless overridden by another specification, its static position for left, right, and top is zero. 14:08:07 futhark: In section 3.1 in CSS-position-4, there's a list on top layer styling that the static position for left, right, and top is 0. 14:08:20 TabAtkins: I guarantee I forgot to list out all four 14:08:51 fantasai: I don't know how much review this rewrite has gotten 14:09:13 Comes from https://github.com/w3c/csswg-drafts/commit/051d37a64ca714fa0238df6db019967de2a086dd fwiw 14:10:03 fantasai: I'm not sure how much reliance I'd put on the validity of the spec since it was copied over from another spec 14:10:19 TabAtkins: Since top layer is new, we probably don't have a lot in the way of meaningful compatibility troubles 14:10:21 s/another spec/another spec drafted by someone who isn't a CSS layout spec expert/ 14:10:26 …So let's just do the simplest possible thing! 14:10:42 …Which is 0,0 static position 14:10:57 iank_: With a zero-width-height static position? 14:11:23 TabAtkins: The concept of static position doesn't exist and everything resolves to zero 14:11:30 iank_: You don't want everything to resolve to zero 14:11:33 TabAtkins: Why not? 14:11:47 iank_: I think you actually just want the static position at 0,0 14:11:54 TabAtkins: I don't understand the objection 14:12:09 iank_: Anchor position sets the alignment differently and strethces 14:12:20 TabAtkins: Oh, yes, we probably want to fix that to not stretch 14:12:30 iank_: Other elements don't support alignment 14:12:52 TabAtkins: If we set it to 0,0 in the corner we don't get the auto-alignment, which we wanted to avoid in anchor positioning 14:13:04 …For legacy reasons, we can't get away with that in abspos 14:13:17 iank_: I think in UA styles, all these things have been set to zero anyway 14:13:30 …Like, you have to set insets to trigger this behavior, right? 14:13:39 emilio: For popover, I think so, but I'm not sure about other things 14:14:00 iank_: I'm fine with saying that static positioning is zeroed out 14:14:23 fantasai: Is that going to make sense for non-fixed-position cases like top layer elements that are halfway down the page? 14:14:37 iank_: Reparenting in the box tree up to the very top, when would that trigger? 14:14:53 fantasai: You scroll halfway down the page and you click on something that's in the top layer 14:15:04 …If it's fixedpos and not in the viewport you can't read the whole thing 14:15:24 …Sometimes it gets pushed into a static position, which makes it scrollable 14:15:45 TabAtkins: The generic answer is, if you want to attach to a thing on the page, use anchor positioning 14:15:59 …We don't need to rely on fixed things that are weird if we have a more powerful variant 14:16:51 (awkward silence) 14:17:11 miriam: I don't feel a need to preserve static positioning generally, and especially not going into the top layer 14:17:24 TabAtkins: Can we just say that then? 14:17:34 …If you're top layer, we do the same as anchor positioning? 14:17:55 fantasai: I think what makes more sense is to define the static position rectangle in the ICB, which I think gives you the right effects 14:18:07 TabAtkins: I don't see why it would, necessarily 14:18:20 …There'd be no connection to its normal position in the DOM 14:18:39 fantasai: I think we want to define the rectangle where it lives and define what that means 14:18:57 …If you set everything to zero then it will anchor to that edge 14:19:02 …We should talk about it offline 14:19:09 TabAtkins: Ah, I see what you mean 14:19:18 …We can resolve on doing something arbitrary 14:19:56 fantasai: Propose to make the static position of the top layer does not depend on the size or position of any other element on the page 14:20:08 fantasai: And probably define by making staticpos rectangle as ICB 14:20:46 miriam: Do we have a thing we can resolve on? 14:21:01 kbabbitt has joined #css 14:21:03 PROPOSED: Make the static position of top layer boxes not depend on the size or position of any other element on the page, likely by making static position rectangle the ICB 14:21:28 sgtm 14:21:29 miriam: Any objections? 14:21:42 RESOLVED: Make the static position of top layer boxes not depend on the size or position of any other element on the page, likely by making static position rectangle the ICB 14:25:48 I have made the request to generate https://www.w3.org/2024/06/11-css-minutes.html fantasai 14:33:54 lwarlow has joined #css 14:35:18 kizu has joined #css 14:40:37 jarhar has joined #css 14:40:40 scribenick: jarhar 14:41:08 ydaniv has joined #css 14:42:30 github-bot, topic https://github.com/w3c/csswg-drafts/issues/7884 14:42:30 Topic: [css-box-4] Longhand values of `margin-trim` allow more combinations than shorthand values 14:42:30 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7884. 14:42:37 none | block | inline | [ inline-start || inline-end || block-start || block-end ] 14:42:50 fantasai: the current syntax of margin trim looks liek this, which doesnt very eaily allow the ability to say all of the sides 14:42:57 none | 14:42:57 [ block || inline ] | 14:42:57 [ block || inline-start || inline-end ] | 14:42:57 [ inline || block-start || block-end ] | 14:42:58 [ inline-start || inline-end || block-start || block-end ] 14:43:01 fantasai: there was a suggestion to allow all possible combinations that make any sense 14:43:21 fantasai: then there was tabs alternative proposal which was to change the block or inline the original syntax to a double or which would look like 14:43:32 none | [ block || inline] | [ inline-start || inline-end || block-start || block-end ] 14:43:50 fantasai: im not sure how often peoplw ant to trim 3 our of 4 sides and if they really want to they can list 3 keywords instead of 2 14:43:56 TabAtkins: the third keyword would be slightly longer 14:44:02 fantasai: i suggest we accept tabs proposal 14:44:06 q+ 14:44:15 una: i like it lets do it 14:44:17 ack una 14:44:30 +1 14:44:41 miriam: the other proposal in there about all, is that something that needs discussion? 14:44:56 TabAtkins: it was my suggestion, i dont care. elikas hesitation ?? 14:45:00 q+ 14:45:10 una: i wouldnt mind having both all and block inline but if there is risk for future compat then im happy with just block inline 14:45:19 ack oriol 14:45:24 s/??/hesitation about confusion with possible future additions makes sense to me/ 14:45:33 oriol: are we then allowing combination of horziontal block wth inline keywords? the second thing you wrote isnt allowing those combinations? 14:45:44 fantasai: yeah you cant write block inline start if you wanted to do that youd have to write block start inline start block end 14:45:47 una: its like margin 14:45:50 fantasai: i think thats ok 14:46:17 fantasai: proposed resolution is to allow the combination of block and inline keywords 14:46:30 miriam: any objections to that resolution? 14:46:46 RESOLVED: Allow combination of 'block' and 'inline' keywords in 'margin-trim' 14:47:19 github-bot, topic https://github.com/w3c/csswg-drafts/issues/6922 14:47:19 Topic: [css-box-4] Applying margin-trim to inlines 14:47:19 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6922. 14:47:42 fantasai: the question was kind of what effect this should have on inline boxes and what effect should htis have on the inline axis of boxes 14:48:03 fantasai: those are the two questions i wanted to ask to the working group. applying it to inline level boxes is complicated so we probably dont want to do that 14:48:12 fantasai: if you set margin trim block inline then that would always affect the block i guess? 14:48:21 fantasai: but im not sure why you would want to do that 14:48:35 q+ 14:48:43 ack una 14:48:59 una: i can see why yodu possibly want to do this on an inline element, if it was creating more height than youd want then you could trim it, but im not sure about straight inline 14:49:51 fantasai: oriol pointed out one of the complications of inlines is that we generate anonymous block classes, so if its margin trim doesnt inherit then if somethings the first - is on the top line then its not necessarily that its adjoining the top edge of the box so we would have to i guess drill through the block edges that dont have padding and 14:49:51 margin and border just like margin col.apse 14:49:57 fantasai: which we can do 14:50:16 iank_: keep in mind that margin collapsing pieces through inlines block side of an inline of that inner block affects the position 14:50:29 s/pieces/pierces/ 14:50:35 iank_: it makes me sad too 14:50:40 s/inline element/inline-block element 14:51:38 dbaron: so my intuition about this is sort of that this proeprty makes sense in the direction in which a block lays out - in the direction in which a blocks children advance. but it doesnt make sas miuch sense in the other direction because of the other thing that you mentioned about inheritance because it becomes hard to follwo the principle that 14:51:38 addaing an empty div aroudn sometjhing doesnt change it. it does apply to block but not grid etc 14:51:50 dbaron: so i kind of feel like for block we probalby dont want this to apply on the inline sides 14:52:10 s/addaing an empty div aroudn sometjhing/dbaron: adding an empty div around something/ 14:52:15 dbaron: mainly i think because of the idea that it does really weird things for thing sthat are diredcdt children of the blcok and we dont want that distinction to be exposed that heavily 14:52:27 fantasai: yeah you have to have a recursive effect to make it do that 14:53:02 fantasai: but then i can see it bein gusefulf or inlines if you have an inline block for example and its on the edge of the paragraph you might not want it to have a margin on that edge. but that could be something we do with a spearate property that applies to the inline rather than this property 14:53:32 s/bein gusefulf/being useful/ 14:53:39 dbaron: and i guess one response to something una said earlier, maybe somebody said this already in the meantime but the property applies to block containers flex container grid containers which means it does apply to inline block because block container means that the dipslay type on the inside 14:53:46 dbaron: so that means blcok and inline block 14:53:53 dbaron: vs the other term for the thing on the outside 14:53:57 fantasai: inline ??? 14:54:28 fantasai: ok so current state is that we are going to spec margin trim on the block container and no affect on inline container, only affects its block level content, basically ignores the inline values of margin trim 14:54:48 Francis_Storr has joined #css 14:54:49 miriam: is that a propsoed resolution? 14:54:51 fantasai: yeah 14:54:55 s/???/block versus atomic inline/ 14:55:04 miriam: any objections to that resolution? 14:55:08 SGTM 14:55:09 (block level) 14:55:49 RESOLVED: margin-trim has no effect on the inline axis of a block container 14:56:07 RESOLVED: margin-trim on a containing block does not affect inline-level content 14:57:26 github-bot, topic https://github.com/w3c/csswg-drafts/issues/8014 14:57:26 Topic: [css-align-3] `grid-*-gap` should be aliases instead of shorthands 14:57:26 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8014. 14:58:06 oriol: so we had the case with grid that we initially added the grid properties but then we wanted to ? as gap and then the currently the specification that grid gap should be a hsorthand of gap 14:58:17 oriol: however, but firefox and webkit implement it not as a hsorthand but as an alias 14:58:40 oriol: both cases basically have the same behavior but if you set a variable to the grid gap property, then you try to read the value of the gap property, if they are aliasses then you get the ? otherwise you get the emptry string 14:58:46 oriol: if it gets set to an internal ? value 14:58:54 s/?/pending substitution/ 14:59:00 oriol: and then i think that doing show interest or ended up doing it as an alias i dont remember the situation 14:59:04 dbaron: it is already done and shipping in 125 14:59:14 oriol: the propsoed resolution would be that grid gap should be an alias of gap and not a shorthand 14:59:16 fserb has joined #css 14:59:21 oriol: not sure if i missed anything 14:59:31 make the spec fiction, non-fiction :) 14:59:32 miriam: so thats the proposed resolution and is also whats now shipping? 14:59:37 dbaron: yes it is now shipping in 3 engines 14:59:49 dbaron: we added it to the agenda around the same time we made the change and it took some time to come to the meeting 14:59:57 miriam: great, lets resolve on the thing that all the engines do 15:00:07 fantasai: make grid gap aliases 15:00:21 PROPOSED: Make grid*gap properties be legacy name aliases 15:00:33 RESOLVED: Make grid*gap properties be legacy name aliases 15:01:13 github-bot, topic https://github.com/w3c/csswg-drafts/issues/9935 15:01:13 Topic: [css-grid] Include scrollbar gutter in #subgrid-edge-placeholders 15:01:13 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9935. 15:01:47 oriol: this is more like a ? issue, basically theres a list of behaviors in some things defer from grids. one of these items in the list, the test is using the summary of the ?, the margin, the ? 15:02:04 oriol: in similar sum of values ?? withou thte scope of gutter, and the scope of gutter should be adding to the second one 15:02:15 oriol: browsers are alreayd doing this because this is whats dropping scrollbar gutter 15:02:24 florian: the complicated values arent needed because we have this 15:02:47 florian: the scrollbar gugter is between the padding and the border, ??? it would just be weird. resolve already 15:02:53 s/? issue/editorial issue/ 15:02:56 miriam: is there any discussion needed on this? 15:03:00 RESOLVED: Add scrollbar gutter to the list where it's missing 15:03:39 s/? issue/editorial issue/ 15:03:42 github-bot, topic https://github.com/w3c/csswg-drafts/issues/9904 15:03:42 Topic: [css-overflow] Top layer containing block and scrollbar-gutter 15:03:42 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9904. 15:04:41 emilio: the thing i noticed is that were doing some fixes with how we deal with scrol.bar gutter. it seems very weird that the contiang block for top layer elements and for fixedpos at least, but it does account for scrollbar gutten and that a fullscreen element wouldnt cover the whole screen 15:04:50 emilio: i wonder if someone has context on why we shouldnt do that 15:04:59 ack fantasai 15:05:17 q+ 15:05:21 fantasai: i think the main reason why you whouldnt do that is because then you cant scroll. that why it doesnt do that for fixed elements. if you have a top layer thats abspos, you want to scroll to see whats below the fold. if you cover the scrollbar then you have a problem 15:05:37 emilio: the main issue is that fullscreen would usually - why does - i need to test this more 15:05:40 q- 15:05:44 q+ 15:05:46 emilio: what youre saying makes sense 15:06:05 ack bramus 15:06:23 bramus: i see both things here and what elika said, you dont want to cover up the scrollbar so that people can scroll, but i think thats fine - you make an element fullscren and that element can be scrollable but only if that thing is overflowing and has scrollbar 15:06:37 fantasai: what if its too big? if i make an element fullscreen and give it 150vh 15:06:46 q+ 15:06:47 bramus: then that element itself will take up the whole screen 15:07:01 bramus: same as if you have a posfixed 500vh you cant reach the bottom contents 15:07:16 iank_: yeah this isnt a new problem people already do this ?? scorllable overflow 15:07:32 fantasai: if the fullscreen element is fixed then arent fullscreen elemtns always fixed 15:07:40 s/then/sure, but/ 15:07:58 kizu: i think i wanted to mention a use cases usually involving overlays which look rather weird when you show some modal with an overlay and it doesnt cover the parent scrollbar on the root scroller 15:08:12 kizu: right now fixed element and top layers do not do anything with the root scroller, so yeah i think there are use cases for both 15:08:17 kizu: would be nice to have some way to handle this 15:08:23 Also see https://github.com/w3c/csswg-drafts/issues/8099 with a bunch of screenshots. 15:08:48 fantasai: im not sure what the right answer is but i dont want to get into a situation where different sized phones work or dont work 15:09:05 bramus: i think we can make a distinction between posfixed and fullscreen 15:09:24 bramus: its fine if you wrote somethint to become fullscreen but if it should be scorllable and you make a fullscreen element scrollable and then for regular posfixed thats a separate issue 15:09:31 q? 15:09:32 TabAtkins: i agree, we should probably ? both cases 15:09:35 ack kizu 15:09:42 emilio: we dont suppress scrollbar gutters which is weird 15:09:52 fantasai: the gutter should be whatever the scrollbar is doing, thats for sure 15:10:22 bramus: example, on youtube if you fullscreen you can only scroll down to the comemtns, would be weird if you fulllscreen a video and then in the overlay you need to scroll the video and the coments underneath 15:10:30 bramus: distinguish regular posfixed and fullscreen 15:10:40 fantasai: that makes sense for posfixed but for absolutely positioned not sure 15:11:29 bramus: for posfixed specifically, you coudl also say ok if you have a footer ?? if you have a scrollbar but for that i filed issue 8099 which goes over that and some other issues, so we could discuss there or in another issue 15:11:56 fantasai: we at least have conasensus that fullscreen otp layer fixposed elements should cover all the gutters and scrollbar because we wouldnt be able to scroll them anyway 15:12:21 PROPOSED: top layer / fullscreen elements with 'position: fixed' cover the scrollbars/gutters 15:12:46 miriam: any objections? 15:12:56 RESOLVED: top layer / fullscreen elements with 'position: fixed' cover the scrollbars/gutters 15:13:23 emilio: ??? fullscreen element not fixed 15:13:45 fantasai: its clarified in the resolution. if its position fixed ? top layer fullscreen, if its abspos either one of these, we dont know what hpapens yet 15:13:49 https://fullscreen.spec.whatwg.org/#user-agent-level-style-sheet-defaults 15:14:14 emilio: i think we can simplify the resolution and say top layer fixpos because i dont think you can make a fulscreen not fixpos 15:14:19 fantasai: if we change that later, i dont know how 15:14:21 emilio: ok sure 15:15:00 s|top layer / fullscreen|(top layer or fullscreen)| 15:15:26 github-bot, topic https://github.com/w3c/csswg-drafts/issues/7770 15:15:26 Topic: [css-sizing-3] border-collapse: padding-box 15:15:26 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7770. 15:16:12 fantasai: this was a suggestion from a designer develoepr to be able to use simplify the amoutn that they have to track for sizing padding because frequenstly they want to have a constant amoutn for th epadding plus border and then be ??? 15:16:29 Growing the border on hover without causing layout jitter, etc, is the use-case 15:16:45 fantasai: so the question is then do we want to have the ability to say that box sizing has the ability to say it includes the width of the padding and the borders to have the padding amount be both the padding and the border 15:17:09 q+ 15:17:12 fantasai: two questions are do we want to add this feature where the number that the author specifies for the padding is the padding and the border, and the seconde question is do wwe want to do that by adding a keyword to box sizing or creating a new property 15:17:14 q+ 15:17:18 ack florian 15:17:25 florian: third question is if we do that and the author specifies a border bigger than the padding, then what? 15:17:31 fantasai: then you take the max 15:17:43 TabAtkins: outside the use case, so do the obvious thing 15:17:45 ack iank_ 15:18:03 iank_: i think this is fine. the only question is how do scrollbars interact with this property and because they ? between the padding and the border, i agree that this should be in proper sizing 15:18:08 q+ 15:18:15 s/proper sizing/box-sizing/ 15:18:24 q- (fantasai had of course answered my question) 15:18:35 q- 15:18:40 ack dbaron 15:18:54 dbaron: i was gonna ask we probably do need to say no it interacts with the border collapse property but it sa proeprty where the interaction is messy, maybe if you use border collapse tables then you can tuse this feature 15:18:56 q? 15:18:58 iank_: you cant use box sizing in both 15:19:06 fantasai: dont we just not even ? the border when ? 15:19:09 iank_: no we do 15:19:12 dbaron: they still have padding 15:19:20 q+ 15:19:22 iank_: i dont know that box sizing ... 15:19:33 dbaron: im also in the camp of ? reusing box sizing but making this distinct 15:19:35 ack florian 15:19:45 s/? reusing/not reusing/ 15:19:49 florian: for the scrollbar gugtter part of the problem ? if tyour padding is not enough to cinlude then you just increase the whole thing 15:19:54 fantasai: thats probably what people would expect 15:20:04 s/can tuse/can't use/ 15:20:20 miriam: is there syntax here? are we resolving to do this then take it back to the issue for 15:20:54 fantasai: its a certain amount of bikeshedding. we need more clarity from usecases should this be a keyword as part of box sizing a separate property or should we split box sizing into two longhands, box sizing size and box sizing padding or something 15:21:15 florian: yeah we need more info about use cases which things need to cascade separately or not 15:21:34 florian: maybe all the info we need is already in the github issue but it hasnt been digested yet so we can resolve on what we have so far 15:21:47 fantasai: then we cna say heres the 3 options, tell us your thoughts on the pros and cons 15:22:30 PROPOSED: Add a control for making padding size include border-width; ask for feedback on its relationship to box-sizing 15:22:53 miriam: any objections to that proposal? 15:23:09 florian: do we need followup resolutions? 15:23:13 fantasai: the minutes are good enough 15:23:18 RESOLVED: Add a control for making padding size include border-width (and scrollbar width); ask for feedback on its relationship to box-sizing 15:23:20 dbaron: does anybody object to my retitling of the issue? 15:23:24 fantasai: go ahead 15:23:42 github-bot, topic https://github.com/w3c/csswg-drafts/issues/9916 15:23:42 Topic: [css-tables][css-backgrounds] Does background-clip work on table columns and rows? 15:23:42 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9916. 15:24:08 oriol: they both are ? table rows, table row group, table columsn, but im going to say rows 15:24:32 oriol: they have a special behavior when they get a background, the background applies to the entire row but instead of padinding that we clip the result to each cell in the row, then when implementing this in servo we had that qeustion about how we should treat the background clip property 15:25:11 oriol: there are two reasonable interoper4tations. the backbground clip applies to the row itself, but since the row doesnt haef padding or border of its own, unless you use border collapse or something, otherwise it doesnt have pading or border so basicaly the property has noe ffect. this would resolve in the firefox behavior where you resolve to 15:25:11 content box and it doesnt change from border box 15:25:27 oriol: when c.ipping to each cell, we takt eh backgorund and borer of each cell into account and then ? into the area 15:25:41 oriol: clip to the contnet box itself. this is what blink is doing. webkit was completely broken 15:25:47 oriol: asking which option would be preferred 15:26:20 dbaron: i have two thoughts on this and they contradict each other. neither is very strong 15:26:36 dbaron: it seems liek theres a readonable thing for th eproeprty to do and that makes it do the same thing it does everywherele slse so why not have it do a thing instead of do nothing. 15:27:05 dbaron: the other thought is that it wseems weird for backgrounde clip and background origin to do different things, it seems weird for background origin and backbground clip be relative to different things. one argues one way the other argues another 15:27:10 q+ 15:27:18 ack fantasai 15:27:18 fantasai, you wanted to show some diagrams 15:27:24 fantasai: i work on this part of the spec a long time ago 15:27:43 fantasai: the model we have for how rows paint is that you dra wht erectangle and thn you clip out the indificual cell areas because otherwise tihings wont line up nicely 15:27:55 fantasai: if you explode the cells it isnt as nice as when the cells are windows 15:28:17 present- 15:28:24 fantasai: the paint area is not that the row boxes mean, it expands beyond that so that the window of an indivicual ceel has to include the row boxes area because it expands into a different row. otherwise you ge thti sefect where you can tsee the text 15:28:31 fantasai: the origin is relative to the row box 15:28:35 fantasai: ill drop a link to this 15:28:41 https://fantasai.inkedblade.net/style/discuss/table-backgrounds/ 15:28:43 florian: i think hyou already have an issue 15:28:48 ack astearns 15:28:58 astearns: am i interpreting these diagrams then fantasai you are going for the second propsal 15:29:23 fantasai: i think i agree with davids assessment of this situation.we can argue there is a bit of differece in terms of the rows painting. it can paint well outside the rows area 15:29:33 fantasai: so i thin kk i might lean more towards making it useful 15:30:00 astearns: my response to david on theidea of having it do something rather than nothinkg , whats the likelihiood of having something we specify be interoperably imnpelemtned, might not be a priority 15:30:33 iank_: we improved a bunch of our rendering a few years ago because we had bugs in this area and webdevs were complaining about it, so given enough webdev response we prioritize it 15:31:08 dbaron: my intuition is that this i sprobably a single digit ish number of lines of code change, maybe a little worse if you need to change 7 functions to pass the right thing throughj them but if it already works for cells then just do the same thing as scells for these other things 15:31:10 then I withdraw my concern 15:31:33 miriam: i like useful things more than non useful things 15:31:50 miriam: is there more discussion here? 15:32:03 fantasai: so the propolsal is to make background clip on tables cols and rows change the clip of the cell box? 15:32:17 miriam: are there any issues with how that interacts with clipping on cells or is taht well defined 15:32:20 fantasai: its well defined 15:32:37 fantasai: we kind of already have a cell defined clip area so that ? the cell respond to the rows or columns 15:32:42 miriam: lets take that resolution if we cna 15:32:49 s/that ?/that would make/ 15:33:24 RESOLVED: background-clip on table columns and rows is interpreted against the cells' box geometry 15:34:34 github-bot, topic https://github.com/w3c/csswg-drafts/issues/10042 15:34:34 Topic: [css-cascade-6] Should `@scope`'s `` & `` be unforgiving? 15:34:34 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10042. 15:35:47 TabAtkins: we specified at some point that the scope start and scope end selectors use forgiving selector list. we were hoping we could use it as many places as we could, and we later changed that decision and ended up locking it down and making forgiving selectors to only be used in is and where. this spot was missed so we should match precedent 15:35:47 and make these forgiving as well 15:36:02 TabAtkins: if you have a comma separated selector list, unforgiving is where whole thing gets dropped and is invalid 15:36:15 TabAtkins: you can always recover forgiveness by wraping in is, mostly 15:36:33 astearns: anyone that wants to make the argument that is and where are the only things we should make forgiving? 15:36:44 miriam: scope is somewhat where like 15:37:04 TabAtkins: we ended up leaning more toward learnability, nearly identical functions which are mostly noop and everywhere is just normal, the terrible css evolved 15:37:35 astearns: tab have you looked to see where we have forgiving in other places we should not have 15:37:44 TabAtkins: a quick grep would estabish 15:37:49 astearns: alright. any other comments? 15:38:02 astearns: it is possible to make these forgiving 15:38:17 miriam: forgiving selectors are good for authors and if we can use them more then we should 15:38:46 fantasai: we can make an argument that it might not matter as much fo rscope start whether its forvinging or not because a forgiving scope start selector it just means that it snot gonna match what you thought it was going to match, typically how selectors work. 15:39:10 fantasai: in a scope end selector if you have a forgiving and you use a selector that is not suposerted then your styles will apply to a whole bunch of things you didnt expect and could be a mes 15:39:14 q+ 15:39:19 fantasai: for scope end its important that its unforgiving 15:39:23 q- 15:39:31 fantasai: making it forgiving in scope start is easier to understand 15:39:33 ack dbaron 15:39:33 dbaron, you wanted to discuss audit results 15:40:09 miriam: I accept that logic! 15:40:21 dbaron: i just did the grep, it looks like were ok, there were 3 specs that did forgiving, selectors 4 makes is use it ??? one of them is ??? one of them is nesting 1 which has intentional prose about how ampersand in a selector list for forgiving selectors. i think this is it unless there is something that says i use the same syntax as is or where 15:41:05 RESOLVED: @scope start and end selectors are unforgiving 15:41:26 selectors-4 defines it, makes :is() use it, and makes :where() like :is(); cascade-6 was the issue we just dealt with, and css-nesting-1 has some prose about & inside of forgiving-selector-list 15:41:38 fantasai: you can make it forgiving explicitly 15:41:52 github-bot, topic https://github.com/w3c/csswg-drafts/issues/10196 15:41:52 Topic: [css-cascade-6] Specificity of Implicitly-Added `:scope` in Scoped Rules 15:41:52 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10196. 15:42:34 emilio: the at scope rules insert an explicit :scope selector when you dont have it, much like nesting 15:42:52 emilio: its weird but it seems intentional as per the discussion in the issue that :scope doesnt contribute to specificity 15:43:08 emilio: its weird but it also seems like if you do the ampersand then webkit and blink have different behavior which is weird 15:43:13 emilio: i think i would expect webkits behavior there 15:43:18 emilio: thats basically a question 15:43:28 miriam: webkits behavior in which? 15:43:34 emilio: in the ampersand case. 15:43:41 https://github.com/w3c/csswg-drafts/issues/10196#issuecomment-2065371007 15:43:56 TabAtkins: the example with which behavior chrome is and which behavior webkit is 15:44:19 emilio: basically ampersand inside scope rules means :scope and right now chrome seems to ignore the specificity of scope ? you have explicitly written the ampersand 15:44:48 miriam: ampsersand isnt :scope exactly, it refers to the scope root element, and the ampersand refers to the seelector in the scope start. consistent with how those two selectors have worked in other places. ampersand refers to a selector and ? refers to an element? 15:45:00 TabAtkins: the ampersand the referring selector is empty 15:45:17 emilio: ampersand and :scope are effectively the same right? 15:45:35 TabAtkins: behavior is the same except for this case because ones a pseudo class and one is a parent selector. how academic this is is a good question 15:46:08 kizu: you could use it not to just target the scope itself ? 15:46:16 kizu: i managed to do something with it but i dont remember exactly 15:46:23 miriam: what does ampersand do on its own? 15:46:30 TabAtkins: its supposed to match the same element in the parent rule? 15:46:36 miriam: what about root level of a stylesheet 15:47:39 matthieud: the root level - it should be :root and it gets one specificity of the pseudo class 15:47:57 TabAtkins: that is not specified in the spec. the specificity line explicitly refers to the line ? selector list, doesnt say what specificity is 15:48:03 TabAtkins: thats just what browsers are doing on their own right now 15:48:34 miriam: im getting zero specificity in chromium 15:48:50 emilio: another case where gecko and chromium do zero specificity but webkit does use specificity 15:48:55 data:text/html,

ABC 15:49:05 green in webkit, blue in gecko / blink 15:49:08 astearns: so we need to fix both things 15:49:19 TabAtkins: we can decide on which behavior we like better, but ... 15:49:27 TabAtkins: zero specificity in chrome 15:49:44 miriam: that feels a little strange to me but i dont have an argument why the other would feel less strange. i dont think of it as a zero specificity selector 15:49:55 TabAtkins: doesnt have a specificity to refer to, it just matches the same thing as scope 15:50:04 TabAtkins: not defined in terms of that selector existing having specificity 15:50:18 miriam: if we have it at zero specificity, then we specify everything on ampersand instead of root 15:50:24 miriam: people will say where root to get zero specificity 15:50:50 TabAtkins: the only difference is if ? target root to ? some of the properties with html as a selector. that would lose if it had a pseuco class specificity. in all cases it wouldnt matter 15:50:57 TabAtkins: they can already do it with where 15:51:29 miriam: maybe the scope case is a better one to look at. is it surprising you write styles scoped styles in an embedded stylesheet you use the ampersand, you get zero specificity 15:51:29 fserb has joined #css 15:51:36 miriam: thats where it would become an issue more often because someone woudl be targeting that div 15:51:53 miriam: if you use solely an ampersand it becomes zero outside stylesheets have ? specificitity, scope comes into play, that becomes riskky 15:52:10 TabAtkins: giving it a specificyt of zero pseudo class is easy to override, zero is easier but not by a huge amount 15:52:37 astearns: im hearing lots of strong opinions, how are we going to decide? 15:52:49 TabAtkins: technically chrome and firefox agree and spec. as 2/3 aint bad 15:53:10 emilio: yeah not strong opinion. just some of it - having a ? context selector doesn't increase specificity 15:53:13 emilio: yeah i guess its ok 15:53:56 s/? context selector/more complex selector which/ 15:53:56 matthieud: i dont have a strtong opionin either, but when you ? a selector more when you add some part to a selector :root i guess itm kaes sense when you are more explicit that you get something from it 15:54:04 matthieud: all this is really edge case i dont know if anyone will check this 15:54:08 miriam: so thats an argument for zero? 15:54:31 astearns: and i believe that the issue about wpt, do they test for zero or something else? 15:54:45 emilio: i think that they test for zero specificity but thats for visit scope not ampersand 15:55:00 astearns: so we could resolve on zeroing both a bare ampersand and scope 15:55:29 astearns: since nobody has a strong opinion about it and they should probably match and we have tests that browsers pass, but with the option of reopening it if we find a use case for doing non-zero at some point in the future 15:55:41 TabAtkins: ultimately authors can do that - they can just put :scope in the @scope selector and that will do it 15:55:54 astearns: and if we find people doing that maybe we can say hey maybe we should be doing hta tautomatically 15:56:09 fantasai: summary of what we're talking about? 15:56:16 TabAtkins: do you want to the proposed resolution? 15:56:26 fantasai: we talked about :scope and ampersand, are we talking about both fo tth eresoultion? 15:56:43 explicit :scope is fine, things to discuss are "implicit" scope and bare ampersand 15:56:46 TabAtkins: no, ampersand doesn't have a selector for its parent, when it implicitly selects nothing at all its specificity is zero 15:56:52 astearns: which is tested but not specified 15:57:02 TabAtkins: it is technically specified, not explicitly. it should be more explicit 15:57:11 fantasai: and whats an example of a case where ? selector 15:57:22 TabAtkins: its at the root level or inside a scope which doesnt have a scope start 15:57:28 fantasai: for example inside a style element 15:57:29 TabAtkins: 15:57:31 TabAtkins: right 15:57:46 astearns: there would also be a resolution that the - that scope would match this as well 15:57:58 fantasai: :scope would be zero always or only when its implicit 15:58:26 fantasai: if i have an at scope and a id selector, then when i write foo inside there, im implicitly adding :scope and that adds a pseudo class to it 15:58:40 TabAtkins: no, that was a decision we made on purpose. you just get the selector that you wrote plus the magical scoping behavior 15:58:52 fantasai: so it doesn't inherit the scope start specificity unless you write :scope explicitly 15:58:59 fantasai: so why dont we do that in the case ?? 15:59:05 matthieud: its not true for the ? selector 15:59:41 TabAtkins: for general nesting, its expected - if nesting didnt ? the specificity then everything would break. scoping gives us some ? for nesting you assume your rules are more specific 15:59:54 TabAtkins: otherwise &hover would almost never match because the parent rule would override it 16:00:11 fantasai: i was trying to figure out why it would suddenly gain some specificity 16:00:15 miriam: nobody is proposing that 16:00:25 miriam: its not clearly defined in either place, lets make sure its the same 16:00:38 s/&hover/&:hover/ 16:00:43 TabAtkins: explicitly state in specs that when an ampersand doesn't actually have a parent rule to draw from then its specificity is zero 16:00:51 TabAtkins: explicitly defined in the spec 16:00:58 astearns: any objections? 16:01:10 astearns: do we also have to make a scope resolution? 16:01:19 TabAtkins: neither ampersand nor explicit scope - thats already in the spec 16:01:22 astearns: i think we are done 16:01:32 RESOLVED: explicitly state in specs that when an ampersand doesn't actually have a parent rule to draw from then its specificity is zero 16:01:36 topic: end 16:08:50 Francis_Storr has joined #css 16:16:43 zrhoffman has joined #css 16:25:48 zrhoffman has joined #css 17:55:43 Linux_Kerio has joined #css 18:22:20 Zakim has left #css 18:58:18 cabanier has joined #css 21:00:18 Linux_Kerio has joined #css 21:37:54 zrhoffman has joined #css 22:01:40 zrhoffman has joined #css 22:24:39 zrhoffman has joined #css 23:26:24 antonp has joined #css