16:53:30 RRSAgent has joined #css 16:53:30 logging to https://www.w3.org/2019/02/13-css-irc 16:53:32 RRSAgent, make logs public 16:53:32 Zakim has joined #css 16:53:34 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:53:34 Date: 13 February 2019 16:54:37 antonp has joined #css 16:56:38 present+ 16:57:18 bdc has joined #css 16:57:48 present+ 16:58:00 present+ dael 16:58:04 ScribeNick: dael 16:58:21 CSSWG_LogBot has joined #css 16:58:32 present+ 16:58:52 antenna has joined #css 16:59:30 present+ 16:59:42 present+ 17:00:25 present+ 17:00:44 astearns: We'll give people a few more minutes 17:00:53 florian has joined #css 17:01:39 Present+ antonp 17:01:51 present+ florian 17:02:04 rachelandrew has joined #css 17:02:10 chris has joined #css 17:02:29 present+ 17:02:40 present+ 17:02:48 present+ 17:02:50 jensimmons has joined #css 17:02:56 astearns: I think we should get started 17:03:03 present+ 17:03:04 present+ 17:03:06 present+ 17:03:10 astearns: First thing, are there any changes to the agenda anyone would like to make? 17:03:29 dino has joined #css 17:03:38 present+ 17:03:40 present+ 17:03:47 astearns: Housekeeping- we have a F2F coming up. If you haven't put your name on the wiki as attending or regrets please do. And look at the agenda. 17:03:51 Topic: minmax(auto,min-content) under a max-content constraint 17:04:00 github: https://github.com/w3c/csswg-drafts/issues/3565#issuecomment-461242081 17:04:03 present+ 17:04:22 astearns: Discussed last week. Sounds like the one thing waiting on is the verbiage for what to do when spans >1 17:04:23 present+ 17:04:26 astearns: Is fantasai on yet? 17:04:38 present+ 17:04:44 astearns: Is there anyone else who wanted to go over last week's discussion or have anything new? 17:05:40 astearns: Rossen it sounds like on this item we were waiting to resolve on fantasai addressing a comment from Mats. She did in the issue. Should we call for resolution? 17:05:43 oh sorry — I was totally confused. I thought you were asking for new agenda items for the call still… SORRY. That’s what I get for doing more than thing at the same time 17:05:59 innovati has joined #css 17:06:11 oriol: fantasai proposed edits and they're not yet in the spec. I had some complaints against them and they need to be tweaked a bit. It would be better to discuss with fantasai 17:06:16 fantasai: I'm here 17:06:39 astearns: oriol did you want to discuss on the call or do it in the issue? 17:06:50 alex_antennahouse has joined #css 17:07:25 oriol: I wrote them in the issue. mostly it was that fantasai proposed to clamp as an upper limit that's the maximum of value. I thought it would make more sense to sum values rather than max of them. Some other minor corrections that maybe can be in github before making edits 17:07:53 present+ 17:08:18 fantasai: It's a max instead of sum because we want it to just fit within the number of tracks it spans. If it spans 50px and then one that's min-content we want it to fit in 50px plus whatever is left. If we add to it the 50px we're giving it more space then it needs 17:08:49 just a sed 17:08:59 astearns: It sounds to me that there are 2 issues. THe one on the agenda and another that has some ramifications on this one? 17:09:02 sec... having problem connecting on the phone 17:09:13 florian: I think ramifications are a follow up to the thing on the agenda 17:09:49 oriol: The item in the agenda was for the non-spanning case and Mats wanted to handle spanning case as a generalization of this and it make it more complicated 17:09:53 astearns: Okay, thank you 17:10:38 astearns: I could see two ways going forward. One is figure out the ins and outs of spanning case on the call. Sounds like discussion is between fantasai and oriol so might not be most efficient. Other is resolve on accepting these edits and if needed open a second issue for spanning case 17:11:09 fantasai: Can resolve on principle of handling min content track sizes as a clamp on automatic sizes in a similar way fixed sizes are a clamp 17:11:16 astearns: Make sense oriol ? 17:11:18 oriol: Yes 17:11:38 present+ 17:11:43 astearns: We're asking for 2 resolutions? One to accept the edits proposed in the issue and second is on principle? 17:11:56 fantasai: Just principle. Deal with the edits in the issue that is open on that 17:12:14 astearns: Issue on agenda needs resolution. Is resolving on the principle sufficient? 17:12:17 fantasai: I think so 17:12:44 astearns: Prop: Close the issue by resolving we will handlemin content track sizes as a clamp on automatic sizes 17:12:50 astearns: Objections? 17:13:00 Rossen: This is on #3565? 17:13:02 falken: Yes 17:13:11 s/ falken /fantasai 17:13:21 Rossen: sgtm 17:13:34 RESOLVED: we will handle min-content track sizes as a clamp on automatic sizes 17:13:47 Topic: jensimmons item 17:14:29 jensimmons: I've started working on CSS remedy project. It's a replacement for the normalized style sheet and css reset. devs use them to help them when getting started with a project. 17:15:08 https://github.com/mozdevs/cssremedy/issues 17:15:15 jensimmons: One of the things I found facinating when joining group is we can't make the default the best value because we can't break compat. THe propose of css remedy is to collect those bits to give best practices rather then old compat. 17:16:04 jensimmons: Some of you have been involved and I'd love more interest. Mostly we're discussing on issue. It could have a lot of traction. Already 1000 people visited on github. We'll hopefully have it out in April or May. 17:16:22 astearns: Anyone want to add anything? Or we can keep this informative 17:16:43 florian: People should participate. I do and if you don't want me to be wrong you should come correct me 17:16:50 Topic: outline on ::selection 17:17:00 github: https://github.com/w3c/csswg-drafts/issues/3604 17:17:02 Thanks for letting me announce that! Thanks astearns ! 17:17:43 fantasai: currently outline applies. I tried to add a definition but it's not that simple and I don't think anyone impl. Does anyone want this? If not we can drop it. It's able selection as well as spell check. 17:17:53 dbaron: I wouldn't know how to define it so happy to remove 17:17:53 s/able/about/ 17:18:05 florian: use cases I'm aware of don't call or it so I'm okay 17:18:08 fremy has joined #css 17:18:10 astearns: Anyone want to keep it? 17:18:17 +1 drop it 17:18:24 bradk has joined #css 17:18:27 astearns: Prop: Remove outline from list of supported styles on ::selection 17:18:30 astearns: Obj? 17:18:35 s/I'm aware of/I care about/ 17:18:36 RESOLVED: Remove outline from list of supported styles on ::selection 17:18:45 Topic: Should Element.pseudo("unknown") be an error or return null? 17:18:52 github: https://github.com/w3c/csswg-drafts/issues/3603 17:19:19 fantasai: Somewhat related to #3607about identity of the pseudo 17:19:38 leaverou: Does it present null in any other case? If it's not defined at all does it return null? 17:19:42 fantasai: That's an open question 17:20:08 leaverou: In general errors meandev have to handle. But we needto be able to distinguish doesn't exist and not defined. Feature detection needs to be possible 17:20:49 Questions: 17:20:51 fantasai: Open questions are should element.pseudo always return same object even if you removet he style that generated it? Other is if it doesn't exist in box tree do we get an object back? When we request something that doesn't exist b/c not supported what do we return? 17:22:19 TabAtkins: Addressed first question last week. Keeping objected identity stable is useful. Question of what to we return when before doesn't have a property and can you fiddle with an object. Second question, we do need to distinguish between a pseudo that doesn't exist and one that isn't valid. I don't think it's useful to return null if a pseduo element doesn't exist on an element. Perhaps a bool to say if it exists or not 17:23:04 TabAtkins: The for the unknown thing where you put ::foo it should throw an error. Even thought CSS style sheets can be forgiving, JS APIs shoudl throw in clear error cases. 17:23:37 q+ 17:23:44 fremy: I think it makes sense to return an object all the time. On the error part I'm less sure b/c we'll have compat issues and errors can cause entire thing not to work. Less sure but understand arguement 17:24:06 leaverou: It's impossible in JS to tell if it's that the element doesn't exist or something else went wrong. You can sort of guess but not be sure 17:24:33 TabAtkins: We can return different types of errors. We don't throw that many errors and you can tell from type. Message will usually let you know what's going on 17:24:44 leaverou: From console, but can't programatically detect 17:24:53 TabAtkins: But there'sone error it can cause 17:24:59 bkardell_ has joined #css 17:24:59 leaverou: What about the future 17:25:13 present+ 17:25:27 florian: With this if you start nesting and I don't know if that's same error as asking for a pseudo that doesn't exist 17:25:36 q- 17:25:36 TabAtkins: Can't ask for a pseudo on a pseudo 17:26:02 present+ 17:26:17 fantasai: I think if we're deciding element returns null when it doesn't exist it makes sense, but if we're not we should return an error 17:26:45 astearns: Sounded like 3 parts to TabAtkins summary. 1) always return 17:26:48 TabAtkins: the same object for a give element/pseudo element pair 17:26:50 1. Always return the same object for a given (element, pseudo-element) pair. 17:27:05 astearns: Always return same object. Return an object for when a element exists 17:27:15 Btw a historical case that may help: In old IE, element.style[foo] would error if the value was invalid. This was very widely considered as annoying by developers, until eventually IE changed and stopped throwing. 17:27:30 fremy: That means you need ot keep object for lifetime of element. You could have to store a gazillion objects which you don't need. I would have to check 17:27:40 florian: Garbage detected? 17:27:45 s/detected/collected/ 17:27:48 s/fremy/emilio 17:27:55 s/element.style[foo]/setting element.style.foo/ 17:28:04 emilio: I guess it's not observable. Any other that does the same? 17:28:12 (discussion about the element keeping a weak reference) 17:28:19 fremy: [missed] if you drop the reference it's garbage collected and you get the new one 17:28:34 fremy: Not possible to notice because you don't have anywhere to join 17:28:56 s/join/compare to/ 17:29:01 TabAtkins: If you ask for a ready promise those are cached and you're not calling because ready state has not changed. That sort of retention of objects is not uncommon 17:29:16 emilio: font face it's one object and this could be many objects. If it's a problem we can face it 17:29:29 TabAtkins: If you're iterating the entire tree, that's weird 17:29:33 emilio: I've seen people do it 17:29:44 florian: Pseudo with a certain style, you look at all 17:30:33 fantasai: One thing we could do is return null if doesn't exist on element. If at any point it does exist browser has to maintain the reference. Function might return null or that object, but never another. SO if pseudo element at some point exists you keep that reference. 17:30:57 TabAtkins: psueod element does exist- if there isn't css setting the before would we return null when asking for the before pseudo 17:31:08 emilio: Also what happens when display on sub tree? I don't know 17:31:40 +1 to what TabAtkins just said 17:31:43 TabAtkins: I'm unhappy with it because it means you can't use this API to toggle a pseudo element on. You have to go through normal css which is a more complicated redirection. Sounds good but messes up too much 17:31:59 plinss[m]: Isn't that a feature? SHould we be able to create pseudo not backed by css? 17:32:12 fantasai: Currently has a .style that allows you to set and have it exist. 17:32:28 q+ 17:32:56 fantasai: Interesting thing is to plinss[m] point you can't serialize that back out. WE have style that will serialize out for .style, but not for a pseudo element. 17:33:29 TabAtkins: If we accept nesting proposal style auto upgrades to be able to support that. Have to define, but you can embed a nested style in the style attribute. There's a route to make it serializable 17:33:33 ack Rossen 17:34:03 Rossen++ 17:34:07 Another maybe-silly option is a null/undefined distinction, if you want to think of .pseudo() as sort of like a shorthand for a long list of DOM properties (where undefined means "not implemented" or "the browser doesn't know about it" and null means "known but not present") 17:34:23 Rossen: Question- Is anyone working with any DOM or HTML folks on this? Curious to their PoV. Sounds like a pretty overarching API that we should be working with at least DOM folks. I'd hate to see something like this worked on for so long and then go back to square one. 17:34:52 Rossen: Perhaps with an envoy it would be good to get their PoV 17:34:56 emilio: We can ask for feedback 17:34:58 dbaron, I don't see a good reason to return undefined vs throwing, tho. 17:35:16 fantasai: Would like to try and resolve and we can reopen if they give feedback and get a publication out to request a review 17:35:25 If we accept Tab's "route to serialization" by allowing pseudo-element styles in the inline style of the main element, doesn't that also open up a "route to dynamically generating a pseudo-element" by declaring a `style="::before{content:"text"}` on the parent element's style object? 17:35:25 astearns: Would be nice, but not sure I'm hearing consensus 17:36:09 astearns: I agree figuring this stuff out does make this issue about a non-existent pseudo...how we answer all these questions does make a difference on how we address this particular issue 17:36:19 AmeliaBR, only if you escape those quotes properly :) 17:36:28 `style="&::before{content:'text'}"`, but yes 17:36:49 Rossen: I'm hearing a lot more questions then suggested answers. Doesn't suggest you're ready to resolve. If we're looking to push an updated version of spec I don't thinkw e need to rush a decision 17:37:13 astearns: Issue on the agenda is just unknown pseudo elements. Are there other issues for psuedos that can hop on and off of existance? 17:37:15 https://github.com/w3c/csswg-drafts/issues/3607 17:37:17 fantasai: #3607 17:37:29 astearns: Gotcha 17:37:35 That transcript misses some of Tab's follow-up comments 17:38:41 astearns: Not happy to not resolve, but I don't think we have a plan. What about we come up with a proposal for both issues, discuss at F2F, come to a decision there. We use time up to F2F to reach out to DOM people and anyone else that would have real input on what to decide 17:38:58 Topic: Mark unimplemented CSSPseudoElement features at-risk 17:39:06 github: https://github.com/w3c/csswg-drafts/issues/3540 17:40:06 fantasai: Suggestion is mark things unimplemented or drop them if no one plans to implement. No one place to impl style method. Other question is which pseudo elements do we want to support. ::selection or jsut those that generate boxes? Moz only supports ::before and ::after 17:40:43 astearns: I don't have an opinion as to which we have to support. I noticed when reading spec there are lots of others in the spec not mentioned here. It would be nice to havea note as to why others are omitted 17:41:09 fantasai: I suggest we trim spec to subset moz supports unless anyone intends to implement? 17:41:22 if it only supports a subset of supported pseudo-elements, that's yet another reason to not throw when other pseudos are used that are supported by the browser but not by that API 17:41:22 astearns: Obj to trim set supports to ::before and ::after? 17:41:23 tantek has joined #css 17:41:23 Tav_ has joined #css 17:41:30 fantasai: And no style 17:41:39 astearns: Objections to either 17:42:02 RESOLVED: Drop style from this level, restrict API to ::before and ::after, add a note to why the other things are not yet supported 17:42:26 fremy: Begs question to what we should do for other things browser supports. WE should say what to do with other stuff. 17:42:28 fantasai: Yeah 17:42:40 astearns: Can you add a comment to the other issue mentioning we should define that? 17:42:42 present+ 17:42:42 fremy: I can 17:43:15 Topic: Clarification on prefers-color-scheme issues 17:43:23 github: https://github.com/w3c/csswg-drafts/issues/3278 17:43:29 ah, misread the log... 17:43:59 emilio: Bascally, people are about to ship this MQ. There were unsolved issues. Should be straightforward 17:44:28 emilio: One is what should MQ evaluate in boolean context. 17:44:45 florian: It's defined in spec. If there's disagreement to what's defined I'm happy to hear it 17:44:54 emilio: Peoplediscussing on issue, but if spec says that's fine 17:45:00 florian: Same as no preference 17:45:38 dino: It makes using that form almost useless. You can't derrive meaning from it. If the query is prefers color scheme it will eval to true if they picked on 17:45:56 fantasai: Not prefers color scheme is interesting though. Makes it shorter to type out. 17:46:04 dino: You save 5 characters 17:46:32 TabAtkins: Prefers color scheme and not is clearly you either do or don't. It makes it this thing exists or doesn't and that's what null communicates 17:46:44 `@media not (prefers-color-scheme)` and `@media (prefers-color-scheme: no-preference)` make sense as equivalents, to me. 17:46:53 emilio: Other question is if it should match light on print or if that's too smart 17:47:02 dino: That is another issue 17:47:24 astearns: I hadn't read the entire thread on #3278. Is that only what to do in boolean context? 17:47:30 emilio: Yeah 17:47:53 do existing implementations follow that answer? 17:47:59 astearns: Sounds like we have an answer. @media prefers-color-scheme is the same as null 17:48:16 astearns: It sounded like dino found it useless 17:48:19 (sorry, I can't unmute since the machine I'm dialed in on is semi-frozen thanks to yesterday's Windows update...) 17:48:34 dino: I don't know why you'd use it, but it does follow behavior so it's fine 17:48:52 TabAtkins: Yes, we're looking for consistency in how other MQs are handled 17:49:12 astearns: Prop: Close this issue no change, it is defined in spec. dbaron asked in IRC if impl match this 17:49:18 florian: I think we're light on tests 17:49:35 dino: We don' have any no-preference option 17:49:51 ??: I think blink is one that would have to change 17:49:54 emilio: Blink matches 17:50:08 dino: We should contribute tests for this. not sure how you can test user choice 17:50:19 florian: That's always the problem with testing MQs. 17:50:31 TabAtkins: Generally they're all manual tests. They're very hard 17:51:25 dino: Internally we have JS API only exposed in test system to set user preference for that page. Would be nice if al browsers could standardize on an API to do things like this. Would cover media style but nice if pointer events and touch events and that type of thing. Not for this WG I guess 17:51:48 sgtm 17:51:50 astearns: Sounds like there's consensus to close this issue and take what's in the spec currently. Objections? 17:52:03 RESOLVED: Close this issue no change, there is already language in the spec 17:52:11 Topic: prefers-color-scheme and printing 17:52:21 github: https://github.com/w3c/csswg-drafts/issues/3522 17:53:08 emilio: Somebody asked if prefers color scheme should always be light web printing. Seems reasonableand I think it's what webkit does. BUt author can already check that. Should we define this? 17:53:21 It sounds like something that the browser should include in their Print UI, just like turning off background images. 17:53:39 (AKA, what Florian is saying) 17:53:52 florian: Feels like something up to UA. Seems reasonable UA choice to switch to light when prining. I think a checkbox in the print pop up is also reasonable as well. Saying UA can have a different preference sounds good, but forcing light is overkill 17:54:03 fantasai: I think suggest UA returns light when prining 17:54:33 yes that seems reasonable 17:54:43 TabAtkins: What's returned is 100% UA determined, but most of the time you want light when printing. Have a note that this may vary on various factors, but printing should default to light 17:55:07 emilio: You might want dark if printing a PDF, but that's something the UA can expose. I'm happy to default to light 17:55:21 s/emilio/dino 17:55:28 fantasai: Suggest if you expect to print to paper you should indicate a preference for white. Doesn't necessarily mean PDFs should default to light 17:56:01 astearns: Prop: Do not have any normative text about this. Add a note encouraging UAs to think about what should be done for printing and to use light when they know printing to paper 17:56:05 astearns: Objections? 17:56:07 unless the paper is black... :) 17:56:12 RESOLVED: Do not have any normative text about this. Add a note encouraging UAs to think about what should be done for printing and to use light when they know printing to paper 17:56:36 Topic: Empty grid tracks should contribute to scrollable overflow 17:56:44 github: https://github.com/w3c/csswg-drafts/issues/3638 17:56:54 astearns: Short intro to this topic 17:57:53 fantasai: Filed by someone using empty grid tracks. It was showing...it's in a scrollable grid container and spacing left by empty ttracks not showing in FF b/c different interpretations. Should scrollable overflow area of grid container be only big enought ot cotnaint elements or big enough for entire explicit grid. It's an abstraction that's not a box 17:58:04 TabAtkins: Grid exists like flex lines. It's not a thing in thebox tree 17:58:24 fantasai: Argument against is impl that's the only thing that's real. Authors expect inluding all grid tracks 17:58:34 Rossen: A grid element that itself is overflow scroll? 17:58:53 fantasai: A grid container that's overflow:scroll with a bunch of tracks and some items in it. 17:59:09 TabAtkins: Items in the grid fit within the visible area, but tracks don't. Scrollbar or no? 17:59:26 jensimmons: Super itneresting. If authors have extra tracks I think they would expect to scroll 17:59:41 rachelandrew: Authors would expect a scrollbar. They expect the grid to be real 17:59:56 plinss[m]: Would you expect it to size to explicit grid lines if it's not overflow:scroll? 17:59:59 fantasai: It does 18:00:06 plinss[m]: Bheavior should be consistent 18:00:19 Rossen: Are you saying the intrinsic size of the grid is the extent for scrolling? 18:00:22 plinss[m]: Yes 18:00:43 astearns: We're at time. That's an intro for this issue. It's an interesting one and we should discuss in the future. 18:00:46 Topic: end 18:00:57 astearns: Thanks everyone for calling in and we'll talk next week 18:01:27 I forgot that we size it to the grid by default. I think that's a reasonable argument for letting the grid be part of overflow. 18:03:25 Karen has joined #css 18:11:42 bdc has joined #css 18:21:25 antenna_ has joined #css 19:12:44 trackbot, end meeting 19:12:44 Zakim, list attendees 19:12:44 As of this point the attendees have been astearns, dauwhe, dael, melanierichards, bdc, oriol, antenna, antonp, florian, dbaron, tgraham, rachelandrew, jensimmons, plinss[m], 19:12:47 ... leaverou, chris, dino, emilio, svoisen, Rossen, TabAtkins, AmeliaBR, bkardell_, bradk, tantek 19:12:52 RRSAgent, please draft minutes 19:12:52 I have made the request to generate https://www.w3.org/2019/02/13-css-minutes.html trackbot 19:12:53 RRSAgent, bye 19:12:53 I see no action items