15:56:37 RRSAgent has joined #css 15:56:37 logging to http://www.w3.org/2017/10/18-css-irc 15:56:39 RRSAgent, make logs public 15:56:39 Zakim has joined #css 15:56:41 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:56:41 Date: 18 October 2017 15:56:52 rachelandrew has joined #css 15:57:27 svillar has joined #css 15:58:27 present+ dael 15:58:35 ScribeNick: dael 15:58:36 present+ 15:58:46 present+ bdc 15:59:54 present+ 15:59:56 present+ 15:59:57 present+ 16:00:17 present+ 16:00:33 present+ 16:01:41 present+ 16:02:02 Rossen_: Let's give a couple more minutes and start at 9:03PT 16:02:03 bkardell_ has joined #css 16:03:04 present+ 16:03:11 present+ 16:03:11 https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0206.html 16:03:38 present+ 16:03:44 Rossen_: Let's get started. 16:03:55 Rossen_: As usual, are there any additional agenda items? 16:04:11 Topic: Spec Rec Next Steps 16:04:19 present+ 16:04:25 present+ ericwilligers 16:04:53 present+ 16:04:59 Rossen_: There were a few specs in the publish pipeline which is awesome. I wanted to check on if there has been any movement on testing or if anyone needs help. Esp for things like writing modes, B&B, flexbox. 16:05:08 bradk has joined #css 16:05:11 present+ 16:05:15 Rossen_: Has there been work? Do you need help? 16:05:32 florian: I have no made progress on writing modes. I odn't need help, just time. 16:05:53 Rossen_: For writing modes, what is the timeline for rec? Is it only those tests? 16:06:07 florian: They're the only ones on my radar. You'd need to check with authors. 16:06:31 fantasai: Mainly the orthogonal flows, but they need impl to update. It was supposed to be CR published, I think. I'm wondering if that happened. 16:06:33 Rossen_: No. 16:06:55 fantasai: Writing modes 3 was supposed to be CR published and 4 as a FPWD. I'm not sure where that's blocked. It hasn't happened. 16:07:01 Rossen_: I'll followup with Chris. 16:07:10 Rossen_: I'll see what the hold up i s. 16:07:17 Rossen_: B&B is in the publish pipeline. 16:07:23 Rossen_: Anything else to update? 16:08:26 gregwhitworth: regarding flex I sent that review is completed, but I haven't gotten to work o n the tests at the base. I'm not sure I have time before TPAC. If anyone wants to help please send PRs on flex. I'll forward the changes fantasai has been making, but I don't know about the rest. I would welcome the help. 16:08:33 Rossen_: If you can help, that would be awesome. 16:08:41 Rossen_: Please give a hand to gregwhitworth 16:08:42 present+ 16:08:44 Topic: Add notIfViewed to ScrollIntoViewOptions; add FocusScrollOptions 16:08:53 Github: https://github.com/w3c/csswg-drafts/pull/1805 16:08:58 present+ 16:09:13 s/I'll forward the changes/I plan to write tests for the changes fantasai has been making 16:09:18 wrt flexbox, also note there's a bunch of PRs awaiting review at https://github.com/w3c/web-platform-tests/pulls?utf8=✓&q=is%3Aopen%20is%3Apr%20label%3Acss-flexbox-1%20-label%3A%22do%20not%20merge%20yet%22 16:09:28 zcorpan: This is about disabling scrolling from the focus method in html. Or customizing how the scrolling should behave. 16:09:48 fremy has joined #css 16:09:51 zcorpan: For scroll into view there is a disctionary to customize. but for focus there is no way to turn off or customize scrolling. 16:09:55 ^ particularly before TPAC for those tests 16:10:11 related PR in WHATWG: https://github.com/whatwg/html/pull/2787 16:10:23 zcorpan: There is a proposal to do these things. The open issue is what the API shape should be and the semantics and how to get interop on default behavivor. 16:10:27 https://github.com/w3c/csswg-drafts/pull/1805#issuecomment-331383688 16:10:41 zcorpan: On one comment there is a table desc default behaviors in browsers. 16:11:19 zcorpan: In chrome, opera, safari the behavior is different between if it's partially in view orentirely out. In FF and Edge there's no scroll if it's partially in view. You get nearest alignment if it's entirely out of view. 16:11:44 zcorpan: That's where we're at. We should figure out a way forward and a way to address these use cases. 16:12:26 florian: One thing mentioned in discussion is there is a number of event options we might want to support. You don't strictly need them but it's not convenient. Prob should take some shortcuts, but how many isn't clear. 16:12:47 tantek has joined #css 16:13:13 fantasai: I had a q on this point in terms of the options for start vs end alignment of the thing you'rescrolling into view. These conflict with the scrollsnap properties. My question is are these options nec. Do we need something in JS to override them? Do we use those prop instead? 16:13:20 fantasai: Has anyone thought about that? 16:13:55 florian: My intuition was the JS do the eq/ of maual and when you release scrollsnap kicks in. I haven't thought in depth 16:14:17 zcorpan: I haven't given enough throughts about integration, but they should pay well together and cssom view should be aware of scrollsnap 16:14:23 fantasai: What's the impl status of the options? 16:14:30 zcorpan: I don't know the current interaction 16:14:41 fantasai: No, are the options impl and deployed or just in spec? 16:15:14 zcorpan: scroll into view is impl at least in firefox and chromium. I'm not sure if they're interop. It would work for basic things. I think nearest keyword isn't supported 16:15:58 fantasai: I think it would be worth thinking about if we need these options or rely on css properties. If you have scrollintoview why would you set a value different then scroll snap. If there isn't the property many not need to exist. If they do we need to think from that perspective. 16:16:08 dbaron: There's definitely use cases for this when not using scrollsnap 16:16:36 fantasai: But we have wording where if something hasa snapping area defined and you target that you can use the scroll s nap into to choose the scroll offset. Snap area has a meaning without snapping 16:16:55 present+ 16:16:55 florian: That tells you have for offset from to top edge if your at the top. It doesn't say how offset if you're at the middle 16:17:02 fantasai: Scroll snap align would tell you 16:17:08 florian: But only if you're snapping. 16:17:28 fantasai: By default that value is none. You're not choosing and alignment, just marking an area. 16:17:48 fantasai: But if you have an alignment it means you have a preferred alignment when that element is being considered. 16:18:02 rachelandrew has joined #css 16:18:29 fantasai: As far as the JS is concerned it's less powerful a nd has to duplicate it with every call and keep track of that. The declarative method has that associated with the element the element tells you the informaiton. 16:18:57 present+ myles 16:19:01 present+ rachelandrew (irc only, in an airport) 16:19:02 fantasai: The only reason I can think of is if there is a scroll alignment and you want to do something different and you may or may not snap to the preferred behavior anyways. I'm not convinced that's something anybody wants. 16:19:25 fantasai: I think that needs thought as to if we need those options. The information it's giving you for scroll options are less powerful then th scroll snap options. 16:19:27 q? 16:19:54 dbaron: I think many of the JS interactions the behavior you want is specific to the interaction. If you're tabbing through controls and focusing on next you want different the reverse tab and focus previous. 16:20:23 q+ 16:20:34 fantasai: Right, but that's generally going to fall out of UA. If next and previous rearrange based on layout it won't help you. UA should choose if you shift to top or bottom and pick the right side. Doing that manaually through JS doesn't seem right. 16:21:04 zcorpan: I think the point is that the one who decides the behavior...liekif you write an app it's the JS dev that makes the call to pull i nto view, not the UA. 16:21:41 fantasai: Scroll into view the UA chooses a position to have the thing in view. It's an optional argument so if you leave out start or end it'll do dbaron 's behavior but more intellegently. The JS dev doesn't have to figure out lots of things. 16:21:55 florian: But in some cases it doesn't. In some cases it jsut centers the thing. 16:22:10 ack jihye 16:22:40 jihye: First of all when I suggested to add some options to control scrolling when focus is called I wanted to prevent scroll or make smooth scrolling. I think if that can be handled by scroll snap? 16:23:51 fantasai: No, but the start vs end is provided by scroll snap. I think you were trying to add this to a new API and they were copied over. I don't think anyone has thought through does anyone need this option if we have scroll snap. I think we need to add the auto non smooth, but my concern is adding start and end and in having it in the API. I don't know why it needs ot be in JS if there's css properties to control it 16:24:41 florian: Another axis of reflection is how much do we want to expose on in view, partially out of view, out of view...how much do we expose? Do we want a numerical threshold, leave it to browser? There's various use cases we can think of and various levels we can expose. 16:25:10 Rossen_: Going back to zcorpan...in the beginning of your desc you had a more specific question of focus and if it should align the same as scroll. 16:25:46 Rossen_: The rest of the convo seems nec around if we're going to expose these APIs and dive into how this interacts with scrollsnap. I'm trying to wind down the discussion. zcorpan is there anything else you want from this? 16:26:11 https://github.com/w3c/csswg-drafts/pull/1805#issuecomment-331383688 16:26:21 zcorpan: Regardless of API shape and scroll snap interaction there is the default behavior of the focus method and how it does scrolling. Do we want to align the behavior between brwosers and, if so, what should that be? 16:26:46 Rossen_: Seems like webkit based browsers have one type of behavior and edge and FF are aligned to not scrolling if it's partially in view 16:27:09 bathos has joined #css 16:27:18 Rossen_: So impl, would this be something that you're interested in aligning to and, if so, which should we align to? 16:27:19 alex_antennahouse has joined #css 16:27:23 IMHO interop on that would be good, I would think webapp devs would like it 16:27:57 Rossen_: As an impl I'm personally for interop where possible, but I'm not sure which is better b/c I haven't spent much time on it and seeing how it intersects across windows platform. But I want to hear what others thinks. 16:27:59 +1 Rossen 16:28:24 florian: Additional question: has anyone checked if behavior is done when calling focus method when there is padding? 16:28:37 zcorpan: If you check in the link 16:28:38 https://jihyerish.github.io/all-about-focus/ 16:28:58 tantek: Another question is if the scrolling is similar to fragment link scrolling since that's done on to an element. 16:29:20 zcorpan: That is governed by html spec and calls scroll into view algo. 16:29:41 zcorpan: I'm not sure if that's what you're asking. 16:29:53 tantek: I'd be surprised if that works differently as an app dev. 16:30:06 Rossen_: I want to wind this down. 16:30:24 answering my own question from earlier: tab focusing and script focusing appear to have the same behaviors 16:30:56 Rossen_: What you were looking for was alignment between focus and scrolling. It seems your quesiton to impl was answered as either they don't care or they're happy with what they have. Either case, the topic is still open. As fantasai pointed out there are a lot of things ot think about in terms of snapping and how these should interact. 16:31:18 Also, based on the example pasted above, the FF/Edge behavior seems much more intuitive to me. Could be different in different examples, and could be subjective, but for this one and for me, it's very clear. 16:31:22 Rossen_: I suggest we take those new questions back to GH. If not we can work through during F2F. It seems your specific question about focus isn't quite answered. 16:32:06 zcorpan: I think an option for going forward is if we can quickly agree on API share or behavior then trim down prop to be able to disable scrollinng in focus and then JS dev will have to use intersesction observer and scrollintoview. 16:32:41 Rossen__ has joined #css 16:32:43 fantasai: I have no problem with aligning params between focus and scrollintoview. I don't have an opinion on the default, but having the same options is reasonable. My main obj is I think part of the API shouldn't exist, but that's applicable to both. 16:32:48 Rossen_: Agreed. 16:33:51 Rossen_: Again, I was hoping you could get a better answer, but it doesn'tsound like there is one. Let's go back to GH and I invite impl to think what the default should be and if we can align. Focusing is important. people with a11y needs require that quite a bit. I'm going to continue advocating for alignment here. 16:34:36 fantasai: It seems to me there's 3 issues. 1) what's the default? 2) shoudl there be options to change the default 3) those options, should they have params that would override scrollsnap or not. If we override scrollsnap how does that work. 16:34:54 florian: And another where do we care about things that are partially or totally outside the screen. 16:35:04 s/API share/API shape/ 16:35:07 Rossen_: We'll have those recorded in the minutes and if needed we can split into sub issues. 16:35:16 Topic: auto cursor should behaves as default cursor except for text? 16:35:25 github: https://github.com/w3c/csswg-drafts/issues/1598 16:36:30 florian: We've already narrowed problem considerably. It's only about distinguishing things we can't in UA stylesheet. There's two things reopened. WE say one cursor over test, one over everything else. Wee should change that to be one over selectable text. That was in originally, seemed an unintentional omissions 16:37:02 Rossen___ has joined #css 16:37:20 fremy: I can give some background as to why this is useful. I fyou have text inside a buttonn you don't want the cursor to become a text cursor, but you don't want that. To me it seems straight forward and most browsers are doing this. I think that should be in the spec. 16:38:10 florian: I sort of have this in L4. In L4 I put an exception to not look like text cursor. I forgot the other things that imght make the text not selectable. [missed] 16:38:20 Rossen: What is the request? 16:38:48 florian: For a resolution to change the definition of the auto cursor to change on selectable text, not all text. I'll make edits. 16:38:57 and I already +1 that here: https://github.com/w3c/csswg-drafts/issues/1598#issuecomment-335863545 16:39:03 last week 16:39:14 Rossen: That would mean change of behavior...fremy your example. what would the change mean to you? 16:39:33 fremy: We are already doinng this in edge. I think all browsers also. 16:39:40 fremy: This is aligning spec with browsers. 16:39:59 dbaron: Were you going to get to the editable thing? 16:40:04 florian: I wanted that sep. 16:40:27 florian: proposed resolution: Change the definition of cursor auto to look like text over selectable text 16:40:32 +1 https://github.com/w3c/csswg-drafts/issues/1598#issuecomment-335863545 16:40:37 Rossen: Objections? 16:40:49 RESOLVED: Change the definition of cursor auto to look like text over selectable text in css UI 3 16:42:03 florian: Second part is another thing where we may want to align to browseres, but it contridicts previous intention. In the general case browsers change to text cursor over editable, even if it's not next. This is doable in UA stylesheet, but we're interop in not doing that. There's reluctance to change, esp. on Chrome side. Do we want to change or grant an exception for this because we are interop? 16:42:20 Rossen: Opinions? Esp from Chrome? 16:42:25 robertknight_clo_: Do we have anyone from Chrome? 16:42:42 s/robertknight_clo_/rossen 16:42:59 Rossen: I guess there's no one from chrome 16:43:36 florian: Chrome seemed if other browsers commit to change and we push hard they'll do it. They prob don't want to be alone in this. I'd like to hear from Mozilla. 16:43:54 dbaron: I'm fine with having editable thing in spec. It's not 100% clear to me that read/write pseudo does the right thing here. 16:44:06 dbaron: I jut haven't thought through it. I'm okay with the editable exception. 16:44:14 tantek: test case: https://test.csswg.org/harness/test/css-ui-3_dev/single/cursor-auto-005/format/html5/ 16:44:18 +1 similar thoughts to dbaron 16:44:23 thanks florian 16:44:55 fremy: I'm in favor too. It's interop i n all browsers. We can change, but I don't think we need to. I don't think author would expect it and changing something interop could cause problems. My opinion is we should make the change to make things easier for impl. 16:45:05 Rossen: I hear a lot in favor or don't mind. 16:45:19 Rossen: Objections to adding an exception into L3 UI? 16:45:20 so we're saying auto should look like text over editable text? 16:45:25 just trying to understand 16:45:28 tantek: yes 16:45:39 RESOLVED: Add exception for editable text into L3 UI 16:45:42 should -> must 16:45:45 +1 16:45:51 Topic: Percentages and intrinsic size 16:45:59 github: https://github.com/w3c/csswg-drafts/issues/509 16:46:22 ready for CSS3-UI PR? 16:46:25 florian: Briefly on previous, but that prob takes us to a passing test suite and we can begin to move toward rec 16:46:41 zcorpan has joined #css 16:46:41 SGTM 16:46:51 Rossen: fantasai summary? 16:47:31 zcorpan has joined #css 16:47:55 https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333759551 16:47:57 fantasai: There is...the never ending topic keeps branching into variations. The current variation has 2 issues. First is that the resolution we took on % sizing, we made edits that are symmetrical for block and inline axis. Igalia guys said we impl asymmetric. So that's an issue of do we want to change for symmetric. 16:48:03 fantasai: Summary comment ^ 16:48:16 zcorpan has joined #css 16:48:29 fantasai: Basically, I think we resolved this is correc tbehavior, but if someone thinks different we should discuss. 16:48:33 https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096 16:48:38 fantasai: Second is what do we do with % gaps. All options ^ 16:48:48 related to first issue, this comment is also important: https://github.com/w3c/csswg-drafts/issues/509#issuecomment-334437618 16:49:12 fantasai: C and E are terrible. F is impl by chrome. B and D are the ones we're combining. Gecko does A. 16:49:46 fantasai: I don't have a strong opinion, but we should think carefully. We havea mix of impl and we need impl, spec, and authors to agree on best option. 16:49:49 s/we're/they're/ 16:50:37 rego: Regarding first issue, I think the change to make symmetric for columns and rows is contrary to rest of impl. We've been checking options and if we do it we have to do extra passes. We'd like to check if other impl will do that or if we should revert status. 16:50:47 fantasai: Another pass for track sizing algo, or jsut through the items? 16:51:10 rego: We believe it needs another pass of the algo. We were finding some strange issues to resolve that. 16:51:23 Rossen: Are you talking about the % resolution of gaps? 16:51:25 rego: Tracks 16:51:29 Rossen: Okay. 16:51:40 Rossen: And there's no interop? 16:51:49 rego: There is interop, but it's contrary to what the resolution says. 16:52:37 fantasai: It's an intrinisically sized grid with a % size grid track. Does that % resolve. It does with columns, not with rows. Spec says resolve in both axises. 16:52:48 TabAtkins: Current is similar to how block works. 16:52:48 the spec text is: 16:52:50 > then the must be treated as auto, for the purpose of calculating the intrinsic sizes of the grid container and then resolve against that resulting grid container size for the purpose of laying out the grid and its items. 16:53:53 Rossen: But block has nothing to do with grid. We shouldn't define one layout system with a completely different. The original desire to keep things symmetric in grid was based on how a good system should work. it's up to us to decline from that model, that's fine if this is what everyone agrees we should do. but let's not justify current with what we internded. 16:54:29 TabAtkins: Sure. We're just saying block behavior wasn't an accident. It was reasonable to avoid extra layout in common cases. Might not be right for grid, but there was good reason behind our choice to copy it over. 16:55:04 Rossen: Trying for progress. Current proposal is to back out on our original resolution from Seattle and go with the asymmetric one. 16:55:17 TabAtkins: Intention isn't to get a resolution this week, it's to bring it up for talk later. 16:55:44 Rossen: If you're not asking for a resolution, let's keep working on it. We should resolve on this during F2F at the latest. 16:55:46 fantasai: agree 16:55:53 this was the change from the resolution: https://github.com/w3c/csswg-drafts/commit/15cf0c6d56efdbb44383134ebe19dff672b01546 16:56:03 Rossen: We should put a time limit on this. We'll have to get consensus. 16:56:10 It does feel like an issue that would benefit from seeing / discussing diagrams in person at the f2f 16:56:34 Have we made progress on this at previous f2fs? 16:56:40 fantasai: It would be useful for people to think and comment on the GH. Understanding the ramifications of this is most useful if people t hink through use cases and behavior and we're not going to get that around the table. 16:56:42 Rossen: Agree. 16:56:52 Rossen: Did you want to discuss gap % resolution or should we let that go? 16:57:03 TabAtkins: I don't think we'd get that in 4 minutes 16:57:11 Topic: hue-rotate() is being used with unitless zero angle 16:57:17 github: https://github.com/w3c/fxtf-drafts/issues/228 16:57:56 tantek, painfully. I'm not sure diagrams would help, mrego already has some good ones in the issue 16:57:59 dauwhe has joined #css 16:58:10 TabAtkins: When we realized seveal impl support uitless angles we marked out the few to worry about and then said not to do it in the future. Our dev figured out what is used and the only one we didn't consider already is hue-rotate. 16:58:27 TabAtkins: Proposal is we addhue-rotateto the list of functions that explicitly allow a unitless angle. 16:58:35 Savago has joined #css 16:58:36 TabAtkins: I don't believe we need anything else. 16:58:42 Rossen: Options against? 16:59:15 Rossen: We're fine with that. I see dbaron said on GHhe's okay. I +1 his request to add a web platform test with that issue. 16:59:31 Rossen: Objections to accepting hue-rotate as an exception to unitless values? 16:59:43 RESOLVED: Accept hue-rotate as an exception to unitless values 16:59:49 action TabAtkins to add a test case 16:59:53 Created ACTION-865 - Add a test case [on Tab Atkins Jr. - due 2017-10-25]. 16:59:57 Topic: Change default and styling? 17:00:36 TabAtkins: Dominic read an article about and and was wondering if he could change html styllesheet to support them instead of the basic way we do. I think it's okay, but we need yes/no from other people. 17:00:47 florian: There are comments. The problem is when you start nesting. 17:00:52 TabAtkins: Okay. Reasonable. 17:01:09 Rossen: Let's put it back to the issue. There's discussion. We'll bring it back next week. 17:01:16 Rossen: That's the top of the hour. 17:01:27 Rossen: Thank you everyone, we'll talk next week. 17:02:34 TabAtkins, the short answer to Domenic's question is "no" 17:03:17 Yeah, forgot about needing. Makes sense. 17:04:16 Could maybe apply it to the first level, and do scaling/shifting for nested stuff, but that's complex. 17:06:28 tmichel has joined #css 17:06:44 TabAtkins: There were proposals for that, see dbaron's links. 17:06:48 TabAtkins: They were rejected. 17:07:27 TabAtkins: atm, I think the priority is getting myles to fix synthesis so semantics don't break even in basic cases when the font is missing those glyphs :) :) :) 17:08:03 florian has joined #css 17:08:41 florian_ has joined #css 17:11:32 tantek has joined #css 17:15:34 bathos has joined #css 17:30:37 zcorpan has joined #css 17:33:52 zcorpan has joined #css 18:07:25 bathos has joined #css 18:15:32 zcorpan has joined #css 18:43:10 Zakim has left #css 19:02:55 tantek has joined #css 19:09:49 dauwhe has joined #css 19:31:28 dbaron: github-log-bot is not awake? 19:32:01 at least I don't see any bot comment in https://github.com/w3c/csswg-drafts/pull/1805 19:39:33 gtalbot has joined #css 19:41:14 zcorpan has joined #css 19:47:33 gtalbot has left #css 20:04:30 github: https://github.com/w3c/csswg-drafts/issues/1888 20:04:34 trackbot, end meeting 20:04:34 Zakim, list attendees 20:04:42 RRSAgent, please draft minutes 20:04:42 I have made the request to generate http://www.w3.org/2017/10/18-css-minutes.html trackbot 20:04:43 RRSAgent, bye 20:04:43 I see no action items