15:53:45 RRSAgent has joined #css 15:53:45 logging to https://www.w3.org/2021/04/14-css-irc 15:53:47 RRSAgent, make logs Public 15:53:48 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:57:19 jfkthame has joined #css 15:58:20 oriol has joined #css 15:58:29 dael has joined #css 15:59:35 present+ 15:59:41 ScribeNick: dael 16:00:06 present+ 16:00:17 present+ 16:00:44 bradk has joined #css 16:00:45 astearns: Thanks to you all for coming in on time. We'll wait a few more minutes 16:01:14 Gottfried has joined #css 16:01:20 alisonmaher has joined #css 16:01:24 present+ 16:01:32 present+ 16:01:36 present+ 16:02:36 present+ 16:02:50 present+ 16:03:15 present+ 16:03:15 astearns: We're a little light but should start 16:03:19 present+ 16:03:21 Morgan has joined #css 16:03:26 astearns: Welcome felipeerias, thanks for joinnig 16:03:41 present+ 16:03:41 astearns: One change to the agenda, scrollbar topics, 6 & 7, will postpone to next week 16:03:49 astearns: Any other changes people would like to suggest? 16:04:08 smfr has joined #css 16:04:13 astearns: Housekeeping- miriam reminded me we had resolved to start work on the scoping proposal and to write spec text 16:04:17 present+ 16:04:26 astearns: Didn't decide where it should go. New draft? In a present draft? ThoughtS? 16:04:41 fantasai: @scope? 16:04:47 TabAtkins: Yeah. I think in scoping spec 16:04:55 fantasai: Or cascade 6. Might fit better there 16:05:11 TabAtkins: I don't think I agree. It's not directly about casade 16:05:14 sanketj has joined #css 16:05:26 present+ 16:05:38 fantasai: About specificity and which elements something applies to. People think in context of cascade and not in terms...scoping is all about shadow dom 16:05:51 TabAtkins: Didn't used to be. I think confusing if scope rule not in scoping specf 16:05:58 fantasai: fair. Then scoping next level 16:06:11 TabAtkins: Fine with it in current. Nothing pressing to scoping pass cr 16:06:29 fantasai: I'm not. I think what's in scoping is a lot more solid. Want a line between super experimental 16:06:31 present+ 16:06:35 astearns: scoping need update anyway? 16:06:44 fantasai: Yep. And it's mainly shadow dom which should be in cr 16:06:55 astearns: Argument to put in current so we have better chance to publish 16:07:17 fantasai: @scope rule should be newer draft. Current level should go to CR soon. We can always pub a FPWD of anything we want 16:07:36 s/soon/soon, and if there's anything blocking that we should be working on it/ 16:07:40 astearns: Prop: Add miriam as editor to next level of CSS Scoping and have them work up spec text in an ED which will become FPWD 16:07:43 astearns: Sound good? 16:07:50 miriam: Sounds great 16:07:57 Topic: [css-display] math/inline-math (whether display:math on a non-MathML context should be more inline or block) 16:08:07 github: https://github.com/w3c/csswg-drafts/issues/5385 16:08:32 astearns: Has been waiting on math people to weigh in. afaict all we need to deal with is display:math on non-MathML 16:08:32 present+ 16:08:36 fantasai: Decided it should be inline 16:08:53 dholbert has joined #css 16:08:59 present+ 16:09:05 fantasai: Issue from mozilla is having it behave different if in MathML context or not is not great. Not difficult to impl but more tricky b/c context sensitive. Not necessary for any reason. 16:09:21 fantasai: Mats asked for it to behave like em row regardless of if on math element or not 16:09:28 s/em row/mrow/ 16:09:41 emilio: and discussion of if need >1. Supposed to be magic depending on valid. If not might need more than one 16:09:52 s/valid/element/ 16:09:56 florian: Assume behavior of making it an em which doesn't contain math is well defined? 16:10:04 iank_: Yeah, triggers em row layout algo 16:10:08 s/em row/mrow/ 16:10:14 iank_: In simple terms layout things on a row and I think baseline align all 16:10:24 Gottfried has joined #css 16:10:43 iank_: I think mathml defines internal types fine. Sometimes mrow if it has more children than expected. 16:11:03 present+ 16:11:21 iank_: I think not having talked to the MathML people I htink I am supportive of adding each display type as FF folks suggest. Seems consistent with everything else. Would like to hear other thoughts. 16:11:29 iank_: Also works with polyfill story 16:11:47 fantasai: Two issue. One is display:math outside mathML is mrow behavior. Second is add more display types per mathML element 16:12:17 plinss: I think have precedent to jsut rely on display property. I would like to see all math in layout not rely on semantics 16:12:24 plinss: Have it default style 16:12:38 iank_: If you put display:grid on mrow it has an internal layout type of grid algo. Have consistency there 16:13:03 chris has joined #css 16:13:18 florian: Do we need to check with a11y people, a11y tree, to see if the way the build right now will break? My understanding is for some things they build from box rather than element tree. We should check. I don' tknow 16:13:27 florian: We've been accused of being careless about this in the past 16:13:36 florian: I hope it doesn't. In theory I support plinss 16:13:55 plinss: Agree worth investigating. Might justify a bug on AT. We can evaluate when we find out answers 16:14:02 present+ 16:14:08 astearns: Sounding like consensus to have display:math always behave as mrow 16:14:19 fantasai: Outside MathML context and unless otherwise specified 16:14:27 castastrophe has joined #css 16:14:36 present+ 16:14:36 astearns: Prop: have display:math behave as mrow and ping a11y to see if that's an issue 16:14:42 RESOLVED: have display:math behave as mrow and ping a11y to see if that's an issue 16:14:51 astearns: Separate issue for other math display types? 16:14:58 fantasai: I believe there is 16:15:11 astearns: Is there consensus to resolve that now or postpone to future meeting? 16:15:14 Topic: MathML individual display types 16:15:17 github: https://github.com/w3c/csswg-drafts/issues/5866 16:15:28 iank_: I would like to ask people more familiat with MathML 16:15:38 earlier discussion in https://www.w3.org/2021/04/14-css-irc 16:15:39 iank_: Does seem like consensus in this group 16:15:54 astearns: Dim recolection is mathML asked for the display types and we thought it too many 16:15:59 iank_: My recolection too. 16:16:02 s/we/Igalia folks/ 16:16:12 astearns: Math WG just spun up. Maybe we can ping them on this 16:16:15 s/recolection/recollection/ 16:16:23 astearns: I'll take an action to send this along 16:16:33 jensimmo_ has joined #css 16:17:03 plinss: I'm in favor of more display types. Maybe not 100, but 2 or 3 with other properties to control sub-behaviors. Early disgn philosophy in Gecko. I don't want layout and design tied to semantics. I want it all in css 16:17:25 iank_: Quite probably quite a few, 5 or 6. Makes sense b/c distinct layout algos. 16:17:45 florian: Are these things only useful in context of math? Or are they potentially useful in general? In favor either 16:17:48 These would be display-inside? 16:18:05 plinss: If we give tools people will have create ways to use them. People will find fun ways to display content we didn't dream of 16:18:21 iank_: mtable has display:table and display:tablecell so this normalizes to that behavior. 16:18:28 bradk, some of them might be more like internal table display types, have to check 16:18:31 iank_: display:mrow there might be. We should give that power 16:19:04 +1 16:19:05 emilio: Agree. If we want to style math with css using display ew have to do all or none. SVG does no such thing, it's its own box type. I like the direction of exposing all mathml display types 16:19:19 astearns: This will go into issue. I'll ping the new math WG and come back 16:19:44 @fantasai I see. Thanks 16:19:47 fantasai: I'd like to propse we take a resolution. csswg believes this is the right direction to go and we prop that to math wg. Useful to capture we're on the same page 16:19:54 astearns: Unless anybody has reservations? 16:20:17 astearns: Prop: We are interested in defining all the math display types necessary for mathml layout 16:20:32 astearns: as individual display types or separate properties in css that let us control the variations 16:20:44 RESOLVED: We are interested in defining all the math display types necessary for mathml layout 16:20:47 present+ 16:20:52 Topic: Discussion about the block cross-folding screen 16:20:54 s/layout/layout to not be element-dependent/ 16:21:01 github: https://github.com/w3c/csswg-drafts/issues/5882 16:21:39 fantasai: I had brought this up. It looks like need discussion. I don't have a proposal. I think I proposed for F2F 16:21:49 fremy has joined #css 16:22:04 astearns: Yeah, even for virtual F2F we need something to go on 16:22:21 astearns: By my reading this is about what to do with text elements since we do have split and mask capabilities for images 16:22:52 fantasai: No, screen folding. Different ways to handle the effect. One is where you move the boxes apart. Another is mask so stuff apeears. Need to expose to author so they don't put content inside the fold 16:23:32 fantasai: If impl creates a gap and cutting content, need no content in gap. When there's masking there is and author needs to know. need to make adaptable so author can layout. Means conveying information. 16:23:46 astearns: I don't see MS people on call who are working on this stuff 16:23:55 astearns: Maybe we kick back to issue 16:23:59 fantasai: Yeah, needs a proposal 16:24:08 Topic: [css-display] Should values be aliased at parse time? 16:24:14 github: https://github.com/w3c/csswg-drafts/issues/5575 16:25:05 fantasai: Question of if new display types, we have things line inline-block. Now that we have separate keywords we have inline-display-flow-root is same as inline-block. Defined as same. When you do gCS wanted to return inline-block b/c shortest serialization 16:25:23 leaverou_ has joined #css 16:25:26 present+ 16:25:40 fantasai: Should this be handled at parse time. I think no, author should get what they spec. I think rachelandrew and others have had value in talking as outer and inner display type. If we merge in APIs harder to conceptulaize 16:26:06 emilio: Much easier to do at parse time for impl. Don't feel super strong. Seems unfortunate display won't compute as specified, but I guess okay 16:26:35 oriol: While FF does at spec value time, chromium does this for combinations and they are considered to be different. It preserves spec keywords 16:26:49 florian: emilio, does it make it awkward for impl long term complexity or jsut when you write 16:26:51 hober has joined #css 16:27:13 emilio: Probably fine. once it computes it's okay. oriol your comment is slightly different. inline-math should be jsut math. 16:27:20 fantasai: Agree with emilio that's a different concern 16:27:41 oriol: Then it should be different if eq possibility one is legacy css2 and other is new? 16:28:01 emilio: That's why I prefer just alias at parse time. Each has a serialization and you're done 16:28:05 present+ 16:28:22 emilio: A bit unfortunate that you say inline-flow-root and get back inline-block. But that's what you get in the computed styles 16:28:40 fantasai: I prop we continue to define newer values as computing to legacy keywords but not process any earlier 16:28:54 emilio: That's more complicated. new thing to old thing. ideally want other way around 16:29:06 emilio: So you just worry about inner and outer display value 16:29:15 fantasai: You want to compute to the new ones but resolved is older? 16:29:21 emilio: Serialize as the. 16:29:34 fantasai: Reasonable that resolved value for gCS is legacy. Need that for compat. 16:29:45 emilio: That does change the behavior of the APIs. 16:29:49 emilio: We probably don't mind 16:29:53 s/APIs/Houdini APIs/ 16:30:13 emilio: If we want computed style map to return the new thing and then resolve into the keyword is the way to go 16:30:18 emilio: Sooner you alias the better 16:31:03 fantasai: From author PoV system is easier with 2 value keyword. If it's jsut a parse time alias that's helpful but could get a bit confusing. If we can get away with it being 2 keyword values in Houdini gude that's reasonable 16:31:14 s/easier/easier to understand/ 16:31:20 emilio: Then waht does specified style do? 3 values we expose, spec, computed, resolved 16:31:34 emilio: What Gecko impl is computed and resolved are same, serialize legacy 16:31:56 emilio: Moving the legacy thing to computational stage...that's okay but we also change behavior of houdini API 16:32:36 emilio: More work to basically keep the new values in the specified style, return old in computed, return new in Houdini. You're uncomputing what you computed. Fine. A bit more annoying 16:32:41 fantasai: TabAtkins or rachelandrew? 16:32:57 emilio: If we can get away with keeping parse time alias. Serialize to legacy. I don't know 16:33:20 emilio: Prefer if each combo had single serialization. Only gCS exposes legacy. But that's breaking change for specified. 16:33:27 emilio: Maybe only Houdini exposes new 16:33:35 TabAtkins: No opinion either way 16:33:44 astearns: Other opinions? 16:34:07 rachelandrew: I think as fantasai said from author PoV the two values are understandable and confusing if you get back something other than expected. 16:34:18 rachelandrew: Prefer we keep the 2 value all the way through if that's possible 16:34:42 emilio: That's another proposal. May be okay. But inline-block and inline-flow-root compute to different thigns but behave same 16:34:54 iank_: I feel like serialization should go to legacy if they can 16:35:00 iank_: Worried about the web compat here 16:35:04 tantek has joined #css 16:35:46 emilio: Right. If you keep as spec it's nice if you're in control. But you prevent adoption. If you use jquery and it expects a return of inline-block and it starts returning inline-flow-root b/c you used it in your style sheet, you can't use it b/c scripts break 16:35:58 fantasai: That's an arguement to not introduce the display types 16:36:13 fantasai: It's a new display type with same behavior. If your scripts break it's a problem with your script 16:36:31 emilio: Perhaps. But you cannot say in our css codebase we'll only use new display types b/c they break stuff. 16:36:46 emilio: I don't have super strong opinion. Can impl whatever. Least complex is parse time 16:37:30 I'm a bit lost. I'd love for us to compute to the new syntax. Get the world of Authors to move on. 16:37:30 iank_: I think I'm with emilio. From maintenance PoV and being a previous webdev this would be somewhat concerning. You don't always controls what people are setting display types to. 16:37:50 astearns: Resolve these return most backwards compat serialization except houdini and houdini has 2 value? 16:37:55 iank_: You mean typedOM API? 16:37:57 astearns: Yep 16:38:03 emilio: Should be fine 16:38:50 emilio: Should also be fine to match computed style either way. As long as same value serializes to the same thing it's fine. backwards compat trips. Up to chrome if they want exisintg users of inline-grid to have breaking change 16:39:25 present+ 16:39:46 jensimmons: I understand if there's a compat problem, but I would love to see us for sake of authors compute and return new syntax. I'd love to be able to teach new syntax. Thinking about where will we be 5 years from now. Hvaing to continually teach the old syntax and why? Always a fan of clear the decks and move forward 16:40:03 jensimmons: I think new display values with 2 parts are so eleigant, don't want the old to stick around 16:40:23 astearns: Which is why I want new to return the 2 value. But we serialize to least backwards compat for a reason 16:40:35 ack jensimmons 16:40:41 ack fantasai 16:40:44 fantasai: Could decide this is new independent value. Has same behavior but don't compute to each other. We've got 3 possible options 16:40:54 fantasai: 1) alias at parse time. 16:41:04 fantasai: 2) 2 independant values with same behavior 16:41:18 fantasai: 3) do inbetween where some apis return old and some return new if you spec new 16:41:42 fantasai: Seems first 2 are most elegant. For sake of authors I vote 1 with jensimmons and rachelandrew 16:41:43 +1 16:42:21 emilio: I'm okay with saying that.Basically quesiton is how much work does adopting this become. Script authors need to care about both values. That's great for authors of css but not great for authors of script 16:42:36 iank_: With emilio. I don't htink this is great to go down for script dev that queries style 16:42:57 astearns: Yeah, if we go with independant values it could slow adoption because not compat 16:43:05 fantasai: I'm n ot convinced it would be compat problem 16:43:27 iank_: From what I've seen on gCS and display I think there's a significant chance of people accidentally breaking and not realizing it 16:43:38 I’m also leaning towards option 3 16:43:53 astearns: Option 3 would not be alias at parse time b/c need to preserve values for TypedOM? 16:44:35 fantasai: Can't do it at parse. Variations on option 3. One would be 2 independent values but have gCS do an extra computation to return old version. We do all kinds of extra lift for gCS. 16:44:49 astearns: Do people have objections to the version 3? 16:45:08 present+ 16:45:19 fremy: Small question based on minutes. Why can't we do option 3 at parse time? I don't understand. They're exactly the same. inline-block will always be same 2 values in Houdini. 16:45:35 fremy: I have one serialization for gCS. You always have 2 value in Houdini. Never get 2 16:45:55 emilio: That how we impl it probably. Have same value but serialize differently for TYpedOM 16:46:05 fantasai: If you put something in specified style do you get 2 value or 1? 16:46:10 emilio: Legacy serialiation 16:46:19 fantasai: .style.display do I get inline-block? 16:46:26 emilio: You would get inline-block 16:46:33 fantasai: What's point of having weird in typed OM? 16:46:43 emilio: It's the one place where we can not go to legacy 16:46:59 emilio: You have issue of script athors having to care about both values if you don't 16:47:16 fantasai: But if you do inline-list-item they need to handle. We keep adding display values 16:47:49 GameMaker has joined #css 16:47:55 present+ 16:48:01 fantasai: We add them al the time. If script doesn't handle new you have to tell the person that my script only handles the old ones. If you're putting limits on script you have to negotiate with user. I don't see why this is a particular problem 16:48:08 emilio: There's a lot of code that won't update 16:48:16 fantasai: Sure, and when using don't use new things 16:48:38 emilio: Problem is, people are not going to be able to use new display values. Moving backwards compat from browser to author. That's fine 16:49:05 florian: Seems we have same problem in many areas. Script for colors there's may ways to spec red. They all look the same. But we don't serialize LAB space back 16:49:12 q+ 16:49:14 emilio: Take all hsl and serialize as rgb for that reason 16:49:36 q- 16:49:39 ack chris 16:49:55 yup. can't unmute 16:50:22 astearns: Not hearing consensus 16:50:33 astearns: Does anyone want to try coming up with something we agree on? 16:50:46 emilio: Won't object if we serialize the new thing, but I don't htink it's best 16:50:57 Note that we *only* serialize the older color forms to rgb(). Newer forms, even ones that are absolutely equivalent to rgb(), stay as they are. 16:50:58 astearns: iank_ you had concerns? 16:51:08 iank_: I don't think it's the way we should go 16:51:31 astearns: And others don't think we should be cutting off new display types at serialization time 16:51:39 astearns: Any way we can get evidence of compat problem? 16:52:03 fantasai: TabAtkins points out [reads IRC] so to bring florian question back, why do you think this applies to display and not color 16:52:37 TabAtkins: We have new color forms that are eq. to rgb but don't serialize. We color turn color into rgb but want to keep in same form. Only older turn into rgb. 16:52:45 aja has joined #css 16:52:50 emilio: I have same concern. It's common for script to just parse rgba output 16:52:53 q+ 16:53:13 iank_: With color example there are scripts that will add a11y dynamically and insert a color. I had similar concerns there 16:53:20 q+ 16:53:34 iank_: I think less bad b/c breakage is more minor in that case. There's a lot of script htat will check if display is inline-block do something 16:53:48 fremy: Talking about inline-style or gCS? I think gCS everything is rgb serialization 16:53:54 ack chris 16:54:18 chris: Thing about rgba is the spec says regardless of how you spec, rgb or rgba, rgb can get an alpha, but if it's 1 it's thrown out. Only reported if not 1 16:54:33 acl ;ea 16:54:33 chris: Clarifying 16:54:36 ack lea 16:55:10 leaverou_: Comment about scripts that parse rgba, that ship sailed. Not every color can be rgba so scripts need to support other forms. Shouldn't be a concern. With typed OM hopefully devs wouldn't parse colors manually anymore 16:55:17 Serialization of rgb() or rgba() only reports non-unity alpha 16:55:42 astearns: I think color discussion is a little far afield. Scripts dealing with display values. I would hope scripts with display values would have an i don't know what this is default. 16:55:46 Sure, people seemed to be arguing by analogy though so I wanted to be sure the analogy was accurate 16:56:08 florian: I think we need data for compat argument. If we show up we can say doing serialization might break things. In theory all sorts of things could break. Do they? 16:56:18 fremy: We have rule of if can serialize to old we do 16:56:28 florian: At computed time, yes. Not at specified 16:56:34 emilio: Isn't that general serialization rule? 16:56:36 I suggest this be taken back to the issue for a bit to stew over the options and arguments. 16:56:40 florian: I don't think so. Am I wrong? 16:57:09 fantasai: When defined to be equal, we do. If defined to eq. it will serialize to shortest. Debate is do we define to be same at computed or specified value time. 16:57:46 fantasai: One proposal is they're distinct and different. We do that in other places. We have places in css with same behavior but serialize independent 16:58:08 iank_: Quick search, jwuery uses this. Likely some cases will break 16:58:16 astearns: Can you put references in issue iank_ ? 16:58:26 iank_: Not exaustive. Just a litmus test 16:58:57 astearns: Nearly out of time. I suggest iank_ puts his in the issue. Others search and add to the issue. We can see what would break and come back at a later date 16:59:01 astearns: Sound alright? 16:59:09 Topic: end 16:59:19 astearns: Thanks everyone for calling in and we'll talk next week 16:59:33 zakim, end meeting 16:59:33 As of this point the attendees have been dael, rachelandrew, miriam, oriol, alisonmaher, bradk, emilio, plinss, dbaron, jfkthame, Morgan, smfr, sanketj, argyle, faceless, dholbert, 16:59:36 ... gregwhitworth, jensimmons, castastrophe, chris, leaverou_, hober, cbiesinger, tantek, GameMaker 16:59:36 RRSAgent, please draft minutes v2 16:59:36 I have made the request to generate https://www.w3.org/2021/04/14-css-minutes.html Zakim 16:59:38 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 16:59:43 Zakim has left #css 17:05:52 jfkthame has left #css 17:07:27 jensimm__ has joined #css 17:13:18 jensimmo_ has joined #css 17:20:16 fantasai: sorry again for speaking over you btw, I didn't notice but Alan was right in pointing it out 17:21:57 fantasai: I commented on the issue with a sample of code from jquery, and again I'm not opposed on changing Gecko here, but I _think_ it's a bit of the kind of change which is harder for both implementors and script writers. 17:25:05 Random question: it turns out the "recommended" is a 2119 keyword, and Bikeshed is complaining about its use in an example. I'm feeling like it's a rare enough word that I can safely remove it from the validation. Sound reasonable? 18:28:03 I see 172 instances in the repo 18:29:16 Is the check that we do not use 2119 keywords in non-normative text? I think I see several instances of that 19:50:40 projector has joined #css 19:51:11 leaverou has joined #css 19:51:41 Rossen has joined #css 19:52:11 shans has joined #css 19:52:41 sylvaing has joined #css 20:17:43 zcorpan has joined #css 20:18:42 zcorpan_ has joined #css 20:20:33 zcorpan has joined #css 20:22:22 zcorpan_ has joined #css 20:23:30 zcorpan has joined #css 20:25:52 zcorpan_ has joined #css 20:26:30 zcorpan has joined #css 20:30:41 zcorpan_ has joined #css 20:31:50 zcorpan has joined #css 20:33:03 zcorpan_ has joined #css 20:33:39 zcorpan has joined #css 20:35:22 zcorpan_ has joined #css 20:37:20 zcorpan has joined #css 20:39:22 zcorpan_ has joined #css 20:39:54 zcorpan has joined #css 20:42:07 zcorpan_ has joined #css 20:43:40 zcorpan has joined #css 20:44:52 zcorpan_ has joined #css 20:47:30 zcorpan has joined #css 20:49:07 zcorpan_ has joined #css 20:50:10 zcorpan has joined #css 20:52:52 zcorpan_ has joined #css 20:54:15 zcorpan has joined #css 20:56:14 astearns: You have to manually turn on that `Complain About` option; this just happens to be turned on for Color 4. 20:56:19 zcorpan has joined #css 20:57:02 zcorpan_ has joined #css 20:57:35 zcorpan has joined #css 21:00:38 zcorpan_ has joined #css 21:05:28 So maybe just fix that instance so that people can run the full check elsewhere if they want? 22:09:43 Where I fix it isn't an issue, I'm just wondering if it's even a word *worth* checking for, since I definitely didn't remember it was even a 2119 word.