09:17:38 RRSAgent has joined #css 09:17:38 logging to https://www.w3.org/2020/01/22-css-irc 09:17:40 RRSAgent, make logs Public 09:17:41 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 09:18:11 faceless2 has joined #css 09:18:11 jfkthame has joined #css 09:18:20 myles has joined #css 09:19:25 svillar has joined #css 09:19:35 present+ 09:19:42 present+ 09:20:04 jensimmons has joined #css 09:20:20 myles_ has joined #css 09:20:22 present+ 09:20:25 present+ 09:20:29 present+ 09:20:57 myles has joined #css 09:21:13 lajava has joined #css 09:21:23 present+ myles 09:21:27 present+ 09:21:49 present+ 09:23:08 present+ 09:23:08 antonp has joined #css 09:23:28 myles_ has joined #css 09:23:28 chris has joined #css 09:24:17 Meeting link: https://mit.webex.com/mit/j.php?MTID=mbd2daa665496d9390b3203930368e47b Meeting number: 641 825 399 Password: style Host key: 140047 09:24:32 stantonm has joined #css 09:24:56 Florian Rivoal, Invited Expert 09:25:03 François REMY, Invited Expert 09:25:04 Christian Biesinger, Google 09:25:09 L. David Baron, Mozilla 09:25:13 Emilio Cobos, Mozilla 09:25:18 Jonathan Kew, Mozilla 09:25:19 Oriol Brufau, Igalia 09:25:28 Manuel Rego, Igalia 09:25:30 Alan Stearns, Adobe 09:25:33 Cameron McCormack, Mozilla 09:25:40 Rachel Andrew, Fronteers 09:25:53 Stanton Marcum, Amazon 09:25:57 Tab Atkins, Google 09:26:02 Jen Simmons, Mozilla 09:26:03 Hiroshi Sakakibara, BPS 09:26:08 Koji Ishii, Google 09:26:32 Rossen__ has joined #css 09:26:42 present+ 09:26:42 faceless2_ has joined #css 09:26:47 Rossen Atanassov, Microsoft 09:26:51 present+ 09:27:03 Ian Kilpatrick, Google 09:27:06 present+ 09:27:16 Mike Bremford, BFO 09:27:20 Brian Kardell, Igalia and OpenJSF 09:27:35 Javier Fernandez, Igalia 09:27:38 Present+ 09:27:39 topic: VAlues and units round()/floor()/ceil()/mod() (tab) 09:28:17 TabAtkins: As we knew would probably happen, as we started suggesting math functions, people wanted more math functions 09:28:53 TabAtkins: problems in the past the prevented these, we have solved those - so this issue is specifically about adding round and mod functions - they are all similar under the hood 09:29:06 github: https://github.com/w3c/csswg-drafts/issues/2513 09:29:21 TabAtkins: the big question for me is whether we want to add these as 4 function names or 1 with a mode? 09:30:12 chrisl: which will people be most familliar with 09:31:17 TabAtkins: another concern is spelling, for me ceil or ciel is confusing to me - I suspect I am not the only one... my suggestion is we go with round function 09:31:30 TabAtkins: Any ideas, comments suggestions? 09:32:06 faceless2 has joined #css 09:32:31 TabAtkins writes on the blackboard: round(keyword? calc, calc, ...) 09:32:39 s/, ...// 09:32:43 TabAtkins: round(keyword?, calc, calc) -- the second being precision you want 09:33:10 leaverou: is there any precedent of having a single function like this in any language? 09:33:17 skk_ has joined #css 09:33:31 TabAtkins: we have several functions with optional keywords in css 09:33:49 leaverou: fair enough 09:34:01 Rossen__ has joined #css 09:34:17 chris has joined #css 09:34:24 present+ 09:34:34 rrsagent, here 09:34:34 See https://www.w3.org/2020/01/22-css-irc#T09-34-34 09:34:40 fremy: when does round function happen 09:35:22 TabAtkins: same time as all of the math functions 09:36:13 jensimmons: it seems like we asked this on twitter and we are now seeming to go against their express intent in this, admittedly non-scientific poll 09:36:14 alias sky ceiling 09:36:43 fantasai: people who come from a math/programming background get 'floor' and 'ceiling' but as someone coming new to programming you won't know that 09:36:55 myles has joined #css 09:36:58 myles: it's a math term 09:37:36 fantasai: i didn't learn it, I don't think a lot of us did. For discoverability of people who are not already familliar with these terms it is a better model 09:37:44 round-up | round-down | round-truncate 09:37:48 q? 09:38:10 leaverou: don't forget that there is limited value in asking people because they will always trend toward whatever they already know 09:38:29 rachelandrew: people will trend toward the simplest things 09:38:46 dbaron: is this proposal written in the issue? I didn't find it in these comments? 09:39:00 fremy: one of them was from amelia, I thin 09:39:08 s/thin/think 09:39:11 s/better model/better model, because all four functions that do almost the same thing with slight variations are under the same feature. With the 4 separate functions, you have to now that they exist, and it's harder to find them unless you already know their names/ 09:40:28 jensimmons: consistency in css is a strong argument 09:41:16 i/jensimmons/rossen?: Could bake the keywords into the function name, like round-up(), round-down(), etc./ 09:41:16 Rossen__: it sounds like we all are agreeing that one function with an optional keyword... 09:41:22 (uh, that’s not what I said.) I said — it makes sense to me what fantasai said, that it is basically one function / one feature — with several different ways to do it. 09:41:38 florian: I was just looking and ruby has this pattern actually, the one we're suggesting 09:41:44 you can get to 8 functions with up|down|towards-zero|away-from-zero|nearest-half-goes-up|nearest-half-goes-down|nearest-half-goes-away-from-zero|nearest-half-goes-towards-zero 09:41:52 https://ruby-doc.org/core-2.5.3/Float.html#method-i-round 09:42:10 Rossen__: prior art, agreement in the room, any objections 09:42:12 i/jensimmons/fantasai: There's no typing benefit to doing that, should just follow the CSS pattern we have in gradients, cross-fade(), etc. to put the keyword in the parens/ 09:42:18 and I think the comment pointed to was https://github.com/w3c/csswg-drafts/issues/2513#issuecomment-565736728 09:42:19 Rossen__: ok resolved 09:42:30 fremy has joined #css 09:43:03 RESOLVED: Adopt a round function with keywords detailing which behavior 09:43:58 TabAtkins: mod() same deal - it's similar to mod() anywhere else, but I suggest we don't match javascript here 09:44:17 myles: there is value in matching js here 09:44:18 Tab is suggesting that the sign of the result should match the sign of the second argument, not the first 09:44:31 ChrisL has joined #css 09:44:38 Present+ 09:44:54 TabAtkins: from what I can tell, most of the time people want the sign of the modulus, not the sign of the first arg 09:45:20 myles: I don't have a strong opinion, I think there is a strong case to match JavaScript though 09:45:31 Present+ 09:46:19 q? 09:46:22 TabAtkins: I feel mathematical mod is more sensible, how you probably learned in school - not as done in js as adopted from Java as adopted from C 09:46:40 jensimmons: I think matching JavaScript is valuable 09:47:17 +1 to jensimmons 09:47:45 Rossen__: breaking the relationship to JavaScript seem to be a bad default - people use JavaScript to create CSS 09:47:51 fantasai: what are the use cases for modding negative numbers? 09:48:26 dbaron: if I am imagining some step pattern or some kind of thing you would create here - it does seem like what TabAtkins is saying is going to be more natural 09:48:33 +1 09:48:42 stantonm has joined #css 09:49:01 TabAtkins: there seems to be good argument both ways 09:49:19 fantasai: I would lean toward dbaron argument 09:50:36 fantasai: people who use JS are going to be more comfortable mucking about with mod functions to get the behavior they want 09:50:49 I was arguing that if you're using mod() to generate step patterns or something like that, if we use the JS mod(), you'll have to be careful to avoid inputting negative numbers (or, as Tab said, using multiple-mod() workarounds for that). 09:51:02 s/both ways/both ways; and you can use mod + add + mod calc pattern to switch behaviors if needed/ 09:51:17 bkardell_: Lots of preprocessors have functions like this -- which do they have, does it matter? 09:51:37 TabAtkins: they don't seem to have an example 09:51:45 TabAtkins: they don't seem to have an example in sass 09:51:54 fantasai: but this way the people who are just trying to get their CSS to work don't have to try so hard 09:52:17 TabAtkins: just looking at the wikipedia page, you can see this problem demonstrated 09:53:00 TabAtkins: it's very easy to just accidentally go negative and then you will have broken code, whereas the way I am suggesting here you have to be more intentional about it 09:53:30 TabAtkins: good argument in general that matching js is good - but we have also agreed that it is maybe less intuitive 09:54:01 TabAtkins: what do we want to do? 09:54:20 Rossen__: straw poll for the initial thing, we can always change our minds 09:54:52 Rossen__: 1) align with js 2) align with 'math' 09:54:56 2 09:54:58 2 09:54:59 2 09:54:59 1 09:55:03 1 09:55:04 1 09:55:04 1 09:55:06 1 09:55:13 1 09:55:25 1 09:55:25 1 09:55:26 2 09:55:29 1 09:55:35 2 09:55:42 on behalf of dbaron — 2 09:55:49 myles: 1 09:55:54 tess: 1 09:56:14 bkardell_: 1 09:57:12 TabAtkins: 11 to 10, I think we have to leave this as an open issue 09:57:19 myles_ has joined #css 09:57:43 Rossen__: any objections to adding the mod() function with an open issue about....what it actually does? 09:57:43 i/TabAtkins/[various people have lost connectivity] 09:58:01 s/connectivity/connectivity; Tab runs an offline poll/ 09:58:16 skk has joined #css 09:58:22 fremy_ has joined #css 09:58:23 the vote in the room was 12 for Option 1 (align with JS) and 11 for Option 2 (align with math) 09:58:29 Rossen___ has joined #css 09:58:40 RESOLVED: add the mod function with an open issue about behavior 09:58:56 It was 11 against 11 of the people in the room; myles claimed to vote for Tess, but she wasn't here for the oral arguments :p 09:58:56 topic: sign() 09:59:10 faceless2_ has joined #css 10:00:23 TabAtkins: this one was opened by oriol, asking for Math.sign equivalent, the usecase presented is hacky, but sure, why not - it seems unobjectionable - I'm happy to add it... he notes you can actualy implement it yourself, it is even worse 10:00:24 github: https://github.com/w3c/csswg-drafts/issues/4673 10:00:33 myles_: should the sign of 1px be.... 10:00:51 heycam: it should return a number if we allow lengths 10:01:00 emilio: what about percentages? 10:01:20 TabAtkins: 50% should resolve to whatever that resolves to 10:01:43 bkardell_: in ..pixels 10:01:56 TabAtkins: in many cases, pixels, but whatever that resolves against 10:02:11 make calc(sign(1px)) == 1, because you usually use the result of sign() to multiply against other things 10:02:12 myles: you could always add non-numbers later 10:02:19 myles has joined #css 10:02:41 heycam: does css really support positive and negative values? 10:02:50 s/values/zeroes/ 10:02:54 chris has joined #css 10:02:58 q? 10:03:00 present+ 10:03:13 TabAtkins: in calc, yes - we use the js semantics -- once you exit the calc no... it can affect the infinity 10:03:13 TabAtkins: yes, but only inside of calc() 10:03:29 fantasai: I dont think you can parse one in? 10:04:06 dbaron: you can write an negative 0, but it is just 0 10:04:29 TabAtkins: if you produce a negative 0 as a result of the calc, you can have a negative 0 10:04:37 Rossen___: is there a use case for that? 10:04:47 TabAtkins: consistency with JavaScript? 10:04:57 Rossen___: so we _want_ that in this case? :) 10:05:35 TabAtkins: you can insert directly via typed om, actually 10:05:50 TabAtkins: anyone have an objection to sign() restricted to numbers only? 10:06:03 Rossen___: any objections? 10:06:26 cbiesinger: Tab explained you get negative zero by dividing by negative infinity, which you get by -1/0 10:06:27 RESOLVED: add the sign() function as described in the issue, restricted to numbers only 10:06:40 topic: the rest of the JS Math functions 10:07:02 TabAtkins: I went through all of the Math functions and reviewed for consistency... 10:07:17 github: https://github.com/w3c/csswg-drafts/issues/4688 10:07:43 TabAtkins: in the issue I listed out the functions and constants - I just dumped the object in chrome, I assume everyone has the same thing... 10:07:50 TabAtkins: I seprated them into categories 10:08:14 TabAtkins: a handfull of algebra stuff - abs, cube root 10:08:43 TabAtkins: you can do these yourself if you know how, but it's fine with me to just go ahead and match for parity/consistency 10:09:26 TabAtkins: low value, but reasonable 10:09:59 heycam: if we have this goal of 'if it is on the math object and there is no reason to not include it here'... it seems even more odd to me that round would devitate from this 10:10:25 TabAtkins: exact correspondance is not my goal, we already can't match exactly because we have to include precision 10:12:13 fantasai: If we aren't going for exact correspondance, we should maybe not add cube root 10:12:30 +1 for adding 'abs' and not adding 'cbrt' 10:12:30 +! 10:12:41 fantasai: I do think we should add abs() because people are unlikely to understand there is anothe way to do that, it's not as intuitive 10:12:58 s/cube root/cube root right now; if there's demand for it later, we can add it later/ 10:12:58 q? 10:13:21 dbaron: I think there is a small chance that it applies here, one reason some of the weird functions exist in JS might be because they can be made faster than the non-weird version 10:13:48 TabAtkins: is that an argument for doing it or not ? 10:14:02 dbaron: it might be an argument for someone to look into it 10:14:09 fantasai: you could optimize it anyway 10:14:17 dbaron: it would be harder 10:14:50 (oriol demonstrates math the scribe couldn't understand) 10:15:59 Oriol was pointing out that cbrt(-8) is -2 whereas pow(-8, 1/3) is NaN 10:16:33 And, particularly, fractions 1/N where N is odd are not representable exactly unless N is 1 or -1. 10:16:40 TabAtkins: next up - hyperbolic trig functions... I don't know use cases here in CSS? 10:17:04 TabAtkins: can skip this entire category unless someone needs to object? 10:17:35 fremy: if you have the exponent function you should be good 10:18:05 TabAtkins: next - the family of e related functions -- log(), log 2, log 10 10:18:31 in JavaScript it was like this - I suggest we just pass in instead of 2, 10 10:18:47 TabAtkins: log() is 2 argument with base defaulting to e 10:19:33 TabAtkins: suggesting we just add log() and possibly exp()? 10:19:54 fantasai: I think I agree with your basic take, I think we just do log() now and exp later 10:20:06 TabAtkins: next is rounding, we already discussed 10:20:16 Ah, Mercator projection drawing math uses asinh(). 10:20:18 TabAtkins: the last thing is constants... 10:21:01 TabAtkins: I can see you wanting to use some of these - Pi, E .. 10:21:42 TabAtkins: should we add these as single argument functions? it seems like there's a challenge with globally reserved keywords 10:21:47 TabAtkins: Would break animation-names of e and pi 10:21:54 heycam: can you not make it global, just in calc? 10:22:05 maybe make them ε and π (the greek letters) to avoid conflicts 10:22:08 TabAtkins: ... maybe, probably 10:22:14 +1 to heycam's suggestion 10:22:32 RossenTheReal: do we need them for now? 10:22:59 TabAtkins: no non-ascii things please 10:23:41 florian: keeping the parser non-breaking seems useful 10:24:13 fantasai: we have an intent to use them anywhere -- as long as it is not a great complication to the parser it seems like a win 10:24:27 could we add them in a function like const(pi)? 10:24:37 env(pi) 10:24:38 s/use them anywhere/add keywords to calc() someday anyway/ 10:24:38 TabAtkins: actually, the units thing is not a terrible idea 10:24:46 s/a win/a usability win/ 10:25:09 dbaron: one thing that is painful about e is its interaction with exponential notation 10:25:14 Tab there is responding to my /me joke to make pi and e be units 10:25:19 dbaron: we already support things like 1e 10:25:39 s/1e/1e1/ 10:25:56 dbaron: I saw a suggestion - what if we stuck these inside of some other function? 10:26:18 TabAtkins: we want this to be short is the counter argument I guess, but const is not bad 10:26:26 1e1e is pretty ugly (in terms of having pi and e be units) 10:26:46 myles: it could be math.e to match javascript 10:26:48 tantek_ has joined #css 10:26:52 fantasai: that would change the parser 10:27:42 TabAtkins: which of these 3 options do we like? 10:27:51 1. "e" and "pi" allowed in calc() as keywords 10:27:57 2. e() and pi() available everywhere 10:27:59 const(e) might be more clear than e for people reading others' code 10:28:06 3. const(e) and const(pi) available everywhere 10:28:29 2 10:28:32 1 10:28:39 1 10:28:40 3 10:28:50 Note that 1 allows calc(e) everywhere 10:29:16 could also be math(pi) rather than const(pi) 10:29:23 2 10:29:23 1 or 3 10:29:27 not 3 10:29:29 3 10:29:37 dbaron, let's take that as a variant of 3 10:29:38 `grid-template-layout: 100px 1fr calc(2pi);` 10:29:38 `grid-template-layout: 100px 1fr const(pi);` 10:29:39 `grid-template-layout: 100px 1fr pi();` 10:29:45 3 > 2 > 1 10:29:45 1 10:30:05 option 1: 13 votes 10:30:43 option 2: 3 10:31:00 oh I wanted to vote for 2 10:31:12 option 2: 2 10:31:16 option 3: 5 vites 10:31:51 TabAtkins: we will take the strawpoll as evidence for now and use option 1 10:32:04 `grid-template-layout: 100px 1fr calc(2*pi);` 10:32:18 Chris: This'll let us close the long-running issue that 'rad' is useless without pi? 10:32:20 TabAtkins: Yes 10:32:38 projector has joined #css 10:32:41 TabAtkins: final bits "stuff we probably don't want"... random ... seems impossible 10:33:08 Rossen has joined #css 10:33:09 TabAtkins: clz32 -- it's... complicated 10:33:15 myles: it's used in video codecs 10:33:23 TabAtkins: which you probably shouldn't be doing in css 10:33:31 tess: I love the idea of someone trying tho 10:33:38 shans has joined #css 10:33:43 TabAtkins: last one is imul() 10:34:09 sylvaing has joined #css 10:34:10 chris: what is that for even 10:34:20 TabAtkins: we don't want it 10:34:39 leaverou has joined #css 10:34:58 TabAtkins: pow with an e argument - I don't know if there is something here with speed 10:35:09 plinss_ has joined #css 10:35:15 fantasai: the pow function takes two args -- what if you give on? 10:35:17 fantasai: the pow function takes two args -- what if you give one? 10:35:29 TabAtkins: it would be invalid 10:35:46 fantasai: maybe we should make it consistent with others? 10:36:40 make second argument to pow optional, defaulting to 1 10:36:41 The other way to make it consistent is to not have the default arg for, log(), and add ln() 10:36:44 s/with others/with log by making it default to e/ 10:36:57 Notes that exp(x) == pow(e, x) 10:37:19 log(val, base), ln(val), pow(val, pow), exp(val) 10:37:28 TabAtkins: that isn't quite true to to precision (which CSS doesn't care about) 10:37:33 pow(foo) == pow(foo, 1) == foo 10:37:36 TabAtkins: but it's almost true! 10:38:14 dbaron: so is anyone going to be annyoed by log in css being math log and not console log 10:38:19 calculators I have known typically have a dedicated e^x key (=exp), although they also have x^y (=pow) 10:39:00 fantasai: do you have a different suggestion dbaron ? 10:39:09 dbaron: ln? 10:39:38 fantasai: for log of base 10? 10:39:53 RossenTheReal: any more comments or objections on adding these 5: abs, log, exp, and the two constants e and pi 10:40:11 s/constants/keyword constants/ 10:40:27 RESOLVED: add these 5 - abs, log, exp, and the two constants e and pi 10:41:19 github-bot, end topic 10:48:29 igalia has joined #css 10:53:39 new URL for calling into the meeting https://meetings.igalia.com/csswg 10:57:50 present+ 11:03:05 fremy has joined #css 11:04:30 ScribeNick: fremy 11:04:42 RossenTheReal has joined #css 11:06:35 Topic: Adding an infinity keyword 11:06:37 github, https://github.com/w3c/csswg-drafts/issues/4688 11:06:51 github-issue, https://github.com/w3c/csswg-drafts/issues/4688 11:06:51 github: https://github.com/w3c/csswg-drafts/issues/4688 11:06:56 TabAtkins: now that we have a precedent for "e" and "pi" 11:07:17 ... heycam mentioned it could be useful to add "infinity" 11:07:39 ... it's not useful per se, but it would allow us to serialize infinite values coming from TypedOM 11:07:49 ... instead of 1/0 11:07:57 TabAtkins: Anyone has opinions on this? 11:08:04 Tab also mentions 1px/0 and the newer option infinity*1px 11:08:06 oriol: could we add "NaN" too? 11:08:19 TabAtkins: do we need NaN to serialize to infinity 11:08:35 oriol: we currently we would need to serialize as 0/0 which is strange 11:09:14 TabAtkins: I don't think we have to serialize these values at will, only when we have that as the result of a computation 11:09:20 `grid-template-column: 1fr 1fr calc(infinity);` ?????? 11:09:35 TabAtkins: and we could say that NaN as a result of a computation is an infinity 11:09:45 s/could/already/ 11:10:26 heycam: Nothing to add, but yeah I find the current serialization annoying, and since we have this concept of values now, I'd like to use it 11:11:02 TabAtkins: Just realized TypedOM allows injecting NaN anywhere, so we might actually need to serialize NaN anywhere 11:11:12 TabAtkins: I'm then in favor of adding NaN as a keyword 11:11:18 `margin-left: calc(-1*infinity);` ??????? 11:11:33 transitions to infinity would be ...interesting 11:11:36 TabAtkins: (if we add any of them) 11:12:05 TabAtkins: to answer to leaverou, we can already do that, we just would need to write as a calc() right now 11:12:19 dbaron: Serialization would be lower case? 11:12:32 TabAtkins: yeah, I'd serialize lowercase 11:12:48 s/I'd/CSS would/ 11:12:50 TabAtkins: but we could do either way, no strong opinion 11:12:52 s/lowercase/lowercase by default/ 11:13:17 jensimmons: what capabilities are we adding by allowing these keywords? 11:13:27 z-index: -infinity 11:13:28 TabAtkins: none, you can already get those results today by doing computations 11:13:47 TabAtkins: (we clamp to the maximum value if we need to) 11:13:59 `margin-left: calc(-1*(1/0));` works today?? 11:14:06 TabAtkins: so, what's the room's feelings about this? 11:14:06 Yes it does 11:14:14 it's defined, in any case 11:15:03 chris: there are also people who want rational numbers, so outputting 1/0 as a returned value would give a bad precedent 11:15:14 -∞ 11:15:30 -oo 11:15:31 chris: negative infinity would have to require a space, correct? 11:15:47 RESOLVED: no non-ASCII in Core CSS 11:15:53 TabAtkins: yes, we would need to be careful, like usual for math in css 11:15:54 heycam++ 11:16:19 (the room seems to have too much fun) 11:16:32 TabAtkins: since nobody objected, let's resolve to add them 11:16:33 heycam, you need some negative letter-spacing there 11:16:43 could you list then explicitly in IRC? 11:16:52 RESOLVED: add infinity and nan as new css math constants 11:16:53 I thought I heard NaN or nand? 11:16:56 calc(infinity), calc(-infinity), and calc(nan) 11:17:45 -moz-infinity 11:17:54 myles: -infinity sounds odd 11:17:55 calc(negative-infinity) 11:18:03 -infinity-infinity 11:18:06 calc(-1*infinity) 11:18:10 TabAtkins: idents can start with dash 11:18:12 == 0? 11:18:27 dbaron: but usually it's for vendor prefixes 11:18:36 TabAtkins: (missed) 11:18:40 RossenTheReal: let's move on 11:18:42 Topic: Double precision math in calc() 11:18:46 github: https://github.com/w3c/csswg-drafts/issues/4551 11:19:01 https://twitter.com/starsandrobots/status/1199757377286754309 11:19:16 s/-infinity sounds odd/does - have to be followed by a digit in order to be classified as a negation? can we actually do -infinity without a parser change?/ 11:19:36 TabAtkins: somebody mentioned that you can use int precision in Blink to implement mod() 11:19:53 -1nfinity 11:20:00 TabAtkins: this is ridiculous, and I think it shouldn't work 11:20:11 dbaron: what is the consistency difference? 11:20:15 q+ 11:21:12 emilio: Firefox uses floats for everything, but Blink and Webkit use floats only when parsing and simplifying, but inside the math expression in use-value-time, it's float 11:21:54 s/use floats only/use doubles only/ 11:22:20 TabAtkins: In general, I agree that precision should be kept undefined if we can 11:22:27 lajava has joined #css 11:22:44 TabAtkins: but TypedOM will allow input any double, so I guess we already have that requirement 11:23:02 emilio: not really, right now we store as float inside the cssom, typedom is truncated 11:23:17 myles: also, we could also be able to used fixedpoint 11:23:26 TabAtkins: but not inside a calc() right? 11:23:34 myles: not right now, but I would like to keep the option 11:23:58 ack myles 11:23:58 myles: also, order of operations would need to be specified for the double-precision to make sense as a requirement 11:24:11 myles: and I'd like not to have to do this 11:24:23 ack dbaron 11:24:25 TabAtkins: based on the concensus in the room, it seems we want to reject this proposal 11:24:50 dbaron: note that we had compat issues in serialization as dbl vs floats 11:25:14 q+ to mention an upcoming float/double serialization issue 11:25:15 dbaron: specified values would be in float, but computed values were doubles, and that caused issues 11:26:03 dbaron: maybe these compat issues are not relevant in the current discussion, but it's interesting to note that if we do, we have 7 random digits at the end 11:26:12 chris: we also will have similar issues with colors 11:26:26 TabAtkins: we could specify that we also serialize in float space 11:26:38 TabAtkins: but myles also wanted to keep fixedpoint, so maybe not 11:26:43 because color() lab() lch() all use float 11:26:45 TabAtkins: but it's a tangent 11:26:50 (as I was talking through it I think I realized the issues I was remembering were about the problem that once you truncate something from double to float, you should never use double-based serialization code to serialize it because you'll then get 6 digits or so tacked on to the end) 11:26:59 TabAtkins: is there any objection to keep precision undefined for math? 11:27:03 RossenTheReal: any objection? 11:27:09 (no objection) 11:27:13 ack c 11:27:13 chris, you wanted to mention an upcoming float/double serialization issue 11:27:27 RESOLVED: Math precision in CSS is currently kept undefined 11:28:04 iank_: (Chrome could also investigate changing the parser to use floats, but it's not high in our priority list) 11:28:22 iank_: (right now, it depends on the class where we store it, sometimes a float, sometimes a double) 11:28:45 Topic: New viewport unit 11:28:47 github:https://github.com/w3c/csswg-drafts/issues/4329 11:29:01 jensimmons: we have discussed this before 11:29:19 jensimmons: we are trying to solve the issue on mobile where the viewport changes when you start scrolling 11:29:38 jensimmons: (as the bottom bar retracts) 11:30:16 jensimmons: you can work around this in javascript, but it's not possible to do in css 11:30:43 jensimmons: proposal also includes taking into account the appearance of the keyboard 11:31:41 florian: I think the top bar sometimes disappear as well in some OSes 11:31:53 jensimmons: ah, good point 11:32:03 jensimmons: and those things can keep changing 11:33:14 jensimmons: (also, similar to the issue with vw and scrollbars) 11:33:34 jensimmons: (maybe it's a different issue, but it's still good to keep it in mind) 11:34:10 jensimmons: I am afraid redefining vh/vw might be too late by now, because authors have corrections 11:34:45 jensimmons: sometimes we don't want things to resize as the viewport changes, too; we want everything to fit at start and that's it 11:35:23 jensimmons: so we should provide all the units to authors, and it's on them to take a look 11:35:29 jensimmons: at performance 11:35:52 florian: so, we would have a unit that would represent the initial containing block? 11:36:07 jensimmons: yes, this new unit would be static, and not change when the chrome changes 11:36:38 jensimmons: VHC would be the same but with the chrome maximized 11:36:51 q+ 11:36:52 jensimmons: but we could also use an environment variable 11:37:20 proposal summarized below: 11:37:24 11:37:35 https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-547551485 11:37:54 q+ 11:37:58 s//https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-547551485/ 11:38:12 dbaron: I just wanted to ask, do we want to talk about keyboards when we talk about maximized chrome? 11:38:25 jensimmons: I don't think so, it would only include the normal chrome 11:38:37 jensimmons: but an environment variable might be better to handle the keyboard case 11:38:44 RossenTheReal_ has joined #css 11:38:53 q? 11:38:58 dbaron, you wanted to ask if that includes virtual keyboards 11:39:00 ack dbaron 11:39:07 TabAtkins: most of the times, you don't want your footer to reduce space when the keyboard appears 11:39:15 TabAtkins: because content space is already tiny 11:39:27 jensimmons: but some things might want to snap etc... 11:39:48 my team's use case DOES want to get the reduced space. We want to position the input the keyboard is operating on to be right above the keyboard 11:39:59 iank_: for example, adding an additional keyboard row 11:40:30 dbaron: but switching keyboard would change the height of keyboards sometimes 11:40:45 iank_: and some settings can cause the number bar to appear or not above the letters 11:40:51 s/keyboard/keyboard (between English and Chinese)/ 11:40:59 s/settings/form input types/ 11:41:05 q+ 11:41:28 ack florian 11:41:38 florian: I am confused at the idea that the animation concept would work 11:41:50 florian: how do you switch between the values on scroll? 11:42:26 fantasai: yeah, I don't think that work in practice, because the units are not meant to change the value of the units as you scroll up and down 11:42:53 fantasai: because some units are used to compute font size etc and relayout during scroll sounds not great in general 11:43:16 fantasai: environment variables are better because it makes it more clear it's gonna change dynamicly 11:43:28 fantasai: but the units are useful for the static initial position case 11:43:39 for the minutes, there have been multiple call-outs thanking @frehner for the very clear issue opening and summaries 11:44:28 florian: I think that answers my question 11:44:40 florian: but if we have both, I don't think we need the other viewport units 11:44:42 q+ 11:44:43 ack myles 11:44:55 myles: I think I might repeat a bit but I do agree the two units don't work 11:45:04 myles: so we add the dynamic thing 11:45:17 myles: but then why do we need the second unit we currently dont have? 11:45:59 q+ 11:46:02 fantasai: the reason I think we should have two units, is that the env() variables will be dynamic, but the other ones would not, and allow ... 11:46:18 ... to use the concept of minimalized and maximalized chrome in layouts 11:46:39 s/not great in general/not great for users, and also not great for performance/not great for users, or for performance/ 11:46:51 q? 11:47:09 florian: an article for the top banner which try to cover the screen as you open the site 11:47:22 florian: but you don't want that banner to resize when you scroll or open a keyboard 11:47:33 florian: and you can't solve that with the env() and the one unit 11:48:09 fantasai: within an article, you can have graphs or images which you want to size in function of the viewport, but you dont want their size to change as you scroll 11:48:20 TabAtkins: I strongly agree that we can use both 11:48:36 TabAtkins: I would have objected to only add the static ones, but if we have both I am fine 11:48:47 fantasai: we don't have a high demand for the keyboard one in general 11:48:56 fantasai: and we can't know in advance the size of the keyboard 11:49:08 ack TabAtkins 11:49:12 fantasai: so I think that use case should only be covered by the dynamic env() unit 11:49:35 jfkthame: should we think about privacy 11:49:42 fremy: we already have that info exposed via JS 11:50:06 s/privacy/privacy effects of exposing the size of the keyboard/ 11:50:08 jfkthame: (because the height of the keyboard might reveal what language the user speaks) 11:50:11 ack jfkthame 11:50:13 q+ 11:50:33 myles: we could also solve all of this with javascript 11:50:54 myles: with an event that say "the chrome is stable now, do yourcomputations now" 11:51:13 ack myles 11:51:18 myles: also I would like to note that this will have implications for the webkit framework as multiple browsers have to expose this to us 11:51:18 q+ 11:51:25 myles: (which is unfortunate) 11:51:39 ack bkardell_ 11:51:44 bkardell_: I'm not entirely clear on what the static thing brings, can someone resummarize? 11:51:52 s/could also solve/already can solve/ 11:51:54 TabAtkins: vh is the full height, never reduce 11:52:06 TabAtkins: vhc would be the same, but without the bars 11:52:15 bkardell_: the vh unit does change 11:52:26 jensimmons: only if the window is resized, but not as you scroll 11:52:43 q? 11:52:45 bkardell_: but, you agree they are not purely static, right? 11:52:50 q+ 11:53:00 jensimmons: yes, but what we mean by static, is that it's static as you scroll 11:53:21 jensimmons: it changes when we need to relayout everything 11:53:40 jensimmons: but it doesn't change otherwise 11:54:02 myles: comment about vhc not being useful for one example jensimmons showed on the powerpoint 11:54:14 jensimmons: good question; both use cases could be fine for designers 11:54:25 jensimmons: but at least on desktop vh and vhc it seems the units would always match 11:54:36 q? 11:55:11 example: https://labs.jensimmons.com/2016/examples/coversheet-2.html 11:55:42 jensimmons shows an example of a page with a large photo taking up the viewport on load, below it is the rest of the article 11:55:54 The goal is to see the entire photo, and just below the fold the article 11:56:01 scrolling should not change the size of anything on the page, just scrol 11:56:13 q? 11:56:21 q+ 11:56:44 If the smaller measurement was used, part of the article would show above the fold 11:56:47 This might not be wanted 11:56:59 s/fold/fold when the bottom bar is retracted/ 11:57:20 but on the other hand, if important info was aligned to the bottom, the author might want to make sure it's always visible 11:57:33 so using the larger measurement (for retracted bars) would be a problem 11:57:55 RossenTheReal_: let's timebox this for another ten minutes 11:58:09 florian: I think there is another layer of complexity in this story 11:58:22 florian: at least in the keyboard case 11:58:33 florian: what if the keyboard is semi-transparent above the content 11:58:48 RossenTheReal_: actually one of the things I wanted to mention 11:59:00 RossenTheReal_: we had a similar issue with Windows (8?) 11:59:15 RossenTheReal_: the keyboard would not change the appwindow size on the platform 11:59:33 RossenTheReal_: sometimes the keyboard was not even transparent, it occluded the app 11:59:57 RossenTheReal_: but we needed to animate the bottom bar of the app to stay above the keyboard 12:00:10 RossenTheReal_: and we had a special "position" value to achieve that 12:00:27 RossenTheReal_: but I don't know if having the units would work, because it would be out of sync 12:00:47 florian: but we can have the value matches the keyboard all the time 12:00:56 florian: but maybe there are good use cases for both, I'm not sure 12:01:09 q+ 12:01:10 jensimmons: I don't think we want to debate this issue too much 12:01:20 jensimmons: I guess there are use cases for all 12:01:44 q? 12:01:46 ack florian 12:01:52 florian: thinking that there are two variants of the right case, one where the keyboard is on top, the other when it's reduced 12:02:19 jensimmons: I understand but what a viewport means from the implementer is their question 12:02:41 jensimmons: but for the point of view of the author, it's about to design an experience, and the question authors have in mind is not this detail 12:03:04 florian: but if you want to coordinate static positions, it's difficult because things would get out of sync 12:03:38 dbaron: a good point TabAtkins outlined before is: are there actually use cases to size things based on the space that would be left after the keyboard 12:03:45 dbaron: but when the keyboard is there 12:04:09 dbaron: and I suspect that this might be right, we don't need to worry about hypotheticals about the keyboard 12:04:22 dbaron: as long as you can react as the keyboard opens 12:04:29 s/after the keyboard/after the keyboard is added/ 12:04:34 s/is there/is not there/ 12:04:38 +1 to dbaron 12:04:45 emilio: fixed position elements used to respond to the keyboard 12:04:52 emilio: and that had complications very soon 12:05:08 emilio: do we want env() units to have the same issues? 12:05:16 RossenTheReal_: you mean visual vs .... viewport? 12:05:23 q? 12:05:23 TabAtkins: I suppose we want visual 12:05:36 ack myles 12:05:42 Specifically, I think we want this height to match the height of a fixpos with top:0; bottom:0; 12:05:59 myles: one note is that I'd want to warn against trying to chase how browsers work today, because that might change in the future 12:06:31 myles: when we tried to ship to disappearing bars, we realized there are some problems, and we might fix them at some point 12:06:48 myles: I'm not sure we want to have a specific value for each of the iterations we ended up with along the way 12:07:09 s/browsers work today/browser chrome works today/ 12:07:11 ack jensimmons 12:07:13 jensimmons: fantasai said we might want two env() variables, what are they? 12:07:39 s/might fix them/might want to fix them/ 12:07:54 fantasai: static: the bigger and the smaller; dynamic: one that's the current one between those two, and the other is what is actually available after the keyboard etc has been taken away 12:07:57 q+ 12:07:57 s/we ended up/the browser community ended up/ 12:08:08 fantasai: I think the keyboard case seems less urgent to solve 12:08:29 fantasai: so if we aren't sure what to do in this case, it's ok, but we just had to keep it in mind to choose the right framework 12:08:44 emilio: replying to tab about the visual viewport thing 12:08:56 emilio: part of the reason we don't update them is performance 12:09:04 emilio: and this would kill that performance optimization 12:09:39 emilio: if you want the visual viewport behavior (fixedpos-0-0) you also need a width unit 12:09:52 emilio: (because when you zoom you change that as well)( 12:10:01 ack emilio 12:10:18 jensimmons: it seems to me that we are talking about a vh unit that's a fixed unit based on the maximized space 12:10:29 jensimmons: vhc would be the minimize space, but also static 12:10:46 jensimmons: and the dynamic variable would be whatever it is right now, and yes that would would change 60fps possibly 12:10:58 q? 12:11:00 jensimmons: we will educate 12:11:07 Zakim, close queue 12:11:07 ok, RossenTheReal_, the speaker queue is closed 12:11:22 jensimmons: but maybe we can make a vhk unit to care about the keyboard later 12:11:35 jensimmons: "question mark, question mark, question mark" (just thinking out loud) 12:11:59 jensimmons: and then there might be another set which is, give me the space available 12:12:15 jensimmons: even if it's behind a keyboard (or not) 12:12:34 ack hober 12:12:55 hober: to reply to fantasai list of things, the values is orthogonal 12:13:12 hober: but for the use case to know about the keyboard, one of the use case it to add things above the keyboard 12:13:27 hober: and that usecase should probably be addressed in html and javascript, maybe not css 12:13:46 hober: for example, we thought about some way to add custom buttons for the touch bar in html/js 12:14:08 hober: and it seems a more natural fit than trying to emulate this with positioning with css 12:14:13 hober: so, is there another use case? 12:14:37 astearns: when the textbox is focused, move it right above the keyboard 12:14:44 fantasai: you can do that with scroll-snap 12:14:52 fantasai: because it will snap to the viewport 12:15:18 jensimmons: so, are you arguing it wouldnt be required to do this math with env variables 12:15:19 astearns: the grey beard seems kind of a give away of that though? 12:15:48 ack fantasai 12:16:20 fantasai: my proposal is the two static sizes (minimized/maximized chrome) and the dynamic one where you report the current size 12:16:36 fantasai: vh should probably be the maximized chrome (smaller measurement) 12:17:08 fantasai: because if people are designing on desktop, they might not realized that it could end up beyond the fold on mobile as you scroll 12:17:18 fantasai: it's not as pretty if you truly wanted to fit 12:17:30 TabAtkins: that's a change of behavior 12:17:47 fantasai: chrome folks said they would have loved to change, but webkit did the other way around 12:18:01 TabAtkins: that was a long time ago, I don't think we could switch without compat 12:18:10 fantasai: more breaking than we would fix? 12:18:12 hober: yes 12:18:48 jensimmons: I would like to come to a resolution with the three we seem to agree on, and leave the fourth one for later 12:19:02 hober: I'd be happy to reject the fourth one and reopen later 12:19:17 jensimmons: actually the issue doesn't cover the fourth one anyway, so not even needed 12:19:38 RossenTheReal_: so, are we reaching a consensus on the two static + one dynamic value? 12:19:45 jensimmons: I think so 12:20:25 fantasai: also, we would also need to add the symetric values for vhi and vhb 12:20:52 hober: I think the issue is that it would be a lot of similar units 12:21:01 hober: I'd rather something longer that's more clear 12:21:17 fantasai: yeah but that's unfair because vh is short, then if you want to write good code you need to write more 12:21:37 fantasai: for instance we already have some confusion with vmin 12:21:48 jensimmons: can we resolve on the concepts but not the name? 12:22:38 myles: rossen said that the symmetrical values would be needed, but in practice we wouldn't have different values in any browser 12:23:05 fantasai: the viewport units are vh, vw, vmin, vmax 12:23:17 fantasai: all of these can potentially map to vh 12:23:18 s/vmax/vmax, vi, vb/ 12:23:39 dbaron: I am not convinced that vmin needs this 12:23:44 fantasai: why would you exclude them 12:24:02 i/dbaron/ At that point, the only one that doesn't have this variant is vw, seems a bit odd to leave it out 12:24:07 s/vmin needs this/vmin and vmax need this new feature/ 12:24:13 RossenTheReal_: in tablet mode on windows, there are different chrome you can trigger when you swipe etc... 12:24:15 s/At that point/fantasai: At that point/ 12:24:21 RossenTheReal_: things like notifcation bars and whatnot 12:24:40 RossenTheReal_: in tablet mode, all of the windows are always maximized 12:24:56 RossenTheReal_: and the bars can appear on top of the content 12:25:14 RossenTheReal_: (but these bars haved fixed size value known in advance) 12:25:15 I think authors should be able to use these "safely-sized" viewport units with the same level of usability as the "unsafely-sized" viewport units 12:25:20 RossenTheReal_: so for us, vw sounds useful 12:25:47 emilio: if we don't want things that are sized with them to be affected by zoom 12:26:43 fantasai: the vh and the new unit and the initial containing block should all behave the same way 12:27:00 fantasai: whether the browser affect the all three the same way, they can do whatever they want 12:27:09 s/whether/as long as/ 12:27:30 RossenTheReal_: are we ready to make a resolution? 12:28:06 RossenTheReal_: can we resolve on the keyboard thing? 12:28:10 jensimmons: not necessary 12:28:28 RossenTheReal_: is there consensus on vhc? (besides the name) 12:28:45 fantasai: plus the variants 12:28:58 RossenTheReal_: plus the variants (vi/vb/...) 12:29:10 RossenTheReal_: any objection to this set of units? 12:29:30 dbaron: not counting scrollbars? 12:29:36 emilio: not counting scrollbars 12:29:58 RossenTheReal_: let's kick that can down the road, we can rediscuss later 12:30:06 RossenTheReal_: but I'm not hearing any objection 12:30:14 RossenTheReal_: so let's resolve 12:30:36 RESOLVE: adding the set of viewport units (vhc and symmetrical values) 12:31:50 RESOLVED: Add a set of viewport units (vhc for ex.) that reflect the size of the layout viewport less all UA UI 12:32:34 RossenTheReal_: the second question, do we need to provide the events / env variable that allows to transition between them 12:32:51 fantasai: I think the consensus was to have the dynamic full size 12:33:12 florian: we can also consider giving differences between the dynamic and full one 12:33:32 jensimmons: that's simpler to just say that env() variable is exactly like vh but it doesn't stay static 12:34:02 jensimmons: and the number is a live measurement of the space, instead of a difference 12:34:21 In hindsight, I think we'd have been better off if we'd called vmin vsmaller, and if we'd called vmax vlarger, or something like that. 12:34:53 florian: I don't disagree but I am unsure it answers my question, but ok let's move on 12:34:58 dbaron: yeah. 12:35:46 jensimmons: example of a use case where there is a footer on the side that needs to stay stuck on the bottom of the viewport, even as the user scrolls 12:35:56 jensimmons: (done in javascript right now) 12:36:06 jensimmons: and I think that use case is important 12:36:33 hober: it's a bummer that we have to do relayout during scroll 12:36:48 s/we have to/we'd have to/ 12:37:25 myles: there is an alternative that doesn't do that (myles to expand, didn't catch all things) 12:37:55 as long as there is an alternative that doesn't do layout on scroll, and this is named appropriately, and it is an opt-in mechanism, it's acceptable. 12:38:16 jensimmons: vh doesn't already change for performance 12:38:42 jensimmons: and that the new env() variable would only be used in cases where it's needed 12:38:48 jensimmons: so the perf impact would be lower 12:39:11 jensimmons: but I agree we need to enable authors to understand what they are doing so they use the unit only when they really need the animation 12:39:49 emilio: also, it's unfortunate because if you use it on the body because then you still need to relayout everything 12:39:58 RossenTheReal_: this example works with position:sticky 12:40:11 fantasai: this case yes, but it might not always be the case 12:41:14 fantasai: For example, maybe I have an effect where I click on a picture and it becomes the full size of the viewport, should be the size of the viewport right now 12:41:17 jensimmons: I am sure there are use cases 12:41:26 jensimmons: I could gather more evidence if needed 12:41:59 RossenTheReal_: I think we should probably get another example, but I think we should focus on answering the question at hand 12:42:27 RossenTheReal_: do we agree to add the dynamic unit? 12:42:52 jensimmons: We need to know if this is something we can implement 12:43:04 myles: yes, if you can do in js 12:43:20 q+ 12:43:29 hober: but it's really problematic that we would need to do layout in scrolling 12:43:38 hober: even if we add this, this would stay janky 12:43:38 http://inkedblade.net/viewport-test.html 12:43:43 q- 12:43:49 hober: so I don't think we should do this 12:44:04 hober: but we can have smooth perf with position:sticky 12:44:26 jensimmons: but there are other examples, if you need to the height to be considered 12:44:45 RossenTheReal_: there's position:fixed for that 12:44:50 emilio: yes 12:45:02 TabAtkins: but there are cases where you only want to show it in some context 12:45:10 TabAtkins: and position:fixed make it visible at all times 12:45:22 dbaron: does position:sticky help with that? 12:45:25 would it be useful to have a collection of use cases and allow the CSSWG to propose how you could do this today, and then let devs tell us why that doesn't suit their needs? 12:45:28 TabAtkins gives example of some widget which is not position fixed or sticky, and is compacted by default, but when expanded (in place) should take the size of the viewport 12:45:41 s/this would stay janky/this would be an attractive nusiance. the behavior would be just as janky as js./ 12:45:51 RossenTheReal_: also if you have a "fake fullscreen" where an experience takes the full size of the viewport 12:46:14 RossenTheReal_: and you might want to resize that experience as the user is scrolling, so it doesn't go out of bounds of the viewport 12:46:26 hober, this is why we're providing the units, and making them a lot more convenient to work with. vhc or whatever is a lot easier than env(viewport-height) unless you've got a strong reason for the latter 12:46:42 RossenTheReal_: you can of course do that with js, and we ask the question whether we want a better solution 12:46:57 btw, anyone with Safari mobile able to load http://inkedblade.net/viewport-test.html ? 12:47:02 RossenTheReal_: I think we should probably defer, and see more use cases 12:47:14 RossenTheReal_: except if we all agree 12:47:36 RossenTheReal_: but the points on perf and layout on scrolling remain 12:47:44 I see blue taller than yellow, fantasai 12:47:46 fantasai: I pasted a testcase 12:48:11 fantasai: there is no interop in a lot of cases 12:48:31 emilio: there is been a lot of effort from us to match Chrome/Safari 12:48:39 emilio: so I'm surprised we don't match 12:49:24 Safari also showing 100% and 100vh not being equivalent 12:49:28 RossenTheReal_: what is showing, I don't have a phone? 12:49:41 florian: 100% and 100vh don't always match 12:49:46 florian: in Chrome 12:49:58 RossenTheReal_: but that's for the previous discussion then? 12:50:22 It's an open point we need to resolve 12:50:25 q? 12:50:41 RossenTheReal_: let's get back on track 12:50:55 RossenTheReal_: can we resolve now, or do we want to defer? 12:51:56 jensimmons: I think we should think about this more 12:52:14 jensimmons: so let's table this for now 12:52:42 fantasai: also, I think we should have a discussion about the compat 12:53:00 fantasai: should 100% and 100vh match? 12:53:13 hober: I don't think we can resolve this 12:53:29 fantasai: the spec doesn't have a concept to allow them to diverge 12:53:52 hober: there is a lot of content designed for mobile 12:54:06 hober: and they rely on webkit/blink actually 12:54:14 fantasai: I would have loved implementations to file an issue 12:54:29 fantasai: because right now the spec doesn't match and we were not aware 12:54:50 +1 to annoyance at not getting an issue from (multiple!) devs breaking spec behavior 12:54:54 heycam: but since we aim to match gecko and blink/webkit, I think yes we would want to update the spec 12:55:18
12:55:29 github-bot, close topic 12:55:29 RossenTheReal_, Sorry, I don't understand that command. Try 'help'. 12:55:36 github-bot, end topic 13:07:18 plh has joined #css 13:10:55 dauwhe has joined #css 13:19:47 dauwhe has joined #css 13:22:57 reading up on the scrollback 13:23:34 re: "should 100% and 100vh match?" <-- was/is there a test case for this? 13:24:36 "I would have loved implementations to file an issue" <-- I'm guessing that if there was a test case, they would have, either in their own system for failing the test, or against CSS for having a bad test (that didn't produce the user/developer desired results) 13:25:29 astearns: re: "annoyance at not getting an issue from (multiple!) devs breaking spec behavior", if there's a test case, I agree with you, if not, then more annoyed at a spec change/behavior *without* a test case 13:29:15 good reason to insist more often on test-cases before spec changes are committed 13:36:18 jfkthame has joined #css 13:55:52 stantonm has joined #css 13:56:53 dauwhe has joined #css 14:04:09 fremy has joined #css 14:04:40 we're restarting, for people to call in https://meetings.igalia.com/csswg 14:04:48 Topic: publication 14:04:53 astearns: where are we with V&U? any issues? 14:05:00 TabAtkins: I want to do a publication 14:05:04 ... I'm editing in resolutions right now 14:05:06 ... so maybe in 2 weeks 14:05:15 Rossen: thought maybe we were ready, but that's fine 14:05:26 astearns: regular WD, let it settle, then go to CR? 14:05:32 fantasai: need people to read from top to bottom and review 14:05:56 Topic: summer meeting 14:06:03 astearns: do we have a date set? has Google reserved rooms? 14:06:19 Rossen: there's a date in the wiki 14:06:31 https://wiki.csswg.org/planning#upcoming-meetings 14:06:52 TabAtkins: Majid was organizing this 14:07:25 astearns: let's ping him, then come back later 14:08:07 my only request on meeting dates is to avoid July 27 (day after SF Marathon) 14:08:13 RossenF2F has joined #css 14:08:27 faceless2 has joined #css 14:08:30 I can add it to the wiki :P 14:09:06 Topic: Special case for inline-block+scroll-container elements needs to cover inline blocks that **contain** scroll containers 14:09:08 github: https://github.com/w3c/csswg-drafts/issues/3611 14:09:21 TabAtkins: not sure if this needs discussion, dholbert agreed 14:09:36 ScribeNick: heycam 14:09:49 TabAtkins: questions from dholbert was about baselines for inline-blocks in certain cases 14:10:17 ... the baseline export section, block containers, it says for legacy reasons [ ... ] the baseline is synthesized from the margin box 14:10:23 ... dholbert found this doesn't cover what browsers do today 14:10:31 ... there are some cases where it does look inside to elements for a baseline 14:10:44 ... we found a fix 14:11:42 ... rather than testing for inline block being a scroll container, change it to if it has a child that is a scroll container 14:11:49 iank_: should be any descendant 14:11:54 astearns: that's not what's in the issue though 14:12:23 here's the change https://github.com/w3c/csswg-drafts/commit/91af157d21c3323d031ce2537d8dfba632b099ca 14:12:27 TabAtkins: if the ineline block is a scroll container, it works properly 14:12:38 sorry, wrong changeset 14:12:42 ... but dholbert found if it contains a scroll container and nothing else, the only child, you still shouldn't look at that child for baseline info, just synthesize 14:13:07 ... we discovered that the condition is different -- some scrollable blocks still do influence the baseline 14:13:44 https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7695 14:13:47 fantasai: it should be the first in-flow item [...] 14:13:57 dbaron: only if the scroll container is block level 14:14:09 TabAtkins: scrollable flex boxes that are child of an inline block still give their baseline info 14:14:14 ... it's just block containers that hide themselves 14:14:21 ... inline blocks and blocks 14:14:42 emilio: in Gecko, the baseline of a scrolling box is synthesized from the margin box if the scrolled thing is block level, or you have contain layout 14:14:52 ... so I think there may be an easier way to define this 14:15:11 ... the scroll box synthesizing the baseline from the margin box, not by looking inside 14:15:40 dbaron: is your proposal the thing in the "13 days ago" comment 14:15:42 TabAtkins: yes 14:15:59 dbaron: my understanding is that this fixes it because it's fixing the recursive invocation of the same alg 14:16:01 ... think this makes sense 14:16:08 iank_: still applies for any arbitrary child? 14:17:25 iank_: I think this special scroll behavior is only executed in the inline block behavior 14:17:32 ... looking at the last baseline 14:17:46 TabAtkins: if anyone has any possible complications, please comment on the issue 14:17:59 https://drafts.csswg.org/css-align-3/#baseline-export 14:18:03 fantasai: I think the change we're planning to make would be in this section 14:18:06 dauwhe has joined #css 14:18:07 "However, for legacy reasons, if an inline-block is a scroll container or contains no in-flow line boxes, its first and last baseline sets are synthesized from its margin box." 14:18:16 fantasai: we'd say it has no baseline set 14:18:20 ... and that would trigger the appropriate behavior 14:18:33 iank_: if you have multiple children 14:18:49 ... two children, one scrollable container, then some text, you'd pick up the baseline from the text? 14:19:03 ... if it didn't have a baseline set? 14:19:14 fantasai: we're requesting the baseline of a box. if it says it doesn't have one, it'll synthesize 14:19:30 iank_: there's a subtle difference between synthesizing a baseline for a box vs something like providing a baseline 14:19:49 ... some things like tables inside of an atomic inline context, they don't synthesize a baseline and they get skipped for this calculation 14:19:56 ... but scrollable containers don't get skipped 14:20:22 fantasai: each formatting context says "this is how I find my baseline to export it out", and table will say my exported baseline is the first row or whatever 14:20:35 dauwhe has joined #css 14:20:40 ... but for block containers, it'll look at the first baseline, skipping tables etc., the next element that's there and ask it 14:20:52 iank_: the scrollable container the baseline is exports out is the block-end offset 14:21:25 iank_: when we enter into an atomic inline block, we set a bit on input saying "I need the last baseline since I'm in an atomic inline block" 14:21:30 ... and that triggers this special behavior 14:21:36 ... it propagates through block level block containers 14:21:45 fantasai: going forward we'll have an option to choose first or last baseline 14:21:46 iank_: that's fine 14:22:03 fantasai: I'll make a PR with some proposed text and we can go over it later 14:22:18 astearns: since this is a spec change should help match reality, can it come with tests? 14:22:19 TabAtkins: yes 14:23:03 Topic: Does stretch work when width/height only behaves as auto? 14:23:07 github: https://github.com/w3c/csswg-drafts/issues/4525 14:23:22 oriol: this is about grid items the default alignment is stretch 14:23:29 ... this is supposed to stretch an element to cover tis container 14:23:44 ... but not if the computed width computes to auto 14:23:51 ... the spec has some ambiguity about computing to auto 14:23:56 ... but it's "behaves" as auto 14:24:08 ... FIrefox thinks this is the case, and instead of checking the computed value being auto, it checks whether it behaves as auto 14:24:48 ... e.g. if you set the height to max-content it behaves as auto, in Firefox it stretches, but in Chromium it doesn't 14:25:05 q? 14:25:09 ... the question is whether if the width/height is set to a value that behaves as auto but isn't auto itself, does this stretch? 14:25:16 q+ 14:25:19 fantasai: I think the author did not want automatic behavior 14:25:25 ... in the most common behavior, automatic behavior is sizing to the content 14:25:26 Zakim, open queue 14:25:26 ok, RossenF2F, the speaker queue is open 14:25:36 ... in the context of grid and flex, auto isn't equivalent to that 14:25:49 ... if the author has set it to a value that's not auto, we shouldn't automatically stretch 14:26:06 ... I think the spec is correct to rely on computing to auto, so we should align on Chromium's behavior 14:26:11 TabAtkins: mats also says that sounds reasonable 14:26:53 is there a test case for Chromium's behavior? 14:27:04 emilio: it's a bit weird that it max-content behaves as auto for some things but not others 14:27:11 tantek_: 14:27:11 https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%23grid%20%7B%0A%20%20display%3A%20grid%3B%0A%20%20width%3A%20100px%3B%0A%20%20height%3A%20100px%3B%0A%20%20grid-template%3A%20100%25%20%2F%20100%25%3B%0A%20%20background%3A%20yellow%3B%0A%7D%0A%23item%20%7B%0A%20%20height%3A%20max-content%3B%0A%20%20align-self%3A%20stretch%3B%0A%20%20background%3A%20cyan%3B%0A%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%20id%3D%22grid%22%3E%0A 14:27:11 %20%20%3Cdiv%20id%3D%22item%22%3EText%3C%2Fdiv%3E%0A%3C%2Fdiv%3E 14:27:20 IRC broke that 14:27:23 across a line 14:27:27 yep, linked on the issue 14:27:34 at the begginig 14:27:37 https://github.com/w3c/csswg-drafts/issues/4525 14:27:41 thank you 14:27:43 RESOLUTION: Keep the spec text about auto and stretching that aligns with Chromium behavior, but add some clarification. 14:27:51 astearns: let's get that test case into WPT 14:27:54 s/RESOLUTION/RESOLVED? 14:27:58 s/RESOLUTION/RESOLVED/ 14:28:02 Topic: Center alignment can be improved 14:28:08 github: https://github.com/w3c/csswg-drafts/issues/4659 14:28:24 https://drafts.csswg.org/css-align/#abspos-sizing 14:28:40 TabAtkins: the diagram shows how alignment affects the available space for sizing static positioned abspos elements 14:28:49 ... you have the abspos containing block 14:28:57 ... you have the parent of the abspos (the static pos containing block) 14:29:00 ... and you have the abs pos child 14:29:08 ... it's statically positioned in the horiziontal axis 14:29:12 ... we look at justify-self for alignment 14:29:18 ... historically we had one rule to do this, based on direction 14:29:23 ... here we're letting you specify that manually 14:29:27 ... if start aligned, it does what you expect 14:29:40 ... the space to align into starts on the start edge where teh static position is, and goes to the end of the abspos containing block 14:29:47 ... it sits in ths same spot, but grows to where 0 would be 14:30:02 ... if you'are end, you do the opposite, growing to where left:0 would give you 14:30:06 fantasai: this is the behavior fro RTL text 14:30:16 TabAtkins: how do you do cetner? 14:30:28 ... previously the spec said you use this box [points to blackboard] 14:30:45 ... you can't get bigger than the abspos containing block, which is weird because the other alignments can 14:31:04 ... Ian's suggestion is to let it grow from both sides until one side would hit the edge of the abspos containing block 14:31:15 ... it's cnetered in the expected space, but gets as large as it can 14:31:20 iank_: this is EdgeHTML's behavior 14:31:32 ... we'll have this when we pick up our new flex impl 14:31:38 ... we've added some tentative tests 14:31:49 TabAtkins: nobody currently center aligns according to the current spec 14:32:07 ... I've edited this into the spec 14:32:21 dbaron: this is the width you end up with auto width 14:32:23 TabAtkins: if you have enough content 14:33:18 fantasai: fun side effect, this makes it possible to interpolate between all three values 14:33:22 ... since it's between the other two values 14:33:58 iank_: this fell out beacuse we were adding static center positions in our new arch, and this was the obvious thing that fell out 14:34:02 ... was relatively easy for us to do 14:34:12 dbaron: I didn't realise we implemented this section of the spec at all, I'm ok with this 14:34:30 cbiesinger: we only implement this for flex boxes? 14:34:36 iank_: we get the available size more wrong 14:34:43 cbiesinger: but we only do this if the parent is a flex box? 14:34:44 iank_: yes 14:34:49 ... only applies in implementations with flex boxes 14:34:56 dbaron: then it makes more sense to me that we implement it 14:35:04 ... because in theory this should be implemented for blocks too 14:35:46 ... as I've mentioned before, I'm worried we'll be unable to implement this for block 14:36:09 heycam: is Chrome implementing block alignment as part of your rewrite? 14:36:20 iank_: not currently. but the new arch does make it easier to implement 14:37:01 astearns: can you get into this situation with abs positioning as well? 14:37:03 iank_: I don't think so 14:38:10 astearns: given this was not well specified before, can you open bugs on impls to match the current text? 14:38:11 TabAtkins: sure 14:38:20 rego: so it applies in grid too? 14:38:31 TabAtkins: in all places that use this text, so flexbox, grid, and theoretically block 14:38:53 RESOLVED: Accept the text in current ED and open bugs on browsers to implement. 14:39:02 cbiesinger: can we add WPT tests? 14:39:11 iank_: I already have 14:39:12 tantek_, probably because folks go in/out of mic proximity 14:39:34 Topic: punt baseline alignment to L4 14:39:42 github: https://github.com/w3c/csswg-drafts/issues/4660 14:39:54 TabAtkins: we want to take Alignment to CR and further 14:40:06 ... it's a failr stable spec, tiny issues solved, except for baseline alignment 14:40:30 ... propose taking baseline alignment stuff out and moving it to L4 14:40:35 ... L3 will contain everything but that 14:40:40 ... then pursue L3 CR 14:41:01 fantasai: I think it's a bit odd since baseline was a very early feature in flexbox 14:41:04 ... and it is already implemented 14:41:10 ... but I won't object 14:41:34 ... there's some issue about baseline alignment vs intrinsic sizing not being adequately explained 14:42:34 florian: so remove the keyword from L3? 14:42:36 TabAtkins: yes 14:42:48 ... I don't see why we need to say anything about it in L3 if we also publish L4 14:43:05 fantasai: alternative is just take the whole thing to CR despite these issues 14:44:21 TabAtkins: flexbox L2 won't have the justify and align props 14:44:26 Main issue we're holding on is https://github.com/w3c/csswg-drafts/issues/1409 14:44:38 florian: if flexbox depends on L4, it's no worse than depending on the combined spec 14:44:42 Then there's also that baseline alignment section just eems to generate the majority of new issues 14:44:52 astearns: what do we gain from a L3 CR? 14:45:04 TabAtkins: process 14:45:13 astearns: and highlighting issues with flexbox relying on unresolved things? 14:45:21 florian: it's unfortunate but we have this problem 14:45:26 fantasai: most incoming issues are around baseline alignment 14:45:32 ... the other issue is the one dbaron raised 14:45:57 astearns: slightly more in favor of pushing out a CR of L3 14:46:04 ... since it replaces some parts of CSS2 14:46:19 fantasai: no because this is just replacing a small part of Chapter 10 14:46:26 a few sentences 14:46:29 here and there 14:46:39 any incremental replacement of CSS2 is a good thing 14:46:39 TabAtkins: but I would like to indicate that the rest of this is stable 14:46:53 fantasai: I would also suggest punting the legacy keyword out of L3 14:47:01 ... because it's defined but nobody's interested in implementing it 14:47:23 fantasai: if nobody's willing to hook this into the HTML features it's defined to help, I don't feel like proposing people implement it 14:47:30 TabAtkins: and they won't be doing it until these apply to block anyway 14:47:40 florian: so is it pushed to L4 or At Risk? 14:47:41 TabAtkins: L4 14:47:49 ... not a stable feature since we have no implementation experience 14:47:53 fantasai: or even idea of intent to implement 14:48:12 RESOLVED: Take the legacy and baseline keywords of CSS Alignment L3 and move them to L4 14:48:59 Topic: Snapping on both axes allows re-snap after layout to choose inconsistent snap targets 14:49:05 github: https://github.com/w3c/csswg-drafts/issues/4651 14:49:17 fantasai: this was an issue raised, there's 2 types of snapping when the document's layout changes 14:49:24 projector has joined #css 14:49:30 ... one type of snapping is find the element you were snapped to, and snap back to it 14:49:38 ... the other time is try to find something to snap to, and snap to it 14:49:48 ... sometimes you can have multiple elements that happen to snap at the same position 14:49:54 Rossen has joined #css 14:49:57 ... so when you're in a snapped position, it's not clear which you should re-snap to 14:50:01 ... if re-snapping is what you do 14:50:08 ... the suggestion was to define which element to re-snap to 14:50:13 ... I suggest leaving it to the UA 14:50:25 shans has joined #css 14:50:27 ... but we could say if it's the target element or has focus, we can suggest that 14:50:36 ... otherwise I don't have a good idea for a heuristic 14:50:55 sylvaing has joined #css 14:51:19 ... I don't want to disallow UAs to have the freedom to track which is the one currently snapped to 14:51:25 leaverou has joined #css 14:51:39 astearns: if we're going to have that suggestion, why not specify it? 14:51:53 fantasai: we can specify that aspect of the suggestion, but with no target/focus, I don't want to specify that 14:51:56 plinss_ has joined #css 14:52:26 astearns: I think it would be a good idea if someone would run into this issue if developing in a browser and they end up relying on the UA's choice 14:53:20 fantasai: [explains an example with a grid with multiple elements in columns, where each column matches the snap position] 14:53:42 florian: leaving it open for now doesn't prevent us from coming up with a heuristic later, or a new property to specify which to re-snap to 14:53:56 ... it's like we have an implied "auto" initial value of such a future property 14:54:02 ... where auto is UA dependent 14:54:06 Example is a 5-column grid of elements. We scroll down, snapping to each row as we go. The user stops scrolling, resizes the page. 14:54:33 It now has 2 columns 14:54:46 5 elements we were snapped to are now distributed across 3 columns 14:54:49 which one do we snap to? 14:55:15 astearns: proposal is to define beahvior with focused or targetted elements in the set of currently snapped to elements 14:55:42 myles: one piece is whether the browser picks an element and follows it, or if the browser should snap to something nearby 14:55:48 ... Q2 is if it's picking an element and following it 14:56:02 fantasai: spec currently requires that if you're snapped to an element, and layout changes, you follow it 14:56:11 ... problem is if there are multiple elements at the current scroll position 14:56:14 Similar question to scroll anchoring -- lots of heurstics involved, don't think we can specify exactly 14:56:17 myles: what's the reasoning for following? 14:56:32 TabAtkins: if you're snapped to it, and you rotate your phone, you probably want to follow it 14:56:39 fantasai: similar situation to scrolling anchoring, but you have more info available 14:57:21 heycam: interactions between scroll anchoring and scroll snapping? 14:57:30 fantasai: if it's a target, when you scroll to the target, you'll snap to it 14:57:45 ... similar to scrollIntoView, focus(), these should all trigger scroll snapping if it's defined on the element 14:58:44 heycam: what if one element is focused and the other is the target? 14:58:49 fantasai: probably leave it undefined 14:58:54 ... though focus seems more important 14:59:41 RESOLVED: Define what happens if you have multiple elements that could satisfy the scroll snapping re-snap situation and there is one that is focused or targeted. Otherwise leave it UA defined. 14:59:59 Topic: re-snapping after layout with animations 15:00:06 github: https://github.com/w3c/csswg-drafts/issues/4609 15:00:26 fantasai: re-snapping can be triggered in different cases 15:00:34 ... if you're snapped to an element, and the layout change 15:00:47 ... another one is a new snap position exists, or now you're in range of a snap position and you weren't before 15:01:08 ... scrolling is sometimes animated, sometimes not 15:01:16 ... there's a scroll-beahvior property that controls programmatic scroll animations 15:01:30 ... majid is saying that the scroll-behavior should probably also control the prgorammatic scroll behavior that's triggered by scroll snapping 15:01:42 ... and you might want to treat re-snapping to same elemetn differently from "not snapped, but not you're going to snap" 15:02:32 ... one proposal is to define that the snapped to a new element case be treated scrolling wise as the same as scrollIntoView() or focus() 15:02:42 ... and then therefore define that this should be subject to scroll-behavior 15:03:21 .. .the other thing w could do is to allow the UA do something different for the re-snap case 15:03:43 ... but in the case where you weren't snapped before, those cases should be animated in the same way scrollIntoView animates, and thus be subject to scroll-behavior 15:03:49 myles: why standardize this at all? why not say nothing? 15:04:03 TabAtkins: because Majid finds that the smooth scrolling behavior for the new snap position seems reasonable for the author to want to depend on 15:04:13 ... for the same reason scrolling to random things from JS be guaranteed smooth 15:04:28 fantasai: also clarifies interaction with scroll-behaviior 15:04:33 myles: how about the re-snapping behavior? 15:04:49 fantasai: I think we want to say something about it to make sure it's seen as distinct 15:05:39 ... we need to distinguish the re-snap case to be UA dependent so that scroll-behavior is not required to affect it 15:05:46 as a user I may want a more responsive UI and set all the scroll behaviors to 'instant' 15:05:59 like I want a way to turn-off cheesy animations 15:06:00 fantasai: don't feel the need to require not animating in that case, but should suggest it's possible 15:06:15 ... the goal of this re-snapping is to make the user feel that the layout changed but I didn't scroll 15:06:31 ... you don't want to animate to get back to where you were 15:06:37 myles: I think it depends how much of the viewport space the element takes up 15:07:01 ... if it's a small element, having most of what the user see jump to a different position would look jarring, but if the element covers most of the viewport, then jumping makes more sense 15:07:03 TabAtkins: that's reaosnable 15:07:14 ... as long as we distinguish it so that these cases are separate 15:07:25 s/more sense/more sense. So would prefer may rather than should/ 15:08:08 RESOLVED: Require smooth scrolling behavior when there is a new snap, but let UA decide when it's re-snapping to the same element. 15:08:26 Topic: Snap area trapping behavior of non scrollable elements 15:08:32 github: https://github.com/w3c/csswg-drafts/issues/4496 15:08:36 fantasai: snapping is on any descendant 15:08:48 ... currently spec says if scroll-snap-type is non-none, it normally only applies to the scroll container 15:09:11 ... but if you set it on a descendant element, it has the same affect as a scroll container in that snap areas in that box will no longer affect the ancestor scroll container 15:09:16 ... Majid points out this hasn't been implemented 15:09:31 ... this use case of wanting to trap any of these snap areas is already handeld by setting overflow to auto or hidden 15:09:40 ... which means we can remove this 15:09:49 fantasai: not convinced on requiriing overflow be set to do this 15:10:09 ... but we have the contain property, which likes to contain things, maybe you want contain layout on it -- and you might want contain:layout to trap snap areas 15:10:12 TabAtkins: yes it should 15:10:54 fantasai: if we're implementing the possibility of trapping snap areas via contain:layout, seems to make sense we maintain the ability to have this independent switch through the scroll-snap-type property 15:11:06 astearns: adding a value to scroll-snap-type? 15:11:11 TabAtkins: no, it's just any value other than none 15:11:49 TabAtkins: the idea would be there's not enough stuff depending on this not trapping 15:12:16 heycam: I kidn of find it weird to re-use scroll-snap-type for this different meaning 15:12:57 fantasai: you can think of it as scroll-snap-type always captures snaps 15:13:13 fantasai: this is already in the spec 15:13:32 ... we might want to consider re-tagging this issue against contain, so that we can make contain:layout do this snapturing 15:14:15 RossenF2F has joined #css 15:15:08 RESOLVED: No change to scroll-snap-type, but contain:layout must trap snaps. 15:15:35 Topic: What's the optimal viewing rect on the root scroller? 15:15:37 stantonm has joined #css 15:15:40 github: https://github.com/w3c/csswg-drafts/issues/4393 15:16:01 emilio: while working through some scroll anchoring issues 15:16:07 ... you need to decide what rect to anchor stuff to 15:16:14 ... Firefox uses visual viewport, I think Blink uses layout viewport 15:16:17 ... but are kind of reasonable 15:16:30 ... but for layout viewport, need to decide the effect of padding etc. 15:16:44 fantasai: my proposal is to use visual viewport, but that %s on the scroll-padding reference the layout viewport 15:16:49 s/of padding/of scroll-padding/ 15:16:56 ... that's where you're likely to block out content 15:17:16 TabAtkins: if we snap in the visual viewport, and you bring up the keyboard, it has to move? 15:17:29 jensimmons: it depends 15:17:33 fantasai: can leave that to the UA 15:17:39 TabAtkins: sounds complicated, but I think that's the best route 15:17:43 emilio: I think it's pretty reasonable 15:17:49 iank_: seems like David is fine with this change 15:18:11 fantasai: sounds like Blink is doing that 15:18:12 https://github.com/w3c/csswg-drafts/issues/4393#issuecomment-537844295 15:18:25 Rossen: currently using the layout viewport, but if you're zoomed in you're not snapped at all 15:18:38 iank_: but sounds like David Bokand is fine to switch to the visual viewport? 15:18:45 s/Bokand/Bokan/ 15:18:54 jensimmons has joined #css 15:19:35 RESOLVED: Use visual viewport for snapping and layout viewport for scroll-padding percentages. 15:19:37 jensimmons has joined #css 15:19:38 svillar has joined #css 15:19:48 Topic: Clarify which writing-mode is used for scroll-snap-align, scroll container or snap position element? 15:19:54 github: https://github.com/w3c/csswg-drafts/issues/3815 15:20:12 fantasai: already discussed what to do when you have a snapping element that has a different writing mode from the scroll container 15:20:23 ... snap to start edge -- the start edge of element being snapped or the scroll container? 15:20:52 ... my original argument was the WM of the scroll container, because when you're doing alignment in general, we always use the WM of the container, so that all elements witht he same start/end alignment are aligned in the same way 15:20:55 ... seems reasonable, consistent 15:21:00 ... the alignment container's WM 15:21:06 ... but then for snapping it makes a bit less sense 15:21:16 ... consider an unusual case, you have a scroll container that's ltr 15:21:28 ... inside there are a bunch of cards, text has articles in various languages 15:21:36 ... most are ltr, snapping on start edge will snap on the left 15:21:46 ... another is rtl, it'll also snap to the left edge 15:21:53 ... if they're smaller than the container that seems ok 15:22:09 ... but if the card is larger than the scroll port, then you'd end up snapping to the end of the content as the first thing the user sees 15:22:15 ... but you're trying to snap to the start of the content 15:22:25 ... so upon reflection it might make sense to use the WM of the element being snapped to 15:22:33 Rossen: only for non-orthogonal? 15:22:39 fantasai: similar case for orthogonal flows 15:22:51 fantasai: the "start' of the content, you'll end up scrolling to the end of thecontent 15:22:59 ... as long ast he content is smaller than the viewport, it's not a problem 15:23:16 Rossen: what happens in the the opposite case? when teh scroll port is larger than the item 15:23:23 fantasai: the behavior should be consistent 15:23:45 ... but ni terms of use cases, when the content is smaller than the scrollport, it's not a big usability problem to use the left or right edge 15:23:54 Rossen: my question is, let's say we have two items 15:23:58 ... first one is ltr, other is rtl 15:24:12 ... they're side by side, 1000px wide each, and weh ave a ivewport that's only 500px wide 15:24:28 ... if we're snapping to the start, the first plae we snap to is box A, which is ltr 15:24:40 ... the first child 15:24:43 ... that'll snap to the left 15:25:01 ... when you snap to the next one, it'll snap all the way to the right edge of the rtl element 15:25:21 ... say that there are many elements, and these two are still side by side, and you're doing a carousel kind of thing 15:25:28 ... every element is snapping to the start of teh scrollport 15:25:33 ... element A is going to snap to its left side 15:25:42 fantasai: the next one snaps to the right edge of element B 15:25:58 ... you're snappiong the right edge of B to the right edge of the scroll container 15:26:45 ... an important thing to think of is snapping because of focus/target, and if you target an entire section and it has a different WM and you snap to the end of that section, that's not good for usability 15:27:05 [blackboard drawing] 15:28:41 [general agreement of oddness] 15:29:03 astearns: could say you snap to the scroll container's start edge, unless the snap element's start edge is not in view, in which case you snap to the element's start edge 15:29:24 florian: or if the element and scroll port size are the same 15:29:27 Rossen: it's not terrible 15:30:07 Rossen: if the item fits entirely in the scroll container, it makes more sense to use the WM of the scroll container 15:30:26 ... if the inverse is true, and the items are larger than the scroll container, it makes more sense to use the item's WM 15:30:32 florian: and at the mid-point it's indistinguishable 15:30:43 jfkthame: still seems a bit weird if some are smaller and some that are bigger 15:30:47 Rossen: would it though? 15:31:00 ... the invariant here is that every time you snap to a start, you'll guarantee you can start readin 15:31:21 ... so if you have a collection that varies small and large, you can always snap to a snap that will guarantee that invariant 15:31:47 ... sometimes you will go past what could be considered the start item from the scroll container's perspective 15:32:16 jfkthame: what's troubling me is that for the items that are smaller than the container, their start is going to end up in the middle 15:32:59 fantasai: I don't think that happens 15:33:45 Rossen: I think this is the solution that guarantees you can start reading 15:34:00 ... it's more important to be able to see the start of the item than have the same alignment point 15:34:24 ... in the inverse case, it seems more appropriate that you snap in the direction of the container, so you don't have to jump 15:34:31 ... that would change the direction of the scroll 15:34:47 ... here you're preserving the direction of the scroll, you're just keeping that invariant that you can read the start of the item 15:35:00 fantasai: I can take an action to propose some text 15:35:09 AmeliaBR has joined #css 15:36:29 heycam: So if you have this element attachd to the scroller 15:36:46 heycam: and you start narrowing the browser window, it'll start attached to one edge, but end up attached to the other edge 15:38:08 fantasai: yes, but that's nice 15:38:19 s/that's nice/it is continuous/ 15:38:29 RESOLVED: Keep the previous resolution to snap to the container's start edge, except when the element is larger than the snap port, in which case we use the scroll edge of the element. 15:38:45 s/scroll edge/start edge/ 15:39:12 Topic: Number of layers in getComputedStyle results 15:39:17 github: https://github.com/w3c/csswg-drafts/issues/4135 15:39:26 fantasai: there's some inconsistency in how many layers we put in these properties 15:39:52 ... the suggestion is to take the computed value's list length 15:40:05 ... if you have a long list for background-image, but a short list for background-position 15:40:16 ... when you return getCS, do you use the original list length, or the number of images? 15:40:36 ... I think we should use the number of values specified 15:40:45 oriol: in Chromium, this information is lost in the computed style 15:40:55 ... inheriting onto children, the information is not inherited 15:41:05 TabAtkins: this is a Chrome bug 15:41:14 ... we should do the right thing and match Firefox here 15:41:29 fantasai: let's do that, and clarify the Backgrounds spec 15:41:34 ... which just says list, not how many items 15:41:40 file:///home/fantasai/w3c/csswg/css-backgrounds-3/Overview.html#background-repeat 15:41:43 ... so clarify to the specified number of items 15:41:48 Computed value: list, each item a pair of keywords, one per dimension 15:41:55 list -> "list of the specified number of items" 15:41:58 or something 15:42:14 list (of the number of items specified) 15:42:35 RESOLVED: Have the computed value of the background / image layer properties match the number of items in the specified value 15:42:40 dbaron: other properties? transitions 15:42:56 ... all of these cases are repeated lists where you key off one list to determine what happens 15:43:03 s/value/value of the property itself, not the reference property/ 15:43:03 ... but I think in all cases that is the right thing 15:43:56 dbaron: transitions used to have two different types of list repeating 15:43:59 TabAtkins: that's in V&U now 15:44:37 Not in Values. Values just as hhttps://drafts.csswg.org/css-values-4/#combining-values 15:46:00 https://drafts.csswg.org/web-animations-1/#animating-properties 15:46:03 Karen has joined #css 15:46:57 dbaron: backgrounds, masking, transitions, animations 15:47:03 ... sounds like the relevant list here 15:47:11 ACTION: fantasai fix animation types of CSS Backgrounds 15:47:22 RESOLVED: Apply the rule for computed value list length of background properties to all other similar list repeating properties like masking, transitions, animations. 15:47:40 Topic: background-size with " auto" and gradient image is not interoperably implemented 15:47:45 github: https://github.com/w3c/csswg-drafts/issues/2675 15:47:54 fantasai: proposal to resolve no change 15:48:00 ... there's some non-spec-compliant rendering 15:48:04 ... I don't think the spec is wrong 15:48:27 RESOLVED: Close no change. 15:48:46 Topic: remaining Backgrounds issues 15:48:51 fantasai: going through remaining open Backgrounds issues 15:49:02 https://github.com/w3c/csswg-drafts/issues/3742 15:49:15 ... one case involving some SVG edge case 15:49:19 ... another one about CSS keylogging 15:49:22 https://github.com/w3c/csswg-drafts/issues/2426 15:49:25 ... don't know what to do with that issue 15:50:31 TabAtkins: this is not even a Backgrounds-specific issue 15:50:40 astearns: there was pushback from Mozilla on taking the fix 15:51:22 AmeliaBR: worth mentioning that the issue here isn't specific to CSS, the problem is with JS frameworks that reflect the content of an input as an attribute that is constantly updated by JS 15:51:30 ... then CSS attribute selectors can expose that 15:51:37 ... there are many steps involved in creating this keylogger 15:51:43 ... not sure CSS is the weakest link 15:52:05 astearns: we can either close this issue no change, or we can make this issue be not a Backgrounds issue 15:52:17 ... lacking any idea to move forward, Im inclined to close 15:52:26 TabAtkins: fairly confident there's nothing we can do apart from eliminating attribute selectors 15:53:13 fremy: sounds like a framework bug 15:53:27 dbaron: in the past we have considered selectors that work on form control values 15:53:40 ... but you probably shouldn't be including untrusted CSS in your website 15:54:03 TabAtkins: I will write the rationale for closing 15:54:05 RESOLVED: Closed WONTFIX. 15:54:25 Topic: background-size at-risk 15:54:28 github: https://github.com/w3c/csswg-drafts/issues/3742 15:54:43 fantasai: this one weird case of SVG that doesn't have a size or aspect ratio 15:54:51 ... I don't think we should mark the entire property at risk for this 15:55:06 ... worst case, if it's the last thing blocking REC, we can make the case it's a bug that will some day get fixed 15:55:25 chris: are you saying it is correctly defined but implementations haven't implemented correctly? 15:55:27 fantasai: I believe so 15:55:42 chris: I'm prepared to argue to leave it then 15:56:14 RESOLVED: Close no change. 15:56:34 github-bot, end topic 15:56:45 I'd note we didn't tell github-bot to comment in https://github.com/w3c/csswg-drafts/issues/2426 15:59:08 thanks dbaron - I'll add that in manually 15:59:41 svillar has joined #css 16:01:16 or I see heycam already got to it 16:02:21 TabAtkins: fantasai Another possible backgrounds issue? I'm not sure the current serialization of is correct: https://github.com/w3c/csswg-drafts/issues/402 16:10:43 stantonm_ has joined #css 16:13:10 lajava has joined #css 16:17:05 smfr has joined #css 16:18:00 stantonm has joined #css 16:19:18 While y'all are on break, anyone else want to consider the CSS implications of this proposed law? https://www.golem.de/news/leistungsschutzrecht-memes-sollen-nur-noch-128-mal-128-pixel-gross-sein-2001-146101.html 16:19:31 is that device pixels or "physical" pixels? 16:20:11 also wouldn't a 128x128 limit on gifts just lead to table of sliced gifs generators? 16:20:22 s/gifts/gifs 16:24:01 ScribeNick: TabAtkins 16:24:36 Topic: vertical-align on orthogonal table cells 16:24:38 github: https://github.com/w3c/csswg-drafts/issues/4033 16:25:05 florian: If we have a table-cell which is orthogonal to the table, and you verticla-align it, what does that mean? 16:25:22 florian: "vertical" isn't a great word in the first place, but is it "vertical" in the table, or in the cell? 16:25:37 florian: Related, how does that interact with the justify/align properties that are also trying to shift the table cell contents? 16:26:07 fantasai: There are two types of properties here. *-self, which apply to the box itself in its context, and *-content, wich apply to the contents of the box relative to the box. 16:26:21 fantasai: vertical-align is like the *-content properties 16:26:40 fantasai: When we drafted up the Align spec, we said that "align-content: normal" looks up vertical-align and does what it says. 16:26:44 fantasai: (for table cells) 16:27:00 fantasai: That works as expected for non-orthogonal cells. But for orthogonal ones, which writing mode is it using? 16:27:41 fantasai: The *-content properties work in the container's writing mode (the table cell). But vertical-align probably applies in the table's writing mode. 16:28:14 fantasai: So we could say that vertical-align doesn't apply to orthogonal cells. 16:28:28 fantasai: Second is vertical-align applies when align-content is "normal" in the appropraite (table's) axis 16:29:10 fantasai: Third is that both align/justify-content is potentially affected by vertical-align: use the writing mode of the table to figure out which property on the table cell cares about vertical-align. 16:29:30 fremy: Third was the behavior of EdgeHTML. 16:29:43 fremy: vertical-align worked the same whether you had table cells or inline blocks. 16:30:05 fremy: In both cases it cared about the line's direction, not the items. 16:30:34 fremy: Complication with tables is just that, at the end, you have to alter the size of the cell to make them all the same height. But before that, the algorithm is identical to inline-blocks in a text line. 16:30:54 fremy: So based on that, I think it makes the most sense for v-a to work the same in both, applying in the axis of the line. 16:31:32 fremy: Downside is that you lose some control here; you can't necessarily apply the place-* keywords because vertical-align has already added magic padding to align things. 16:31:50 RossenF2F has joined #css 16:32:00 fremy: Possibility is that if you say "*-content: normal", you do the normal vertical-align stuff, but if you say any other keyword, vertical-align has no effect. 16:32:32 faceless2 has joined #css 16:33:08 florian: Initially I thought this was counter-intuitive, as v-a on table-cells doesn't *seem* to do the same as alignment; because of the extra padding added, it felt like it wasn't shifting boxes, it was shifting the content of the box. 16:33:30 florian: So if that's your model, you might think that it should align in the cell's writing mode, rotated relative ot the table. 16:34:12 florian: So it's a little counter-intuitive to me, but v-a is anyway, and the underlying model is sensible. So as long as we get *-content to actually work on table cells, you can achieve whatever result you wanted. 16:34:29 florian: If v-a was the only property we could use, we might want something different, but as the spec stands it seems okay. 16:34:52 dbaron: A lot of legacy table stuff maps into verticla-align or text-align depending on writing-mode. Does this cause them to ever act on the same axis? 16:35:04 fremy: I think so, yes, for any orthogonal cell. 16:35:48 florian: I think it's a problem that previously you used text-align and vertical-align to control everything, and having them always be perpendicular was good, but now we have the *-content properties which definitely are perpendicular. 16:36:11 dbaron: I think that's not *great*. 16:36:26 florian: v-a and t-a are already parallel for orthogonal inline-blocks 16:36:45 dbaron: They're a bit different because table-cells have a special behavior for vertical-align. 16:37:16 fremy: Using the *-content properties you get full control. The old properties didn't always give you full control anyway. 16:37:47 fantasai: I think dbaron's issue is valid. The model of vertical-align requires that the content is smaller than the table cell and you add padding. 16:38:02 fantasai: In text-align, you rely on the fact that the linebox fills the table cell. 16:38:19 fantasai: verticla-align doesn't have stretch, it aligns you to some spot, and only applies if the item is smaller than the container. 16:39:20 fantasai: So basically orthogonal cells won't be affected by vertical-aign at all, since the linebox will fill the full height. 16:39:52 TabAtkins: Yeah, I think that's what we expect actually. 16:40:43 florian: Another possible model is that the vertical-align applies first, then you vertical-align the tight bounding box of the text. 16:40:51 dbaron: Too many fundamental model changes for an edge case. 16:41:22 florian: So we're saying that text-align applies in the only axis it can possibly make sense, and vertical-align applies in the table's writing mode. 16:41:30 (parallel directions) 16:41:47 TabAtkins: So what happens today? 16:42:11 fremy: Orthogonal cells don't work at all in Chrome or Safari, EdgeHTML used the behavior we're discussing, and Firefox has broken sizing behavior. 16:42:13 If anyone else wants to look at current browser behavior, I made a test: https://codepen.io/AmeliaBR/pen/afcd79a788685ccee7892f733cc8251f Chromium currently ignores `writing-mode` on a `td`. Firefox supports them, though it's weird. It uses the table's definition of top/bottom for `vertical-align` 16:43:49 dbaron: So my preferred suggestion is that both v-a and t-a work on the cell's writing mode. 16:45:55 fremy: Either case is potentially weird. I think it's weird to not follow the same model as inline-block. 16:46:18 fremy: Maybe come up with a lot of examples and see what looks most reasonable? 16:46:31 florian: I think from an author point of view what dbaron proposed makes more sense. 16:46:33 smfr has joined #css 16:46:54 florian: You've still got the two properties, they jsut rotate 16:48:02 fremy: Still a difference - you'd have to redo row layout here, where in the "just stretch it" model you don't. 16:48:20 dbaron: You need to redo layout once you discover the final row height anyway, for %s. 16:48:56 florian: Every time I've used orthogonal table cells I've tripped over this, and wanted dbaron's behavior. 16:49:09 fremy: So if I do make that change, would anyone want to implement it? 16:49:26 dbaron: Which change? 16:49:42 fremy: That v-a and t-a both work in the cell's w-m, so you have to do a second layout pass. 16:50:00 dbaron: You do a second pass, and it can only increase the height. 16:50:05 fremy: yes 16:50:26 dbaron: In principle this seems reasonable, we have a bunch orthogonal cell bugs that haven't been a priority. 16:50:51 TabAtkins: I can volunteer Aleks to look at this, yeah 16:51:28 fantasai: the inline axis of an ortho cell is sized *after* the baseline alignment of the non-ortho cells in that row. 16:52:52 RESOLVED: vertical-align operates in the block-axis of the table cell 16:53:09 RESOLVED: the inline axis of an orthogonal table cell is sized *after* the baseline alignment of the non-orthogonal cells in that row 16:54:03 fremy has joined #css 16:54:25 Topic: Custom Origins 16:55:06 https://noti.st/jensimmons/QOEOYT/three-topics#srFUYHC 16:55:27 github: https://github.com/w3c/csswg-drafts/issues/4470 16:55:36 jensimmons: Possibility of custom cascade origins, controlled by authors. 16:55:52 jensimmons: Part of a larger convo, which could be called "modernize the cascade" 16:56:25 jensimmons: Why modernize? Some folks argue that specificity was designed for a simpler time, when one or a small number of people wrote the CSS for a site. Today CSS is maintained over years by large teams, and the cascade gets really hard. 16:56:42 jensimmons: If a dev gets a ticket, they can't really rearchitect the whole page's cascade to fix that one thing. 16:57:04 jensimmons: Lots of ways people attack this. 16:57:10 jensimmons: (1) just do it right the first time 16:57:18 jensimmons: (2) OOCSS, SMACSS, BEM, etc 16:57:33 jensimmons: (3) Only ever use one class, to give identical specificity and remove the cascade. 16:57:41 jensimmons: (4) overuse !important 16:57:59 jensimmons: (5) CSS-in-JS, ignoring cascade again 16:58:17 jensimmons: Problem there is no way to control order CSS is loaded. No wonder the cascade is confusing! 16:58:29 jensimmons: (6) just inline-style everything, screw selectors 16:58:37 jensimmons: Why not use specificiy as designed? 16:58:49 jensimmons: IDs increase specificity, but can only use it once per page 16:58:53 jensimmons: Not great for components. 16:59:12 jensimmons: Element selectors work well for simple defaults, but too dependent on doc structure, and hard to use otherwise. 16:59:23 jensimmons: So leaves a lot of these teams only using classes, attributes, and !important 16:59:28 jensimmons: [shows example] 16:59:42 jensimmons: [Tailwind CSS] 16:59:55 jensimmons: [everything's inline, with no cascade] 17:00:12 jensimmons: A lot of possible ideas here too, web components, scoping, etc. 17:00:22 jensimmons: A project I did last year is how to protect CSS from this hate. 17:00:50 jensimmons: So we put together a hard-core course on teaching the cascade. 17:01:00 jensimmons: Miri Suzanne did a deep dive into the history/etc. 17:01:16 jensimmons: She began thinking about how we could change CSS to modernize the cascade and work better. 17:01:24 jensimmons: One of her ideas is to extend selectors, in #4690. 17:01:35 https://github.com/w3c/csswg-drafts/issues/4690 17:01:53 jensimmons: Another idea is to allow authors to make custom cascade origins. 17:02:03 jensimmons: I didn't really know what a cascade origin was until Miri taught me. 17:02:15 jensimmons: [describes the cascade origins] 17:02:51 See https://www.w3.org/TR/css-cascade-4/#cascade-origin 17:04:11 jensimmons: Proposal is for custom origins. Say, create 3 named origins (get !important variants automatically that work as expected), and put styles in the chosen origin to get auto-overriding. 17:04:14 jensimmons: So use case. 17:04:27 jensimmons: Reset styles in one origin, design system in another, then one-off overrides into a third. 17:04:55 jensimmons: Or split apart the design system: reset -> defaults -> patterns > layouts -> components, all distinct origins. 17:05:23 q+ 17:05:26 jensimmons: Or CMS Core -> CMS Extensions -> Base theme -> site styles 17:05:57 jensimmons: Or a team trying to rewrite their CSS. Can't fix it all at once, but could put all their old code in one origin, and put their new code in a higher origin, to piecemeal fix it as they go. 17:06:49 jensimmons: Or Bootstrap -> 3rd party -> ad networks -> actual site styles 17:07:27 jensimmons: Adventages? 17:07:38 jensimmons: Coudl help with specificity wars between frameworks and author styles. 17:07:56 jensimmons: Could put !important back into its proper role, rather than being abused just to get a second origin. 17:08:19 jensimmons: Or just using origins as a type of !important; might be just as annoying? 17:08:30 jensimmons: Pulled some use-cases from Twitter (already mentioned) 17:08:41 jensimmons: So what do you think? Want to pursue? 17:09:11 q? 17:09:13 q+ 17:09:13 q+ 17:09:15 ack emilio 17:09:18 q- 17:09:22 emilio: I'm a bit confused abuot !important. 17:09:44 emilio: If you want ad networks on an origin, and your styles on a higher origin, the ad networks could still override everything with !important style. Maybe that's not what you want? 17:09:47 q+ 17:10:09 emilio: Second, it may be invalid, but IDs *can* be repeated on the page... 17:10:34 emilio: There are ways for authors to use cascading origins that have better behavior - web components. 17:11:04 fantasai: They're really hard to use 17:11:08 TabAtkins: And also won't handle these use cases 17:11:08 TabAtkins: WC doesn't solve any 0f Jen's use-cases, tho. 17:11:31 emilio: When we discussed custom element default styles behavior, Apple was strongly against. Unsure if the'd still have complaints. 17:11:37 i/emilio/iank_: We should add declarative shadow roots 17:11:43 hober: I'l talk to Ryosuke/Antii, see if they have feelings on this. 17:11:48 Though ++ to declarative shadow roots 17:11:49 ack florian 17:11:52 florian: I think it's a brilliant idea. 17:12:06 florian: We've had the luxury of multiple origins here in CSS, letting us design thru problems. Authors haven't had that. 17:12:24 florian: I think it would be great. Almost want to stop talking about whether or not to do it and jus tstart talking syntax. 17:12:36 florian: Even as a singl eauthoe this seems useful. 17:12:40 q+ 17:12:41 ack fantasai 17:12:45 fantasai: I always want to say I love it. 17:12:49 ack dbaron 17:12:50 dbaron: I'm also a big fan. 17:13:05 dbaron: There are multiple choices we coudl make about !important. 17:13:24 dbaron: Don't have to say they go in the opposite order. They could go in the same order, or be configurable, etc. 17:13:40 +1 17:13:40 dbaron: Maybe have the !important right after the normal origin. 17:13:54 essentially an origin can encapsulate its !important level 17:14:00 dbaron: So lots of options we could choose between, or let authors configure. 17:14:00 +1 to dbaron says. Definitely don't want !important to automatically do reverse order. 17:14:13 fantasai: Along those lines, might have an origin with sub-origins. 17:14:32 q+ 17:14:35 fantasai: Which might have its !important held within the larger origin 17:14:39 ack bkardell_ 17:14:49 bkardell_: First, thanks for bringing it up. 17:14:49 q+ 17:14:58 bkardell_: I've had these same conversations and I think this is really healthy. 17:15:07 Examples (from slide 25): 17:15:07 Reset < Design System < Overrides 17:15:07 Reset < Defaults < Patterns < Layouts < Components 17:15:07 CMS Core < CMS Extend < Base Theme < Site Styles 17:15:08 Old Styles < New Styles 17:15:09 q- 17:15:09 Bootstrap < 3rd-party libs < Ad network < Site Styles 17:15:10 bkardell_: To discuss what people are actually doing, rather than just relying on education 17:15:33 bkardell_: I think CSS-in-JS does have an order... 17:15:37 jensimmons: They can, but don't always 17:16:14 bkardell_: wrt WC, they don't solve all problems, but they do solve some. They're already .2% of the web archive, despite only getting the last impl this week. 17:16:52 bkardell_: Do we really rely on origin for UA level? I thought we kept them low speicficity. 17:17:15 TabAtkins: We don't use IDs, no, but we do freey use attribute selectors, which can easily clash if it wasn't for the origin difference. 17:17:17 slides (again): https://noti.st/jensimmons/QOEOYT/three-topics#srFUYHC 17:17:17 yes, we really rely on origin for UA level 17:17:52 bkardell_: I do believe we'r emissing something here. I don't know if this addresses or exacerbates the problem. At some level it addresses their complaints, but by doubling down on what they're complaining about. 17:17:56 jensimmons: Agree. 17:18:20 ack TabAtkins 17:18:20 Scribnick: fantasai 17:18:26 TabAtkins: I totally like this idea 17:18:34 TabAtkins: had similar thoughts, but never did the use case exploration 17:18:48 TabAtkins: Definitely agree we should pursue this, and the use cases made me absolutely sure we should pursue this 17:18:51 ScribeNick: TabAtkins 17:18:51 ack heycam 17:19:04 heycam: I think it's very important fo rus to try to address these problems. 17:19:20 heycam: A little of a shame that it's taken several years after people started complaining, biut glad we're addressing it now. 17:19:34 heycam: What I like about this is that it's so simple, and slots into the existing model. 17:19:48 q+ 17:20:03 heycam: Not super sure about whether it really will capture all of these use-cases, or might need more discussion with real proponents of CSS-in-JS to see how well it works. 17:20:12 q+ 17:20:17 heycam: I'd want to be more sure this is the right way to go for solving that. 17:20:21 heycam: But see th eother use-cases anyway. 17:20:39 astearns: I agree this is very nice it slots into our model, but a little concerned it's not the general author model. 17:20:53 astearns: You had to learn about the concept anyway. 17:21:17 astearns: So as Tess said, "origin" is an overloaded term, maybe we can come up with something else? 17:21:20 [various suggestions] 17:21:22 ack astearns 17:21:26 ack fantasai 17:21:41 "style sources"? 17:21:49 fantasai: Some discussion about this addressing all the cases; I don't think it does, biut it addresses quite a few, and addresses the organizational layer of many projects. 17:22:01 fantasai: So I think it fits well with how people put together their sites. 17:22:26 fantasai: There's other places in the cascade where specificity gets unwieldy. I don't think WC is great here; it adds a *ton* of encapsulation. 17:22:40 fantasai: Another proposal was scoped styles in CSS, which might also help. 17:22:56 q? 17:22:57 if we had this, would we need leaverou 's zero specificity pseudo still too? 17:22:58 fantasai: They let you say "within this sidebar, these styles win over other things". 17:23:41 s/things/things, regardless of specificity/ 17:24:05 TabAtkins: I think declarative shadow dom addresses a lot of the problems with WC; I'd like to explore that more seriously first before we add something that is 98% identical to WC's model, but with 2% weird differences that make impl complicated. 17:24:07 ack emilio 17:24:19 bkardell, you wouldn't need it for an entirely swath of styles, but would likely still be useful locally, for specific selectors or parts of selectors 17:24:33 q+ 17:24:36 emilio: I agree this is neat. Is there a concrete proposal? Is that at the stylesheet level, or allow 3rd party styles to choose their origin, etc? 17:24:46 emilio: Depending on details it might solve some use-cases but not vice-versa. 17:24:54 emilio: Also need to figure out how this interacts with shadow dom. 17:25:04 bkardell_: I believe so. This is great, but sometimes you need more fine-grained control. E.g. when theming *within* the same origin 17:25:08 emilio: Shadow DOM introduces a stack of origins; introducing this naively makes it a matrix, which is harder. 17:25:09 q? 17:25:29 ack AmeliaBR 17:25:57 AmeliaBR: echo Emilio's concern that we need details to see exactly how this sort of thing works. 17:26:40 AmeliaBR: Coming up with specific proposals and cross-reffing them with specific use-cases would be helpful. 17:26:54 AmeliaBR: So we should work from the use-cases to what features we actually need. 17:27:08 ack fantasai 17:27:29 fantasai: For "how do you control", an easy way to think of it would be the person importing the sytlesheet bea ble to say what level it imports at. 17:27:44 fantasai: And within each level, maybe you can have sub-ordering. 17:27:51 q+ 17:27:53 fantasai: And with a nesting block that lets you specify the layer within a single file. 17:28:25 fantasai: Using numbers to establish the ordering might work if there's only one controller; multiple controllers gives you the z-index wars. 17:28:42 q+ 17:28:46 emilio: My concern with nubmers or letting stylesheets choose their own levels becomes a z-index fight. 17:29:15 ack florian 17:29:39 florian: One thing I'm a little concerned is how we figure out the syntax to have a migration path toward this from legacy CSS.s 17:30:14 florian: In particular, a syntax ignorable by old browsers is bad because the cascade will be all mushed up; but making it hide rules from old browsers means they'll just miss a lot of code. 17:30:26 florian: Writing everything twice is bad, but not having an upgrade path is bad. 17:30:28 ack faceless2 17:30:32 ack faceless 17:30:53 faceless2: What if you had two toolkits, importing the same stylesheet at different levels? 17:31:10 zakim, close queue 17:31:10 ok, astearns, the speaker queue is closed 17:31:26 TabAtkins: Same as importing a style sheet twice, it's just present in both places 17:31:36 TabAtkins: cascades together; effectively later one wins 17:31:47 jensimmons: So got a lot of good issues and concerns. 17:32:08 +1 to talk about "this set of problems" for sure 17:32:16 jensimmons: I do think it's worth looking deeply at the solutions we might need for the complete set of problems, not just what this particular solution could address, so we can tell if this is a good idea in the totality of a complete solution. 17:32:56 jensimmons: I've even convinced myself that if we ship this today by itself, it could get abused pretty badly. 17:33:04 jensimmons: (similar to people abusing Flexbox to do grids) 17:33:18 jensimmons: Putting this on Twitter, I got a lot of trepidation from folks. Powerful tool, could be bad. 17:33:32 jensimmons: But I got that people who really knew CSS the most thought this was a terrific idea. 17:33:44 jensimmons: I think it does require some teaching, but it's not that complicated. 17:34:22 jensimmons: So I'm hearing a tentative "yeah, this is good", but I think there is a bigger metaproject to modernize the cascade. 17:34:46 jensimmons: Also, Miri has been very active in Sass to push CSS to be a featureful language; did crazy things with Sass variables back in the day. 17:34:54 jensimmons: So I'd like to invite her as an IE. 17:35:19 [intentionally not minuting] 17:36:29 fantasai: Where to put it? 17:37:15 TabAtkins: Suggest putting it in WICG until it gels, then merge it into Cascade 5. 17:37:19 i/fantasai/astearns: So sounds like interest in the room, try to move proposal forward/ 17:38:00 jensimmons: And I want to get some highly-skilled authors involved in the convo too, so hopefully WICG works there. 17:38:27 Topic: Summer meeting dates 17:39:49 I can't hear Rossen, but we now have conflicts both weeks of July 20 (AB meeting) and July 27 (Tantek doesn't want Monday, Rachel Andrew needs to be in UK by Friday) 17:40:30 https://wiki.csswg.org/planning 17:41:41 svillar has joined #css 17:41:52 If we move to the following week, FYI Monday Aug 3 is a holiday in Canada. 17:43:40 jensimmons has joined #css 17:44:19 proposal is Mon-Thu, week of July 27, Houdini on Monday 17:46:25 Topic: Path length in CSS 17:46:27 github: https://github.com/w3c/svgwg/issues/773 17:46:49 TabAtkins: SVG has a pathLength attr supported on 17:46:58 ... it allows you to override the length of the path 17:46:59 q+ 17:47:06 zakim, open queue 17:47:06 ok, astearns, the speaker queue is open 17:47:11 q+ 17:47:11 q+ AmeliaBR 17:47:12 ... allows you to set up e.g. exactly 100 dashes or such 17:47:31 ... otherwise you'd need to do a bunch of math or use JS 17:47:37 ... given you can set the path in CSS 17:47:53 Zakim, open queue 17:47:53 ok, RossenF2F, the speaker queue is open 17:47:54 ... it seems reasonable to let you set it in CSS as a property alongside d 17:48:08 ... in terms of signals, we got positive signals from WebKit and Blink 17:48:10 heycam: seems fine too 17:48:16 ack AmeliaBR 17:48:17 ack AmeliaBR 17:48:35 AmeliaBR: originally in svg1 it only had an effect on ``, in SVG2 it affects all shapes 17:48:41 ... I think implementation of that is pretty god 17:48:43 good* 17:48:52 ... but we don't have good implementation of what it actually does 17:49:04 ... so we do have some concerns on our last svgwg discussions 17:49:32 ... so want to followup with proper testing and ensure we have interop to deal with some patterns 17:49:41 ... but kind of a separate issue of whether it should be a pres attr 17:49:45 q+ 17:50:01 q+ 17:50:07 ... it makes sense to be consistent with the stroke properties and such 17:50:25 ... one complication is that this is the first time we use an attribute in mixed-case form 17:50:34 Karen has joined #css 17:50:34 ... recommendation is that it becomes hyphenated 17:50:44 ... and the mismatch will just be a legacy version 17:50:53 TabAtkins: that's my exact suggestion 17:51:05 ... and also that means that the style object gets the camel-case object, which is nice 17:51:10 ack emilio 17:51:19 emilio: Do we need to do something for stuff that takes a path function, like shapes and such? 17:51:39 TabAtkins: nothing else lets you go along the path 17:51:44 astearns: motion-path 17:51:57 TabAtkins: but that allows percents which provides this functionality 17:52:27 astearns: for shapes I could see using pathLength to short-circuit some stuff, but it doesn't seem a big use-case 17:52:38 TabAtkins: that's not how pathLength works, it just resets the length in the calculations 17:53:08 q? 17:53:39 myles: doesn't motion-path allow you to describe infinite-length paths or something like that? 17:53:55 TabAtkins: it allows you to define ray() but there's a definition for what 100% means 17:54:00 Motion path is one thing where distance along a path is relevant. That was one of the original uses in SVG (for the SMIL motion path) 17:54:03 zakim, close queue 17:54:03 ok, astearns, the speaker queue is closed 17:54:12 heycam: an alternative would be to allow percentages in stroke-dasharray/dashoffset 17:54:23 ... would make it similar to other CSS things 17:54:48 myles: so one of the nice things of path-length would be that you can animate it to have your dashes grow and stretch along the path 17:54:55 q+ 17:55:02 ... if you have a bunch of percentages you need to animate them individually 17:55:25 AmeliaBR: getting percents in stroke-dasharray would be nice, right now they're valid but don't have a useful interpretation 17:55:32 ... kinda separate from other use cases for path-length 17:56:06 faceless2: path-length is not only about dashes but also precise text positioning around a path 17:56:23 chris: the generating tools have an idea of how long the path is 17:56:39 ... and by setting it the implementation just agrees to scale it 17:56:45 astearns: objections to resolve? 17:57:13 RESOLVED: add path-length as a CSS property and make pathLength map to it 17:57:18 topic: end 18:00:54 Lea's LCH color picker https://css.land/lch/ 18:19:46 aja has joined #css 18:39:40 drousso has joined #css 18:50:20 Did we land for a date for Summer meeting. I had offline chat with dbaron and emilio and both are fine with evenly-spaced option in July. The previous date was July 20-23 but I understand it now has a conflict. 18:51:06 So did you all agree on July 27-30th? 19:00:39 drousso has joined #css 19:09:58 majidvp: Yes, the request was for "Mon-Thu, week of July 27, Houdini on Monday" if you can get use the room. 19:12:12 AmeliaBR: Thanks for the confirmation and for working to finalize the dates. I will confirm the facilities (should be safe) and respond to the email thread on this. 20:15:29 projector has joined #css 20:15:59 Rossen has joined #css 20:16:29 shans has joined #css 20:16:59 sylvaing has joined #css 20:17:30 leaverou has joined #css 20:18:00 plinss_ has joined #css 20:20:05 Zakim has left #css 21:26:20 drousso has joined #css 22:25:39 jfkthame has joined #css 22:36:33 jensimmons has joined #css 22:44:54 Zakim has joined #css 22:45:08 Zakim, end meeting 22:45:08 As of this point the attendees have been (no one) 22:45:10 RRSAgent, please draft minutes 22:45:10 I have made the request to generate https://www.w3.org/2020/01/22-css-minutes.html Zakim 22:45:14 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 22:45:18 Zakim has left #css 23:10:30 birtles has joined #css