00:00:23 flackr i agree that it's a better model for props which are meant to be used outside. but for the ones meant to be encapsulated, would be nice if they were defined internally only 00:00:33 +1 to flackr 00:00:43 q+ 00:00:43 ack TabAtkins 00:00:47 TabAtkins: any shadow internal custom props being in capable of being defined, unless you also include a script or stylesheet globally is bad 00:00:51 q+ 00:01:10 the fact that they can't be scoped at all is a consequence of inheritance. being able to define them internally with a well named internal semantic is worth it 00:01:22 i can accept it being global only. 00:01:28 ack noamr 00:01:53 noamr one way to resolve this. problem with internal props is that it could be a mismatch. so if it's defined internally, let's make it not inherited 00:01:55 present+ 00:02:01 then this is your own property, deal with it 00:02:26 your prop would fallback to what you defined in the descriptor as initial value and not inherit from global scope 00:02:42 TabAtkins what happens on the host element itself. can define something. otherwise the idea sounds reasonable 00:02:51 ack emilio 00:02:59 emilio was gonna argue for currently implemented behaviour 00:03:34 q+ 00:04:16 as soon as there are name conflicts. you need to remove all the niceties of the shadow dom data encapsulated. have preference for the current behaviour. i need to think through, you have properties with same name. one is defined outside via part one is inside via regular stylesheet. that also seems fairly annoying. preference to just spec what is 00:04:16 currently there 00:04:42 TabAtkins i want to explore the behaviour noam was talking about. if we can find a less annoying version. but ok with specing current behaviour 00:04:47 ack kizu 00:06:01 kizu: this is something i encounter without shadow dom. multiple sources define the same prop name with different values. if some element registers it with a different value, custom element on the host or regular element on itself. as soon as it reaches this by inheritance it will use initial value if there is a type mismatch 00:06:29 you define for your scope. if an internal one defines the same type then inheritance works otherwise it's overridden 00:06:39 q+ 00:06:44 TabAtkins if noam's idea is limited to defining on tree roots it matches your idea 00:06:51 and sounds reasonable behaviour to me 00:07:26 q+ 00:07:56 ack westbrook 00:08:09 astearns my chair hat off, i would accept what noam is proposing. prop def scoped to the shadow root. accept what's currently there, everything is global. don't accept what is currently implemented that shadow dom can't define props. 00:08:28 q? 00:08:39 westbrook cross shadow boundary and change if there is something defined inside the shadow dom. 00:08:56 q+ 00:09:00 TabAtkins if inheritance carries a font face to the shadow, the font face being defined won't changge 00:09:05 janina1 has joined #css 00:09:34 if the outer face defines font face foo, and shadow defines the same. outer sets font-family: foo, it is referring to the outer one. when inherited it refers to the outer one 00:09:46 it won't use the internal one, name collsiion was accident 00:10:00 if the shadow says font-family foo, now it's the internal one 00:10:01 ack emilio 00:10:12 emilio what is the implemention for font-face. gecko ignores them 00:10:21 strong +1 to Tab's point about binding font-family to @font-face before inheritance 00:10:24 TabAtkins it's consisntent. some ignore them internally, some make it global 00:10:38 s/consisntent/inconsistent/ 00:10:41 emilio wouldn't want to expose font faces to document.fonts. haven't discussed this 00:10:58 TabAtkins that is undefined. happy to do reasonable stuff there 00:11:14 TabAtkins we don't have a version of .fonts for shadow trees 00:11:16 q+ 00:11:39 emilio all shadow roots have their fonts in document.fonts is not good behaviour 00:11:47 ack noamr 00:11:50 TabAtkins figuring out reasonable behaviour there is more complicated 00:11:52 q+ 00:12:22 noamr prop is an API surface between shadow roots by definition. and the desc defines an interface point, fonts don't have any of this. they define something else. so the parallel is not right 00:12:34 ack chrishtr 00:12:36 there's reason default scopung is not for prop 00:12:43 chrishtr let's take it back to the issue 00:12:54 astearns take it back to the issue. see if we can scope the prop definition. 00:13:19 github-bot, take up https://github.com/w3c/csswg-drafts/issues/5092 00:13:19 Topic: [css-values] Security concerns regarding attr() 00:13:19 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5092. 00:13:20 on that note, I think the right behavior for scoped @property is that *the host element* will refuse to inherit from its parent, if its shadow registers a custom property. 00:14:18 leaverou2 has joined #css 00:14:26 moonira 2 open questions left for attr security. invalidation time and second is painting custom props 00:14:52 leaverou2 has left #css 00:15:18 q+ 00:15:22 for the first we propose making security violation. if we have a grammar that allows doing type, that doesn't cause security issues we can't say for sure 00:15:37 until after the substitution 00:16:53 in the current spec, attr is already a computed value time. there's no substition value 00:17:13 we just be consistent with security violation at computed value time 00:17:38 if attr is subsitutued into custom prop value. affected part of custom prop become tainted, not the whole custom prop value 00:17:54 moonira that's the proposal 00:17:57 ack TabAtkins 00:18:25 TabAtkins i agree with both of these. url taining only causes invalid at computed value time, not parse time. makes it more diff to do that 00:19:18 indivisual tainiting is amazing! at the moment, spec says entire value is tainted if any part has attr. i assumed it's easier. if doing it for individual tokens is possible, which means we can combine sec and not security sensitive tokens in the same prop. that's great! 00:19:29 astearns 2 separate resolutions? 00:19:35 q+ 00:19:41 ack emilio 00:19:57 emilio curious about how you do partial tainting? 00:20:04 q+ 00:20:24 if that token gets used for a security sensitive spot then it's invalid, color is fine 00:20:25 q- 00:20:31 emilio feels sketchy 00:20:51 astearns we could resolve on what is proposed. and make it more strict? 00:21:25 TabAtkins presence of attr taints the entire custom prop which keeps chaining 00:21:41 emilio what is the computed value? does that contain attribute value? 00:21:52 TabAtkins computed value is post substitution 00:22:15 emilio i like the current spec more. i can see why it's more useful. 00:22:35 emilio feels unfortunate to track token tainiting lacking clear use-cases 00:22:51 TabAtkins both need to taint token, you need to tell that URL came from a tainted variable 00:23:14 emilio if i were to implement this, you would mark img as tainted. 00:23:34 the whole custom prop --img is tainted. rather than partial tainting 00:23:39 feels simpler to spec, reason about 00:23:54 TabAtkins on the spec side its only slightly simpler 00:24:07 implementation wise also feels same, you have to care about token ranges 00:24:15 one is example using bar and the other one is a URL 00:24:41 q+ 00:24:45 emilio very curious about use-case, feels more complex than current spec and unwarranted 00:25:04 iank_ i'll show you the chrome implementation 00:25:28 https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/css_attr_value_tainting.h (i think) 00:25:41 ack chrishtr 00:25:56 moonira is that correct? 00:26:11 chrishtr the second part of the proposal, is the reason you suggested it is because it's more natural to implement 00:26:19 moonira yes, it's easier to implement that way 00:26:43 moonira it makes sense. the example in the issue, there it makes sense 00:27:01 moonira not sure 00:27:28 astearns what if we resolve on first part. and left the second part open so we could decide whether there is enough author justification 00:27:28 https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/css_attr_value_tainting.cc;l=20;drc=f522344e45882da4c7f7cb1b3a0a7bd747d654bb seems pretty hacky to me fwiw, I'd rather keep a tainted bit on the value you substitute around, but I haven't thought it through 00:27:30 emilio +1 00:28:00 astearns PROPOSED RESOLUTION: change the spec such that violating attr security restriction will make it invalid at computed value time 00:28:15 astearns for now the tainting whole custom prop stays as is 00:28:21 can decide whether to make it partial later 00:28:32 RESOLVED change the spec such that violating attr security restriction will make it invalid at computed value time 00:28:40 castastrophe has joined #css 00:28:41 RESOLVED: change the spec such that violating attr security restriction will make it invalid at computed value time 00:30:28 github-bot, take up https://github.com/w3c/csswg-drafts/issues/9041 00:30:29 Topic: Alternative masonry path forward 00:30:29 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9041. 00:31:22 sgill has joined #css 00:31:23 fserb has joined #css 00:31:34 rachelandrew summarize the feedback. we've got 2 versions in terms of feature parity they are the same 00:31:42 the syntax is different 00:31:46 taken it to 2 devs 00:31:57 after the initial post from webkit, we got feedback 00:32:14 there's no way that devs will get all features showed in the post if we go with separate syntax 00:32:34 went through all the comments and looked at how many of them said display:grid because that's the only way to get features 00:32:36 I think that's not quite correct, just that the state of the opposite proposal was to intentionally exclude some of the grid-integrated features. 00:32:41 at the time of that post 00:32:51 other feeedback is, is masonry grid or not. 00:32:59 as a teacher of CSS it matters how people think 00:33:03 there is noo consensus there 00:33:21 the other response, which approach is easier to teach and understand 00:33:32 Adam_Page has joined #css 00:33:32 that's the core issue, what is easier for devs to understand 00:33:51 that post is really hard to write 00:34:13 because it's complicated. display masonry has much simpler syntax. display grid requires changing other values 00:34:32 it's just hard. i'll have a hard time explaining it to people 00:34:47 the response to the second post has supported masonry 00:34:57 me and chrome team prefer display: masonry for ergonomics 00:35:07 the other point is future proofing 00:35:17 there are enough things in display grid which are weird 00:35:31 we will have to work around by saying they only work in masonry 00:35:33 +1 to display:masonry 00:35:40 ack fantasai 00:35:48 bts has joined #css 00:35:51 fantasai: i intentionally did not add it to the agenda. too early for this debate 00:35:57 underlying layout model is the same 00:35:58 q+ 00:36:01 only syntax is up for debate 00:36:11 we only published it end of last week 00:36:13 (it's not just a syntax issue, there is still some behavior differences) 00:36:17 chrome madde the blog post last thursday 00:36:22 (and they're unresolvable imo) 00:36:24 we should continue to work on issues 00:36:29 impl is not blocked 00:36:42 i want to collect author feedback and think through the syntax 00:36:48 get input from TAG 00:36:54 too soon to start debating syntax 00:37:05 Won't go into my opinion on the syntax 00:37:19 the state of the draft which outlines the 2 syntax and have same functionality 00:37:31 there's pros/cons to each syntax. one is definitely not better 00:37:42 has to come from the context where the syntax is being used and rest of CSS 00:37:54 let's not argue it here right now 00:37:55 ack TabAtkins 00:38:14 TabAtkins: the difference between integration into grid vs masonry is not just syntax. 00:38:22 diff initial values for properties 00:38:32 display: masonry gets you better values right away 00:38:43 masonry can do auto repeat of instrinsic size tracks 00:38:50 that is not even possible with grid 00:38:58 fantasai: those are separate issues 00:39:13 TabAtkins : it's incorrect to say it's only syntax. behaviour is different 00:39:17 i'm fine with deferring 00:39:42 TabAtkins: it's pretty clear that a bunch of common cases are indeed simpler with the display: masonry syntax. 00:39:48 want to see similar examples with grid. 00:39:49 fserb has joined #css 00:39:53 Chrome post https://developer.chrome.com/blog/masonry-syntax 00:40:03 let's have those examples when this discussion happens 00:40:08 q+ 00:40:32 keithamus: display: masonry is a inside display: grid 00:40:40 i can't see any examples for inline masonry 00:40:48 TabAtkins assume inline-masonry exists. 00:41:10 astearns please file an issue for this 00:41:51 fantasai: one argument for grid syntax is we don't have props which only apply to specific context 00:42:06 it's better to go with more examples/input before debating 00:42:11 I think we actually don't have *any* such properties here. Every property is *at least slightly* different in its syntax. 00:42:22 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10882 00:42:22 Topic: [css-grid-3] The initial value of `masonry-slack` should be 0 00:42:22 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10882. 00:42:44 oriol: it would be better to summarize the prop. another issue for naming it 00:43:06 with masonry we place the item into a track that is less filled. 00:43:23 with this prop you can provide a threshold so instead of doing it strictly order is preserved 00:43:30 current spec tentative initial value is 1m 00:43:38 i think it should be set to 0 00:44:09 s/1m/1em/ 00:44:09 was investigating js frameworks which provide this 00:44:09 all of them have the strict value 00:44:23 they offer 2 possibilties: masonry-slack: 0 or infinite 00:44:34 ack keithamus 00:44:35 when you set it to a positive value, no framework supports it 00:44:40 authors don't expect or ask for it 00:44:58 maybe it can be beneficial. exact value which will work well is highly dependent on the use-case 00:45:05 so just supporting 1em is confusing 00:45:14 ack fantasai 00:45:14 fantasai, you wanted to point out they don't have a concept of masonry-slack 00:45:15 align with frameworks and set initial value to 0 00:45:32 +1 to fantasai's point 00:45:33 fantasai: the reason why frameworks don't have non-0 initial value since there is nothing other than infinity 00:45:41 this is a concept frameworks don't have 00:45:51 allows placements to occur in a more natural way for the user 00:46:16 slight diff of a few pixels jumping to a diff track breaks accessibility and sequencing order also 00:46:24 it would be better to have a non 0 initial value 00:46:30 1em is used for gap 00:46:40 significantly more than 1px but less enoug 00:46:50 almost no use-case for anything less than this 00:47:08 q+ 00:47:17 oriol: i don't get the accessibility problem. reorder happens anyway in other cases 00:47:42 fantasai: when you start mixing span values, you have this problem. span: 1 doesn't cause jumping backwards. 00:47:52 the most common case won't have this jumping around 00:48:05 as long as your slack is big enough yoy're always moving fwd 00:48:21 masonry-slack being too small makes it not obvious why the movement happened 00:48:42 noticeable difference between 2 columns for you to go higher. user won't understand why we moved unless the slack is high 00:49:07 astearns: i don't understand the argument that an em's worth of slack is more natural when none of the current libs give you that facility 00:49:15 fantasai: they just didn't think of it 00:49:26 astearns: it's been long enough. why no feature request? 00:49:39 fantasai: we might be able to do better than the js framework though 00:49:50 astearns: 1em is currently spec'd? 00:49:52 fantasai: yea 00:49:58 TabAtkins: +1 to fantasai 00:50:32 oriol: this would align with col-gap. it's initial value is normal. 00:50:36 fserb has joined #css 00:50:39 should we do something more along the lines? 00:50:46 not 0 but normal keyword 00:51:07 oriol: there may be different cases where the value changes due to other things and changing the initial value would be harder 00:51:11 so yes 00:51:16 fantasai: sounds good to me 00:51:33 oriol: i still believe defaulting to a positive value will trigger confusion 00:51:39 fantasai: happily surprised? 00:51:45 astearns: any implementations? 00:51:49 fantasai: not yet 00:51:59 s/happily surprised/surprised and delighted/ 00:52:07 janina1 has joined #css 00:53:14 I have a concern that 1em as a magic value might produce unexpected layouts, if a user has a different font-size in their UA stylesheet etc 00:53:35 1em as a threshold of "a distance that a user may notice" is a bit fiddly 00:53:57 which means I think I agree with a "normal" value, but I'm not sure how it should be defined. :) 00:54:03 dholbert, it's not 1rem, it's 1em :) 00:54:05 astearns: we don't have a basis to decide this issue. let's implement and get feedback from authors. revisit once we have that data 00:54:10 so it will always scale with the font the author chose 00:54:13 +1 astearns 00:54:19 I would consider 1lh… 00:54:30 fantasai: let's resolve on what we have 00:54:44 fantasai: if a user sets a minimum font-size in their browser, I thought that still impacts 1em sizing? need to confirm 00:55:27 Topic: [selectors] Pseudo-class to indicate when a slot has content 00:55:48 q+ 00:55:51 keithamus: has slotted is a pseudo class. it is the opposite of definition of default slotted 00:55:58 has slotted means that it has been slotted 00:56:06 ack astearns 00:56:08 we resolved on the issue to just have the ... pseudo-class 00:56:23 s/... pseudo-/:has-slotted pseudo-/ 00:56:39 a bare pseudo class. not functional one 00:56:48 i want a functional one which takes a compound selector 00:56:57 lea has raised a PR of non-functional pseudo-class 00:57:01 could we resolve on both 00:57:33 lea: there are distinct use-cases for both 00:57:46 the non-functional version is not an alias for :has with * 00:57:56 have chatted with implementors, bare version is easier 00:58:01 i want it to move fwd 00:58:08 there is confusion with has(slotted) 00:58:10 s/with */with *, because the non-functional version also matches text nodes/ 00:58:20 we don't have slotted pseudo-class, only pseudo element 00:58:41 there is potential confusion in terms of authors not understanding 00:58:46 but functionality is clear 00:58:58 i'm not sure if i would be in favour of fallback based naming 00:59:04 since we want it for other use-cases 00:59:05 q+ 00:59:07 but just mentionning 00:59:11 ack lea 00:59:20 emilio: the bare version is very straightforward 00:59:29 s/i'm not sure if/we could name it something related to fallback, but I'm not sure if/ 00:59:45 ack emilio 00:59:49 the functional version feels hard to implement. naming suggests we're looking at descendants. what's supported would be confusing 00:59:51 q+ to also mention :has-slotted variant that excludes whitespace-only slotted nodes 00:59:54 I don't think it would be that confusing. It would be interpreted basically identically to ::slotted() 00:59:59 keithamus: there is confusion around what combinators would do 00:59:59 s/for other use-cases/even if there's no fallback content/ 01:00:07 should only match the slotted element 01:00:07 If ::slotted(.foo) would match an element, :has-slotted(.foo) will match 01:00:19 q+ 01:00:19 emilio: it might be worth naming it after nth-child perhaps 01:00:25 has it been considered? 01:00:33 zakim, close queue 01:00:33 ok, astearns, the speaker queue is closed 01:00:53 the naming is off and confusing, otherwise it's fine 01:00:53 the bare version is extremely simple to implement 01:01:03 emilio: you mentioned you wanted it to also match fallback content. 01:01:17 lea: if we wanna change the naming to not confuse with has, it could be fallback-show 01:01:23 the matching would be the same logic 01:01:29 q? 01:01:43 ack lea 01:01:43 lea, you wanted to also mention :has-slotted variant that excludes whitespace-only slotted nodes 01:01:46 lea: since this has to reflect the behaviour of existing js api 01:01:57 even if only slotted is blank white space node it still has to match 01:02:09 we want a bare slotted version which includes just whitespace 01:02:13 is that easy to implement> 01:02:14 ? 01:02:23 ack fserb 01:02:27 fserb: maybe the name would be better as revered 01:02:36 has-fallback-content for example 01:02:47 :fallback-shown is also nicely analogous to :placeholder-shown. What happens with that pseudo-class if there is no placeholder on the input? 01:02:57 keithamus: i like the symmetry between the 2. renaming would make them asymetrical and cause confusion 01:03:47 fserb has joined #css 01:04:52 zakim, end meeting 01:04:52 As of this point the attendees have been emeyer, moonira, dbaron, kizu, kbabbitt, bts, romain, Penny, flackr, ydaniv, rachelandrew, matthieud, oriol, dholbert, futhark, miriam, 01:04:54 ... sgill, chrishtr, alisonmaher, masonf, castastrophe, bkardell_, lea, tantek, !, kzms, bramus, khush, vmpstr, noamr, mustaq, fserb, ntim, ethanjv, emilio 01:04:54 RRSAgent, please draft minutes v2 01:04:55 I have made the request to generate https://www.w3.org/2024/09/27-css-minutes.html Zakim 01:05:02 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 01:05:02 Zakim has left #css 01:07:16 gsnedders has joined #css 01:08:54 florian_irc has joined #css 01:11:44 florian_irc has joined #css 01:13:35 florian_irc has joined #css 01:13:38 nigel has joined #css 01:32:14 Francis_Storr has joined #css 01:32:18 janina1 has joined #css 01:38:52 gsnedders has joined #css 02:00:19 janina1 has joined #css 02:03:43 nigel has joined #css 02:12:32 janina1 has joined #css 02:16:55 nigel has joined #css 02:17:18 nigel has joined #css 02:28:22 Francis_Storr has joined #css 02:35:14 emeyer has joined #css 02:43:46 nigel has joined #css 03:55:19 karlcow has joined #css 03:56:28 Francis_Storr has joined #css 04:01:20 karlcow_ has joined #css 04:01:24 karlcow__ has joined #css 04:13:05 emeyer has joined #css 04:28:17 Francis_Storr has joined #css 05:21:53 Linux_Kerio has joined #css 05:29:14 nigel has joined #css 06:11:46 jfkthame__ has joined #css 06:23:33 florian_irc has joined #css 06:58:04 florian_irc has joined #css 07:02:53 gsnedders has joined #css 07:05:57 jfkthame__ has joined #css 07:08:44 projecto- has joined #css 07:09:15 leaverou_ has joined #css 07:09:45 Rossen- has joined #css 07:10:16 shans_ has joined #css 07:10:46 sylvaing_ has joined #css 07:29:31 projecto- has joined #css 07:30:01 leaverou_ has joined #css 07:31:02 Rossen- has joined #css 07:31:32 shans_ has joined #css 07:32:02 sylvaing_ has joined #css 07:54:49 gsnedders has joined #css 08:02:34 gsnedders has joined #css 08:21:04 gsnedders has joined #css 08:39:56 gsnedders has joined #css 08:53:45 florian_irc has joined #css 08:59:29 gsnedders has joined #css 09:39:49 florian_irc has joined #css 09:45:59 gsnedders has joined #css 10:06:56 gsnedders has joined #css 10:29:13 Linux_Kerio has joined #css 10:30:38 gsnedders has joined #css 11:03:55 gsnedders has joined #css 11:15:15 florian_irc has joined #css 11:41:30 hypebeatsmagazine has joined #css 12:14:09 gsnedders has joined #css 12:47:34 gsnedders has joined #css 12:51:04 florian_irc has joined #css 13:01:22 Francis_Storr has joined #css 13:22:34 gsnedders has joined #css 13:41:11 gsnedders has joined #css 13:52:00 florian_irc has joined #css 14:20:32 florian_irc has joined #css 14:21:39 nigel has joined #css 14:21:57 mustaq has left #css 14:44:40 gsnedders has joined #css 14:45:21 florian_irc has joined #css 14:52:30 Francis_Storr has joined #css 14:53:39 florian_irc has joined #css 14:53:56 florian_irc has joined #css 15:11:33 Francis_Storr has joined #css 15:12:58 Zakim has joined #css 15:23:47 karlcow has joined #css 15:24:20 Penny has joined #css 15:27:13 hypebea88 has joined #css 15:40:27 janina1 has joined #css 15:41:29 dholbert_ has joined #css 15:45:24 nigel has joined #css 15:47:41 nigel has joined #css 15:50:25 Penny has joined #css 15:55:22 zakim, start meeting 15:55:22 RRSAgent, make logs Public 15:55:23 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:55:24 zakim, this meeting spans midnight 15:55:24 I don't understand 'this meeting spans midnight', astearns 15:55:39 RRSAgent, this meeting spans midnight 15:56:01 zakim, remind us in 9 hours to go home 15:56:01 ok, astearns 15:56:21 gsnedders has joined #css 15:58:56 Rossen9 has joined #css 15:59:22 kbabbitt has joined #css 15:59:49 alisonmaher has joined #css 15:59:53 present+ 16:00:27 present+ 16:00:39 kschmi has joined #css 16:01:05 present+ 16:05:14 futhark has joined #css 16:05:26 oriol has joined #css 16:05:26 present+ 16:05:33 present+ 16:05:34 ethanjv7 has joined #css 16:05:47 ethanjv7 has left #css 16:06:14 ethanjv has joined #css 16:06:25 Patrick_H_Lauke has joined #css 16:06:32 present+ 16:07:14 siye has joined #css 16:07:20 Present+ 16:07:32 ydaniv has joined #css 16:07:36 kizu has joined #css 16:07:52 lea has joined #css 16:09:00 scribes list - David (shapes) Kevin (first scrolling), Tab (later scroling), 16:09:03 ScribeNick: dbaron 16:09:09 Topic: [css-shapes-2] Add a way to change an element's shape 16:09:23 present+ 16:09:36 noamr has joined #css 16:09:46 present+ 16:10:56 present+ 16:11:17 present+ 16:11:39 present+ 16:11:43 https://github.com/w3c/csswg-drafts/issues/6997#issuecomment-2311513957 16:12:47 masonf has joined #css 16:12:49 sgill has joined #css 16:12:53 present+ 16:12:54 noamr: I posted the comment from smfr with a proposal 16:13:08 fantasai: The proposal is to add a new border shape property 16:13:11 present+ 16:13:17 fantasai: We can probably split discussion into concept vs. specific syntax. 16:13:19 q? 16:13:31 fantasai: The idea of a border-shape property is that it defines shape of border edge of box. 16:13:40 fantasai: It can both cut in to border edge and go out. It just gives a new path. 16:13:46 fantasai: We use that for painting purposes only. 16:13:54 fantasai: So backgrounds, border. Doesn't affect layout. 16:14:06 fantasai: The syntax here subsumes the corner-radius step. We can talk about that... 16:14:14 present+ 16:14:17 fantasai: We could make it a shorthand for corner-shape and border-radius and another thing that has a path. 16:14:28 fantasai: The proposed syntax has several variations. 16:14:33 q+ 16:14:40 fantasai: One is to provide border radius and corner shape values and derive shape from that. 16:14:49 fantasai: Another is a basic-shape that gets stroked. 16:14:52 castastrophe has joined #css 16:14:57 fantasai: With shape function you can provide shapes relative to the box. 16:15:09 fantasai: Third option gives 2 paths, one for the outer border edge and the other for the inner border edge. 16:15:12 fantasai: you fill in between them. 16:15:24 fantasai: There's an example in the issue showing how that would work. 16:15:30 fantasai: With the shape function you can have fully responsive shapes. 16:15:35 q? 16:15:38 fantasai: That's the basic proposal, we can go into details from there. 16:16:08 q+ 16:16:09 q+ 16:16:16 lea: First, +1 to pursuing this. This needs solving, outstanding for some time. This avoids complexity about how borders adapt to regular shapes. 16:16:23 ack lea 16:16:32 lea: I think we should avoid basing things on corner-shape or using it as precedent. I think at this point it was a bad design that we need to rethink. 16:16:39 lea: It introduces a lot of complexity for things that aren't needed. 16:16:47 lea: I'd design this ignoring corner-shape. 16:16:56 lea: Naming border-radius around borders is a recognized mistake in CSS. 16:17:06 lea: I worry about calling this border-shape. Element might have no borders. 16:17:21 lea: I think it makes more sense than border-radius here because it's defining the shape of the border. 16:17:32 lea: Though there's complexity about what if these paths intersect. 16:17:33 SebastianZ's refinement of the proposal -> https://github.com/w3c/csswg-drafts/issues/6997#issuecomment-2342081298 16:17:40 lea: Also, does border line style need to be a part of this? 16:17:48 lea: Would be nice to see examples with real world use cases and the syntax. 16:18:10 fantasai: I've gone back and forth on the border-radius question for that reason. 16:18:18 fantasai: It does give border edge rather than padding edge or content edge. 16:18:28 fantasai: We could call it box-shape if we wanted something different, but might be useful to be consistent. 16:18:41 fantasai: I think I disagree on corner-shape, it's a good way to do common cases like beveling. 16:18:54 ack TabAtkins 16:19:04 TabAtkins: This proposal looks good to me. I think all 3 variants are useful. 16:19:13 TabAtkins: Simple one, single path, or two paths. 16:20:11 TabAtkins: A little weird: the way to specify fill on 2 stroke path is weird. The fill is specified using a border-area background-clip value. 16:20:13 TabAtkins: background-clip: border-area; was something we resolved on months ago 16:20:19 it's not part of this proposal 16:20:35 s/TabAtkins:/TabAtkins,/ 16:20:46 gsnedders has joined #css 16:20:56 lea: background-clip border-area was something we resolved in February 16:21:10 lea: It's something we've already specified, not being proposed here. 16:21:17 TabAtkins: I'll leave it alone though I think we're overloading background. 16:21:24 ack noamr 16:21:40 noamr: Wanted this in my web developer days. Popup baloon on wikipedia. 16:21:45 noamr: I wonder if this is 3 proposals. 16:22:03 noamr: I think the third one with the 2 paths is complex and has many questions. Could we start with other 2 and then add the third? 16:22:12 noamr: Or do we need to specify all at the same time? 16:22:19 noamr: Most use cases seem handled by second type. 16:22:38 kschmi has joined #css 16:22:42 noamr: Also needs clarification, important for this proposal: it's not just about painting, but also clips descendants like border-radius. 16:22:46 fantasai: only if you specify overflow 16:22:54 noamr: yes, same clipping semantics as border-radius 16:23:05 q+ 16:23:08 I'm not sure what looks particularly complex about the two-path version. Fill one shape, cut out the second shape, that's well-defined to do with a single path using reverse winding on the "inner". 16:23:11 noamr: Reason why ??? are specific and not using the existing ones is that some of the values don't work with arbitrary paths. 16:23:29 fantasai: This is the rendering simon gave me about how border colors should work. 16:23:47 fantasai: Now when you specify border colors there's a diagonal cut where the color changes. That's calculated from the inner and outer border stuff. 16:24:09 s/???/border-line-style options/ 16:24:13 fantasai: From this picture I think he's proposing we use that same calculation. This isn't especially useful. But it's a clear path from the existing behavior to what we'd do as the border path. 16:24:18 fantasai: and generally you only use one color. 16:24:27 fantasai: gives a defined rendering for the other cases. 16:24:37 fantasai: We could consider other options but this seems like the best idea so far. 16:25:23 fantasai: Regarding inner/outer paths, Simon's rendering is weird. But use case: consider a speech bubble. You don't typcially want a single thickness stroke around the entire speech bubble. The corners are narrow, middle of curve is thicker, etc. Or some other pen/brush-like effect. 16:25:25 castastrophe has joined #css 16:25:27 fantasai: So variation in thickness of stroke of border is a common scenario. 16:25:32 fantasai: That's the use case for having two. 16:25:52 astearns: To noamr's point, those could be separated and we could get to them later. The first 2 bits don't depend on it. 16:25:59 fantasai: but we have a proposal that also addresses those. 16:26:03 ack lea 16:26:20 lea: Re fantasai, I agree the diagonal could be any angle, just needs ot be well defined. 16:26:41 lea: grammar is hard to parse here. What happens if you specify only one shape, or do you always need an inner and outer. 16:26:41 TabAtkins: Can specify one shape and you stroke that shape. 16:26:53 lea: Discussions in June about difficulty of offseting a path to make it smller or bigger. 16:26:57 q+ 16:27:15 TabAtkins: IT strokes the center of the path; if you want inside/outside you need to specify two. 16:27:27 lea: You could have it represent the outer edge, stroke it, and clip it, but that's... 16:27:36 s/lea/fantasai/ 16:27:43 fantasai: The stroking in the middle is one thing I don't like about this. 16:27:55 lea: That would force authors to use 2 shapes in many cases when they could use one. 16:28:05 s/lea: You could/fantasai: You could/ 16:28:06 lea: forces authors to specify a path that's not visible at all in their layout 16:28:22 lea: I noticed in the rendering that some text is clipped, how does that work? 16:28:32 fantasai: With border-radius it's clipped if you specify overflow. 16:28:39 lea: Would be nice to see what happens if you don't 16:28:46 fantasai: Just draws on top like any other box. 16:28:58 fantasai: we're not chagning the layout, just the border and background painting 16:30:08 kizu: This issue with overflow -- we might want how to make it accsesible in most cases. ??? ??? How we can make a big border-radius. For example, making big area by default -- by default the content if hidden or auto will not ??? and will exapnd further 16:30:19 kizu: It would be nice by default to not put content under something that's hidden. 16:30:26 kizu: Would be nice to find a safe solution for this. 16:30:28 karlcow has joined #css 16:30:45 ack kizu 16:30:47 kizu: This is a proposel that I'd want to see. ??? define shape in a way that borders still work. 16:31:08 kizu: I will check... It will depend on ths proposal to make compat shapes as boxes. 16:32:01 fantasai: With an arbitrary shape there's no real way to make extra padding magically. The intrusions might not be at the bottom. If it's hourglass shape, what does that do? 16:32:06 there is shape-inside… 16:32:17 fantasai: This has to be something that ... shape of the box. Up to author to adjust the padding. 16:32:41 fantasai: For authors adjusting shape... we still don't have a way to make shape-inside to something s in a responsive + performant way. 16:32:57 fantasai: border-image doesn't avoid the content. If you make the border thick it does. But if you use insetting ability then you don't have that. 16:33:02 fantasai: It will paint under the content. 16:33:06 q? 16:33:18 fantasai: I have some questions. 16:33:28 +1 16:33:28 fantasai: First, do we want to adopt a border-shape property such as this one, in princple? 16:33:33 (questions to the group) 16:33:33 and as a hack, you could use shape-outside to mimic the inside edge of the fancy border 16:33:34 +1 16:33:35 +1 16:33:39 +1 16:33:43 +1 16:33:44 fantasai: with details ot be worked out later 16:33:44 +1 16:33:48 +1 16:33:54 +1 but very concerned about the single shape syntax 16:34:13 astearns: back to noam's point of separability, we can draft this, and if we find the 2 shape thing is more complicated we can mark it at risk or move to another level 16:34:16 noamr: or give it TODOs 16:34:19 q+ 16:34:23 fantasai: but this is the beginning, so draft what we can 16:34:26 q+ 16:34:36 ack fantasai 16:34:38 chrishtr: what about animations? 16:34:44 fantasai: yes, you can animate it 16:34:53 fantasai: given with shape syntax, animates same way as shapes 16:34:59 chrishtr: can it be HW accelerated? 16:35:02 q+ 16:35:04 fantasai: as much as anything else? 16:35:09 ack chrishtr 16:35:15 chrishtr: has the team tried? Expressed in shader, put on compositor thread? 16:35:19 fantasai: I don't know implementation details. 16:35:25 q+ 16:35:25 chrishtr: would be good to follow up on that question 16:35:30 fantasai: does that block anything? 16:35:38 TabAtkins: Given that we can hw accelerate clip-path, seems similar. 16:35:40 s/does/sure, but does/ 16:36:20 noamr: we don't hw accelerate border (?), we don't hw accelerate clip-path yet. We don't accerelate border-raidus if it's complex. 16:36:46 chrishtr: We draw it with a shader when possible. But we don't accelerate animations of it. 16:36:47 chrishtr: I want to make sure the syntax gives us a path to doing that. 16:36:58 noamr: I think the challenge is the complextiy of drawing borders, not the shapes. 16:36:59 florian_irc has joined #css 16:37:11 chrishtr, noamr: color, image, storke, shadow 16:37:19 ack lea 16:37:32 lea: Were lots of +1 about working on this. I wanted to get clarity on what's a detail? 16:37:54 lea: Would people be open to improving single shape syntax so it doesn't define something that's not visible anywhere. 16:38:02 fantasai: Just question of whether we want to solve the problem. 16:38:05 q- 16:38:15 fantasai: I don't want to dive into all the details without agreeing that we want to pursue the general idea. 16:38:16 florian_irc has joined #css 16:38:22 florian_irc has joined #css 16:38:26 q+ 16:38:34 gsnedders has joined #css 16:38:37 dholbert has joined #css 16:38:44 ack ydaniv 16:38:53 ydaniv: Why you can do something like shape-outside to offset text? 16:38:56 fantasai: you can, yes 16:39:00 present+ 16:39:10 ydaniv: so if you want text overflowing, and also ?? on top of it, you can use shape-outside 16:39:24 shape-outside uses floats. this would not 16:39:32 fantasai: You can use shape-outside on a shape element to flow text around it. But there are interesting problems with shape-inside. 16:39:56 fantasai: This proposal doesn't change layout. You could use the same path in shape-outside (which we have) and shape-inside (which we don't). 16:40:08 Rossen9: do we want to resolve on all 3 or one at a time? 16:40:17 fantasai: Let's go one at a time, I have more questions on specifics. 16:40:31 Proposed resolution: adopt border-shape in principle and continue to discuss specifics 16:40:46 RESOLVED: adopt border-shape in principle and continue to discuss specifics 16:40:50 q+ 16:40:51 fantasai: Next question: what should we call it? 16:40:57 q- 16:40:57 fantasai: Current proposal is border-shape. 16:41:03 fantasai: Do people want to suggest other names? 16:41:06 I like `box-shape` 16:41:16 fantasai: Quickly, could bikeshed more later. 16:41:26 s/ydaniv: Why you can/ydaniv: Why you can't/ 16:41:27 ack noamr 16:41:41 noamr: Argument for border-shape -- it's in the family of existing things. We already have border-radius even if we don't like it. 16:41:47 noamr: this makes it discoverable 16:41:59 fantasai: We have border-shape and box-shape. Should we straw poll? 16:42:09 1. border-shape 16:42:11 2. box-shape 16:42:34 sgill has joined #css 16:42:36 1 16:42:36 1 16:42:36 2 16:42:37 1 16:42:37 0 16:42:37 abstain 16:42:38 1 16:42:38 1 16:42:39 Penny has joined #css 16:42:40 1 16:42:44 1 (for now, ok to bikeshed later) 16:42:44 1 16:42:48 1 16:42:53 abstain 16:42:55 abstain 16:42:59 abstain 16:43:05 (box-shape feels like a layout thing) 16:43:14 RESOLVED: Call it border-shape for now 16:43:48 fantasai: next question: should this be a shorthand that sets corner-shape and border-radius properties, or should it be a separate property than when sets, overrides everything else regardless of cascade 16:44:05 q+ 16:44:06 q? 16:44:06 fantasai: I feel like shorthanding makes sense, but question about what happens if you set both. 16:44:10 q+ 16:44:23 fantasai: If we make it a shorthand then if you specify either a shape or corner then that's what you get for sure. 16:44:30 q+ 16:44:36 fantasai: If it's a separate longhand, then the border-shape always wins. 16:44:52 fantasai: We could go either way... could also open separate issue. 16:45:15 astearns: I would like to take this to an issue. I'm happy to have something in the draft with issue in it. But I don't think we can design this in committe right now. 16:45:17 ack astearns 16:45:29 ack lea 16:46:13 lea: I agree that this needs more design work. I also don't think we should design around corner-shape, in spec for >10 years and not implemented. If we're adding a new thing, do we *also* need corner shape? We already have border-radius for common cases. We don't need another new way to set element shape. 16:46:26 lea: For something it might be easier, let's define a shape funciton and continue to use element shape for them. 16:46:44 qq+ 16:47:00 fantasai: Counter to that is that there are common use cases. When you're using a path you have to give a path for the whole shape. Corner shape lets you set corners independently, can do writing-mode-relative easily. 16:47:12 fantasai: When you're doing something compcilated you need to specify the whole path. 16:47:14 ack lea 16:47:14 lea, you wanted to react to lea 16:47:19 ack fantasai 16:47:19 fantasai, you wanted to respond to that 16:47:30 lea: That would apply if all we could do is specify path. But there's a lot to shapes: inset, etc. 16:47:48 fantasai: But you have to set them all. But if you want a slash shape, you have to define the path of the whole box rather than just the corner. 16:47:59 q+ 16:47:59 fantasai: I think that's a much easier thing when that's what they want,which is common. 16:48:07 fantasai: So I think the border-shape properties make sense. 16:48:19 fantasai: But that doesn't really affect this question because we still have the border-radius properties. 16:48:30 fantasai: corner-shape is only a minor additional complexty 16:48:48 lea: That's a ???. corner-shape does make some cases simpler. But it has cruft for things that aren't really needed. 16:49:07 lea: For things like bevel, helps with some polygons, but most polygons in the wild have rounding which it doesn't account for. 16:49:14 ack TabAtkins 16:49:53 TabAtkins: ??? concern is that I don't care about shorthand or complicated direction. If you just set border-shape it should do the right thing. It looks like in the example he didn't to do something to explicitly cause the regular border to not render. It should work better in that case. 16:50:10 TabAtkins: If you set border-shape it should affect the other border properties appropriatly without author needing to do extra work. 16:50:49 castastrophe: Question: is there a perf gain for repainting just a border corner versus a larger shape? 16:50:56 fantasai: no idea 16:51:07 fantasai: I also don't think that's a consideration; we should worry about the ergonomics. 16:51:11 q? 16:51:26 noamr: We could probably figure out from any shape, could reverse-engineer it to a corner-shape and get the same hypothetical perf benefit. 16:51:32 ack castastrophe 16:51:43 fantasai: So on this question we're opening a new issue. 16:51:59 fantasai: ANother question: do we want the 2 path syntax where you can fill between or do we think that's not worth trying? 16:52:33 q+ 16:52:37 q+ 16:52:39 fantasai: The current proposal has a stroked 1 path version and a filled 2 path version. Do we like both options or want just 1? 16:52:52 +1 to add it in for now, issues to remove or postpone as necessary 16:52:57 ack noamr 16:53:07 noamr: I tihnk we want both shapes, question of editorial understanding and iteration on spec to make it readable. 16:53:16 1-shape super restrict you to *solely* the geometry of a shape's stroke, that's quite limiting (if common) 16:53:19 ack lea 16:53:37 lea: especially if we don't figure out how to offset paths property, I think the 2-shape syntakx is essential for specifying what you want 16:53:51 lea: If you don't have a way to specify the shapes explicitly then it doesn't have the necessary level of control. 16:54:03 lea: we definitely need the 2 path syntax esp. if we don't figure out the 1 path syntax. 16:54:16 (I think lea meant offsetting for the 1 path syntax.) 16:54:37 RESOLVED: specify the 2 path syntax 16:54:55 RESOLVED: also specify the 1 path syntax 16:55:06 q+ 16:55:29 fantasai: One other question from smfr, a little orthogonal, do we need additional keywordsfor background-origin. 16:55:36 fantasai: and maybe background-clip 16:55:43 q- 16:55:48 fantasai: to change from using the layout box to using the box of the whole border shape 16:56:04 Rossen9: also sounds like a feature we can define once we get ... 16:56:07 Yeah, I think it's needed. 16:56:22 astearns: noam, would you be willing to become an editor for shapes2 for these features 16:56:26 noam: yes 16:56:37 astearns: my proposal is to add Noam as editor to shapes 2 16:56:41 fantasai: this goes in borders 4 16:56:45 astearns: ok, that spec instead! 16:57:06 s/instead!/in addition!/ 16:57:13 fantasai: I'm going to take actions to file followup issues, and I'm going to add this to the ED of borders 4. 16:58:09 Topic: [css-shapes-2] In `shape()` It should be possible to specify control points relative to their point on the curve 16:58:23 noamr: This is about the shape syntax. 16:58:39 noamr: Mostly saw ??? a bit complex to define shape syntax with bezier curves, cubic and quadratic. 16:58:53 noamr: When we define those curves we first define end points and then control points. 16:59:06 noamr: sometimes we want control points relative to start rather than to what we just defined which is the end 16:59:10 noamr: this can be boggling 16:59:21 noamr: In SVG control points go in order. They always end in the end. 16:59:27 noamr: Here we can have either order. 16:59:40 noamr: With keyword where you can specify 2 or specify ???? 16:59:56 noamr: Simon added another issue that I think we should open separately. 17:00:13 noamr: Proposal here that I raised that we can discuss is that you can add the word "from" after specify point, can say "From start" 17:00:45 kschmi has joined #css 17:00:48 noamr: It's getting less and less similar to SVG, for better or for worse. 17:00:56 q+ 17:01:03 noamr: Do we want to keep it similar-ish to SVG, with same mental model, or do we want to break free from that. 17:01:13 noamr: We were breaking away a bit, but piecemeal. 17:01:19 noamr: I think it needs a higher decision about that. 17:01:20 my vote is to break free if there is good justification 17:01:40 noamr: Specifically here because we changed the order of endpoints earlier, it makes it difficult to have points relative to start, and we need another keyword for that. 17:01:45 noamr: This becomes quite wordy. 17:02:00 noamr: I think with the property syntax, people sometimes avoid it because it adds a lot of CSS. 17:02:07 noamr: We need to be careful about not being too verbose. 17:02:15 noamr: The SVG ordering allows being a bit more terse. 17:02:41 noamr: I think switching the order and allowing using keywords is more verbose. 17:03:11 This issue seems to be related to #10647 (overloading path() for the path syntax that is closer to SVG) 17:03:27 ack TabAtkins 17:03:40 I don't have an opinion on exactly ???, but it's complicated... but for the more general case of close to SVG or break free. I don't think we should pay attention to what SVG can do right now. We should continue expanding what's useful regardless of what we can port back to SVG syntax. 17:04:09 +1 to TabAtkins 17:04:33 noamr: For now, proposed resolution would be that you can add from keywords that latches the next coordinate to the beginning of the sequence. 17:04:58 noamr: you can say from-start, latches the previous coordinate to the start of the segment 17:05:02 s/sequence/segment/ 17:05:23 Fine with this for now; I'll review more closely when I get back. 17:05:54 jamesn has joined #css 17:05:56 RESOLVED: Add a from-start keyword that goes after the value and latches the coordinate to the beginning of the segment. 17:06:22 Topic: [css-shapes-2] Order of points and control points in `shape()` 17:06:32 noamr: This is a very related issue. 17:06:34 andreubotella has joined #css 17:06:45 noamr: We resolved on allowing any order -- either control points first or end points first. 17:06:57 noamr: With verbosity it seems like it's making things unnecessarily complex 17:07:05 noamr: Maybe endpoints should always go first and control points second? 17:07:29 Rossen9: any reason we can't do it? Implementations that need to change? 17:07:33 noamr: Not shipped yet anywhere. 17:07:52 Rossen9: any objections to making the order strict with the endpoints first? 17:08:16 RESOLVED: Make the order strict: endpoints before control points. 17:08:46 chrishtr: did you resolve to use the adjustment approach in the issue or what simon said in the beginning? 17:08:57 TabAtkins: I think the opposite. 17:09:06 noamr: yeah, what Simon was suggesting that the endpoints go firs.t 17:09:21 (noam's comment has the endpoints last; we resolved (correctly) on Simon's preference for endpoints first) 17:09:46 Topic: [css-shapes-2] Interpolation between `shape()` and `path()` needs more detail 17:10:15 noamr: This is about what happens when you animate betwen a path shape (a pixel based SVg string) and a shape (going farther and farther away from SVG). 17:10:20 Adam_Page has joined #css 17:10:41 noamr: There's already some ambiguities. For example with shape you always start from where theshape starts from, whereas SVG path functions start from 0,0. 17:10:48 noamr: smfr suggested just not animating. 17:11:07 noamr: This creates a cleaner ex.pectation -- just use a tool to convert your path to a shape rather than relying on the browser to convert for you. 17:11:30 +1 to pretending that path() has a `from 0 0` argument that tinterpolates with the shape()'s `from` argument. 17:11:33 noamr: The other option is more complex, is that path with moves it will be the first one to mix them together. In SVG path you can do to and by. 17:11:38 noamr: In shape you kind of can. 17:11:47 noamr: I think it's between those 2 options. 17:12:05 noamr: I think prefer to not interpolate between path andshape, but there was pushback in the issue. 17:12:32 noamr: ??? 17:12:44 TabAtkins: This issue is about whether shape and path interpolate based on the from stuff. 17:13:16 noamr: I want to address this issue by ... this specific issue of the from is one divergence between path and shape. There might be more in the futuer. This issues makes me think they shouldn't be interpolated. 17:13:33 TabAtkins: There's a trivial transformation of the path string into the shape syntax, we should just do that. 17:13:51 TabAtkins: The path syntax will just turn into a moveto and a closepath if it was a shape. 17:14:00 noamr: So interpolate path as if it always has "From 0 0" 17:14:22 TabAtkins: my assumption this whole time is that the SVG path syntax turns into a bunch of shape commands 17:14:38 q+ 17:14:41 TabAtkins: Whavever arguments ?? takes given appropriate default value, in this case `from 0 0`, and interpolation is based onthat. 17:14:51 s/??/shape()/ 17:15:16 emilio: There will probably always be a way to turn a path into a shape. It feels a bit weird to do it automatically for interpolation. 17:15:27 q+ 17:15:31 TabAtkins: when things are easily inter-convertable, I think it's good to do so. 17:15:49 TabAtkins: for example 3 rect functions: inset(), xywh(), ... 17:15:54 q+ 17:15:55 emilio: those all compute to same function 17:16:00 ack emilio 17:16:02 emilio: this distinction is preserved at computed value time 17:16:26 emilio: given how trivial it is to turn a path into a shape, it feels like adding the special code path ???, ... it's fine 17:16:30 q+ 17:16:38 TabAtkins: I don't have a strong opinion, but doing it since we can seems right. 17:16:47 noamr: The difference here is that usually you start your path with a moveto. 17:16:48 ack noamr 17:16:52 TabAtkins: given how trivial it is to turn a path into a shape, it feels like something we should do for the author ^_^ 17:16:57 noamr: If the path doesn'tstart with 0 0. 17:17:05 noamr: so your path will turn into a shape that doesn't have a from. 17:17:10 noamr: It starts it on the wrong foot. 17:17:17 noamr: Something about thsi conversion doesn't feel right. 17:17:28 noamr: It will be not exctly as intended. 17:17:48 noamr: Telling the developer to turn it into a shape yourself and decide if it's a moveto or a from, or use several movetos in the beginning, would be cleaner. 17:18:27 kbabbitt: A couple things: I'm curious why shape starts with this from to begin with. It seems like syntactic sugar for a move but maybe I'm missing something. 17:18:47 TabAtkins: All the shape functions have an origin. That ??? the motion-path. 17:19:10 TabAtkins: A starting point for where the motion path is from rather than forcing them to start at 0,0 17:19:27 kbabbitt: I'll have to take a closer look at motion path. 17:19:42 kbabbitt: I was just looking at the grammar for motion path, it requires that the first command is a move. 17:19:52 kbabbitt: Another alternative: have ?? line up with the first move in the path. 17:20:18 s/??/from/ 17:20:20 ChrisL: That was a design decision, every path segment creates the start position for the next segment, so has to start with a move. 17:20:43 noamr: We need to explore whether this is enforced in the shape segment in CSS. If it doesn't that solves it. 17:20:44 s/grammar for motion path/grammar for SVG path/ 17:20:48 can't we just default to a move to 0,0 if no move is specified? 17:20:57 https://drafts.fxtf.org/motion-1/#offset-position-property lets you change the "starting point" of a path that doesn't manually specify its start 17:21:00 noamr: I think the resolution should be to align from with the first segment which is supposed to be a move. 17:21:10 noamr: With the constraint that we will check if this is actually enforced by browsers. 17:21:16 s/so has to/so the first has to/ 17:21:41 Proposed: Align `from` with the mandated first move. 17:21:53 RESOLVED: Align `from` with the mandated first move. 17:22:08 Di has joined #css 17:22:26 Topic: [css-shapes] Overload `path()` for CSS-y SVG path syntax instead of taking up `shape()` 17:22:48 lea: As mentioned many times, SVG paths don't have the best ergonomics. 17:22:54 lea: Have been long discussions about improving. 17:23:11 lea: And not just expose the exsiting model with CSS syntax. Though there's value in exposing existing model in CSS syntax. 17:23:19 q+ 17:23:19 lea: Seems like we're trying to do both with shape() function. 17:23:32 lea: But we already have a path() function which has a very strange syntax for CSS. 17:23:50 lea: It seems reasonable to me that we should overload that function to harmonize with rest of CSS functions 17:24:02 lea: That frees up shape() to do what we want, we don't have to be consistent with SVG. 17:24:15 lea: We don't have to be consistent with SVG at all without being bound by legacy/baggage of SVG. 17:24:36 lea: Seems like it's 2 birdds with one stone. Make path() a reasonable function and free up shape() to do something more reasonable without baggage(). 17:24:55 lea: Lea is that path() is CSS specification of SVG paths whose model stays close to SVG aths, and shape() can be whatever. 17:25:07 TabAtkins: I don't agree with this. 17:25:22 TabAtkins: I don't think we need to do more reinvention while keeping close to SVG. 17:25:30 TabAtkins: I don't think the SVG starting point is particularly holding us back. 17:25:35 TabAtkins: what SVG does is mostly fine. 17:25:40 q? 17:25:42 q+ 17:25:42 q+ 17:25:47 tantek has joined #css 17:25:49 TabAtkins: We can engineer around the awkward bits. curve sucks but we can do better curvens. 17:25:52 ack TabAtkins 17:25:57 TabAtkins: I don't think we're limited in a meaningful way. 17:26:10 TabAtkins: I don't like when functions have significantly divergent grammar paths. 17:26:23 TabAtkins: It's clearer when path() is the SVG syntax and shape() is the CSS nytax, more teachable. 17:26:29 TabAtkins: I like the current approach and think we shouldn't change. 17:26:31 ack noamr 17:26:42 noamr: I t hink most useful thing about path() is that you can paste in strings from an SVG authoring tool. 17:26:55 noamr: It's a feature that can stay the way it is 17:27:05 noamr: Let sleeping dogs lie. 17:27:17 ack lea 17:27:17 lea: I'm not proposing we drop the string argument of path(), just overload it. 17:27:41 lea: If you don't think the current shape() is a sigificant departure from SVG, then maybe we should just stick with path(). 17:27:59 lea: All the other SVG shapes have CSS functions, path() is the odd one out that only takes a string. 17:28:30 lea: We should fix path to have a better design. Then question of if we need a new function. But I think we do -- fix how we specify control points, how we ??, fix arcs. 17:28:42 lea: We've discussing many improvements, many of which we can't backport. 17:29:01 TabAtkins: 2 things to repsond to -- all other SVG shapes are just elemnts with attributes, there's no data format to port over to CSS. 17:29:12 TabAtkins: path is the execption where the data are in a string 17:29:15 lea: polygon! 17:29:26 TabAtkins: Aside from the whitespace rules it's identical to CSS grammar. 17:29:39 TabAtkins: path() has nontrivial syntax that can be dropped into other contexts. Taking that is still useful. 17:29:40 q? 17:29:42 q+ 17:29:48 TabAtkins: but also useful to take advantage of CSS and its gfull abilities. 17:30:19 TabAtkins: Second, I don't understand how points about gradually making shape better than what SVG can do suggest putting it into path(). If anyhting, I think shows separate function is better to underline that it's different. 17:30:42 ack lea 17:30:43 lea: That's not what I was suggesting. If was saying that if we're significantly different it should be a separate function, but there's still value in a CSS serialization of path. 17:30:56 lea: I think you could do a CSS-if-ication of path syntax and allow that in path(). 17:31:09 lea: Having to reach for a different function that has nothing to do with paths makes it difficult to learn. 17:31:14 Francis_Storr has joined #css 17:31:19 TabAtkins: I don't see great value to users in a direct cssification of the path syntax. 17:31:35 TabAtkins: if people are using path syntax, they want to ureuse it, just take te string and go. 17:31:47 TabAtkins: If they're rewriting then rewriting into shape syntax which gives substantially more ???. 17:32:04 lea: I don't think it should be mapped that closely, but I'd take thit af itis' the only way. 17:32:09 lea: ??? 17:32:38 lea: Taking a path from SVG and sticking it into CSS has limited utility because SVG paths are fixed sizes... current path odesn't deal with percentages, units. 17:32:44 TabAtkins: it's well defined 17:32:51 lea: It's well defined but not useful. 17:32:59 TabAtkins: are you asking to drop path() entirely? 17:33:01 lea: no 17:33:29 lea: I'm saying what either what we have now in shape() in which case it should be in the path() function, or it's far enough and we should improve the path() function and have the shape() function separately. 17:33:47 TabAtkins: I agree with second point except I don't think there's value with improving path syntax and I think we should stick with current approach. 17:34:18 Rossen9: I think we should take this back to the issue. Two contrasting opinions here. 17:34:27 I think this proposal should be a bit more specific 17:34:29 Rossen9: Sounds like we should get closer together on the issue before trying to resolve. 17:35:13 Break until 11am PDT 17:36:59 Penny has joined #css 17:37:26 jfkthame__ has joined #css 17:40:39 florian_irc has joined #css 17:41:38 florian_irc has joined #css 17:42:09 florian_irc has joined #css 17:45:47 nigel has joined #css 17:46:51 bts has joined #css 17:55:05 janina1 has joined #css 18:00:43 janina1 has joined #css 18:01:03 nigel has joined #css 18:02:39 kschmi has joined #css 18:02:45 kbabbitt has joined #css 18:03:00 Adam_Page has joined #css 18:03:13 janina1 has joined #css 18:04:16 nigel has joined #css 18:07:58 kbabbitt has joined #css 18:08:48 ydaniv has joined #css 18:09:18 Di has joined #css 18:11:08 scribenick: kbabbitt 18:12:43 Rossen0 has joined #css 18:12:50 florian_irc has joined #css 18:12:57 florian_irc has joined #css 18:13:06 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10861 18:13:06 Topic: [css-align][css-position][css-anchor-position] Introduce "document containing block" for some purposes? 18:13:06 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10861. 18:13:19 present+ 18:13:37 alisonmaher has joined #css 18:13:40 present+ 18:13:46 present+ 18:13:51 TabAtkins: Anchor positioning exposes details of the containg block a lot more than abspos did 18:14:06 ...generally this works just fine, inset-area cares about how it's positioned relative to cb 18:14:15 ...or if it's outside, it's an exceptional case and is also handled fine 18:14:28 ethanjv has joined #css 18:14:36 ...exception is when you're fixpos, because then you end up using the ICB which while is reasonably sized, is not a reasonably positioned rect 18:14:41 ...ICB just sits at the top of the document 18:14:54 scribe+ 18:15:00 kbabbitt has joined #css 18:15:15 ...and most of the document is outside of that rectangle 18:15:28 ...which means that almost all of your acnhors need the exceptional behavior of anchor outside of CB 18:15:35 ...while we have as reasonable as we can behavior, it's not ideal 18:15:42 ...all an error case and always recovering 18:15:57 ....all you really want for something like an element acnhored to something far down is to avoid flowing outside the bounds of the doc 18:16:00 ...e.g. offscreen 18:16:05 ...and that doesn't work well in the case we have here 18:16:12 ...what you want is a CB that is the size of the visible document 18:16:16 ...what that means is part of this issue 18:16:26 ...My proposal is that this sort of request is useful outside of anchor positioning 18:16:50 ...relatively common for people within a scrollable area to position in the bottom right area of ths scrollable content 18:16:57 ...can't do that today wiothout an additional wrapper 18:17:22 ...if you go to the bottom right with insets and it positions you in th ebottom right of the scroll container not the scrollable content 18:17:34 ....people work around that today by using a replos wrapper around all of their scrollable content 18:17:43 ...so their abospos can go to the bottom right of the scroll container 18:17:49 ydaniv has joined #css 18:18:00 ...making this behavior easier to opt into, and making anchor positioning generally work better when your CB is the document is worth fixing 18:18:17 ...my proposal is that we have a new concept: the document containing block 18:18:26 ...which is a rectangle size to contain all the stuff in the document 18:18:37 ...we use that by default for anchor position ing if we would use the ICB 18:19:00 ...also have some way to explicitly opt normal abspos into being able to reference this concept both for document and for any scrollable content 18:19:16 ...two big questions: first what is this rectangle, how do you define it in a way that's reasonbly chjeap 18:19:27 ...iank_ has an answer that works in Chrome and sounds approximately right 18:19:33 ...don't know how generalizable that is 18:19:35 q+ 18:19:48 iank_: when you calculate the scrollable overflow for a scroll container 18:19:54 ...you need to know where the end ? is 18:20:02 ...and that's one of the calculations that goes into the whole scrollable area 18:20:12 ...e.g. for grid this is defined as the end of the grid 18:20:26 ...this is relatively cheap, the calculation is only based on the in-flow children at that point 18:20:34 q+ 18:20:36 ...w/o transforms, usually what people wnat for this calculation 18:20:49 TabAtkins:: other questio would be how we can let normal abposes opt into it 18:21:05 ...probably a position subproperty, don't want to solve for it now, can still devault anchor positioning to right default today 18:21:18 Rossen0: I missed the reasoning about, does top line get redefined as well? 18:21:26 q+ 18:21:28 ...so that when you scroll, that positioned element also gets scrolled with it? 18:21:55 TabAtkins: No, the DCB will start still at the top left of the entire ducoument just like ICB, will just grow downward and rightward to contain entire contents of the page 18:22:13 iank_: not growing into negative space beyond the scrollable region 18:22:24 ...there are cases .eg in rtl container where right would stay 0 and flips like that 18:22:31 ack Rossen0 18:22:33 ack fantasai 18:22:36 fantasai: curious about the definition in the inline axis 18:22:50 ...this totally makes sense, we probably want a similar concept for non-document scrollers 18:22:57 ...agree with most of what you're trying to do here 18:23:41 iank_: easiest thing is unify behavior when we fixed the end point for the scrollable behavior 18:23:54 TabAtkins: I'm calling it DCB, need a better name 18:24:10 ...intend it applies equally to other scrollers, if your anchor is inside a scroller you want same behavior 18:24:18 q- (I was going to ask about applying to other scrollers) 18:24:23 q- 18:24:31 fantasai: you're suggesting for inline axis we calculate padding ??? I agree with that 18:24:36 q? 18:24:42 Rossen 18:24:47 ...have to think about exactly where else it would be used, using it for anchor positioning seems reasonable 18:24:47 ack Rossen 18:24:57 iank_: when I as doing webdev stuff, I ran into this problem constantly 18:25:03 +1 18:25:15 emilio: agree this a good thing in general 18:25:20 ...esp when you get into edge cases e.g. rtl 18:25:29 ...having something that consistentl covers scrollable areas gets tricky 18:25:36 s/we calculate padding ???/we use the point where we attach the inline padding?/ 18:25:53 ...2 questions, one: with regards to scrollable padding we add, you mean that CB would be included or excluded? 18:25:55 iank_: included 18:26:02 emilio: so it would cover everything, sounds good 18:26:13 iank_: we're not changing the fact that abspose references padding box by default 18:26:21 q+ 18:26:24 fantasai: any box that is scrollable when it gerneates a CB, genreates 2 CBs, inner and outer 18:26:37 ack emilio 18:26:38 ...I guess it generates 3, you have the content one too 18:27:14 Rossen4 has joined #css 18:27:16 emilio: if you have something that overflows that cb, you have something that scrolls down 18:27:18 q? 18:27:33 iank_: the reason the padding edge definition is useful is, you don't need to calculate the entire scrollable area 18:27:45 iank_: based on flow content this is where the padding edge is, then you run abspos layout 18:27:50 iank_: then you gather up scrollable area 18:28:05 fantasai: this comes from when we decided to add padding to scrollable ??? ... it only considers input 18:28:11 s/input/in-flow content/ 18:28:13 emilio: sounds good 18:28:15 s/???/area/ 18:28:27 iank_: that ? is also nice because it doesn't consider transforms 18:28:30 gsnedders has joined #css 18:28:41 s/?/box/ 18:28:48 emilio: wonder if there are use cases like, I want to ? the whole scrollbar 18:28:52 iank_: [missed] 18:29:17 ack fantasai 18:29:30 ack Rossen 18:29:30 fantasai: we've got each box generates 3 CBs, inflow CB which is content area, local CB which is this padding edge that takes over the area that scrolls, then outer CB which is the background attachment scroll box 18:29:40 ...we need better terms for these 18:29:52 ...in your comment you suggested position area would be one way to capture this entire area 18:29:56 ...that reads really well 18:30:01 ...issue says only when there's a valid anchor 18:30:09 ...do we make position area do it always since it doesnt rely on anchor> 18:30:16 ydaniv has joined #css 18:30:30 TabAtkins: potentially. I feel like that's a bit hacky and probably wnat CB control to be done via a more focused properly, more things in that vein you want to select between 18:30:44 ...somewhat uninclined to fix things in this hacky way but could be convinced in another issue 18:30:52 fantasai: making it contidional on the validity of anchor is a little weird 18:31:00 ...making it not that would be great, I have a few ideas 18:31:19 Rossen4: the position area bounds you define is based on the static content only but it doesn't include any abspos content? 18:31:24 TabAtkins: correct, no abspos no transforms 18:31:31 I'm thinking maybe `position-area` always applies, it's just that if you have no valid anchor then you always get the entire area 18:31:32 Rossen4: what about relative 18:31:35 18:31:45 iank_: it does not include relative 18:32:05 iank_: when it comes to adding padding to scrollable end, we have basically alignment on that 18:32:12 q? 18:32:18 Rossen4: sounds like a very useful feature 18:32:47 florian_irc has joined #css 18:33:02 TabAtkins: suggest resolution: Adopt the concept of document containing block (better name TBD) into position-4 and have anchor positioning use it by default instead of ICB 18:33:14 Rossen4: additional comments or objections? 18:33:14 +1 18:33:29 fantasai: we should proably actually publish position-4 18:33:35 RESOLVED: Adopt the concept of document containing block (better name TBD) into position-4 and have anchor positioning use it by default instead of ICB 18:34:40 [discussion about contents of position-4] 18:35:18 Rossen4: any objection on publishing FPWD of position-4? 18:35:25 RESOLVED: Publish FPWD of position-4 18:35:49 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10858 18:35:49 Topic: [css-anchor-position-1] Define scroll interaction better. 18:35:49 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10858. 18:35:57 florian_irc has joined #css 18:36:31 q+ 18:37:57 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10796 18:37:57 Topic: [css-conditional][css-anchor-position][scroll-animations] Snapshotting post-layout State 18:37:57 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10796. 18:38:21 futhark: there are multiple specs that do some sort of snapshotting of particular scroll state 18:38:27 ...some specs try to specify this timing and some have not 18:38:36 florian_irc has joined #css 18:38:37 ...for scroll driven animations there is a spec that refers to the HTML spec 18:38:51 ...that scroll position is snapshotted in the HTML ? at the begining of the animation 18:39:03 ...there's a separate snapshotting that happens after resize observers 18:39:10 ...in order to have a stable first frame and avoid flickering 18:39:18 ...then there is the anchor positioning spec that emilio pointed out 18:39:31 ...that has an issue to specify when this scroll position / adjustment snapshotting happens 18:39:47 ...now we're working on state queries and I need the exact same thing for sticky pos state queries 18:39:58 ...in this issue I propose we try to unify scroll snapshotting to a common point 18:40:06 ...instead of referring to modified HTML ? from CSS spec 18:40:20 ...the CSS specs that need to do snapshotting can say it needs to be done during these steps in CSS 18:40:30 Adam_Page has joined #css 18:40:30 ...what I propose is that we introduce a new step called run snapshot 18:40:40 "run snapshot post-layout state steps" 18:40:45 ... do this between media query and ?? 18:41:02 ...basically aligns with where scroll animations spec specifes to do it 18:41:19 ...and then update the snapshots again and if the snapshots have changed beacuse of layout change, there is a second run of style and layout 18:41:20 q+ 18:41:33 s/??/update animations/ 18:41:33 ...that is my proposal 18:41:33 ack futhark 18:41:35 ack emilio 18:41:42 emilio: first, why do we need two steps? 18:41:52 ...could we do it as part of the resize observer step 18:42:01 ...do content visibility stuff to prevent unstable frame issue 18:42:01 . 18:42:13 ...I think that would be nice because you wouldn't need resize observer updates 18:42:20 futhark: right, that is actulaly what the current chrome implementation does 18:42:36 I talked to flackr and he said dieally in terms of the specification have it after the resize steps 18:42:49 flackr: it's fairly common that devs use resize observer to change the shape of something on screen 18:43:05 ...you expect that these things that respond to scroll or anchoring or other things to be able to anchor to the content or the size based on developer ? 18:43:34 emilio: the loop is basically: update style and layout, then figure out ??, then figure out for resize observers wehtehr something's changed 18:44:08 emilio: if you ? you would potentially run multiple layout loops 18:44:22 emilio: and you could make it so that you ? resize observations probably 18:44:37 flackr: I agree and that's probably better, you could have resize observers respond to updated snapshot 18:44:46 emilio: other question is why do we need snapshot at beginning? 18:45:02 flackr: usually the scroll position doesn't change and you need to do some layout in your initial pass 18:45:21 flackr: so in the case where the thing that you're responding to hasn't changed as a result of scrolll, we onlyl have one pass through style and layout 18:45:30 flackr: whereas if you did it after you'd always have second pass 18:45:37 flackr: [missed] 18:45:54 flackr: and unless the result of running that caused scroll position to change, you have your result 18:46:17 emilio: you are doing the thing right after scroll events get sent 18:46:29 ...but you have no guarantee that you have updated layout here right? 18:46:45 ...and you would snapshot a potentially dirty tree or you would run layout there 18:47:04 https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model 18:47:21 emilio: proposal is iintroducing a step right after step 10 [in link above] 18:47:32 futhark: yes, that was our proposal, inspired by scroll animations spec 18:47:43 emilio: but you either run layout there, in which case it's not more efficient, or just snapshot ? 18:47:50 flackr: but there is a known scroll position at the least 18:48:00 ...I guess you're saying some of these things could have snapshot there 18:48:26 emilio: in order to get consistent bejavior and not depend on... you would get different behavior if a media query change had updated layout versus not which seems bad 18:48:36 ....so to get consistent behavior you need to update style and layout before doing snapshot 18:48:46 flackr: other reason to run at this time is I believe it's before rAF callbacks 18:48:54 emilio: no, it's after 18:49:00 emilio: nm, it's before 18:49:15 flackr: this also puts things in a correct animation state which is good for scroll driven animations 18:49:22 ...your animations are based on the correct input state 18:49:26 ...would be open to moving that around 18:49:36 emilio: if we put it before the update animations and send events you also need to update style & layout 18:49:48 ...that seems promising because rAF is something people use to move content around 18:49:57 ...so you want to update style & layout as late as possible 18:50:07 flackr: I think it might be okay to remove that early snapshot 18:50:25 emilio: that would be great because then snapshot the right thing, resize observer can react properluy 18:50:34 emilio: update events or animations can ? that snapshot 18:50:48 emilio: other than anchor positioning where the snapshot doesn't affect what the page can observe ... 18:51:11 flackr: I suppose if you had a rAF observer that was looking at the position of an anchor element, that observatio nwould forcea style and layout to make it correct 18:51:16 florian_irc has joined #css 18:51:20 emilio: you would use the snapshot from your last frame 18:51:26 flackr: then it would be a correct ? 18:51:30 emilio: potentially 18:51:45 futhark: [missed] 18:51:59 emilio: yes and that's unfortunate because it causes inconsistent behavior if someone has updated style & layout before 18:52:11 ...anything that changes frame that updates style & layout causes different offsets 18:52:17 futhark: we use information from last frame 18:52:24 emilio: not necessarily, you use info from last layout update 18:52:28 futhark: should be information from ? 18:52:44 emilio: would prefer to move this only to resize observer, then you get that behavioor automatically 18:52:50 ...without changing depending on whether someone has updated ? 18:53:02 ...the whole frame sees the updated offsets until the resize observer 18:53:18 flackr: right, it makes these scroll dependent queries basically equivalent to a developer observer 18:53:29 Penny has joined #css 18:53:38 emilio: if we decided that we need for some reason after the offsets from before rAF then I think we should update style & layout to be consistent 18:53:42 ...that's unfortunate 18:53:43 karlcow has joined #css 18:53:59 futhark: there are a couple of things I'd like to resolve on regardless of orderting 18:54:15 ...creating this new run steps where we collect all these kinds of snapshotting in the same space for CSS specs 18:54:24 emilio: think that's great 18:54:39 futhark: strictly this forum cannot decide the order of the HTML event loop 18:54:52 ...but creating that step is one resolution I'd lie to make 18:55:03 ...propose CSSOM-view for it 18:55:27 Rossen4: back to first resolution which is adding this step for snapshotting 18:55:36 ...is there anything else we need to discuss about it? 18:55:46 ...not sure if there was agreement 18:55:57 flackr: I think we have agreement, I think this is okay to draft 18:56:04 ...my only concern is things devs to in rAF 18:56:06 kschmi has joined #css 18:56:13 ...but that's also a problem with anything they do in resize observers 18:56:22 emilio: already the case if author has updated layout manually 18:56:36 flackr: I do think that case is less common, still common but majority of updates are scroll with no dirty layout 18:56:54 emilio: in that case we're observing a dirty tree because you haven't done layout yet 18:57:55 flackr: if the animation time is updated according to the new scroll position, then a rAF observing some style or layout property will force an update, getting the correct for now position 18:58:13 Rossen4: back to resolution, any objections? 18:58:29 “run snapshot post-layout state steps” 18:59:14 RESOLVED: run snapshot post-layout state steps 18:59:27 Rossen4: second part was figuring out where this should go 18:59:32 ...was suggested to put in cssom-view 18:59:45 futhark: that's kind of arbitrary based on where scroll steps were 18:59:50 emilio: seems fine to me 19:00:05 RESOLVED: add it to cssom-view 19:00:22 futhark: the rest here is really WHATWG's HTML spec change 19:00:43 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10858 19:00:43 Topic: [css-anchor-position-1] Define scroll interaction better. 19:00:43 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10858. 19:01:00 emilio: the timing of the operation was already discussed 19:01:11 ..seems we should put it somewhere in HTML, not talk about it here 19:01:25 ...other problem is that the whole anchor element doesn't resolve 19:01:38 ...depends on whether there's an anchor function which means that gCS doesn't round trip anymore 19:01:42 ...feels quite unfortunate 19:01:55 ...setting the inset to a fixed value would remove the anchor ness and that would just break positioning 19:02:01 ... that seems kind of bad 19:02:17 TabAtkins: that is the case, I agree it's bad, we have a case or two of that already with the shadow related things we were talking about before 19:02:21 ...agree they're not great 19:02:37 ...don't know how to get around it unless we add a syntax to let it reflect the fact that there was an anchor 19:02:47 ...indicate that it was anchored even though you're using an explicit value 19:03:01 emilio: could also include scroll offset in resolved value but that might be weird too 19:03:05 TabAtkins: I'd have to think about that, might work 19:03:21 emilio: we can think about it and figure out a solution 19:03:36 TabAtkins: would not mind coming up with something that addresses this problem, let's see what we can do in the issue 19:03:51 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10784 19:03:51 Topic: [css-conditional] @container scroll-state(snapped) and snapchanged vs snapchanging 19:03:51 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10784. 19:04:06 futhark: this is an issue about scroll state snapped 19:04:26 ...question of whether state queries should match at the same time the snap changes or also including snap changing 19:04:37 ...think it makes sense to maek state query change while you're scorlling 19:04:47 ...got some feedback from ? that he thought you might want to have 2 separate queries 19:04:49 q+ 19:04:57 ...one that changes with snap query and one that's only matching after ? 19:04:59 q+ 19:05:24 ...just looking for input, if someone thinks current behavior matching snap changing is good or if there are any other suggestions 19:05:31 q+ 19:05:47 ack TabAtkins 19:05:53 kbabbitt has joined #css 19:05:57 florian_irc has joined #css 19:06:20 TabAtkins: I agree that if we continue to keep just one query, having it match the snapchanging event so you'll start succeeding on the element that is becoming snapped is right 19:06:31 ...Adam's argument about having 2 is intriguing, would like to see an example 19:06:39 ...could easily be convinecd that it's a good thing to do 19:06:46 futhark: happy to resolve on matching snapchanging 19:06:57 ack flackr 19:07:06 flackr: also agree that snapchanging is the right first step would like to see use cases for snapchanged 19:07:17 https://github.com/w3c/csswg-drafts/issues/10838 19:07:19 ...also wanted to point out open issue about what snapchanging targets 19:07:25 ...10838 19:07:36 ...where I think, Adam has potentially requested a third possible query 19:07:37 futhark 19:07:45 futhark: just to correct a bit about what I have implemented so far 19:07:52 ...checking oth snapchanged and snapchanging 19:07:59 ...in case there's snapchanged that happened without snapchanging 19:08:04 flackr: that is not supposed to happen 19:08:14 ack miriam 19:08:17 miriam: I think I basically agree with TabAtkins and flackr 19:08:27 ...to clarify, snapchanging is inclusive of ? changed 19:08:41 ...we're not saying it matches only when it's changing but also when it has changed 19:08:51 ...agree we're starting in the right way 19:09:05 Rossen4: other opinions? 19:09:40 futhark: currently snap... if that's a bad name, if we decide to add the scroll changed / snap changed later... [?] 19:09:51 flackr: are there other patterns we could follow 19:09:55 TabAtkins: I don't think we have precedent yet 19:10:01 miriam: I think snap is nice for the default 19:10:07 ...we can figure something else out for the other 19:10:23 futhark: we can just resolve that snapped matches snapchanging 19:10:34 Rossen4: other comments? 19:10:52 RESOLVED: snapped matches snapchanging 19:11:29 ScribeNick: TabAtkins 19:11:37 Topic: CSS Forms 19:11:56 astearns: just before eth power went out Tuesday, we took a resolution on what the scope of the new CSS forms draft is gonna be 19:11:59 https://log.csswg.org/irc.w3.org/css/2024-09-24/#e1647946 19:12:07 astearns: there was some confusion about the scope of that resolution 19:12:12 astearns: it's "this is what will go into the draft" 19:12:22 astearns: the only thing we resolved about the specific *concepts* into the draft are the principles 19:12:42 astearns: the rest we're gonna wait for Apple's proposal, and look at what OpenUI has, and we'll have further discussion/resolutions about what actually goes into the draft at that point 19:12:57 astearns: so the resolution wasn't "we're gonna adopt Apple's currently-unseen proposal and put it into the draft", we've got more steps 19:13:02 +1 19:13:09 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10711 19:13:09 Topic: [css-ui] Support setting offscreen content inert 19:13:09 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10711. 19:13:11 +1 thanks 19:13:20 florian_irc has joined #css 19:13:26 florian_irc has joined #css 19:13:33 flackr: we talked about this previously, there were some open questions and a arequest to talk to a11y folks 19:13:36 flackr: i've done both 19:13:46 s/"this is what/"this is the *scope* of what/ 19:13:52 flackr: certainly a controversial area, but i think a11y folks are largely in support of making it easier to match the expected a11y of these use-cases 19:14:13 flackr: and i've outline a way in which a property could explain the inert attribute, so we don't have complex interactions between the two 19:14:32 flackr: could we pursue the proposed option of adding a new property for this, and the UA stylesheet explaining inertness? 19:14:56 https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2378378364 19:15:02 flackr: Option 1, bikeshedding welcome 19:15:42 q+ 19:16:11 chrishtr: Is Scott's comment in line with this? 19:16:27 flackr: I believe so, yes, he has some additional comments about how/when you should be able to escape inertness. 19:16:34 ack emilio 19:16:49 emilio: This also affects how browsers implement this 19:17:01 flackr: It mostly tracks how browsers implement, but the current proposal has the ability to escape 19:17:23 emilio: In Gecko, you can't - we implemented stuff without the :has() (it doesn't work with shadow Dom) 19:17:31 emilio: we implement escaping the same way 19:18:25 emilio: the only reason authors can't escape inert now is because we don't expose the internal property that allows that 19:18:42 emilio: exposing it contradicts some of the discussions a while ago when this was being discussed. I'm personally okay with it, tho. 19:18:57 emilio: part of the reasoning to not expose to CSS was a lack of use-cases, but it seems there are some 19:19:07 q? 19:19:12 Rossen4: so back to the original proposal, Option 1. 19:19:21 Rossen4: Objections? 19:19:28 emilio: to clarify, this is inherited? 19:19:30 flackr: yes 19:19:37 emilio: okay, instead of doing wonky pseudo-inheritance 19:19:59 RESOLVED: Accept Option 1 in flackr's latest comment 19:20:14 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10715 19:20:14 Topic: [css-overflow-5][css-scroll-snap-2] Snapping and generating scroll-marker pseudo-elements from fragments 19:20:14 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10715. 19:20:37 flackr: we had a previous discussion about the use-cases for snapping and generating scroll markers on column boxes 19:20:50 flackr: based on some of the discussion/concerns, i'm proposing we go with a fourth option 19:20:56 flackr: define a ::column pseudo 19:21:12 flackr: that you can attach scroll markers to, set scroll-snap-align on. potentially we could expose more props in the future 19:21:26 flackr: and I think this resolves a lot of the issues we had, and is consistent with some of elika's comments 19:21:38 +1 from me 19:22:17 Rossen4: Rune, you had comments on this issue 19:22:40 flackr: you commented on the ::nth-fragment option, but the proposal now is to go with a ::column pseudo 19:23:01 futhark: that's kinda a sidenote, about styling columns when elements fragment across them 19:23:06 futhark: is that relevant now? 19:23:22 flackr: I think there's one potentially relevant question here. 19:23:29 flackr: if you set scroll-snap-align:inherit... 19:23:45 futhark: yeah, which one do you align if an element breaks across columns 19:23:49 flackr: need to decide if we inherit 19:24:07 flackr: if we never support selecting particular columns, it's okay 19:24:18 flackr: but if we do, you could inherit different values on each fragment 19:24:37 fantasai: there shouldn't be inheritance 19:24:40 miriam: why? 19:24:46 fantasai: we could go either way in theory 19:25:04 fantasai: I think there are use-cases for having *some* sort of inheritable pseudo-element, but that's really complicated 19:25:16 fantasai: but a lot of times you just want to address the pseudo itself as a box 19:25:32 fantasai: another issue, ::column is a pretty generic name, we have columns elsewhere. 19:25:42 got it, makes sense - thanks 19:25:48 fantasai: if we have it just be a leaf box in the tree, it's easier for us to reuse it in those other contexts 19:26:42 flackr: proposed resolution, add ::column pseudo-element as described in the issue 19:27:11 flackr: it's a leaf node (nothing inherits from it), and it supports scroll-marker and scroll-snap-align for now 19:27:27 q+ 19:27:44 ack futhark 19:27:56 futhark: you said nothing inherits from it, what about ::scroll-marker? 19:28:09 fantasai: nothing *in the tree* inherits from it. chained pseudos still do, as normal 19:28:17 RESOLVED: Add ::column pseudo, as a leaf node on the multicol, supporting scroll-marker and scroll-snap-align 19:29:08 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10722 19:29:08 Topic: [css-overflow-5] Scroll button pseudo-elements 19:29:08 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10722. 19:29:29 flackr: the ::scroll-button pseudos let authors easily add buttons scrolling partiuclar directions to a scroll container 19:29:43 flackr: last time the main thing tha tprevented us from resolving was a lack of clarity on how they would work 19:29:51 flackr: i have a specific list of answer to the open questions in my comment 19:30:05 flackr: basically, ::scroll-button() syntax, taking logical or physical directions 19:30:16 flackr: the buttons come before the scrolling contents in focus order, all together 19:30:31 flackr: they scroll one "page", as determined by the UA similar to PgDn, in the relevant direction 19:30:50 flackr: I have opened a separate issue specifically to talk about the focus order of th epseudos with respect to each other 19:30:53 q? 19:30:59 nigel has joined #css 19:31:00 q+ 19:31:07 TabAtkins: I was gonna ask about that, happy to have it in a separate issue 19:31:35 lea: this seems reasanable. could we have a non-parenthetical version so you can style all of them the same way without enumerating them? 19:31:35 zrhoffman has joined #css 19:31:50 fantasai: that makes sense, but I'd keep the parens and let it be empty 19:31:53 lea: why? 19:31:58 fantasai: it's more like a universal selector 19:32:15 fantasai: we have other patterns similar to this 19:32:33 lea: we have precedent for un-paren'd pseudo-classes 19:32:46 fantasai: yeah, but pseudo-elements don't have that precedent. VT pseudos, for instance. 19:32:51 lea: Okay, no strong opinion. 19:33:11 I think `::scroll-button` is cleaner than `::scroll-button()` but not a hill I'd die on 19:33:25 flackr: proposed resolution, add ::scroll-button() pseudo-elements to Overflow 5, as describe din the issue 19:33:41 RESOLVED: add ::scroll-button() pseudo-elements to Overflow 5, as describe din the issue 19:34:08 janina1 has joined #css 19:34:51 Topic: end 19:34:58
19:35:23 tantek has joined #css 19:39:16 florian_irc has joined #css 19:41:06 Penny has joined #css 20:00:22 jfkthame__ has joined #css 20:00:38 jfkthame__ has joined #css 20:05:07 masonf has joined #css 20:14:50 florian_irc has joined #css 20:16:44 kzms2 has joined #css 20:24:37 jfkthame__ has joined #css 20:30:09 nigel has joined #css 20:32:42 karlcow has joined #css 20:33:59 nigel has joined #css 20:42:46 gsnedders has joined #css 20:43:09 Francis_Storr has joined #css 20:49:02 kbabbitt has joined #css 20:56:18 florian_irc has joined #css 21:00:13 alisonmaher has joined #css 21:01:15 kizu has joined #css 21:02:15 florian_irc has joined #css 21:02:37 florian_irc has joined #css 21:07:18 florian_irc has joined #css 21:08:08 kschmi has joined #css 21:08:13 ethanjv has joined #css 21:08:34 Rossen6 has joined #css 21:10:20 scribenick: fantasai 21:10:21 Topic: Pseudo-Elements 21:10:51 tantek has joined #css 21:11:05 jarhar has joined #css 21:11:16 s/Pseudo-Elements/Scrolling Continued/ 21:11:25 Topic: [css-overflow-5] Creating scroll-marker groups within which to select an active marker 21:11:48 flackr: ::scroll-marker() have an implicit element [missed] 21:12:00 flackr: but when using anchor tags to create scroll markers, the grouping mechanism needs to be explicit 21:12:08 flackr: currently proposal is to use ? as focusgroup 21:12:19 flackr: do we want to do this? should that be dependent on focusgroup existing? 21:12:28 flackr: should we add a specific attribute name or something on ancestor of elements? 21:12:50 andreubotella has joined #css 21:12:52 flackr: My suggestion was stick with focusgroup as container of elements 21:13:10 flackr: ergonmically it means any time you create a group of scroll markers they will have arrow navigation among them 21:13:16 flackr: because that's what focusgroup does 21:13:33 flackr: it'll also pull in any focusable elements 21:14:18 Rossen6: what's the proposal? 21:14:33 flackr: outside of CSS, but would push for an attribute, either on links themselves to how radio buttons have a name 21:14:37 flackr: or attribute on an ancestor 21:14:45 flackr: to capture all of the anchors as a marker group 21:14:56 flackr: I would propose explicit name as more reasonable alternative 21:15:25 Rossen6: was this already socialized beyond CSS, with a11y or HTML folks? 21:15:45 flackr: original proposal was socialized 21:15:51 q+ 21:15:55 Rossen6: seems reasonable for now... 21:16:01 q- 21:16:24 fantasai: this doesn't affect making a scroll marker, just navigation among them 21:16:36 flackr: we need to choose the active marker among a group of active markers 21:16:55 flackr: need a group to select from 21:16:59 ack kbabbitt 21:17:14 kbabbitt: suggestion to change, alternative mechanism, was there feedback? or just something you were thinking about? 21:17:28 flackr: not based on author feedback, but more spec concern that focusgroup is not yet specced 21:17:45 flackr: so relying on a feature to develop the HTML version of this that still needs to pull out into its own spec 21:18:05 kbabbitt: but ?? does use a named identifier 21:18:17 flackr: if we have concrete proposal, happy to take to HTMLWG, but 'name' is not available :) 21:18:28 s/??/radio button group/ 21:18:47 fantasai: would help to show your demo, so everyone has full context on what you're asking 21:18:55 s/demo/demo and markup/ 21:19:06 fantasai, you wanted to ask robert to show the markup so everyone is on the same page 21:20:30 flackr: [projects demo of table of contents of a doc, dots on the right] 21:20:49 flackr: Look at source, we have
    on the table of contents, ancestor of all the related links 21:20:58 flackr: similarly we have focusgroup on an ancestor of all the circles 21:21:06 flackr: so that's created two scroll marker groups 21:21:15 flackr: where one is active in the left group and one is active in the right group 21:21:24 flackr: the inline links in the doc don't become active because not part of the group 21:21:25 q? 21:21:29 gsnedders has joined #css 21:21:42 flackr: this is how written now. Alternative would be possibly some sort of name attribute on each link 21:21:55 q+ 21:21:55 flackr: or add any attribute on an ancestor 21:22:20 fantasai: styling the active one with ...? 21:22:27 flackr: :checked right now. Issue about bikeshedding that name? 21:22:42 q? 21:22:49 ack kizu 21:22:55 kizu: I like this proposal, focusgroup sounds like a good way to grou pit 21:23:06 kizu: only thing to have that would be nice would be to opt-out some of the ?? 21:23:26 kizu: you might want some of the items excluded, only use prior items. Or even highlight multiple...? 21:23:36 kizu: I guess can just use :has(:checked) 21:23:45 kizu: [missed] 21:24:04 kizu: use case, summary collapsed with elements, if they do not currently display should be excluded from the group? 21:24:09 flackr: that's an interesting question 21:24:34 flackr: if I put display: none in here 21:24:39 flackr: then supposed to select other markers 21:25:05 fantasai: I think this should be a style 21:25:14 scribe+ 21:25:15 fantasai: I think that this should be a style property rather than an html property 21:25:28 fantasai: if you want your ToC to be different, then yeah, it should be in the html 21:25:45 +1 fantasai, and we should figure out what the right style primitives are to make this feasible/easy 21:25:46 fantasai: but if you want to change the scroll marker [???] effect, then that should be a property 21:25:53 fantasai: I don't think that doing this markup is the right place to do it 21:26:12 fantasai: so that would mean you wouldn't have the up/down arrow effect. but you'd at least get the :checked styling 21:26:14 flackr: Makes sense 21:26:18 +1 21:26:21 +1, if it is possible to make it just via CSS, it would be more flexible 21:26:21 flackr: appreciate suggestion of doing as style 21:26:23 Di has joined #css 21:26:48 PROPOSED: Enabling active scroll marker styling and grouping should be done via CSS properties 21:26:50 sgtm 21:27:15 lea: agree with fantasai that this should be a style, but haven't dived deep 21:27:19 lea: but it does seem like styling 21:27:23 Rossen6: others? 21:27:28 Rossen6: objections? 21:27:34 RESOLVED: Enabling active scroll marker styling and grouping should be done via CSS properties 21:28:18 Topic: Publishing css-overflow-5 21:28:45 https://drafts.csswg.org/css-overflow-5/#scroll-navigation 21:29:17 fantasai: should we resolve to publish FPWD? Not published yet, but we're actively working on it 21:29:22 Rossen6: do we want to wait for edits? 21:29:33 fantasai: yes but want to put some pressure on flackr to publish :) 21:29:40 Rossen6: you feeling the pressure? 21:29:46 flackr: I'm feeling the pressure 21:30:09 Subtopic: [css-overflow-5] Improve active marker calculation 21:30:16 s/Topic: Pub/Subtopic: Pub/ 21:30:51 flackr: Currently in spec we select the marker whose target has scrolled at least as far as, if not further than, 21:31:05 kbabbitt has joined #css 21:31:08 flackr: but this means that as you scroll into next section, doesn't become active until it hits its aligned position 21:31:12 flackr: e.g. at top of viewport 21:31:24 flackr: similarly for carousel use cases, doesn't switch until next item is completely scrolled into view 21:32:03 flackr: [demo of lag in the scroll marker] 21:32:15 flackr: proposing more intelligent selection, finds next marker when it's closer to the viewport 21:32:20 flackr: rough proposed algorithm in the spec 21:32:30 flackr: details are nuanced, because don't need to be larger than scrollport 21:32:36 q+ 21:32:37 flackr: for example distance from one heading to another 21:32:37 q+ 21:32:47 flackr: so wanted to take a resolution that yes, we make changes 21:33:01 flackr: similar to if we were snapping, would change to the new thing 21:33:11 flackr: not quite the same because scroll targets could be headings, not the entire section 21:33:21 flackr: so this is why we can't share exactly the scroll snap properties 21:33:41 ack fantasai 21:34:05 fantasai: haven't thought through it in detail, but going in this direction does make sense 21:34:31 q+ 21:34:41 florian: Makese sense to go in this direction, but wonder if it shouldn't be a quality of implementation issue 21:34:42 ack florian 21:34:45 florian: Can imagine variants 21:34:55 florian: e.g. if you are scrolling towards one vs (missed) 21:35:01 florian: may be some nuances 21:35:11 flackr: could keep it open for now 21:35:19 flackr: but in any case what you're proposing shouldn't be disalowed 21:35:24 miriam: there's some advantage to predictability 21:35:31 miriam: so I have some concerns about being too clever with it 21:35:46 miriam: which makes me lean other way from Florian, maybe better to keep it simple and consistent across browsers 21:35:55 xiaochengh has joined #css 21:35:57 miriam: definitely I don't trust the concept of "closer" because one heading can be much closer when still not in th viewport 21:36:02 miriam: it has to be a lot more clever than that 21:36:08 flackr: cleverer thing written in the issue 21:36:22 miriam: don't want to lose simple and predictable 21:36:22 q? 21:36:30 q+ 21:36:32 ack miriam 21:36:45 flackr: would it make sense to come back with a concrete somewhat clever proposal and see if we can agree on it? 21:37:01 kizu: what's proposed there in the issue makes sense 21:37:07 kizu: this is close to my latest implementation of this 21:37:27 https://github.com/w3c/csswg-drafts/issues/10917#issuecomment-2380087937 21:37:30 kizu: [describes his latest marvel of CSS engineering] 21:37:37 kizu: in Chrome you can see how it works 21:37:46 kizu: I really like this, it's very in line with what flackr wrote 21:37:54 kizu: but would be nice to see exactly what's proposed 21:37:57 ack * 21:38:02 ack kizu 21:38:04 flackr: for discussion with mia, goes both ways 21:38:04 ack florian 21:38:07 s/flackr/florian/ 21:38:18 florian: to the extent people will build on it, better to have more predictability 21:38:34 florian: on the other hand this is in UX space, and trade-offs in one UA might differe from other UA, possibly depending on input modalities 21:38:55 florian: I would expect UAs to fine-tune this, which might result in different answers 21:39:03 florian: so providing flexibility seems useful 21:39:17 miriam: less about building on top and, already there are use cases where I would want different ansewrs 21:39:25 miriam: if I was being clever 21:39:35 miriam: I would come up with a different clever algo for ToC than for carousel slider 21:39:52 miriam: so that makes me mistrust the idea that we can find one clever option that will work across use cases 21:40:07 flackr: could add for a snapping carousel, if using scroll position that you would land on after snapping 21:40:24 flackr: so this exampe with carousel is slightly contrived, since I'm holding downt the scrolling mechanism 21:40:32 flackr: but in any free-flowing content, this problem is as I showed you 21:40:42 ack fantasai 21:41:04 fantasai: I don't remember what's in the spec, but if there are constraints we are sure of, e.g. this should definitely be the scroll marker, we should document those in the spec 21:41:21 fantasai: for cases where we need to decide the next action, we/miriam shoudl document some use cases 21:41:51 fantasai: flackr should perhaps document the parameters that are worth reasoning about when comparing strategies here 21:42:05 fantasai: once we have the examples for these use cases, we can decide which direction to go 21:42:12 flackr: what sorts of examples might be handy? 21:42:34 fantasai: e.g. "if you're an implementor and you're looking at these two cases, here's how you might write an algorithm to land on the right thing" 21:42:41 fantasai: maybe with an illustration, but that's optional 21:43:15 jarhar has joined #css 21:43:19 flackr: Propose resolve as keep spec as-is, but miriam adds use cases, flackr adds example algorithms ... 21:43:27 flackr: but might require resolving that there's flexibility in the spec 21:43:45 flackr: so should we resolve on flexibility in the spec? 21:43:54 fantasai: there's some flexibility, and some non-flexibility 21:44:08 fantasai: there are cases when e.g. you'd land on a thing where it's obvious you need to pick that scroll marker 21:44:18 flackr: I think for this demo should relax it a bit 21:44:40 q? 21:44:41 flackr: so need to remove the explicit algorithm about finding the thing before the current scroll position and use more open language 21:44:50 flackr: similar to snap point selection 21:45:25 +1 21:45:42 PROPOSED: Relax spec for less definitive cases, miriam to add use cases to issue, flackr to write possible algorithm(s) as examples 21:45:57 RESOLVED: Relax spec for less definitive cases, miriam to add use cases to issue, flackr to write possible algorithm(s) as examples 21:46:21 Subtopic: [css-scroll-snap-1] Avoid page scrolling skipping past snappable items 21:46:48 flackr: context of scroll buttons , but pre-existing issue with snapping 21:47:01 flackr: currently if you pgae down, the browser can select a snap area that is more than one page away 21:47:12 flackr: even though there's a possible snap area that's not that far away 21:47:34 flackr: I propose putting wording in the spec that, at least for explicit actions like page down, find a snap area that is less than one page away 21:47:38 flackr: so that you don't skip over content 21:47:54 flackr: then I had a further open question of whether we need to solve this for scrolling APIs 21:48:05 flackr: original issue was calling .scrollTo 21:48:08 flackr: to mimic same behavior 21:48:29 fantasai: I think yes, page-up page-down should scroll <= viewport 21:48:37 fantasai: might be exactly equal, but could be <= 21:48:55 fantasai: for programmatic API, those are supposed to [...] 21:48:58 ack fantasai 21:49:07 fantasai: ...have the same behavior as a person scrolling 21:49:23 fantasai: if scroll-snap is going to interfere with a person scrolling, then programmatic aPI should get that same interference 21:49:43 flackr: if I make a page-down button, as a web developer, and add an event listener that calls scrollTo(currentPos + 85% of scrollport) 21:49:59 flackr: the same problem as pressing pagedown on keyboard exists, that browser could select something further away 21:50:06 flackr: should we try to scroll less? 21:50:10 fantasai: round-down version? 21:50:19 flackr: most expressive version is to say "don't want to scroll more than 1 page" 21:50:28 fantasai: ... 21:50:33 flackr: that's scrollIntoView 21:50:46 flackr: this is for APIs where you specify how far you want to scroll, or a position 21:50:54 fantasai: do we want to add a scrollByPages API? 21:50:58 flackr: that would be reasonable 21:51:05 fantasai: or do we give a "bias-towards" parameter? 21:51:19 fantasai: which of those would make more sense 21:51:43 flackr: I feel like we'd be more likely to do what the dev expects, if the API was specifically "scroll by a page" 21:51:52 fantasai: I guess then we have 2 resolutions? 21:52:08 fantasai: (1) pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area 21:52:23 PROPOSED RESOLUTION: pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area 21:52:30 RESOLVED: pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area 21:52:57 fantasai: (2) we want to add some kind of scroll-by-page type API, to be sketched out by flackr 21:53:02 flackr: I can sketch that out 21:53:07 Rossen6: no need to resolve on that now 21:53:12 ACTION: flackr to sketch out a scroll-by-page API 21:53:36 Topic: Fragmentation 21:54:17 FWIW there is a scrollByPages API in Firefox, non-standard: https://developer.mozilla.org/en-US/docs/Web/API/Window/scrollByPages 21:54:45 kbabbitt has joined #css 21:54:58 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10761 21:54:58 Topic: [css-box-4] Applying `margin-trim` to fragmentation containers 21:54:58 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10761. 21:55:28 fantasai: we discussed this issue & related issue about text-box-trim on multicol containers a while back 21:55:48 fantasai: iank wanted some time to talk about how feasible it'd be to implement on the end side 21:56:01 fantasai: of containers 21:57:03 iank_: I synced up with morten. we're fine with the proposals. it does require backtracking 21:57:13 iank_: (the proposals for margin-trim and text-box-trim) 21:57:54 fantasai: the proposal is that margin-trim on a multi-column container trims the block-level margins adjacent to the affected edge of the column box 21:58:10 fantasai: if your margin is adjoining the top edge of the column, the margin-trim-top applies to you, and analogous for the bottom 21:58:34 RESOLVED: margin-trim on a multi-column container trims the block-level margins adjacent to the affected edge of the column box. if your margin is adjoining the top edge of the column, the margin-trim-top applies to you, and analogous for the bottom 21:58:46 Subtopic: [css-inline-3] text-box-trim vs fragmentation 21:59:07 fantasai: this issue is the same, but now for text-box-trim 21:59:28 fantasai: if you apply text-box-trim to a multicol container, it applies to the first formatted line of each column, and analogous for the last 21:59:51 q? 22:00:00 PROPOSED RESOLUTION: if you apply text-box-trim to a multicol container, it applies to the first formatted line of each column, and analogous for the last 22:00:12 RESOLVED: if you apply text-box-trim to a multicol container, it applies to the first formatted line of each column, and analogous for the last 22:00:38 Topic: Pseudo-Elements 22:00:52 Subtopic: [css-shadow-parts] are rules for which pseudo-classes and pseudo-elements work after ::part() parse-time or match-time? 22:01:32 dbaron: I filed a series of pseudo-element issues. this first one was a case where spec was written after impls/tests were written 22:01:39 dbaron: impls are interoperable and disagree with spec 22:01:50 dbaron: spec says some pseudo elements / classes work after ::part 22:02:05 dbaron: but all of them are supposed to be syntactically allowed at parse time, and the ones that don't work just don't match 22:02:14 dbaron: but impls reject at parse time the ones that don't work 22:02:28 dbaron: TabAtkins prefers what the spec says 22:02:45 dbaron: TabAtkins thinks parse-time selector restrictions haven't been very successful and we shouldn't add more of them 22:03:01 +1 22:03:02 dbaron: counterargument: it's already implemented across 3 engines, so changing impls might have some level of risk 22:03:09 q+ 22:03:12 dbaron: Also, it's more consistent with other pseudo-elements 22:03:13 q+ 22:03:26 dbaron: other pseudos that don't do anything are invalid at parse time 22:03:27 q+ 22:03:34 dbaron: [gives an example with two ::before elements] 22:03:51 dbaron: my inclination is to do easy thing and change spec to match the impls + tests 22:04:05 q+ to ask, it sounds like there's a clear upside to doing the validation at match time. What's the downside? 22:04:09 dbaron: this is widely tested in WPTs. We could just change the spec and say we've got it already implemented and tested 22:04:12 s/two ::before elements/::before::before selector, which is invalid/ 22:04:21 dbaron: I'd like us to do that, or to hear a convincing argument in the other direction 22:04:26 ack keithamus 22:04:41 ???: another benefit is that impls can highlight this in devtools 22:04:49 We can address that head-on by providing a method to test whether selectors are valid 22:04:50 s/???/keithamus/ 22:04:59 keithamus: that's another argument for the parse-time restriction 22:05:09 ack florian 22:05:21 florian: people who put tests in WPTs are welcome to change the spec & file spec bugs 22:05:32 florian: we should generally be more careful about this 22:06:07 dbaron: in this particular case, the tests were mostly testing other things. They were testing the rules for what wasn't allowed, and they didn't realize that there was stuff about it being a parse-time restriction 22:06:31 florian: there's a significant difference between things that are currently invalid are strongly expected to stay invalid forever, vs. if it may someday change 22:06:46 florian: if we treat a selector as a parse-time error and we want to make it valid in the future, that'll be painful 22:07:10 florian: But if we know these are going to be invalid forever, I have an easier time agreeing with your position 22:07:13 ack emilio 22:07:28 emilio: I think parse-time is generally better; it works better with @supports 22:07:35 emilio: (and CSS.supports, etc) 22:08:02 +1 to emilio and keithamus 22:08:06 emilio: I was going to also argue that impl-wise it's better not to have to deal with sort-of valid states, but we have to deal with that with nesting anyways 22:08:19 emilio: but yeah, @supports makes parse-time checking very valuable 22:08:28 emilio: if you want match-time restriction, you can use :is or :where 22:08:40 emilio: given we have a way of doing both things, I lean towards fixing the spec to match reality 22:09:01 florian: I'd be more ??? if we had selector invalidation at each ??? [agreeing I think] 22:09:25 dbaron: given the later issues I want to discuss, there might be a few strange cases of restrictions where we want to relax in the future 22:09:35 dbaron: but in most cases the restrictions are solid because it just doesn't make sense 22:09:44 lea: it sounds like there are upsides & downsides 22:09:45 ack lea 22:09:45 lea, you wanted to ask, it sounds like there's a clear upside to doing the validation at match time. What's the downside? 22:09:48 s/I'd be more ???/I'd be more comfortable with the proposal 22:09:58 lea: sounds like arguments for parse-time checking are for testing if something's supported 22:10:12 q+ 22:10:18 lea: is there a way we could add a way to check for if something is valid that would account for this case, and if we can, are there remaining arguments? 22:10:48 s/ if we had selector invalidation at each ???/ if we had selector error recovery at each comma, but especially given the availability of :is and :where, I think that's fine. 22:10:49 ack kbabbitt 22:11:05 kbabbitt: does document.querySelector throw on an invalid selector, and that could be used to check for validity? 22:11:10 lea: only throws at parse time 22:11:25 lea: all our tools right now check for validity at parse-time 22:11:39 kbabbitt: you're looking for a way to check whether a selector that's valid at parse time is valid when used? 22:11:42 lea: sort of, yes 22:11:58 dbaron: we just listed 3 different ways for checking whether selectors are valid, and they're all the parse-time version 22:12:11 dbaron: it'd be confusing to add another way that checks at a different time 22:12:28 lea: who was arguing for making it invalid at match time? 22:12:29 [various]: Tab 22:12:45 dbaron: TabAtkins is OK either way but would prefer match time 22:13:05 Rossen6: we're leaning towards fixing the spec & going with parse time 22:13:06 q? 22:13:11 Rossen6: objections? 22:13:28 RESOLVED: reject these invalid selectors at parse time 22:13:38 (fixing the spec to match reality) 22:14:10 Subtopic: [css-shadow-parts] need definition of which pseudo-classes can follow `::part()` that is sufficient to produce interoperability 22:14:41 dbaron: this is now going into the details of the rules for which pseudo-classes are invalid or valid after ::not 22:14:52 dbaron: this is important because we're introducing concept of part-like pseudo-elements 22:15:03 dbaron: this set of rules is now not only applying to part but also to other things 22:15:26 dbaron: the spec says the part pseudo element can take pseudo-classes like :hover...tree information... local element information [quoting spec] 22:15:40 dbaron: this is a reasonable design guideline for authors, but it's not specific enough to produce interoperability 22:16:01 dbaron: some tests revealed differences between implementations on this, RE whether something is tree information vs. local-element information 22:16:30 dbaron: what I want to do is change the spec so that it's explicitly listing which pseudo-classes are & are not allowed 22:16:38 dbaron: still giving design principle behind that, but making it more explicit 22:16:46 https://github.com/w3c/csswg-drafts/issues/10787#issuecomment-2332414419 22:16:46 dbaron: proposal is what's in Tab's comment from 3 weeks ago^ 22:16:51 masonf has joined #css 22:17:16 dbaron: which is basically, the things that we'll disallow the things the spec defines as structural pseudo-classes - first-child, nth-*, etc 22:17:25 dbaron: you can't use :has, it's asking about descendants 22:17:32 dbaron: you can't use :scope, :host, :host-context 22:17:45 dbaron: but all the other current pseudo-classes would be allowed. We'd be allowing :lang and :dir (previuos resolution) 22:17:55 dbaron: we'd be allowing :focus-within and :target-within, and :picture-in-picture 22:18:06 q+ 22:18:07 dbaron: those are the ones Tab thought were somewhat ambiguous but probably allow 22:18:16 dbaron: that's the proposal unless people want to change it 22:18:22 emilio: I agree on making it more explicit 22:18:24 ack emilio 22:18:39 emilio: I think there are some tests that are invalid, e.g. the last one uses :is ... 22:19:03 emilio: I think some of the tests that you landed may need tweaks. I think current behavior from WebKit and Gecko is correct, on :is:first-child etc 22:19:16 emilio: because it was resolved that we'd preserve the inner element serialization [?] 22:19:38 dbaron: there are some tests that Chromium fails due to serialization 22:19:51 emilio: we can sort this out async. generally I support this 22:20:00 s/this/the test failures/ 22:20:46 Rossen6: did you get a chance to check WHATWG discussions to be sure nothing needs to change 22:21:21 dbaron: I read through the more recent discussions. I don't think any of that would change this list 22:21:41 PROPOSED RESOLUTION: Tab's comment from 3 weeks ago https://github.com/w3c/csswg-drafts/issues/10787#issuecomment-2332414419 22:22:02 PROPOSED RESOLUTION: disallow 22:22:02 :has() 22:22:02 :scope 22:22:02 :host, :host(), and :host-context() 22:22:12 +1 22:22:27 Di has joined #css 22:22:34 RESOLVED: disallow :has() :scope :host, :host(), and :host-context() 22:22:53 Subtopic: [css-pseudo] more clearly define which pseudo-elements are tree-abiding or part-like 22:23:20 Related: https://github.com/w3c/csswg-drafts/pull/10839/files 22:23:26 dbaron: we introduced this concept of ::part-like pseudo-elements 22:23:48 dbaron: there's a few different ways to think about it; I like to think it's a pseudo-element where underneath there's actually an element. So you can do most things with it 22:24:01 dbaron: ::part lets you use a pseudo element that was part of the shadow tree 22:24:14 alisonmaher has joined #css 22:24:15 dbaron: we're adding another way to do for form-controls that's similar 22:24:32 dbaron: we've added tree-abiding pseudo elements. they support a smaller set of things. General assumption: we can make a tree out of them 22:24:40 dbaron: they're not things like ::selection that cross the tree in random ways 22:24:58 dbaron: they're like ::before which lives in the tree at this place, and it has clearly-defined before/after siblings 22:25:32 dbaron: we have a lot of pseudo-elements in different specs. We need to be sure the ones that should be defined as ::part-like are defined that way, and same for tree-abiding, and we should say which ones aren't those things too 22:25:47 q+ 22:25:47 dbaron: I tried to make a list of which pseudo-elements go in each bucket 22:26:03 dbaron: I'd like other folks to take a look, especially the ones that I put question marks next to 22:26:20 dbaron: this is in the last comment in the issue, https://github.com/w3c/csswg-drafts/issues/10794#issuecomment-2379912294 22:26:27 ack fantasai 22:26:48 fantasai: there are multiple categories of pseudo-elements. we should be sure the names for the categories are reasonable 22:27:14 fantasai: "tree-abiding" seems reasonable. we have some that are restricted in terms of which properties they can take (e.g. ::before vs ::marker) 22:27:41 fantasai: "tree-abiding and takes any property", "tree-abiding but restricted", and "part-like" -- are those the 3 categories? 22:27:52 dbaron: we've already allowed pseudo elements to have hand-written restrictions 22:28:11 dbaron: everything not in the ::part-like bucket has some restrictions hand-written at its definition 22:28:30 dbaron: there are also a bunch of general rules about how selectors combine, more than about what properties are used 22:28:51 dbaron: ::part-like pseudo elements do allow any properties, but the more interesting part is about how you can combine selectors 22:29:00 dbaron: anything that's not part-like has custom prose saying which properties are allowed 22:29:04 q+ 22:29:16 ack emilio 22:29:28 w.r.t. having a known location in the tree, see https://drafts.csswg.org/css-animations-2/#animation-composite-order 22:29:28 emilio: I think your list is pretty reasonable. I don't think all the tree-abiding pseudos support the content property 22:29:36 dbaron: that was me reading the spec, not checking reality 22:29:46 dbaron: I looked through all the specs for things that reference those definitions 22:29:54 dbaron: in reality support for the content property does not match the spec 22:30:16 emilio: ::backdrop might not be implemented as an element in all engines... as a box, in all engines? 22:30:34 fantasai: that's how it should be defined. There's no reason for it to have an element backing... 22:30:53 emilio: not sure if all impls make it an element. if they don't make it an element, I'm not sure it should be tree-abiding? 22:30:55 q+ 22:31:04 fantasai: it does fit in the tree. stuff that's not tree-abiding is stuff that crosses element boundaries. ::first-letter, ::first-line, all that stuff 22:31:14 q- 22:31:29 emilio: ::cue might be ::part-like 22:31:37 emilio: and also [...] 22:32:07 emilio: for now we can go with -- if an engine doesn't implement it as a part, we can consider it not-part-like, and we can sort out more later 22:32:24 emilio: my other intuition for part-like vs. not is whether there's an actual dom element behind it, that isn't created by layout 22:32:35 emilio: (::before and ::after and ::marker are special) 22:32:51 emilio: but generally, my list would match yours, except for maybe ::backdrop and ::cue 22:32:57 ack andreubotella 22:33:04 perhaps ::placeholder could be part-like 22:33:16 Once we define how `` is laid out 22:33:19 One of these days ;) 22:33:21 andreubotella: you could think of ??? as selecting something in the flattened element tree, tree-abiding as selecting something in the box tree 22:33:27 s/???/part-like/ 22:34:07 andreubotella: do these pseudo-elements have some particular distinction? does it make sense to group them in this way, depending on what they select into? 22:34:08 q? 22:34:34 andreubotella: first and last select into the fragment tree, and nth-fragment also 22:34:51 s/first and last/::first-line and ::nth-fragment()/ 22:34:56 andreubotella: does it make sense to treat these as a separate category? or are the restrictions on those similar enough to the groups you've defined already? 22:35:15 dbaron: It may well make sense to describe that as a category 22:35:28 dbaron: I'm not aware of any common definition, so I'm hesitant to define spec terms if we don't have a reason to do so 22:35:32 dbaron: but the classification makes some sense 22:35:58 kizu has joined #css 22:35:59 q+ 22:36:06 I think dbaron's list makes sense for the selectors that I understand 22:36:07 dbaron: might be premature to take a resolution on this one. but I'd encourage discussion on the issue 22:36:49 ack jarhar 22:36:53 jarhar: for the classification question/concepts: hopefully this is related... On Mon or Tues at a joint meeting, I brought up whether new pseudo elements for customizable select should be before-like or part-like 22:37:06 jarhar: there weren't spec concepts for this but it's important for implementation 22:37:28 jarhar: if I want to make it part-like, I need to wire it to shadow tree, real element in the tree, etc 22:37:47 jarhar: would be useful to have some kind of distinction for implementors, to help steer impl strategies 22:37:56 jarhar: (on new pseudos) 22:38:04 q+ 22:38:35 emilio: that's the main distinction. tree-abiding may encompass other things that are like generated content 22:38:49 emilio: we want to make part-like be things that have an element behind, unrelated to the styling of the parent 22:38:59 emilio: that's how a lot of the form-control shadow trees are implemented 22:39:11 ack emilio 22:39:15 nigel has joined #css 22:39:23 emilio: I'm pretty sure gecko/webkit have same kinds of assumptions about generated content. It'd be kinda hard to support a lot of these pseudo-classes on before/after 22:39:49 emilio: depending on how we decide to make a pseudo-element work, you need to take one approach or the other to implmeent it 22:40:05 fantasai: could you implement a tree-abiding as a part-like pseudo-element? 22:40:10 emilio: you could, it'd be more restricted 22:40:28 emilio: if you have an actual DOM element, you can implement a part-like and tree-abiding pseudo-element 22:40:43 fantasai: you can't implement a part-like pseudo without an actual element backing it, without a lot of work 22:40:56 fantasai: ... 22:41:05 emilio: that's how placeholder is implemented in webkit and blink 22:41:13 s/.../but you could implement tree-abiding as a part-like pseudo-element with some disabled features/ 22:41:14 emilio: we could change how gecko works to work that way too 22:41:28 emilio: but that's not great if we don't define what tree it is and what it works 22:41:37 Rossen6: let's move on 22:41:49 Subtopic: [css-pseudo] Should ::before / ::after really be part-like? 22:42:17 dbaron: this is a subtopic of previous one. emilio filed a specific issue about ::Before and ::after 22:42:29 dbaron: I agree with him, that ::before and after are not part-like 22:42:36 +1 22:42:36 fantasai: right, it surprised me to find that in the spec 22:42:40 emilio: sounds good 22:42:44 +1 22:42:55 PROPOSED RESOLUTION: ::before and ::after are not ::part-like 22:43:00 q+ 22:43:05 +1 22:43:08 ack flackr 22:43:10 ack fantasai 22:43:13 ack kbabbitt 22:43:29 kbabbitt: but they are tree-abiding? 22:43:31 emilio: right 22:43:34 PROPOSED RESOLUTION: ::before and ::after are not ::part-like but are tree-abiding 22:43:43 RESOLVED: ::before and ::after are not ::part-like but are tree-abiding 22:44:39 Subtopic: [css-pseudo][css-shadow-parts] Define "part-like pseudo-element" concept 22:45:05 dbaron: this one, we already had a resolution, but I wanted to give a brief update since the state of things is confusing 22:45:14 dbaron: so we resolved to make this :part-like pseudo-element concept 22:45:23 dbaron: half of the edits are edited in, but not all of them 22:45:41 fantasai: e.g. this edit, which has been waiting for this current discussion 22:45:46 -> https://github.com/w3c/csswg-drafts/pull/10839/files 22:45:51 dbaron: we've made some of the edits, to make partlikes like ::part 22:46:09 dbaron: earlier we were discussing what selectors and pseudo-classes apply after ::part 22:46:20 dbaron: those all apply to ::part-like as well, and I'm planning to make those edits 22:46:33 dbaron: Tab made edits about what properties apply. But the selector edits have not yet been made 22:46:35 dbaron: that's all 22:47:05 Subtopic: [css-shadow-parts][css-nesting] is & allowed after ::part() 22:47:28 dbaron: this is getting into fun stuff that I don't have strong opinions about, mixing multiple new features 22:47:39 dbaron: is the & selector after ::part? 22:47:48 dbaron: we have restrictions saying these selectors are allowed, these aren't (after ::part) 22:47:57 s/selector after/selector allowed after/ 22:48:05 dbaron: should we allow the nesting & selector after part, when it is a selector and is after part, or not 22:48:11 https://github.com/w3c/csswg-drafts/issues/10788#issuecomment-2329279090 22:48:14 fantasai: I'd go with "no" per this comment^ 22:48:24 fantasai: we do allow ::is but with restrictions, IIRC 22:48:51 fantasai: the & is pulling in a whole type-selector ... Unless we're wanting to allow type-selector, I don't think it makes sense to allow & 22:49:37 fantasai: proposed resolution: no change to spec, & is not allowed after ::part 22:49:47 RESOLVED: No change to spec. & is not allowed after ::part 22:49:58 Subtopic: [css-shadow-parts][css-scoping] Is ::slotted() allowed after ::part()? 22:50:15 dbaron: this is the last one of these 22:50:21 dbaron: is ::slotted allowed after ::part? 22:50:30 dbaron: this only makes sense if a shadow DOM exposes a slot as a part 22:50:34 lea: I've done that 22:50:43 dbaron: ok. So it sounds like this is maybe a useful thing to do sometimes 22:50:57 q+ 22:50:59 lea: that's useful when you want to expose a part but you don't want to pay a separate container for it. It can become a box. why not expose it 22:51:22 dbaron: So, the current state of allowing ::slotted after ::part is that Chromium and Gecko do not allow it 22:51:36 dbaron: WebKit allows it at parse time but it doesn't match the things I thought it should match 22:51:42 dbaron: there are 2 points here. 22:51:52 dbaron: (1) it's not clear to me if there's much of a use-case for ::slotted after ::part 22:51:58 dbaron: (2) it's pretty complex to implement 22:52:00 q+ 22:52:17 dbaron: it's combining things that jump in/out of shadow trees in ways that are extra fun and raise questions about how to cascade rules from different sources 22:52:45 dbaron: general rules suggest that this should be allowed, but it's a good bit of work to do correctly, and it's not clear to me if there are actually good use-cases for it 22:53:03 kbabbitt has joined #css 22:53:05 dbaron: and if it would require rewriting a bunch of scary code in the middle of cascade impl to do something obscure that nobody needs 22:53:07 ack emilio 22:53:15 emilio: I was going to say what dbaron just said 22:53:24 emilio: I'm pretty sure the reason this doesn't work in webkit is: 22:53:39 emilio: when youre styling a slotted node, you look at the trees from the shadow-trees where you're slotted (?) 22:53:57 emilio: the slotted combination makes it go out of the trees you would usually look at, which is why it doesn't work 22:54:20 emilio: this doesn't seem useful. I'd rather not allow it, & agree with dbaron 22:54:42 lea: the use-case for me was for a wrapper that's there whether you have the fallback content display or not 22:54:59 lea: doing that with a nested element... you have to wrap the slot with a separate element... I suppose that'd work 22:55:05 lea: there was a reason, but I need to remember it 22:55:19 q+ 22:55:24 dbaron: it's not just about why did you want to expose a slot as a part, but: if you did that, would you want to use ::part::slotted _from outside_ 22:55:31 ack lea 22:55:46 emilio: there are use cases for exposing slots as parts, thats's what the details element ended up doing 22:55:59 emilio: but the question is why would you do details::slotted::div (?) instead of details>div 22:56:08 ack keithamus 22:56:20 s/details::slotted::div/details::details-content::slotted(div)/ 22:56:33 keithamus: for something to be slotted, you can query for it... the only thing you gain from ::slotted on the outside is to know that it's a descendant of a named ::part. but I can't see why that would matter in practice 22:56:44 keithamus: it kind of exposes an impl detail of the shadow dom that might be undesirable 22:56:48 q+ 22:56:53 keithamus: would you have to make it unmatchable in a closed shadow root? 22:56:58 ack emilio 22:57:13 emilio: we resolved to add :has(:slotted) , so that detail would already be exposed via that pseudo-class 22:57:24 keithamus: good point, maybe we should ??? 22:57:27 s/:has(:slotted)/:has-slotted/ 22:57:29 s/:has(:slotted)/:has-slotted/ 22:57:44 dbaron: even though it's a closed shadow-root, it's exposed as a part. there's supposed to be something exposed there 22:58:15 q+ to say, it's definitely not high priority. Q: if we decide to not allow it now, is that something we can revisit later or will we run into web compat? 22:58:39 emilio: in general we haven't gone very far on trying to prevent exposing pseudo-classes/elements that are dependent on what element the part is 22:59:01 emilio: some are useful. you can do ::part ::placeholder to style a placeholder - that's an actual thing that was requested 22:59:12 emilio: I'm not sure we should go to great lengths to avoid matching ::has(::slotted) 22:59:22 er :has-slotted 22:59:27 s/::has(::slotted)/:has-slotted after ::part() 22:59:32 lea: if we decide not to do it, can we revisit this in the future? 22:59:44 lea: or will we be hit by webcompat in that scenario? 23:00:08 +1 to dbaron 23:00:15 dbaron: always some risk of webcompat problems. Maybe there already are webcompat problems. But I think this is in the category of low-risk, and we could allow it in the future even if we don't do it now. But not a thing we can promise 23:00:27 +1 to dbaron 23:00:31 dbaron: and I can't even really promise that we can do it now 23:00:41 Proposed resolution: don't allow ::slotted after ::part 23:01:05 RESOLVED: don't allow ::slotted after ::part 23:01:49 hypebeatsmagazine has joined #css 23:02:04 nigel has joined #css 23:18:57 florian_irc has joined #css 23:33:41 karlcow has joined #css 23:37:06 When do we reconvene? 23:38:07 lea: 7 minutes ago officially, but I am guessing 5-10 minutes from now 23:39:26 florian_irc has joined #css 23:42:08 We are reconvening 23:42:23 Rossen9 has joined #css 23:42:28 ethanjv has joined #css 23:43:02 kbabbitt has joined #css 23:43:09 alisonmaher has joined #css 23:43:44 ydaniv has joined #css 23:43:51 present+ 23:44:04 scribe+ 23:44:32 topic: Cascade 23:44:56 github-bot: take up https://github.com/w3c/csswg-drafts/issues/10889 23:44:56 Topic: [css-cascade] may need to define cascading order between sibling encapsulation contexts 23:44:56 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10889. 23:45:58 dbaron: one of the steps in the cascade, between origin and specificity 23:46:08 ... (don't remember how it interacts with layers) 23:46:23 ... is that rules based on tree scopes cascade separately 23:46:46 ... so rules from outside the shadow root generally wins, except !important which goes the other way around 23:47:14 ... there's spec text that assumes that only tree scopes relevant to styling are outside / inside 23:47:23 ... but in some edge cases you can have sibling scopes 23:47:38 ... one of these is if we allow ::part() after ::slotted() 23:47:53 ... the other is the /slotted/ combinator 23:48:20 present+ 23:48:26 ... so in these cases you have stuff in one shadow tree that affects styles in a sibling shadow tree 23:48:37 ... the cascade spec is not clear about this 23:48:53 ... I don't really have a solution, thinking about this makes my head hurt 23:49:05 ... for an impl perspective is probably easier not to cascade them together 23:49:15 ... because having them together may be painful 23:49:22 ... the problem here is we don't define what happens 23:49:38 ... I don't have very strong opinions 23:49:47 q+ 23:49:48 q+ 23:50:00 Rossen: tab seems to propose tree order 23:50:07 ack lea 23:50:07 lea, you wanted to say, it's definitely not high priority. Q: if we decide to not allow it now, is that something we can revisit later or will we run into web compat? 23:50:27 q+ 23:50:35 ack emilio 23:51:22 emilio: The shadow incluuding tree order thing makes sense except I don't know how to define !important in that case beacuse there's no inside or outside. Not clear if it should be reversed or not, that seems weird. So don't have clear answer. 23:51:56 dandclark: Was going to agree with tab 23:52:01 ... it generalizes that definition 23:52:12 ... but agree with emilio that it seems weird to do the reverse from !important 23:52:20 ack dandclark 23:52:23 ack lea 23:52:25 ... unclear if there's something better 23:52:31 lea: not quite sure I understand so might be off 23:52:39 ... not sure how making slotted a combinator relates to this 23:52:49 ... the whole point was to circumvent some of the issues 23:53:03 ... wouldn't it be the same as 23:53:21 ... you're using regular selectors to target the slotted elements 23:53:29 ... so regular cascade rules should apply 23:53:49 ... if it's about styling inside and outside we have :host and regular selectors too 23:53:53 ... maybe I'm misunderstanding 23:53:54 q+ 23:54:14 dbaron: I think it'd be the /slotted/ combinator in combination with ::part or something else 23:54:25 ack emilio 23:55:01 dbaron: I think I was thinking was something like /slotted/ element::part(foo) from inside a component 23:55:39 emilio: No because the outside is not a sibliing 23:55:39 ... then slotted looks at the parent tree scope, and ::part() could be a child of the parent tree scope (thus a sibling) 23:55:52 lea: wouldn't that be the same as targetting the part from outside? 23:56:02 emilio: no because outside scope wouldn't be a sibling 23:56:17 dbaron: the other possibility is that some of the rules are not desirable with ::slotted() 23:56:33 lea: that's a big motivation for the slotted combinator 23:57:24 that any CSS you include in ::slotted() has lower precedence than litterally any other CSS, including the universal selector, CSS resets, generic type selectors etc 23:57:30 q+ 23:57:34 unless you use !important, which is too strong 23:57:49 ack emilio 23:57:57 emilio: I am confused because the slotting behavior doesn't fix that layout 23:58:24 lea: my understanding was that ::slotted() behaves like this because it's a pseudo of the slot 23:58:31 emilio: that's not correct 23:58:38 lea: so this is the reason ::slotted() doesn't work? 23:58:55 dbaron: yes, the reason ::slotted() is so weak is this rule about encapsulation context 23:59:05 ... which I think makes sense for ::part() 23:59:13 ... but maybe it's not the right decision for ::slotted() 23:59:23 lea: but now we cannot change ::slotted() because of webcompat 23:59:28 ... so /slotted/ would work 23:59:57 ... btw I chatted with rniwa, and his implementation concerns are about targetting descendants and other elements 00:00:14 ... but if we restrict what comes after to a compound selector he's fine with it 00:00:14 q+ 00:00:22 ack emilio 00:00:41 q+ 00:00:53 emilio: So that is correct, that was an implementation issue, but making @@@ doesn't help as long as we don't change the cascade spec in subtle ways. 00:00:56 ack lea 00:01:00 lea: it's clear we need to fix both 00:01:04 s/@@@/slotted combinator 00:01:19 ... but we probably can't change how ::slotted() behaves because webcompat 00:01:20 q+ 00:02:18 emilio: I am not sure that's necessarily true. Does need some investigation . RIght now in the cascade spec all @@@ have hte same behavior. So it would feel weird to change the behavior only because multiple selectors can match 00:02:23 ...we could try to fix the cascade spec 00:02:34 ...but that's sort of tangential to this issue 00:02:41 ...but should do that if that's what we really want 00:02:50 https://github.com/w3c/csswg-drafts/issues/7922#issuecomment-2380098440 00:03:02 lea: there are a lot of other things that need to be fixed, see ^ 00:03:15 q+ 00:03:18 emilio: Seems there's no clear consensus 00:03:26 ack emilio 00:03:33 ack keithamus 00:04:24 keithamus: Can you style `:has()` with a combinator? So you'd do `:has(/slotted/ something)` 00:04:36 rniwa has joined #css 00:04:38 lea: yeah `:has()` supports relative selectors 00:04:48 ... first example in mdn 00:04:52 Rossen9: let's take this back to the issue 00:05:12 github-bot: take up https://github.com/w3c/csswg-drafts/issues/6867 00:05:12 Topic: [selectors] Pseudo-class to indicate when a slot has content 00:05:12 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6867. 00:05:47 Rossen9: who's best to summarize this one? 00:06:23 dbaron: was discussed yesterday according to github-bot 00:06:34 https://github.com/w3c/csswg-drafts/issues/6867#issuecomment-2378207271 00:06:36 keithamus: didn't resolve because I had a question about the functional pseudo-class 00:06:47 ... to do the same things I was talking about 00:06:51 ... wrt /slotted/ 00:07:14 ... I think we need to pick a direction, either we look into the slotted combinator or we look into :has-slotted() 00:07:21 q+ 00:07:35 emilio: Did we resolve on the nonfunctional version? 00:07:48 keithamus: we resolved to that prior 00:08:00 ... but test were written for the functional pseudo-class 00:08:15 ack emilio 00:08:18 ... it seems the functional pseudo is more interesting to the WC community 00:08:32 ... but happy to investigate the combinator 00:10:35 emilio: Given :has-slotted() is dependent on whether we do the combinator, and the combinator kinda depends on what we do about the cascade order, I'd prefer to discuss the cascade order at least first, when TabAtkins is around ideally 00:10:39 castastrophe has joined #css 00:11:09 emilio: We can keep the tests as tentative or I can split it 00:11:27 emilio: I think we need an issue about the cascade issue 00:11:43 ...wasn't clear that was the main complaint about the slotted selector 00:11:54 ACTION: keithamus to open issue about ::slotted() cascade order 00:12:24 github-bot: take up https://github.com/w3c/csswg-drafts/issues/10498 00:12:24 Topic: [css-pseudo-4] ::self-link pseudo, for self-linking 00:12:24 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10498. 00:12:58 flackr: as TabAtkins wrote, it's a very common pattern (bikeshed etc mentioned) 00:13:13 ... this adds a link to the heading that you can link to 00:13:23 ... developers write tools to add these 00:13:39 ... the proposal is to add a pseudo to generate this before the element 00:13:45 ... long list of proposed behavior 00:14:00 ... main one is it requires the content is linkable which means it has to have an ID attr 00:14:32 ack fantasai 00:14:43 fantasai: main issue, sometimes they want it at the start or at the end 00:14:54 ... the other is sometimes you want a link to the container, not the heading itself 00:15:07 ... e.g.

    ... 00:15:21 ... you could add the id to both but the desired thing is to target the section 00:15:23 moonira has joined #css 00:15:25 ... so I like the idea 00:15:33 ... I don't think it's a problem to do it with CSS 00:15:45 ... but needs a way of solving these two 00:15:45 flackr: the second seems more tractable 00:15:58 ... we could allow it to refer to the nearest ancestor with id 00:16:14 fantasai: that won't get you reasonable behavior for the fifth heading in the section or something 00:16:21 ... you'd be jumping too high 00:16:24 ... maybe fine 00:16:33 ... but if you have somewhat unpredictable markup... 00:16:38 ... [missed] 00:16:42 ... it's a bit tricky 00:16:48 flackr: not sure I understand the use case 00:17:12 ... isn't the
    what you link the one you want? 00:17:22 fantasai: the nearest element with an id might be
    or what not 00:17:28 flackr: ah because they forgot or something 00:17:43 1+ 00:17:45 q+ 00:18:07 flackr: I supposed if there was a functional pseudo you could use `attr(id)` to refer to yourself or something 00:18:25 fantasai: that might be more practical 00:18:38 ack emilio 00:18:42 ... I think those are my two concerns 00:18:49 scribe+ 00:18:56 emilio: Is it well-defined to have generated interactive content? 00:18:58 emilio: My question is is it well defined to have generated interactive content? 00:19:04 ...What's the click event target? 00:19:13 ...Might be fine but might need some work on DOM side as well 00:19:32 flackr: there is common behavior when you click on pseudos that you dispatch on the outer element, not great but... 00:19:39 ... it is at least targettable 00:19:44 ... we could explain this in the future 00:20:23 emilio: But I think the targets @@@ is mostly an effect of the generated content. Not quite pointer events but sort of. Must be targetable. Thinking about user-select. 00:20:49 flackr: not sure I have the answer about how to support before / after 00:20:50 q+ 00:21:21 ack emilio 00:21:26 emilio: What if instead of making new pseudo you make it content function or something? That way you can use ::before and ::after, can target anything 00:22:12 ... that way you could use content: self-link(self) or self-link(closest) or something 00:22:19 ... and would solve the before / after issue 00:22:21 flackr: yeah 00:22:25 Rossen9: let's take it back to the issue 00:23:42 github-bot: take up https://github.com/w3c/csswg-drafts/issues/7875 00:23:42 Topic: [css-overflow][css-contain][css-sizing] `overflow: auto` incompatible with size containment and container queries 00:23:42 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7875. 00:24:00 oriol: florian added this to the agenda 00:25:26 github-bot: take up https://github.com/w3c/csswg-drafts/issues/5900 00:25:26 Topic: [css-color] [css-ui-4] Authors should have access to accent-color value to use in their code 00:25:26 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5900. 00:25:48 florian: no longer objecting 00:26:09 emilio: to restate, this was about making AccentColor and AccentColorText react to accent-color property 00:26:33 emilio: some concern about them resolving at computed value time making it harder to not expose the system color from OS 00:26:39 emilio: but as Florian said, no longer objecting on that basis 00:26:49 emilio: I think general consensus was, make these react to accent-color property 00:27:07 emilio: figure out a reasonable definition for what happens with color/currentColor/accent-color/AccentColor cycles 00:27:16 emilio: That's TBD, can sort out in a separate issue 00:27:36 emilio: I think we were working towards resolving like other system colors at computed value time 00:27:50 emilio: it's easier implementation-wise, and more sense if accent-color changes throughout the tree 00:28:05 fantasai: not sure about the resolving about the resolving at computed-value time 00:28:09 ... currentcolor doesn't do that 00:28:16 ... sympathetic to the impl complexity argument 00:28:34 emilio: I have a counter-example 00:28:47 emilio: all system colors go in pairs, right? Not talking about one keyword, but two 00:28:58 emilio: all system colors that go in pairs resolve early 00:29:08 emilio: changing the color could cause text to be unreadable 00:29:42 emilio: consider you have :root... { background: AccentColor; color: accentColorText; } 00:30:00 emilio: if you change the accent-color further down in the tree, then you can end up with text you can't read 00:30:12 q+ 00:30:32 fantasai: but that's the behavior of color: currentColor and such right? 00:30:46 emilio: but color is only one, there's no background / foreground concept 00:30:53 fantasai: right, but... 00:31:14 miriam: several questions 00:31:23 fantasai: if you set a color that works on a background, and then change it down the tree you can get unreadable text also 00:31:32 fantasai: so don't do that; same thing here. 00:31:40 miriam: maybe I wasn't following 00:31:55 ... do these get set once at the root and then they stay through the document 00:32:16 ... or do they change (both?) when I change accent color 00:32:52 fantasai: what emilio is proposing is binding to the element you set them on and then they stay fixed 00:32:55 ack miriam 00:33:03 s/fixed/fixed as they inherit/ 00:33:07 ... alternative is to have them as keywords and let them change if accent-color changes 00:33:08 q+ 00:33:14 s/changes/changes in a descendant/ 00:33:21 miriam: but then you change accent color and it changes both? 00:33:39 fantasai: think we can resolve to do the easier thing (eager resolution) and come back if we hit a use cases that needs it 00:33:48 s/needs it/needs it late/ 00:34:27 emilio: I'm fine resolving; but if some concerns with resolving at computed value time then happy to ? 00:34:33 what about color-scheme and canvas/canvastext? 00:34:35 s/?/elaborate 00:35:03 emilio: canvas/CanvasText does eager resolution against color-scheme 00:35:46 kbabbitt: little confused because two keywords (accentcolor/accentcolortext) 00:35:54 ... the accent-color property influences accentcolor 00:35:55 yes, I also have @lea'a question above 00:35:58 ... what about accentcolortext 00:36:12 ... wouldn't that mess up the contrast 00:36:17 miriam, lea: those resolve at computed value time; emilio is proposing to match them essentially 00:36:38 emilio: same way accent-color affect background of checkbox, but also adjusts tickmark so you can still see it 00:36:44 emilio: you would do same with AccentColorText 00:36:47 emilio: ensures contrast between the two 00:37:01 fantasai - the question is about updating them in the document as the color-scheme changes 00:37:01 emilio: you can't specify the exact color of the checkmark, similar with AccentColorText 00:37:17 kbabbitt: what's the intended relationship between these two? 00:37:23 emilio: one is background other is foreground 00:37:49 miriam, the answer to that question is it binds at computed value time 00:38:05 emilio: AccentColor will be what you specify in accent-color 00:38:17 emilio: and AccentColorText will be the foreground color associated with that accent-color 00:38:32 q? 00:38:34 q+ 00:38:40 ack kbabbitt 00:38:45 emilio: I don't think there's a precise algorithm, but UAs do have one (that may or may not be fully interoperable but nonetheless ensures contrast) 00:39:44 lea: I thought we resolved on when do they resolve? 00:39:48 fantasai: didn't resolve on anything 00:39:53 lea: what are we discussing? 00:40:21 ... my understanding was that the primary objection was florian 00:40:36 ... did miriam ask about canvas/canvastext 00:40:46 fantasai: yeah 00:40:53 lea: is the proposal to do the same for these? 00:40:55 fantasai: yeah 00:41:00 lea: why not doing that? 00:41:05 fantasai: we haven't concluded yet 00:41:07 lea: why not? 00:41:11 ack lea 00:41:43 PROPOSED: AccentColor takes its value from accent-color, and AccentColorText takes its value from the appropriately contrasting foreground color for AccentColor; these resolve at computed value time 00:42:38 RESOLVED: AccentColor takes its value from accent-color, and AccentColorText takes its value from the appropriately contrasting foreground color for AccentColor; these resolve at computed value time 00:43:06 topic: https://github.com/w3c/csswg-drafts/issues/10746 00:43:13 github-bot: take up https://github.com/w3c/csswg-drafts/issues/10746 00:43:13 Topic: [selectors] Shouldn't there be a pseudo selector for `:unchecked` inputs? 00:43:13 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10746. 00:44:02 fantasai: proposal to have :unchecked, parallel to :checked and :indeterminate 00:44:17 ... parallel to other pseudos like :enabled/:disabled 00:44:25 ... apparently this one is the only one that doesn't have it 00:44:29 ... proposal is to add it 00:44:31 ethanjv has joined #css 00:44:52 Rossen9: so when does this match? 00:45:17 fantasai: when it can be checked but isn't 00:45:18 q+ 00:45:28 ack emilio 00:45:47 fantasai: e.g. div:not(:checked) matches but div:unchecked doesn't 00:45:54 emilio: is it exclusive with :indeterminate? 00:45:57 fantasai: yes 00:46:23 fantasai: because indeterminate means it's not checked or unchecked 00:46:37 dbaron: checked can match radio/input/option 00:46:54 rniwa has joined #css 00:46:54 ... indeterminate can match radio/checkbox/progress 00:46:58 q+ 00:46:59 ... I assume this would match only the things checked might match? 00:47:03 fantasai: yes 00:47:05 https://html.spec.whatwg.org/multipage/semantics-other.html#selector-checked 00:47:15 ack kizu 00:47:19 kizu: in scroll-marker :checked was mentioned as something we'd match 00:47:26 ... should we have :unchecked too? 00:47:32 fantasai: I think we shouldn't have :checked for that 00:47:41 flackr: if we use :checked it probably should 00:47:52 :unchecked sounds good to me 00:48:45 PROPOSED: Define :unchecked for elements for which :checked applies, exclusive with :indeterminate 00:49:29 RESOLVED: Define :unchecked for elements for which :checked applies, exclusive with :indeterminate 00:50:13 Topic: [css-overflow-5] Bikeshed pseudoclasses for active scroll-marker 00:52:09 flackr: so in scroll-markers spec I used :checked, because it's a state that doesn't involve focus... but :checked is associated with form elements 00:52:11 +1 to `:current` 00:52:15 ... there was a suggestion to use `:current` 00:52:29 ... related to `:past` and `:future`, tab objected to that 00:52:41 -> https://github.com/flackr/carousel/issues/28#issue-2406219421 00:53:14 ... we can't use :active because things become :active while you interact with this 00:53:16 alisonmaher has joined #css 00:53:29 q+ 00:53:31 `:scroll-target`? 00:53:37 fantasai: fun historical link, on IE clicking a link to the same page would remain `:active` 00:53:49 flackr: so there's precedent for `:active`! 00:54:00 s/to the same page/to a target on the same page/ 00:54:05 `:active-anchor` 00:54:11 ack miriam 00:54:23 s/`:active`/`:active` as long as the browser was still targetting that ID/ 00:54:27 miriam: seems tab's objection to `:current` seems more about `:past` and `:future` 00:54:38 ... `current` matches what I'd use in JS which is aria-current 00:54:54 flackr: wouldn't mind `:current` 00:55:24 +1 to :current 00:55:35 fantasai: my only concern with current is possible conflict with a different meaning of `:current` 00:55:43 +1 to miriam 00:55:50 emilio: does any browser implement `:current` with any other meaning? 00:56:01 astearns, you asked to be reminded at this time to go home 00:56:09 (nobody knows) 00:56:19 emilio: Gecko doesn't at least 00:56:22 q? 00:56:46 flackr: another thing to think about is whether `:current` makes sense for all use cases 00:57:09 ... can't think of any, even if you use it for tabs, or scrolling content, or ???, `:current` feels right 00:57:21 s/???/slides 00:57:40 fantasai: current was designed to work as a styling for navigation or so for screen readers 00:57:44 ... currently used for captions 00:57:59 ... like the fact that it means the right thing 00:58:19 ... but if we did this and we ever wanted to do something like that then it'd conflict 00:58:58 flackr: should we try to resolve on `:current` for now? 00:59:10 fantasai: yeah I think `:current` is better than `:checked`, we can keep the issue open 00:59:38 astearns: reading MDN of the current use of `:current` it'd match the ancestor of the thing that's currently played 01:00:14 ... so if you style a marker with `:current` it'd pop out everywhere 01:00:14 dbaron: is it video or vtt? 01:00:16 astearns: vtt 01:00:22 emilio: isn't the vtt tree scoped? 01:00:31 fantasai: if it isn't it should 01:00:36 Rossen9: what's the issue with `:active`? 01:00:53 fantasai: while you're clicking on the button that's `:active` 01:01:03 ... don't mind reusing it but if you need that meaning... 01:01:29 flackr: that wouldn't work for the link version of scroll markers 01:01:53 fantasai: yeah you probably want something different then 01:02:01 s/style a marker/style a marker for a carousel tab that is currently playing a video/ 01:02:03 [jokes] 01:02:30 emilio: seems people thought `:current` is better than `:checked` 01:03:01 https://www.w3.org/TR/selectors-4/#time-pseudos 01:03:23 PROPOSED: `:current` > `:checked`, issue remains open while we look for better alternatives 01:03:50 RESOLVED: `:current` is better than `:checked`, issue remains open while we look for better alternatives 01:04:04 Topic: End of TPAC 2024 01:05:04 Zakim, end meeting 01:05:04 As of this point the attendees have been alisonmaher, kbabbitt, Rossen, futhark, oriol, ethanjv, dbaron, kizu, chrishtr, lea, noamr, miriam, sgill, ydaniv, rachelandrew, dholbert, 01:05:07 ... flackr, keithamus 01:05:07 RRSAgent, please draft minutes v2 01:05:09 I have made the request to generate https://www.w3.org/2024/09/27-css-minutes.html Zakim 01:05:15 I am happy to have been of service, Rossen9; please remember to excuse RRSAgent. Goodbye 01:05:15 Zakim has left #css 01:07:20 florian_irc has joined #css 01:34:11 projecto- has joined #css 01:34:42 leaverou_ has joined #css 01:35:42 Rossen- has joined #css 01:36:13 shans_ has joined #css 01:36:43 sylvaing_ has joined #css 02:09:17 florian_irc has joined #css 02:11:49 zrhoffman1 has joined #css 02:12:15 florian_irc has joined #css 02:25:36 zrhoffman has joined #css 02:26:37 florian_irc has joined #css 02:40:27 florian_irc has joined #css 03:08:21 Francis_Storr has joined #css 03:13:31 florian_irc has joined #css 04:48:06 nigel has joined #css 05:12:27 nigel_ has joined #css 05:24:03 nigel has joined #css 05:24:25 nigel has joined #css 05:38:52 atrigent__ has joined #css 05:48:29 hypebea0 has joined #css 05:49:43 hypebea46 has joined #css 06:07:12 zrhoffman has joined #css 06:14:33 florian_irc has joined #css 06:39:31 hypebeatsmagazine has joined #css 07:40:23 jfkthame__ has joined #css 08:14:36 florian_irc has joined #css 08:40:47 florian_irc has joined #css 08:49:15 florian_irc has joined #css 10:25:06 florian_irc has joined #css 10:32:32 jfkthame__ has joined #css 12:00:26 florian_irc has joined #css 12:12:59 jfkthame__ has joined #css 13:35:31 jfkthame__ has joined #css 13:46:51 jfkthame__ has joined #css 15:13:01 hypebea21 has joined #css 15:35:49 florian_irc has joined #css 15:51:18 jfkthame__ has joined #css 15:57:14 florian_irc has joined #css 16:47:02 Francis_Storr has joined #css 16:52:16 hypebeatsmagazine has joined #css 16:52:21 jfkthame__ has joined #css 16:55:13 jfkthame__ has joined #css 17:57:53 tantek has joined #css 18:15:27 florian_irc has joined #css 18:18:34 jfkthame__ has joined #css 18:18:47 jfkthame_ has joined #css 18:18:49 florian__ has joined #css 18:22:13 floria___ has joined #css 19:01:33 florian_irc has joined #css 19:03:56 florian__ has joined #css 19:13:16 florian_irc has joined #css 19:13:38 florian_irc has joined #css 20:29:16 Francis_Storr has joined #css 21:43:53 jfkthame_ has joined #css 21:59:05 jfkthame_ has joined #css 00:49:17 hypebea72 has joined #css 01:28:24 projecto- has joined #css 01:28:54 leaverou_ has joined #css 01:29:55 Rossen- has joined #css 01:30:26 shans_ has joined #css 01:30:56 sylvaing_ has joined #css 01:32:19 hypebeatsmagazine has joined #css 02:03:48 fserb has joined #css 02:21:18 Francis_Storr has joined #css 03:23:28 Francis_Storr has joined #css 03:32:49 Francis_Storr has joined #css 04:26:09 Francis_Storr has joined #css 04:46:27 dholbert has joined #css 06:42:48 jfkthame_ has joined #css 08:16:06 jfkthame_ has joined #css 12:52:59 jfkthame_ has joined #css 13:50:23 hypebea78 has joined #css 14:31:10 jfkthame_ has joined #css 16:48:09 jfkthame_ has joined #css 18:20:31 jfkthame_ has joined #css 18:41:24 jfkthame__ has joined #css 19:50:01 jfkthame__ has joined #css 20:32:59 hypebeatsmagazine has joined #css 20:38:15 jfkthame__ has joined #css 02:14:39 Francis_Storr has joined #css 02:59:00 Francis_Storr has joined #css 07:11:32 jfkthame__ has joined #css 08:04:20 projecto- has joined #css 08:04:51 leaverou_ has joined #css 08:05:51 Rossen- has joined #css 08:06:22 shans_ has joined #css 08:06:52 sylvaing_ has joined #css 09:26:47 hypebea30 has joined #css 09:44:39 jfkthame__ has joined #css