08:12:40 RRSAgent has joined #css 08:12:40 logging to http://www.w3.org/2016/09/20-css-irc 08:12:42 RRSAgent, make logs public 08:12:44 zcorpan has joined #css 08:12:44 Zakim, this will be Style_CSS FP 08:12:44 ok, trackbot 08:12:45 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 08:12:45 Date: 20 September 2016 08:12:49 Simon Pieters, Opera 08:13:01 present+ 08:13:02 -> https://www.w3.org/WAI/APA/task-forces/css-a11y/work-statement CSS A11Y TF Work Statement 08:13:06 present+ 08:13:08 present+ 08:13:08 present+ 08:13:09 present+ 08:13:09 present+ 08:13:09 present+ 08:13:10 present+ 08:13:11 present+ 08:13:12 present+ 08:13:12 present+ 08:13:12 present+ 08:13:12 present+ 08:13:14 present+ 08:13:15 present+ 08:13:15 present+ Janina 08:13:16 present+ 08:13:16 Dave Cramer, Hachette Livre 08:13:16 present+ 08:13:17 present+ (Francois REMY, Microsoft) 08:13:18 present+ fantasai 08:13:20 Daniel Glazman, Disruptive Innovations 08:13:23 present+ dauwhe 08:13:24 Florian Rivoal, Vivliostyle 08:13:28 Ian Kilpatrick, Google (an Alphabet Company) 08:13:28 Dean Jackson, Apple 08:13:28 present+ (Emil Eklund, Google) 08:13:28 present+ 08:13:28 (Myles C. Maxfield, Apple, Inc.) 08:13:29 present+ 08:13:29 Naina Raisinghani, Google 08:13:30 Chris Lilley, W3C 08:13:32 Simon Sapin, Mozilla 08:13:32 joanie has joined #css 08:13:33 present+ Shintaro Sakahara, BPS 08:13:35 Lea Verou, Invited Expert 08:13:37 Brian Birtles, Mozilla 08:13:39 Rossen Atanassov, Microsoft 08:13:39 Manuel Rego, Igalia 08:13:41 Michiel Bijl, The Paciello Group 08:13:42 Tantek Çelik, Mozilla 08:13:43 present+ 08:13:45 Tomek Wytrębowicz, Starcounter, Poland 08:13:47 Janina: Idea was that we'd organize our work 08:13:48 L. David Baron, Mozilla 08:13:51 https://www.w3.org/WAI/APA/task-forces/css-a11y/work-statement#main 08:13:53 Gottfried has joined #css 08:14:02 Hiroshi Sakakibara, BPS 08:14:02 Janina: Started to see same issue with multiple specs 08:14:05 present+ Takamasa Ikeda, BPS, 08:14:12 Janina: Don't want to hold back CSS, but have some real issues wrt accessibility 08:14:16 present+ Behdad Esfahbod, Google 08:14:16 present+ Gottfried Zimmermann, Invited expert APA 08:14:19 RMurillo has joined #css 08:14:24 janina: Wanted to bring together APA and AR? expertise 08:14:34 present+ 08:14:34 janina: Don't want to go off on our own andmisinterpret the spec 08:14:43 rachelandrew has joined #css 08:14:51 janina: Togther there are certain things we can do that would help, and ltimately solve issues we've identified 08:15:00 janina: For instance, had good success in ARIA WG with mappings 08:15:06 janina: a11y API mapping specification 08:15:20 janina: Worked through W3C process through REC, tested and implemented and implementable 08:15:27 janina: Test and validate your implementation of a11y 08:15:39 janina: Many things can be handled by CSS-a11y mapping, that's why ARIA is involved 08:15:44 jcraig has joined #css 08:15:59 janina: Until a week ago, a11y mappings were owned by ARIA... HTML mappings are their own story 08:16:10 janina: Furthermore, some access among our various members to the various platforms where we are mapping 08:16:18 janina: So if we're missing support on the OS side, have opportunity to do somehting there 08:16:26 janina: Whether that covers everythng, expectation is probably not 08:16:31 janina: May need a Best Practices as well 08:16:36 Present+ jcraig 08:16:42 present+ 08:16:44 janina: But after looking at various issues, group that goes to wok on this can decide what gets handled 08:17:00 janina: Another YAM, best practices, and maybe some tweaks to specs 08:17:00 Present+ 08:17:07 janina: talk about that it coordinated and cohesive manner 08:17:13 Vlad has joined #css 08:17:14 janina: Excited about this, overdue collaboration 08:17:18 -> https://github.com/w3c/aria/tree/master/css-aam CSS AAM stub (will migrate to a new repo soon) 08:17:23 janina: Wrt draft of ?, Michael and I did some work on it 08:17:23 present+ 08:17:34 janina: APA approved it, but it's a starting point 08:17:43 janina: Will have a TF, chairs will appoint facilitators 08:17:51 q+ to mention co-publication 08:17:54 tzviya has joined #css 08:17:55 johanneswilm has joined #css 08:18:02 tmichel has joined #css 08:18:05 johanneswilm_ has joined #css 08:18:07 janina: Expecting group will meet on some regular schedule, a lot of async communication, some telecons, etc. usual range of tools for communication 08:18:18 janina: That's organizational perspective we've put forward 08:18:30 janina: Also had a document prepared for us, making argument for why we though TF was really necessary 08:18:40 janina: Prepared by one of our members who suddenly and unexpectedly is no longer part of W3C 08:18:43 plh has joined #css 08:18:46 janina: Didn't get that email til yesterday... 08:18:57 janina: Was hoping she'd give us a quick overview of the issues 08:19:02 janina: Asked Rich to give an overview 08:19:10 -> https://github.com/w3c/aria/wiki/CSS-AAM-Potential-Features CSS AAM Potential Features 08:20:13 richardschwerdtfeger: OK, so, how this started is we had found some issues where CSS was injecting content, and we didn't have mapping sacross the browsers for that 08:20:21 richardschwerdtfeger: We'd also found issues with Flexbox, working through that 08:20:33 SteveZ has joined #css 08:20:34 richardschwerdtfeger: Have been working with HTML and SVG, and all those languages have mapping specs 08:20:37 present+ 08:20:48 richardschwerdtfeger: Able to make issues, make sure whatyou put in gets mapped 08:20:53 richardschwerdtfeger: Talked with Rossen about how to go about this. 08:21:05 richardschwerdtfeger: Wanted to make sure a11y issues are addressed early on, bc CSS critical to web 08:21:10 richardschwerdtfeger: So platform was crated 08:21:20 richardschwerdtfeger: Don't need mappings for everything, but those things athat are cirtical 08:21:32 richardschwerdtfeger: TF is members of a11y and CSS, addressing a11y issues 08:21:40 richardschwerdtfeger: Make sure that content and presnetation is addressed by WG as a team 08:21:58 richardschwerdtfeger: We haven't agred on TF work state, next step is how do we populate a group that will work on these issues together 08:22:15 richardschwerdtfeger: Was just told by joni diggs (????) who would like to be an editor, but need more than that. Need members of CSSWG 08:22:20 Rossen: I tink that's a great summary 08:22:36 rachelandrew has joined #css 08:22:46 Rossen: I've been communication g what we've talked about with the CSSWG, we have few telecon time slots to tlak about going forward, how to proceed in terms of participating in TF and what TF isactually going to do 08:22:50 johanneswilm__ has joined #css 08:22:54 Rossen: Quick summary for benefit of everying, of what mapping spec is 08:23:01 Rossen: They are fairly different from most specs we do in CSS 08:23:10 Vlad_ has joined #css 08:23:22 richardschwerdtfeger: What peopl opften don't think about when creating Web content is that they're congributing to a software application 08:23:46 richardschwerdtfeger: Every OS has a11y services that communicate necessary nfo to assistive technlogy, e.g. text on screen, role is, how it relates to othe rcontent, where th ekeyboard focus is, etc. 08:23:47 Example mapping spec: https://rawgit.com/w3c/aria/master/core-aam/core-aam.html 08:23:51 richardschwerdtfeger: That info is mapped to platform API 08:23:55 richardschwerdtfeger: On every single OS 08:24:01 richardschwerdtfeger: So write once, accessible on all platforms 08:24:12 richardschwerdtfeger: as long as you write a11y code 08:24:25 richardschwerdtfeger: In CSS, when oy do things like inject content, want to make sure it maps to those serices 08:24:33 richardschwerdtfeger: For HTML ARIA try to make mappings for that 08:24:37 richardschwerdtfeger: We do ...???? 08:24:40 richardschwerdtfeger: Would do same thing here 08:24:49 richardschwerdtfeger: You end up behaving just like accessible software app on that platform 08:24:57 Florian: Since CSS doens't exist in a vacuum but exists on top of HTML 08:25:09 Florian: Mappings we define here, just need to have diff from HTML mapping, right? 08:25:18 richardschwerdtfeger: Yeah fo examppe with content injection in CSS 08:25:29 richardschwerdtfeger: Doens't show up in DOM, there's an OM that shows up. 08:25:37 q? 08:25:47 astearns: Before going into details, ChrisL on the queue 08:25:55 ChrisL: Gone thorugh work statement, in gneral it's fine 08:26:07 ChrisL: One thing that is different from our charter, our charter says that documents ill be co-published 08:26:19 ChrisL: Whereas work statement here is that one group will publish. Sort of uncomfortable 08:26:25 janina: Don't think we meant that, did we ? 08:26:32 ChrisL: Wiling to change? 08:26:36 janina: Yes 08:26:43 ACTION Janina fix charter to co-publish 08:26:44 Error finding 'Janina'. You can review and register nicknames at . 08:26:46 takeshi_ has left #css 08:26:53 dcooney has joined #css 08:27:08 Rossen: I'll try to give quck soummary of work that was identified for the TF 08:27:23 Rossen: Problem statemnt here is that CSS affects the a11y layer in 2 major ways 08:27:42 Rossen: First one is when we end up affecting structure like injecting generated content, or in case of table fixup, more elements that ar mapped 08:27:45 ack ChrisL 08:27:45 ChrisL, you wanted to mention co-publication 08:28:22 Rossen: Second part that we've been having a11y related issues have been when there's visual changes that are drastically different from DOM order, such as flex-order property 08:28:43 https://github.com/w3c/aria/wiki/CSS-AAM-Potential-Features 08:28:47 MichaelC_ has joined #css 08:28:56 Rossen: So in order to get things going, Cynthia Shelly who was MS representative for APA and other a11y groups created a quick outline of all of the modueles that might have a11y issues 08:29:19 Rossen: As you can see, breakages the work that will be covered, related to reading/navigation order 08:29:26 Rossen: Flexbox, grid and positioning are called out explicitly 08:29:27 IanPouncey has joined #css 08:29:46 Rossen: There is generated content and ... 08:30:09 Rossen: Documents of existing features that are implemented 08:30:11 aboxhall has joined #css 08:30:15 Rossen: e.g. Generated content 08:30:25 Rossen: Which is supposted to be accessible, but isn't implemented as such 08:30:49 Rossen: Did some work in Edge recently to address some of these issues. Can attest that this type of work is not all that hard to do, and improves a11y layer a lot 08:30:59 jungbin has joined #css 08:31:05 Rossen: Don't want to list all the specs out loud but this is set of work that has been identified 08:31:10 Rossen: Kickstart discussion 08:31:19 Rossen: I have volunteered myself 08:31:30 Rossen: to join the TF and help the work forward 08:31:37 Rossen: Would be very happy to have other CSS members 08:32:08 astearns: Two questions. One is question of editorship -- who is tasked with putting all the info into the document? 08:32:10 q+ 08:32:20 astearns: Then further question of just participating in the TF, not necessarily writing specs 08:32:21 +1 to address the generated content comment. Pseudoelements are mapped to the a11y layer in Chrome, Safari, (and possibly Firefox?), constituting a majority. 08:32:26 astearns: Are you also volunteering yourself as an editor 08:32:34 q- 08:32:38 astearns: Anyone else from CSS interested in the TF for participation? 08:32:43 astearns: I am definitely interested 08:32:47 astearns: A couple ppl from MS 08:32:53 dauwhe: I'm interested 08:32:53 q+ 08:32:56 jcraig: Me too 08:32:57 bkardell_ has joined #css 08:33:20 iank_: participation wrt Houdini 08:33:29 astearns: Editing? 08:33:50 MichaelC_: I'm intersted, from APA 08:33:58 fantasai: I'm willing to help out 08:34:04 s/a couple ppl/Francois & Greg 08:34:15 fantasai: I think one thing that I should be working on is the Best Practices document 08:34:25 s/MichaelC_/MichielBijl/ 08:34:26 astearns: Was at chairs breakfast this morning, talking about wid reivew esp by groups like APA 08:34:44 astearns: One thing that helped me in my writing is not just having a Best Practices document, with cirteria 08:34:45 s/intersted/interested/ 08:34:50 q+ to ask permission to set up TF infrastructure etc. 08:34:54 astearns: But having a list of questions, like the security questionnaire 08:34:56 q- MichaelC_ 08:35:05 astearns: Short questionnaire so as ppl stat writing specs, they have something to refer to 08:35:08 q? 08:35:13 astearns: Mayb esme of the work in best practices can be done ?? 08:35:28 q+ to address the generated content comment. Pseudoelements are mapped to the a11y layer in Chrome, Safari, (and possibly Firefox?), constituting a majority. 08:35:51 Rossen: I think fantasai was referring to .. we committed last TPAC to write best practices for authors of CSS 08:36:06 Rossen: This is something that will go a long way, I think there will be value of having reference directly from CSSWG 08:36:07 jensimmons has joined #css 08:36:20 s/??/as a short questionnaire on accessibility gotchas that editors can refer to/ 08:36:22 Rossen: Can hold this as formal recommended practices from our POV 08:36:48 ?: I'm willign to collaborate on best practices, so that we refer to each others' documents 08:36:56 q+ to differentate AAM from APG 08:36:57 ?: ARIA authoring practices guide 08:36:59 Matt King, facebook ^^ 08:37:06 > http://w3c.github.io/aria-practices/ 08:37:15 q? 08:37:17 q? 08:37:21 ack MichaelC 08:37:21 MichaelC, you wanted to ask permission to set up TF infrastructure etc. and to differentate AAM from APG 08:37:22 ack MichielBijl 08:37:29 ??: We were focused on a11y mapping specification 08:37:35 rniwa has joined #css 08:37:35 ttp://fantasai.inkedblade.net/style/talks/best-practices/#title 08:37:38 http://fantasai.inkedblade.net/style/talks/best-practices/#title 08:37:39 Karen has joined #css 08:37:42 s/??/MichaelC/ 08:37:47 ??: Not sure that best practices belong in ARIA best practices 08:37:51 s/??/MichaelC/ 08:37:57 Matt: Want to make sure documents are coordinated 08:38:37 MichaelC: What I do with TFs is to set up an ? in formal W3C infrastructure for participation 08:38:43 MichaelC: Will have to talk about ML, anyone object? 08:38:59 ChrisL: Certainly not objecting. In this WG we're trying to move away from MLs to GitHub 08:39:06 ChrisL: Would encouage TF to work on that 08:39:23 MichaelC: Put in link to ? would move t new github repo 08:39:32 MichaelC: Do you want me not to et up an ML? 08:39:40 ChrisL: No, go ahead, useful for some stuff 08:39:45 MichaelC: Didn't want to do without permission 08:39:49 ack me 08:39:49 jcraig, you wanted to address the generated content comment. Pseudoelements are mapped to the a11y layer in Chrome, Safari, (and possibly Firefox?), constituting a majority. 08:39:50 q? 08:39:58 present+ 08:40:04 jcraig: Rossen mentioned pseud-elements mapping to a11y layer 08:40:10 tmichel has joined #css 08:40:11 jcraig: Not true in most browsers... Firefox 08:40:29 jcraig: The issue that Michael just brough that 's interesting is, a separate github repo... 08:40:48 jcraig: I have reservations about accessibility TFs within WGs. 08:41:07 jcraig: It ends up getting groups of ppl siloed, so a11y ppl on one side and CSS ppl not in the TF don't learn about the a11y side 08:41:20 jcraig: My general approach is that this type of work should happen in the main group 08:41:26 q+ 08:41:28 jcraig: I feel that works a little bit better 08:41:33 +1 08:41:37 astearns: I share your concerns 08:41:54 jcraig: separate github repo .. 08:42:11 astearns: I think github repo for deliverables is ok 08:42:19 astearns: My epxectation for TF is that it's a coordination function 08:42:37 astearns: CSS folks in TF wouldn't be only ones doing work, would be the ones outlining the work and drawing in each editor as specs need mapping, adjustment, review, etc. 08:42:54 astearns: On CSS side, ppl not directly on TF, don't assume that you have no a11y work that is going to be assigned to you! 08:42:59 astearns: Just TF ppl will be ones coordinating 08:43:15 q? 08:43:21 ack MichaelC 08:43:30 MichaelC: core stuff about how CSS maps into a11y 08:43:41 MichaelC: Often times a piece of that work will start in that spec, and then needs to move xyz place 08:43:48 MichaelC: I think coordnation role of TF makes that easy to do 08:44:09 MichaelC: TF can set up prefs for access to repo to everyone or just editors or whatever 08:44:18 q? 08:44:20 q+ To give example of mappings w.r.t. generated content and tables 08:44:33 sangchul has joined #css 08:44:50 bobbytung has joined #css 08:44:52 s 08:44:53 q- 08:45:09 Karen has left #css 08:45:13 MichaelC: also want to know if ppl invovled prefer or oppose telecons 08:45:23 Rossen: I'm in favor of starting with light telecon requirements 08:45:28 s/Not true in most browsers... Firefox/Generated content mapped in majority of browsers... Chrome and Safari at least... Possibly Firefox (Joanie responded ~"-ish")/ 08:45:35 fantasai: Maybe monthly? 08:46:19 Rossen: Yeah,s omething liek that. Otherwise work on githup issues etc. 08:46:41 MichaelC: Also what level of checking goes thorugh WG? 08:46:55 MichaelC: e.g. sometiems TF will go to parent WG for each thing 08:47:06 fantasai: probably we'll do both 08:47:33 rniwa_ has joined #css 08:47:35 fantasai: if an issue is a bug fix, then it just gets written 08:47:51 fantasai: if it's a design issue, it will go back to the WG for feedback 08:48:04 fantasai: (to make sure people are paying attention) 08:48:12 fantasai: issue-by-issue basis 08:48:50 j: I imagine it's going to come up regularly to consult with the APA 08:49:12 q+ to +1 for most (all?) discussions happening on GitHub rather than conf calls, as conf calls are imprecise, and inaccessible in both senses of the word. 08:49:27 s/j:/janina:/ 08:49:27 s/j:/janina:/ 08:49:56 Karen has joined #css 08:50:10 nainar has joined #css 08:50:25 jeff has joined #css 08:50:56 ack me 08:50:56 jcraig, you wanted to +1 for most (all?) discussions happening on GitHub rather than conf calls, as conf calls are imprecise, and inaccessible in both senses of the word. 08:51:03 jamesn has joined #css 08:52:09 also +1 technical discussions on GitHub rather than mailing lists. 08:53:25 +1 08:53:32 q? 08:54:11 plh has joined #css 08:54:25 newton has joined #css 08:55:13 cabanier has joined #css 08:56:10 topic: MQ 08:56:37 IanPouncey has joined #css 08:57:08 ChrisL_ has joined #css 08:57:17 olivexu has joined #css 08:58:44 janina: In APA we regularly go over a spec, assign someone to read about a new spec and report 08:58:51 csswg 08:58:57 Rossen: What I was saying is, let's start with the TF as an issue-generator 08:58:57 Rossen: We often have technical discusisons, magine those that require desgin change wil lhave to do with larger participation 08:59:00 MichaelC: We'll ned to pull in... make sure we have expertise from boths ides fo the border. 08:59:03 astearns: At minimum I'd like to see notification, this is whta's been discussed, here's the minutes 08:59:06 nainar_ has joined #css 08:59:06 astearns: In Most cases don't need extra step of "did we do OK" 08:59:09 jcraig: Regardling what's discussed, minutes. 08:59:11 jcraig: I have a lot of trouble following minutes 08:59:14 fantasai: Have you tried following CSSWG minutes? 08:59:16 jcraig: Those are different 08:59:19 jcraig: But in general, easier to follow discussions on github 08:59:21 jcraig: More accessible in all ways 08:59:24 jcraig: Can have full, precise discussion at any time 08:59:25 Karen has joined #css 08:59:26 jcraig: So prefer to have discussion in text on the Web, most accessible 08:59:29 MichalC: That said, when disagreements, often easier to sort out in telecons 08:59:29 q+ 08:59:31 astearns: In CSSWG, as we discuss things on the phone or in F2F meetings, as opinion coalesces, people update github issues to say what we discussed, what we decided, where are the minutes. 08:59:35 astearns: Think that's a good practice going forward 08:59:38 jcraig: Important to summarize, not just link to minutes 08:59:40 [discussion of what to discuss] 08:59:43 janina: Trying to avoid using the word, cuz lots of controversy over attribute, but trying to get beyond that because requirements.... 08:59:46 [jokes about longdesc] 08:59:48 janina: Trying to get beyond that, firstly because we don't like doing things that are opposed by browser makers 08:59:52 janina: Secondly have more general requirements from dpub 08:59:54 janina: Issue is, we want to make it possible for someone who isn't using AT to be aware of e.g. simplified description or braille alternative 08:59:57 janina: We have ways to do this for ppl who use assistive technology 09:00:00 janina: What we're looking for is for ppl who don't use AT to get at that additional information, alternative information. 09:00:03 janina: want them to know that ARIA-details is available 09:00:05 janina: Idea was to make extensions/plugins to experiment 09:00:08 janina: The short-term ask is, can we have an MQ that all it does it says that this element has an extended description 09:00:11 janina: Also looking at extended MQs 09:00:13 q+ 09:00:15 Elliott: what is the aria thing you're talking about? 09:00:18 Elliott: What computes an aria... 09:00:19 AT == "assistive technology" 09:00:28 Elliott: You wanted an MQ on aria-details, what computes aria-details 09:00:30 johanneswilm has joined #css 09:00:33 q? 09:00:38 dbaron: I'm also a little confused that you're asking for an MQ that's asking about the state of an element 09:01:02 dbaron: MQs are about the presentation context, not about qualities of a particular element 09:01:11 dbaron: Were you maybe wanting a selector? 09:01:18 maybe even a pseudo-class? 09:01:42 jcraig: I think that what we were discusisng is related to new aria property that is a string of text that isn't displayed anywhere 09:01:48 jcraig: More or less the same as details and summary in HTML 09:01:50 glazou has joined #css 09:02:33 Karen has joined #css 09:02:46 jcraig: I believe what janina is asking ofr is a media feature that allows you to detect when the user wants to see additional detals 09:03:01 jcraig: If that's the case, then the design, the CSS should be able ot display addition atext 09:03:04 janina: Close bu tnot quite 09:03:22 richardschwerdtfeger: what digipub wants to do is to show extended escriptions o rdrawings on the page 09:03:29 richardschwerdtfeger: This could be alternative formats, coudl be a whole variety of things 09:03:40 richardschwerdtfeger: Problem with digital publish is that by default, publishers don't want this information rendered on the screen 09:03:44 richardschwerdtfeger: But need ability to know that it's there 09:04:01 q? 09:04:03 richardschwerdtfeger: They want to put the conte tin the pages, and they wnat ot e able thte user able to activate a setting i nthe browser, that would tell the book for example, to expose this detailed information with drawings 09:04:12 richardschwerdtfeger: What they're asking for is the ability write a custom media query 09:04:16 richardschwerdtfeger: Maybe through a plugin in the browser 09:04:29 richardschwerdtfeger: So that they could turn on a feature that activeates CSS to expose that t information on the page 09:04:36 richardschwerdtfeger: No opiino in interface 09:04:47 richardschwerdtfeger: Details attribute in ARIA simply says that that extended description is associated with this other thing 09:05:00 richardschwerdtfeger: But publishers want ot not impact the normal visiblity of the page, because they want topreserve the intent of the publisher 09:05:10 richardschwerdtfeger: But for ppl who need the extended info,want to be able to turn that on 09:05:13 newton has joined #css 09:05:20 richardschwerdtfeger: MQs are generally about OS/device capabilities 09:05:23 richardschwerdtfeger: But htis is about preferences 09:05:37 astearns: A suer preerence 09:05:37 q? 09:05:42 bz has joined #css 09:05:42 q- 09:05:42 ack Florian 09:05:48 Florian_ has joined #css 09:05:52 Florian: co-editor, Meida Queries 09:06:03 Florian: dpub was still thinking about this idea yesterday 09:06:03 s/Meida/Media/ 09:06:16 Florian: If it's just about hte dtails element, then seems too specialized for MQ 09:06:33 Florian: But if it's a general "if there's extended descriptions in the page, user wants to see them" 09:06:42 Florian: This goisn into new area of user preferences 09:06:50 Florian: Related to preferences for inverted colors, high contrast, etc. 09:06:55 Florian: We're exploring this category 09:07:05 newton has left #css 09:07:20 Florian: Seems to fall into this category, but for e.g. inverte colors, might be thing wishes to see OR might be thing user wishes to see but might have ben forced by browser 09:07:33 Florian: Wrt details, rowser can't do ti for you, page has to do it itsefl 09:07:44 Florian: Need to epxlore more, but given what we've discussed today 09:07:48 Florian: makes sense to me 09:07:57 Florian: Another thing is custom media queries 09:08:09 Florian: We've also discussed custom MQs, based on whatever JS wants to compute 09:08:14 Florian: I'm not sure how this would work out in this case 09:08:29 Florian: Because in the case of custom Qs, this is the JS in the document talking to CSS in the document viwa MQ 09:08:46 Florian: But for this case, you want the plugin to talk to the page via browser 09:08:47 q+ to ask if custom MQ allows for a defined "taxonomy" of de facto MQ 09:08:54 Florian: It doens't sem to really be custom, seems to be standard 09:08:58 zcorpan has joined #css 09:09:05 riAlso talked about "I would like to render differen tcontent basedon my preference" 09:09:15 ricManagement systems, working on today, have ability to store personal info about hte user 09:09:20 rego has joined #css 09:09:24 richI would say that weuite know exactly what those are going to look like 09:09:37 ricThis is why extending MQ is a better solution, experiment and figure out what we really need 09:09:57 Florian_: If it's about protyping, then yes makes sense for extending 09:10:08 q? 09:10:13 Florian_: We had custom MQs in Level4, but are deferring to L5 because less stable than other stuff in L4 atm 09:10:23 Florian_: ATm unclear whether will go into MQ or Houdini spec in the future 09:10:31 mck has joined #css 09:10:32 Florian_: But definitely on the radar 09:10:45 ack me 09:10:45 jcraig, you wanted to ask if custom MQ allows for a defined "taxonomy" of de facto MQ 09:10:56 Florian_: Tab and I will b eworking on it, will either go into a Houdin doc or MQ L5 which we wil be starting soon cuzwrpaping p L4 nowish 09:11:13 jcraig: ... oggles value of a media feature, tells web page it's ok to expose this info 09:11:38 jcraig: Mentioned working on custom MQs, siilar to data-* attributes in HTML. Allowed to do anything you want, no consistency across websites 09:11:47 jcraig: Is there an affordance here for a standard taxononmy? 09:12:03 jcraig: We'd be discussing something like -epub-prefers-extended-descriptions 09:12:15 jcraig: If there's a list of standard taxononmies, where would that live 09:12:25 dauwhe has joined #css 09:12:33 Florian_: From my understanding this would be about prototyping in a limited context where pl have agreed on common semantics 09:12:57 Florian_: Once it's no longer experimental, no longer needs to be a custom MQ, can be a standard MQ 09:13:11 Florian_: No need for prefixing 09:13:18 Florian_: ... 09:13:24 q? 09:13:27 Florian_: Room fof expermination if it's boolean, epxressis ... 09:13:30 MichaelC_ has joined #css 09:13:38 Florian_: But once no longer prototyping, should be a standard MQ, not a custom one. 09:13:46 Florian has joined #css 09:14:08 astearns: MOve on to navigation? 09:14:32 plh_ has joined #css 09:14:49 q- 09:14:51 q? 09:15:12 [discussion of whether to discuss navigation issue] 09:15:13 myles has joined #css 09:15:54 prototyping sounds like incubation 09:15:58 s/cuzwrpaping/cuz wrapping/ 09:16:01 how do we incubate new media features? 09:16:38 -> https://www.w3.org/WAI/APA/wiki/Category:CSS_Navigation Specs APA thinks are related to the CSS navigation issue (there are more, still need to tag them) 09:17:31 rich: Ther eare times in Flebox where order is improtant to user of AT 09:17:45 rich: What we had was, felxbo was changing thigns visibly on the screen but it wasn't reflected in how it maps to the a11y services layer 09:17:52 rich: You're looking at things in a sequence 09:17:55 rich: that was first par tof the problem 09:17:56 Vlad has joined #css 09:17:59 q? 09:18:07 rich: Second part was that the kyboard navigation idnd't qutie navigation din't follow the visual order on the screen 09:18:14 rich: so someon who is blind and is trying to havigate, didn't make sense 09:18:29 rich: There needs to be a discussion on how that can bee corrected. At hte mapping layers, and also how keyboard navigation is addressed 09:18:42 jdaggett_ has joined #css 09:18:43 rich: we had propose d away to deal with ekyboard nviagtion when necessary, but much more work tha needs to go on in the TF 09:19:02 rich: when do we change the order? Should we change the keyboard order when flexbo vies display on the screen? Etc. That needs to be discussed 09:19:06 astearns: Last item 09:19:08 astearns: Grid 09:19:24 fantasai: we're planning to transition grid to CR 09:19:27 Florian_ has joined #css 09:19:37 fantasai: Emailed you at start of year. I think that's going to happen this week. 09:19:46 fantasai: we emailed you about transitioning Grid to CR, do you have an obj? 09:19:49 fantasai: Wanted to check with you if there's any objections to this transition 09:20:06 -> https://www.w3.org/WAI/APA/wiki/CSS_Grid_Layout_Module_Level_1 APA notes on Grid 09:20:08 rich: Wasn't involved in that discussion, and have sene where grid is mapped correctly 09:20:20 rich: sturcutral information in CSS, need sto be mapped into a11y tree fwith rows/columns 09:20:27 rich: More cpaability to do that in ARIA 1.1 09:20:40 rich: Haven't looked at Grid, things nee dto be looked at in terms of accessbiliyt tree 09:20:41 q_ 09:20:43 q+ 09:20:45 Matt: Want to make a statement 09:20:45 q+ 09:21:16 Matt: So, rich just said that with grid, when affecting structure, need sto be mapped to a11y serices layer 09:21:33 Matt: want to make statmetn that we should nto make any changes to the a11y tree that are also not reflected in the keyboard focus board 09:21:46 Matt: That's very important, that order of a11y tree matches keyboard order 09:21:50 s/board/order/ 09:22:02 Matt: THat's really important for combination of touch and keyboard. Do not separte these two orders. 09:22:10 janina: I think maybe we need TF to make sthis a priority 09:22:21 janina: Since you're going to CR, not blocking, ahppy to be on a plath to a solution 09:22:34 janina: Mor tools to offer, prioritizing is important 09:22:40 astearns: Grid is important 09:22:48 jcraig: Navigation index? 09:22:57 janina: Best summary is Cynthia's document 09:23:20 q- 09:23:23 Rossen: Back to grid question for minutes, what I heard from APA there is no current objection to proceeding to CR, will work thorugh issues in TF 09:23:26 jcraig: nav-index was dropped long ago 09:23:36 Rossen: If any changes come up, we will take... 09:23:44 janina: THis is chair expressing her opnion 09:23:49 q? 09:23:53 ack MichaelC_ 09:23:55 q+ 09:24:11 q- 09:24:18 MichaelC_: Wanted to say that we have a wiki page or every spec that we look at, and our notes on grid are that we did, three onths ago, plan to work on this in the TF. So don't think we were epxecting to object to a transition. 09:24:39 Florian_: Don't know if you're aware of it, there is in CSs4 UI nav-up/down/left/right properties for spatial navigation 09:24:47 Florian_: The ordered variant of the same, nav-next/nav-prev, are not specced. 09:24:57 Florian_: If you would like them to exist, let us know. If yo uthink they'd be terrible let us know as well 09:25:02 Florian_: There si something along these lines in CSS3 UI 09:25:15 jcraig: Tantek just posted that they died a long time ago 09:25:22 tantek: We took nav-index out ocmpletely years ago 09:25:29 tantek: Based on feedback from a11y and other feedback 09:25:34 jcraig: up/down is still there? 09:25:44 tantek: Yes, in multiple implementations, referencd from TV specs 09:25:48 ?: I like that fo SVG a lot 09:25:55 astearns: OK, out of time, thanks 09:25:58 janina: thanks CSS 09:26:04 astearns: CSS will be on break for the next 20 minutes 09:26:12 Thanks all! 09:26:16 janina: APA in our room at 11! 09:26:18
09:26:32 jcraig note: dropped nav-index citation: https://www.w3.org/TR/css-ui-3/#changes-since-2012 09:26:55 jungbin has joined #css 09:28:38 dauwhe has joined #css 09:29:11 tmichel has joined #css 09:31:30 rniwa has joined #css 09:33:03 ChrisL has joined #css 09:33:16 myles has joined #css 09:33:45 MichaelC has joined #css 09:33:49 tmichel has joined #css 09:33:50 plh_ has joined #css 09:33:58 skk has joined #css 09:34:01 rniwa has joined #css 09:34:04 skhrshin has joined #css 09:34:07 dauwhe has joined #css 09:34:10 takeshi has joined #css 09:34:18 duga has joined #css 09:34:18 zcorpan has joined #css 09:34:19 sam has joined #css 09:34:24 shepazu has joined #css 09:34:29 jensimmons_ has joined #css 09:34:37 myles has joined #css 09:35:35 tzviya has joined #css 09:38:21 Karen has joined #css 09:39:06 webex details for the next segment: https://mit.webex.com/mit/j.php?MTID=m0c1976483287cfcf250bf914633bfe36 09:40:15 MichaelC has left #css 09:40:21 takamasa has joined #css 09:40:24 behdad has joined #css 09:42:57 kuettel has joined #css 09:43:15 Manuel has joined #css 09:43:34 https://mit.webex.com/mit/j.php?MTID=m0c1976483287cfcf250bf914633bfe36 09:43:51 takeshi has left #css 09:45:30 rego has joined #css 09:48:05 astearns: jdaggett: https://twitter.com/abrax5/status/776708619043762176 09:48:48 jdaggett: plus the other two things I demoed at atypi 09:49:24 right, saw that one too 09:49:25 jdaggett: full video here: https://www.youtube.com/watch?v=6kizDePhcFU 09:50:16 Demos start at about 1:11:00 09:50:30 network is horrible here, so webex would probably have not been realistic anyway. 09:52:52 github issue for font variations support 09:52:52 https://github.com/w3c/csswg-drafts/issues/498 09:53:29 my little pony discussion needs to be minuted... 09:53:44 glazou has joined #css 09:53:53 John Hudson blog post on variable fonts 09:53:54 https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369#.u93slo7n5 09:54:18 rachelandrew has joined #css 09:56:07 Gottfried has joined #css 09:57:32 IanPouncey has joined #css 09:59:19 ChrisL has joined #css 10:00:48 mck has joined #css 10:02:23 Florian has joined #css 10:02:38 sergeym has joined #css 10:02:48 Vlad has joined #css 10:02:48 ScribeNick: TabAtkins 10:02:55 kochi has joined #css 10:03:18 behdad: Last week at atypi we announced, with Apple, Google, MS, Adobe, we announced opentype 8, the biggest change since it first happened. 10:03:33 behdad: Biggest addition is variation fonts. I'll show a demo, then Myles and John will discuss the implications for CSS. 10:03:37 s/8/1.8/ 10:03:53 behdad: Our current fonts are scalable in size. VAriation fonts bring that same scaling to other aspects. 10:04:06 [shows a width varation, then a weight] 10:04:18 behdad: Look at dollar sign, it changes to a difference design based on the weight. 10:04:21 (applause) 10:04:33 behdad: Similar demo of Arabic script. The ligature and combining marks just work. 10:04:51 behdad: This isin't new, it's based on Apple tech from the 90s. Adobe multiple masters is very similar as well. 10:05:01 behdad: But for the first time it's in OpenType, and extended to handle OT layout. 10:05:09 (Apple TrueType GX) 10:05:18 behdad: Designers have already been designing with interpolation, they just export to flat/individual instances. We're bringing it to runtime. 10:05:31 behdad: While we bless the most common interp axises, the tech supports arbitrary axises as well. 10:05:44 frremy has joined #css 10:05:49 bobbytung has joined #css 10:05:54 behdad: Here's a western font with axises that change several aspects of the font. 10:06:06 dino has joined #css 10:06:09 [changes the buttons, the joints, the way the serifs look] 10:06:16 [behdad shows example of font with circular holes, the etra axis changes the holes from round circles to squares] 10:06:24 behdad: So in CSS we need to hook up weight, width, and other "standard" axises. Then arbitrary axises. 10:06:30 Example of a family using different axes 10:06:31 weight and contrast 10:06:32 http://typeproject.com/fonts/tpmincho 10:06:39 behdad: And really interesting applications is responsive design. Like adjusting the params to fit text into a space. 10:07:12 myles: Two reasons this is valuable to add to CSS. 10:07:15 (applause) 10:07:17 myles: First is you get super-great typography. 10:07:44 q+ 10:07:46 myles: Likely the axises will affect weight and stretch. Currently very common for websites to have the same font in multiple weights/stretches. Now they can just have one font. 10:07:58 myles: Current thinking for how to plug this into font selection breaks down into three pieces. 10:07:59 rniwa_ has joined #css 10:08:13 newton has joined #css 10:08:18 myles: These variations are not OT features - that's something different. They interact, but reusing font-feature-settings would be a mistake. 10:08:22 myles: These sliders are called axises. 10:08:34 myles: The current thinking of how to map these to CSS is to break down the sliders into three pieces. 10:08:45 myles: First is axises that affect font selection - weight, width, stretch. 10:08:54 myles: These are important because we already have proeprties that affect font selection. 10:09:08 weight, width, slant 10:09:08 myles: So all three of them dont' have a concept of floating point values. 10:09:17 newton has left #css 10:09:19 dcooney has left #css 10:09:28 myles: So presumably some value would be assigned, so if you say "give me a bold font", a variation font could be selected, and then made bold. 10:09:35 myles: So an extra stage in font selection. 10:09:49 myles: Those three are expected to be the most common axises. 10:09:57 mck has left #css 10:10:00 myles: Set 2 is common axises that dont' affect font selection. 10:10:06 myles: One example is optical sizing. 10:10:16 myles: No existing properties, we'll likely add new ones with associated syntax. 10:10:24 myles: Set 3 is low-level arbitrary axises. 10:10:29 myles: Where author can specify whatever name. 10:10:47 myles: This is important, because in OT, if you make a font you can respond to any axis, even if it's not registered in a spec. 10:10:50 tantek has joined #css 10:11:04 myles: So conceptually this is similar to font-feature-settings, but this is meant for variations, and will take a floating-point rather than an int. 10:11:06 q+ 10:11:11 myles: So that's basic thinking for mapping. 10:11:26 myles: I've written a draft spec which isn't in the repo yet. 10:11:45 q+ 10:12:02 myles: Rather than merging draft text into Fonts 4, there are a fair number of high-level issues to resolve (like how to make @font-face respond to this) 10:12:19 myles: We'd discuss this in GH in issue trackers, and when it dies down then I'd write some text and start adding it to level 4. 10:12:21 q? 10:12:28 myles: There's one piece I forgot to mention 10:12:29 q+ 10:12:40 https://github.com/w3c/csswg-drafts/issues/498 10:12:51 myles: Witht he font selection I mentioned - if you're on an old browser that doesn't support variations, and you tell it to use this variation font, 10:13:03 myles: You'll say "apply bold", the browser doesn't know how to, so you'll get a normal version. 10:13:14 draft spec (fork of css fonts 3, but intended for fonts 4) https://github.com/litherum/csswg-drafts/commits/variationfonts 10:13:21 myles: So maybe an addition to the format specifier so an older browser doesn't even download them if it doesn't know how to use them. 10:13:29 q? 10:13:39 glazou: First, congrats. 10:13:51 q+ 10:13:52 glazou: As I understand, this is going to be useful for responsive design. 10:14:06 glazou: ONe of the thing I'd like to avoid is flickering when the font changes at a boundary in your responsive design. 10:14:16 glazou: ONe way of doing that is to do transitions on the font axises. 10:14:32 glazou: If you can make that property animatable in CSS, that would be really awesome. 10:14:39 myles: Being able to animate is a stated design goal in this. 10:14:46 q- 10:14:48 glazou: Good. I wanted to mention because it has deep implications. 10:14:53 Florian: Also this is great. 10:14:57 ack gl 10:15:03 Florian: I wanted to clarify - how would font selection work? 10:15:22 Florian: Would youb e able to declare a range of weights to use this font, like 100-600, but for 800 use this old-fashioned one? 10:15:32 NavidZ has joined #css 10:15:35 myles: There are at least 2 models for how this would work. 10:15:39 myles: Many different parties with diff ideas. 10:16:01 myles: Web authors that are font designers, and like TypeKit serving fonts. 10:16:16 myles: We have not reached consensus, in short. 10:16:18 It doesn't seem to me that responsive design would be a use case for animation. While people like demoing how responsive designs respond to resizing, the point is that it is a good design at any particular static size. 10:16:30 Vlad: Variation fonts would likely have named instances. 10:16:40 (that's a response to glazou's comment) 10:16:51 dbaron: and indeed things frequently get confusing when resizing due to movement of content 10:16:56 Vlad: In the scale, there will be certain points in the axis with a name assigned. You say "bold", the browser may not know the variation scale, but there will be a value known as "bold". 10:17:01 certainly may be other use cases, though 10:17:03 Vlad: But I'm not sure there's a mechanism to query a font for that. 10:17:03 joanie has left #css 10:17:19 myles: Axis discovery is related but somewhat distinct. 10:17:30 myles: Font feaetures are similar. And there's no mechanism for discovering those features. 10:17:32 dbaron: imagine a emoji font where the smile/grin mouth is set by a font axis ; transitioning that would be awesome 10:17:49 myles: It might be possible to go down that road. I'd like to consider them as related but separate topics. 10:18:13 Vlad: I think variation is a little bit trickier. 10:18:33 behdad: The CSS shorthand routes into the font, and there is @font-face for the name instances, same as for @font-feature-settings. 10:19:02 myles has joined #css 10:19:06 Vlad: Question: related to responsive typography. 10:19:21 SteveZ has joined #css 10:19:27 Vlad: You ahve a font with width variation, and idea is that when you resize the window or column, you apply a smooth width variation. 10:19:38 q? 10:19:40 Manuel_ has joined #css 10:19:41 Vlad: Reflows can be very objectionable when text jumps. 10:19:42 johanneswilm has joined #css 10:19:43 ack vlad 10:19:46 I think he meant the font provider's CSS generator generating @font-face rules rather than the CSS shorthand parser. 10:19:57 Vlad: But what I didn't see in the spec is the mechanism that connects window information back to font variations. 10:20:22 Q+ 10:20:22 q? 10:20:30 ack ChrisL 10:20:40 ChrisL: I'd like to reiterate that animations/transition will be great for this. 10:20:49 ChrisL: ONe thing not mentioned yet is that system fonts will ahve variations. 10:21:07 ChrisL: So you'll set a fallback font and set its width/weight/etc, so less of a "jump" when your downloaded font loads in. 10:21:18 astearns: Doesn't that depend on the system fonts being quite similar? 10:21:29 ChrisL: Right, ti's the same problem as having Arial vs Helvetica. 10:21:52 astearns: Right, wondering if we need a way of seting up system fonts *per system*, so it's known to match. 10:21:53 q+ 10:21:59 myles: There's a GH issue for that. 10:22:09 q+ 10:22:12 q+ 10:22:12 ChrisL: There's a detailed proposal in the GH for that. 10:22:30 ChrisL: This is just gonna change things so much. 10:22:33 rachelandrew has joined #css 10:22:40 eae: let me see 10:22:43 https://github.com/w3c/csswg-drafts/issues/498 10:22:46 q- 10:22:49 ChrisL: Instead of downloading 4 fonts and wishing there wer emore weights, you jsut do one and get 7 weights, etc. 10:23:09 ChrisL: What we really want is to get approval from the group to move into Fonts 4. 10:23:22 astearns: Proposed resolution is to take what's written and move into CSS4 Fonts. 10:23:34 dbaron: Are there other substantial features in Fonts 4? 10:23:36 fantasai: Yes. 10:23:40 bz has joined #css 10:23:44 dbaron: How likely is is to progress relative to those? 10:23:56 ChrisL: Similar. Chromatic fonts there right now. Gonna run on similar timescale. 10:24:13 fantasai: Small set of simple features that have been added, then palette colors and whatnot. 10:24:24 astearns: And when we find that things progress slower, we'll move them around. 10:24:29 q- 10:24:36 jdaggett: I think the underlying tech here hasn't been implemented on platforms yet. 10:24:57 jdaggett: I think it's complex enough that issues will come up in the spec itself. Relative to other Fonts 4 features, this... 10:25:07 eae: https://github.com/w3c/csswg-drafts/issues/126 10:25:08 q- 10:25:25 ChrisL: I agree it hasn't quite shipped, but at the announcement last week there were OS companies and font foundries saying they were adding it. Adobe added a rasterizer to FreeType. 10:25:34 ChrisL: Much more ready than one would expect. 10:25:43 behdad: OS 10.12 shipped San Francisco as a variation font. 10:26:05 astearns: Things will shift, but do you think we should keep it out of Fonts 4? 10:26:17 jdaggett: My concern is that the APIs for supporting them ahven't been laid out completely. 10:26:26 jdaggett: I think there are issues of how impls will be able to support this. 10:26:40 jdaggett: I think it's fine for Fonts 4, but there could be, it could take longer than other features. 10:26:59 ChrisL: We have things where we want to freeze a particular spec where a delta is hard to read, and this is effectively that. 10:27:08 ChrisL: Like, Fonts 3 needs to have been shipped yesterday. 10:27:17 ChrisL: ONly definition of @font-face, and way past due. 10:27:27 astearns: I don't think it slows down Fonts 4? 10:27:30 newton has joined #css 10:27:33 ChrisL: But then you need to track changes. 10:27:37 myles: I'm willing to do that. 10:27:42 q? 10:27:43 newton has left #css 10:28:08 TabAtkins: Given this is a brand new feature under heavy changes, this seems like a great hting to work out in the WICG 10:28:13 Manuel_ has joined #css 10:28:22 TabAtkins: Prefer to move new ideas into WICG instead of putting them into a spc with ther features 10:28:31 TabAtkins: Want to talk it out on a lower-volumen list 10:28:43 astearns: Lower volumen list, but also a different list tha needs for ppl to subscribe to 10:28:52 s/hting/thing/ 10:28:59 ChrisL: What's the benefit here? We have the font ppl here, and CSS ppl here. 10:29:03 q+ to ask if we should then make css-font-4 a FPWD. 10:29:12 ack TabAtkins 10:29:16 TabAtkins: Didn't want to mix up this feature with unrelated features like font palettes 10:29:28 TabAtkins: The point here is to have smaller groups that are more focused 10:29:41 leaverou: If everyone in the CSSWG joins WICG group, how is that smaller? 10:29:53 I think this feature will affect some fairly fundatmental CSS features 10:29:56 Side comment I forgot to mention: variation fonts have significant size saving for webfonts. 10:29:58 TabAtkins: Not everybody would join 10:30:00 q? 10:30:07 Rossen: WICG is a separate topic 10:30:08 font properties and @font-face rule 10:30:10 q+ 10:30:13 Rossen: Discussiong FOnts 4 10:30:13 I mentioned the size savings earlier 10:30:14 q+ 10:30:17 ack SteveZ 10:30:22 Bert: I think good idea to put this into the draft 10:30:23 ack SteveZ 10:30:29 ack Bert 10:30:29 Bert, you wanted to ask if we should then make css-font-4 a FPWD. 10:30:34 Bert: But should make the draft official draft fo the WG 10:30:42 fantasai: I thought we had an outstanding resolution to publish 10:30:43 ack Vlad 10:31:04 Vlad: I'm not concerned about ppl in this room, concerned about ppl who ar not in this room but are subscribed to the list. 10:31:16 jcraig has joined #css 10:31:18 list? www-style? 10:31:19 Vlad: I would be concerned that people would not be following 10:31:27 q+ 10:31:33 Vlad: Concerned about independent font dsigners, who have a lot of work on their main jo oto do 10:31:43 agree with vlad 10:31:45 Vlad: We have a lot of good participation on www-style from John Hudson, etc. 10:31:53 astearns: We would notify the list, obviously. 10:31:53 how to include type designers is critical 10:31:58 agree with vlad too 10:32:32 fantasai: Irt whether Fonts 4 or WICG, something we can do for shorter-term features is just... rename the current draft to Fonts 5, merge in the small features to the current Fonts 3, make that Fonts 4. 10:32:55 fantasai: Then we can just take like min-font-size, and system-ui font. They can go to CR as soon as editting is done. 10:32:58 q? 10:33:02 ack fantasai 10:33:08 ack ChrisL 10:33:27 ChrisL: I feel that one of the benefits of ahving WOFF going, is having type experts like John Hudson contribute to this. 10:33:53 ChrisL: I don't want to dilute things by moving off to another group. 10:34:28 q? 10:34:28 hmm, aren’t we using github issues for discussions?!? 10:34:44 jdaggett, yes we are 10:34:44 TabAtkins: If they want to follow all of CSS--fonts plus non-fonts-- then they should be okay to follow fonts plus non-fonts in split groups 10:35:01 so what’s the fire hose… 10:35:17 astearns: It's not a new module. It's just adding stuff ot a module we already have, and it's pretty well integrated with the text we have in FOnts L3 10:35:28 ah, ok 10:35:28 astearns: So keeping it in our module system seems easier for the eidotrs 10:35:44 astearns: And everyone working on it has expressed an interest in keeping it in github 10:36:00 astearns: Tab, you're free to object, but in this case I think we should keep it in house 10:36:18 astearns: As a different argument, we were talking about koji's propsoal for ste-psizing, and takng that to incubation 10:36:20 jamesn has joined #css 10:36:23 astearns: I think it would be appropriate there. 10:36:33 astearns: I would like to decide now to keep it in the group, will you object? 10:36:37 ericwilligers has joined #css 10:36:40 TabAtkins: I object 10:36:45 ChrisL: Then we have to recharter 10:37:05 ChrisL: The charter says, that for each new deliverable we have to have consensus to add it. If there is a sustained objection, we're required to recharter. 10:37:20 TabAtkins: I'm not saying it doesn't go into fonts, I'm saying it goes to WICG first, and then we put it into fonts 10:37:25 TabAtkins: I'm not objecting to a new deliverable. 10:37:27 I'm going to point to this related proposed break out session for tomorrow: https://www.w3.org/wiki/TPAC2016/SessionIdeas#Incubation_as_the_New_Normal 10:37:50 Florian: Current practice of the WG hasn't been to use the WICG 10:37:58 Florian: If we want to... 10:38:11 Gottfried has left #css 10:38:18 Florian: If we want to do this, we should have a discussion about this topic, not about Fonts specifically. 10:38:33 +100 to Florian 10:38:35 Florian: Until we have that discussion, then we should follow the usual process that we have in this group 10:38:50 Florian: If we need to pause everything and have that discussion now, fine. 10:39:11 TabAtkins: I don't think we should take up time during the F2F for this discussion. 10:39:51 astearns: We have no more time to this. We had a proposal. We had an objection. We are going to do nothing. 10:40:11 myles: Nobody likes this. Nobody in the whole world thinks this is a good idea. 10:40:35 leaverou: So Google is stalling process until we change the process to be the way Google wants 10:41:26 Florian: And moving to a process where consensus doesn't apply 10:41:40 Vlad: So we have a procedural objection, but no substantive objection. 10:41:59 RESOLVED: We will work on font variations. 10:42:43 I believe Vlad (or someone else) also said something like "there's consensus to work on it, but not consensus on where to work on it" 10:43:22 who is minuting? 10:43:30 s/stalling process/stalling progress/ 10:43:42 rachelandrew has joined #css 10:43:43 what's the URL of this spec? 10:43:44 jihye: [missed some intro] 10:43:55 jihye: There are two new properties - offset-position and offset-anchor. 10:44:04 jihye: offset-position defines where the path starts in the container 10:44:06 https://drafts.fxtf.org/motion-1/ 10:44:07 oh, it's https://drafts.fxtf.org/motion-1/ 10:44:17 jihye: offset-anchor defines where on the element starts on the path. 10:44:58 newton has joined #css 10:45:21 (shane draws) 10:45:33 jihye: There's a problem when we put these into the shorthand. 10:45:39 https://drafts.fxtf.org/motion-1/#offset-shorthand 10:45:47 jihye: The shorthand is now ambiguous. 10:45:53 https://usercontent.irccloud-cdn.com/file/NnZEDgV4/IMG_20160920_114516.jpg 10:45:57 Zakim: lolwut 10:46:19 zakim: ack 10:46:31 ack https://drafts.fxtf.org/motion-1/#offset-short 10:47:15 jihye: Both offset-rotation and offset-path have an , and offset-position and offset-anchor have . 10:47:22 jihye: So they're ambiguous. 10:47:32 jihye: Shane proposed to use a ray() function in offset-path. 10:47:37 Florian has joined #css 10:47:50 ray( && ? && contain? ) 10:48:19 jihye: With this, it cancels the ambiguity. 10:48:25 ACTION jihye change offset shorthand to use || instead of && 10:48:26 Created ACTION-793 - Change offset shorthand to use || instead of && [on Jihye Hong - due 2016-09-27]. 10:48:26 jihye: Next is ambiguity. 10:48:46 antonp has joined #css 10:48:46 offset-distance also has conflicts with the position values, no? 10:48:47 jihye: ONe solution is getting rid of offset-position/anchor in the shorthand (it resets, but can't be set). 10:48:54 jihye: Another is use to slashes to separate. 10:49:19 TabAtkins: 1st option is drop -position and -anchor from shorthand, so get reset but can't get set 10:49:27 TabAtkins: Other option is to use slashes 10:50:00 fantasai: There's another issue - the offset property should be resetting top/left/bottom/right. 10:50:22 TabAtkins: This is a name collisions, they're not actually interacting. 10:50:28 dauwhe_ has joined #css 10:50:44 shane: offset-path feeds into Transforms. 10:50:53 fantasai: Okay, we might need to rethink the naming of one or both. 10:51:01 shane: We had shipped when it was named motion-path. 10:51:03 https://drafts.csswg.org/css-logical-props/#propdef-offset-block-start is a bit of a naming collision 10:51:11 shane: We just put thru a rename, as early as we thought we could. 10:51:23 shane: We'd be increasingly concerned about changes to the names. 10:51:38 TabAtkins: While the logical t/r/b/l isn't implemented by anyone. 10:52:00 TabAtkins: I'm in favor of just taking out of the shorthand; most of the time defualts work just fine 10:52:16 shane: I got some impl feedback from Eric Willigers, chrome impl. 10:52:33 dauwhe_ has joined #css 10:52:52 shane: He did some demos. He said most of them, he has to manipulate top/left (because we don't have offset-position implemented yet). 10:53:02 shane: So that suggests offset-position is frequently used. 10:53:16 shane: And it suggests the ordering - offset-position first, then offset-anchor? 10:53:25 TabAtkins: Makes sense to me. 10:53:27 myles has joined #css 10:53:48 astearns: If we're introducing a slash for position, might as well do it for anchor. 10:53:55 TabAtkins: Oh yeah, once we've paid the cost, we should go all the way. 10:53:59 astearns: Any objections? 10:54:25 is there a GH issue on this? with history? 10:54:28 dbaron: This is getting complicated syntax. 10:54:32 I'm having trouble following :/ 10:54:47 s/complicated syntax/to be a complicated microsyntax/ 10:54:52 I'd like to see a proposal in a GH issue if possible 10:54:59 https://github.com/w3c/fxtf-drafts/issues/24 10:55:07 thanks ericwilligers 10:55:24 offset: || || [ / [ / ]? ]? 10:55:37 offset: [ || || ] [ / [ / ]? ]? 10:55:54 tantek: also https://github.com/w3c/fxtf-drafts/issues/42 10:56:15 fantasai: What if you just want to do an offset-position? 10:56:20 TabAtkins: That's the same as just doing a translate. 10:56:26 fantasai: Hmm, that doesn't match my recollection. 10:56:32 svillar has joined #css 10:56:48 shans, you haven't shipped the shorthand, have you? 10:57:04 I'm a little concerned about a mixture of spaces and '/'s for separation 10:57:16 svillar has left #css 10:57:24 sounds confusing, like the 'font' shorthand (which I still can't remember reliably enough to use :p) 10:57:49 svillar has joined #css 10:57:53 https://drafts.csswg.org/css-fonts-3/#propdef-font 10:58:13 I'm not convinced the syntax that Tab wrote above is even unambiguous 10:58:14 fantasai: From what I recall discussing, if everything else was set to its initial value, offset-position would be setting the absolute position of the box with respect to the containing block. 10:58:23 fantasai: This makes it a useful positioning system, independent of the other values 10:58:38 fantasai: And so the shorthand should be able to accept only a position, to allow for it to be used as such. 10:58:43 TabAtkins: You can't just use translate for that 10:58:50 since offset-path has bits that conflict with the other two (or at least one of them) 10:59:06 fantasai: translate can't reference the size of the containing block 10:59:11 fantasai: It's not the same thing at all. 10:59:28 s/size/size and position/ 10:59:58 fantasai: We integrated a proposal that could do many things. 11:00:05 fantasai: We were expecting to use certain parts together. 11:00:16 fantasai: It would be less common that using just path, etc. 11:00:30 fantasai: So what we need for the shorthand is look at what people actually want to specify, and make those easy. 11:00:39 fantasai: So setting just position looks common. 11:00:45 fantasai: And setting a path with distance + rotation. 11:00:52 shane: That will usually require a position, too. 11:01:17 shane: If the path is an SVG path, you can get similar effect by using a M command. But the other path types can't do that. 11:01:44 shane: And using the keywords for positioning, you can't be relative to the containing block. 11:01:49 https://drafts.fxtf.org/motion-1/#propdef-offset-path 11:01:54 fantasai: So we can use positioning information rather than slashes everywhere. 11:02:25 fantasai: So like start with offset-position first. Then path/rotation. Then distance. 11:02:48 fantasai: Then after you can have the anchor. 11:02:53 offset-path changes to => | ray( ? && contain?) | [ | ] || | none 11:02:57 shane: You still have anchor, so we can leave it out or use a slash. 11:03:16 fantasai: I guess you'd put a slash before anchor. 11:03:23 frremy_ has joined #css 11:03:26 myles has joined #css 11:03:28 shane: jihye could speak to common polar positioning uses. 11:03:38 fantasai: location, direction, distance along the ray. 11:03:47 shane: jihye, how common is it to set anchor in polar positioning cases? 11:04:10 jihye: I think center is the common thing. 11:04:38 jihye: Default value for anchor is "auto". When I described some use-cases, I found center is more useful than "auto". 11:04:48 fantasai: WE made it auto so the position would function the same way as for backgrounds. 11:05:26 jihye: That's useful when path is specified with angle; when you're using the other value types, like circle(), you have to adjust every element which is on the circle path. 11:05:37 bobbytung has joined #css 11:05:38 s/when/but when/ 11:05:58 astearns: So this sounds like we do still need anchor with a slash. 11:06:12 astearns: So it sounds like we can put position first, use ray(), then the rest, then / with anchor. 11:07:02 TabAtkins: I might say leave anchor out entirely - it's like transform-origin, and that's a separate property. 11:07:41 fantasai: Yes, but it seems that switching between auto and center would be reasonably common 11:07:59 TabAtkins: That suggests that "auto" can just do the bg-pos thing when path is "none", and otherwise be center. Then you rarely need to touch it at all. 11:08:29 Am I understanding correctly that 'offset-position: auto' is like relative positioning and 'offset-position: ' is like absolute positioning? 11:08:41 yes, exactly dbaron 11:08:55 I think that section of the spec could be a bit clearer, then. 11:09:12 shane: Almost all examples use offset-anchor:center. It's by far the most common thing to do when you position on a path, sounds most common when it's polar as well. 11:09:27 shane: It's okay to make this work okay for positioning as well, but all the rest requires center as the default anchor. 11:09:54 fantasai: So "center" as the initial value? That's fine. 11:09:55 I still don't understand what offset-anchor: auto combined with offset-position: auto does 11:10:06 fantasai: I think switching it when path is none vs other is confusing. 11:11:17 fantasai: We can do something like have it default to bg-like when you don't have a path in the shorthand, center otherwise. But not base it on the actual value of path. 11:11:40 TabAtkins: I think we generally dislike magic in the shorthands; we've used it before, but usually want to handle it at the value level. 11:12:40 astearns: Running out of time. Let's fix up resolutions. 11:13:03 RESOLVED: Switch the polar-positioning part of offset-path to be a ray() function. 11:14:24 ? [ [ || ] [ / ]? ] 11:15:20 q? 11:15:28 RESOVED: Position before path before distane and anchor 11:15:32 s/distane/distance/ 11:15:49 s/RESOVED/RESOLVED/ 11:16:47 andrey-rybka has joined #css 11:26:17 I filed https://github.com/w3c/fxtf-drafts/issues/45 and https://github.com/w3c/fxtf-drafts/issues/46 on my issues. 11:38:33 WalterTamboer_ has joined #css 11:48:55 liam has joined #css 11:49:48 newton has joined #css 11:50:11 duga has joined #css 11:53:29 dauwhe has joined #css 11:54:30 rego has joined #css 12:00:08 bobbytung has joined #css 12:00:34 jensimmons has joined #css 12:04:23 takeshi has joined #css 12:05:19 tzviya has joined #css 12:14:42 myles has joined #css 12:21:18 Karen has joined #css 12:24:59 glazou has joined #css 12:29:25 Florian has joined #css 12:29:50 bkardell_ has joined #css 12:33:40 rego has joined #css 12:34:09 rachelandrew has joined #css 12:35:25 frremy has joined #css 12:35:42 ScriberNick: frremy 12:35:51 ChrisL has joined #css 12:36:03 myles has joined #css 12:36:09 Topic: CSS Scroll Snaps disposition of comments 12:36:32 fantasai: we have one open issue, which is scroll padding 12:37:01 Florian and fantasai: deciding who to present 12:37:16 Rossen: Matt wanted to be able to join for this issue 12:37:30 https://github.com/w3c/csswg-drafts/issues/156 12:37:32 Rossen: let's change the order of topics 12:37:57 fantasai: another issue is the event model 12:38:17 fantasai: the proposal is to defer this to the next level 12:38:21 Rossen: any objection? 12:38:51 TabAtkins: I would rather have scrollsnaps as soon as possible 12:39:06 Rossen: since there are no objection, let's call this resolved 12:39:19 RESOLVED: Defer the event model to the next level 12:39:43 Florian: If you try to snap to something beyond scrolling reach, what happens 12:40:13 fantasai: the snap position is changed so that it becomes in range 12:40:39 Florian: my understanding is that is says precisely how you snap 12:40:47 Florian: but now whether you should do it 12:40:56 Florian: another part seems to indicate you don't 12:41:05 Florian: because the "corridor" is not defined 12:41:34 fantasai: since you *shift* them inside range, they are 12:41:56 Florian: ok, this didnt used to be written this way when I filed the issue 12:42:05 Florian: I am convinced by the explaination now 12:42:26 Florian: I'll review again and will return if I find anything else, but its ok for now 12:42:40 Topic: Media Queries 12:42:47 Florian: 4 issues 12:43:07 https://drafts.csswg.org/mediaqueries/#issue-d9e3b586 12:43:14 Florian: Issue 3 needs to be discussed 12:43:18 Rossen: the color one? 12:43:21 Florian: yes 12:43:43 Florian: should we have a "shitty" color one, when you support colors, but poorly 12:44:00 dbaron: we already have grayscale btw 12:44:18 Chris: what would you do in that case? 12:44:48 dbaron: there is one for srgb 12:45:17 ChrisL: still not sure what the author could do with it 12:45:26 jcraig has joined #css 12:45:34 Florian: I am not arguing in favor, just trying to make sure we considered 12:45:47 q? 12:45:55 ChrisL: we want to go up, not down 12:46:18 LeaVerou: contrast ratio could be different 12:46:33 LeaVerou: so you might want to adapt 12:46:55 dbaron: there are more than just "non-srgb" and "close-to-srgb" 12:47:06 LeaVerou: how about a percentage of coverage? 12:47:21 Florian: any measure won't be expressive enough 12:47:44 LeaVerou: it's not perfect but looks sufficient 12:47:51 bz has joined #css 12:48:06 Florian: how about one point "less srgb but still better than usual"? 12:48:33 fantasai: we should have a note 12:48:43 fantasai: explaining what matches what 12:48:58 explaining what it means to match not sRGB 12:49:03 dean: the issue is also browsers that just do not support the media query 12:49:05 which is implied by the spec, but not clear to readers 12:49:23 dean: if you try to detect "not-srgb" 12:49:33 tantek has joined #css 12:49:36 IanPouncey has joined #css 12:49:36 Florian: it is a general issue 12:49:45 s/contrast ratio could be different/Devices with small gamuts typically display colors as less saturated/ 12:49:45 skhrshin has joined #css 12:49:47 takamasa has joined #css 12:49:57 dean: but not makes it worse 12:50:13 Rossen: proposed resolution is then to resolve as wont fix 12:50:22 Rossen: no objection? 12:50:36 RESOLVED: do not add a less-than-srgb mq 12:51:02 Florian: other issue: script mq 12:51:21 Florian: how about engines that run scripts, but only until some point (like printed) 12:51:25 ericc has joined #css 12:51:41 skhrshin has left #css 12:51:42 Florian: if the MQ doesn't tell you that it is supported, the MQ isn't very useful to depend on 12:52:08 Florian: maybe a value would be great 12:52:10 is there a link for the proposal / GH issue? 12:52:19 Florian: but defining the theshold is tricky 12:52:34 Florian: but if we define a threshold might force user agents to lie about it 12:52:46 Florian: so we should probably keep it fuzzy 12:53:06 Florian: we discussed but we didn't resolve on that last time 12:53:21 tantek: any pointer to the old discussion? 12:53:28 Florian: nope, sorry 12:53:49 https://drafts.csswg.org/mediaqueries/#scripting 12:53:49 Florian: but this summary is about as good as it got 12:54:05 https://drafts.csswg.org/mediaqueries/#issue-51d591c9 12:54:07 Rossen: your preference? 12:54:17 skhrshin has joined #css 12:54:18 Florian: not changing the spec, keep fuzzy 12:54:34 Rossen: fantasai, since it is your issue, what is your call? 12:55:00 fantasai: I am fine with a fuzzy boundary, but I want at least one certainty value people can trust 12:55:23 Florian: a "onload" threshold could be an issue if there is a timeout 12:55:56 Florian: so I don't think it would help anyone 12:56:10 Rossen: but would it solve the issue? 12:56:26 fantasai: I don't know, you guys know 12:56:27 q+ to request this issue be captured in GH and iterated there 12:56:59 fantasai: but authors want at least some way of knowing that 12:57:28 fantasai: if we define a baseline, at least authors can depend on that baseline 12:57:36 q+ 12:57:46 fantasai: otherwise, people will rely on undocumented heuristics and we won't get interop 12:57:47 q+ 12:57:47 q+ to also ask how many / if any implementations, and suggest at-risk 12:58:08 ack tantek 12:58:08 tantek, you wanted to request this issue be captured in GH and iterated there and to also ask how many / if any implementations, and suggest at-risk 12:58:09 tantek: please capture this in github 12:58:18 fantasai: I know almost no JS, but if I write a script, I want to know if it will be guaranteed to run, interoperably 12:58:35 tankek: second question, did anyone prototype this? 12:58:47 Florian: not any implementation 12:58:55 Florian: that I know of 12:59:01 tantek: then lets assume none 12:59:05 Is it actually useful to detect the opera mini case? because it is an arbitrary cutoff 12:59:14 tantek: then let's mark as at-risk 12:59:20 Florian: fine by me 12:59:25 https://drafts.csswg.org/mediaqueries/#scripting 12:59:52 the summary artificially constrains what the feature implies 12:59:54 tantek: (pasting what he just read) 12:59:56 q+ 13:00:12 tantek: that description contraints the use case 13:00:14 ack gregwhitworth 13:00:20 tantek: it could be used to do more things 13:00:26 bkardell_: Yes. And it's horribly awkward. See all usage of :root.no-js etc. 13:00:27 tantek: so it's misleading 13:00:31 q+ 13:00:43 Florian: i am fine doing this editorial change 13:00:46 ack dbaron 13:01:16 dbaron: if you want to figure it out, you need use cases where css needs to be different based on javascript running 13:01:29 dbaron: why not just have the script do something 13:01:38 q- 13:01:44 100% agree with dbaron 13:01:50 dbaron: like removing classes that will trigger the behavior 13:01:58 dbaron: assume it won't run 13:02:05 dbaron: then cancel the effect 13:02:16 TabAtkins: it's cheaper on MQ 13:02:36 TabAtkins: so perf might be better 13:02:53 tantek: you could even flip the stylesheet, or a nojs class 13:03:14 LeaVerou: people don't like to toggle the stylesheet because it is easier 13:03:20 TabAtkins: also makes bundling faster 13:03:22 q? 13:03:39 s/makes bundling faster/friendlier to bundling/ 13:03:39 ack gsnedders 13:03:41 Florian: can we just agree on a "something will run, at least"? 13:03:46 that said, I think the main use case is really just "is script enabled"? 13:04:09 shepazu has joined #css 13:04:16 s/people don't like to toggle the stylesheet because it is easier/reality is, all big websites use a nojs class that they remove via JS. They do not toggle stylesheets, because this is easier for maintenance./ 13:04:26 dino: lets set the print baseline 13:04:39 s/you could even flip the stylesheet, or a nojs class/what is this nojs class nonsense, you can just flip the stylesheet to enabled/ 13:04:43 dino: when the rendering finalizes, scripts stop running 13:05:22 tantek: ok, then lets call that value "onload" 13:05:49 ???: opera didn't state if they want to implement it 13:06:01 simonp: not in blink 13:06:08 q? 13:06:09 s/???/gsnedders/ 13:06:22 ??: so is it theoritical only? 13:06:29 s/??/gsnedders/ 13:06:56 LeaVerou: google crawler does run some scripts 13:07:00 q? 13:07:08 eliott: google crawlers won't report that 13:07:10 s/opera didn't state if they want to implement it/has Opera said if they're going to implement this middle value? has anyone?/ 13:07:22 eliott: we just act like if we were really loading the page, right? 13:07:33 Florian: then we can make the entire mq as at-risk 13:07:34 s/not in blink/Opera Mini is still using Presto and we're not going to implement any new features there/ 13:07:49 tantek: let's punt the new value to the next level 13:07:58 Rossen: would you oppose that? 13:08:05 Florian: I don't oppose either way 13:08:19 tantek: lack of prototype is a strong signal to punt it 13:08:26 Rossen: any objection? 13:08:40 RESOLVED: the new value will be punted to the next level 13:08:48 Rossen: what about the entire MQ? 13:08:57 Florian: we should keep, as at-risk 13:09:13 Florian: print is a valid use case 13:09:27 Rossen: Proposal is to mark it as risk, then. Objections? 13:09:45 johanneswilm has joined #css 13:10:28 ?: what to do with intermediate value? 13:10:41 dbaron: I think it should probably match what people do with nojs classes, which means those implementations should return true 13:10:42 RESOLVED: keep the script-detecting mq, but mark as at-risk in current level 13:10:56 Florian: we now need to make a disposition of comments 13:11:03 Florian: but we went through all the known open issues 13:11:19 Rossen: ok, anything else on the topic? 13:11:39 Florian: no, I'll ask for CR when we are done with these 13:11:47 (various +1) 13:12:28 tantek: ask for a review after you made those changes, please 13:12:31 Florian: ok 13:12:50 RESOLVED: publish that as a working draft 13:13:11 https://drafts.csswg.org/css-grid/issues-wd-20160519 13:13:12 Rossen: there was a grid issue to be discussed? 13:13:26 Topic: Grid 13:13:36 fantasai: first one is the baseline issue 13:13:48 fantasai: we decided to not to block-axis baselines 13:13:59 fantasai: but original poster isn't very happy 13:14:38 fantasai: proposal is: given lack of review, we should drop the feature for now, but maybe consider for later addition 13:14:39 andrey-rybka has joined #css 13:14:48 WalterTamboer has joined #css 13:14:59 fantasai: for a while, it is not expected you can make it work anywhere anywhere 13:15:38 Rossen: anyone objecting to keep the current resolution not to work on block baselines 13:15:47 Could you share the link for webex? 13:15:59 jet: I am just wanting to check that is is what we are going to ship 13:16:09 fantasai: I can also make it undefined 13:16:27 fantasai: the point is not to make it prevent the spec to go to CR 13:16:34 jet: wait wait wait 13:16:40 jet: let's see if we matches first 13:16:53 fantasai: can I get a response today? 13:16:56 jet: i hope so 13:17:01 q? 13:17:11 fantasai: bug 1151204 btw 13:17:31 tantek: would it be possible we match others? 13:17:44 Rossen: not us, we don't have vertical baselines at all 13:18:45 dbaron: why would an author want that? 13:18:53 dbaron: they can make the whole grid vertical 13:19:04 fantasai: mixed mode 13:19:34 dbaron: seems like the case you describe should be described in the other way, and you don't have the problem 13:19:50 fantasai: yeah, it's just a convenience 13:20:05 jensimmons has joined #css 13:20:27 Rossen: just a reminder, we want to keep an existing resolution 13:20:35 Discussion was about block-axis baseline alignment, for example by having a column of 5 author bios which are horizontal-tb grids with vertically-written author names in the first column of each bio item 13:20:38 Rossen: how about we resolve again, and you reopen if you need 13:20:42 jet: looks fine to me 13:20:50 and then you want to align along the block axis the vertical bio names within the column of the parent grid 13:20:52 Rossen: anyone else want to object? 13:20:57 newton has joined #css 13:21:02 dbaron was saying that you could just make the items vertical and make the rest of the content inside them horizontal 13:21:05 and that would sovle the problem 13:21:07 RESOLVED: block-axis baselines are not supported (confirmed!) 13:21:13 and agred that we should not have block-axis baselines as a feature 13:21:14 Rossen: next issue? 13:21:21 but my point was that if you have a grid item where the thing you want to align is vertical, then structurally that grid item is vertical, with some horizontal stuff inside -- and then you don't need block-axis baselines 13:22:01 ScriberNick: gregwhitworth 13:22:12 fantasai: the only other issue is % gaps 13:22:24 .. we resolved to treat them as empty tracks 13:22:38 ... mats disagrees as he thinks they should back resolve the %s 13:23:10 fantasai: I think that Ilgalia has implemented intrinsic % to auto and back computing other ones 13:23:17 Rossen: wait they're not semmetric 13:23:25 fantasai: no, I don't think so 13:23:38 fantasai: this deals with how to deal with % in CSS in generals 13:24:10 fantasai: let's say you have a float and a block inside that with %s and it will overflow 13:24:18 ... we can't change that because of back compat 13:24:42 https://github.com/w3c/csswg-drafts/issues/347 13:24:58 dbaron: we do back tracking for margin/paddings when inside of a shrink wrapped container 13:25:20 addison has joined #css 13:25:35 fantasai: if we go with the order of importance then we show go with what Gecko does 13:25:42 fantasai: that's what author's want 13:26:06 fantasai: where we don't have a back compat issue do we want to fix them or fallback to auto 13:26:12 Rossen: we've discussed this in the past 13:26:37 Rossen: our experience in the area is that this is very fragile especially when %s go over 100 13:26:51 Rossen: so trying to backcompute the margins becomes really crazy 13:26:55 ScribeNick: gregwhitworth 13:26:59 Florian: what does it mean if it is over 100% 13:27:19 dbaron: I think the answer there is to only deal with it in in maxcontent widths and not mincontent widths 13:27:39 dbaron: that way you'll be ok 13:27:56 Rossen: at the very least min and max are supposed to be treated differently 13:28:14 fantasai: I think I have a bunch of related questions, the key one here is gaps 13:28:38 fantasai: we figured it'd be nice if the gaps are handled similar to tracks, and that's what Mats has been arguing for 13:28:43 fantasai: that's one option 13:28:56 fantasai: the other option is to make them compute the same and fallback to auto 13:29:16 fantasai: make them compute the same but have them both back compute the %s 13:29:30 Rossen: our opinion is #2 13:29:40 Rossen: behave consistently and fallback to auto 13:29:53 Rossen: consistency over inconsistency 13:30:06 Rossen: and implementation simplicity over this 13:30:21 s/this/complex % back tracking 13:30:37 Florian: as in it's hard for browsers to get them right? 13:30:43 Rossen: yes 13:30:54 especially when you nest them 13:31:04 dbaron: I'm not sure what nesting them has to do with it 13:31:19 dbaron: you go level by level resolving the % against that of the intrinsic width 13:31:34 fantasai: I don't have an opinion on this 13:31:50 fantasai: it would be good to hear from the Blink folks 13:31:52 ojan: hi 13:32:14 dbaron: it would help if someone explained the issue 13:32:24 dbaron: draws a diagram on the board 13:33:22
13:33:33 s/margin/margin-left/ 13:33:44 dbaron: We make the intrinsic size 125px 13:33:49 dbaron: and the whole thing fits 13:34:04 dbaron: Gecko does this for margins and padding in this case, and other impls don't 13:34:07 dbaron: What we're talking about is doing this sort of thing for grid stuff 13:34:11 s/ dbaron: so the alternative here, is if you ignore the % you make the intrinsic width 100px 13:34:39 dbaron: you end up with a margin that is 25px and it overflows by 25px 13:34:39 dbaron: If you ignore the percentage, you make the div 100px, and the margin is 20px, and it overflows 13:34:46 Florian: Which doesn't sound like what an author would want 13:35:12 fantasai: I think there are actually two things happening here 13:35:44 fantasai: one of them is: if you have a child box of an intrinsicly sized element for grid we would have a track that is in a shrink wrapped grid container 13:36:05 fantasai: we can say that % depends on an indefinite size and treat it as auto and we wont' have the overflow problem 13:36:19 dbaron: I don't think that's quite true 13:36:48 dbaron: one of the thing this gets you, if you have the image inside of the grid track and says 20% and the image is 100px 13:37:13 and the track needs to be 20% of the parent then this will cause overflow 13:37:21 dbaron: tables do this, nothing overflows 13:37:27 TabAtkins: let's keep that in tables 13:38:00 dbaron: you might have overflow but it depends on the sizing the of the tracks 13:38:17 dbaron: if you end up with a 300px grid and then you say, this piece is 20% 13:38:18 floar 13:38:38 Florian: that's not what fantasai is saying, it's ignore 13:38:48 dbaron: for everything or just intrinsic sized items 13:38:53 fantasai: for everything 13:38:58 dbaron: that's ok too 13:39:05 fantasai: I don't want overflow 13:39:13 Rossen: I want to timebox this discussion 13:39:28 Rossen: there are two things we need to decide, do we want consistency with gaps and tracks 13:39:45 ^ in regards to resolving %s 13:40:33 dbaron: so treating them as a 0 even though you asked for a % there will be nothing there 13:40:39 ojan: that seems fine to me 13:40:42 Rossen: what does 13:41:08 ojan: if you put an % sized gap on an intrinsic sized track that seems fine to 0 them out 13:41:27 fantasai: so mats Palmgren said we should back compute on gaps, not tracks because it's more complex 13:41:37 fantasai: so we end up with 3 options 13:41:56 Rossen: so in other words, two of them would be consistent and one of them would not 13:42:09 wseltzer has joined #css 13:42:11 Rossen: would any one object to keeping them consistent? 13:42:29 Florian_ has joined #css 13:42:41 Rossen: let's call it resolved 13:42:44 resolution resolved 13:43:01 Rossen: now on to the other part, if they're consistent are we back computing %s or not? 13:43:06 RESOLVED: percentage gaps and percentage tracks use same resolution method 13:43:16 Rossen: Does anyone object to not backcomputing %s on tracks? 13:43:33 dbaron: I would like to hear actual author feedback 13:43:43 Rossen: are there any objections 13:43:51 jensimmons: I don't know what you're discussing? 13:44:30 gsnedders: I think asking for author point of view makes a bit of sense, but, I think back track has to be there or it does not make sense 13:44:38 dbaron: what are the use cases for intrinsicly sized grids 13:45:07 dbaron: I feel like it's mainly used for top down not bottom up 13:45:19 jensimmons: it's pretty big deal honestly 13:45:19 a simple example of a percentage gap and how it actually works in both FF and Blink/WK implementations: https://github.com/w3c/csswg-drafts/issues/345#issuecomment-240333816 13:45:33 jensimmons: people will expect the math to add up 13:45:45 tracks work exactly the same right now, so using: grid: 100px 10% 100px / 200px 10% 200px; behaves consistently 13:45:58 fantasai: let's say you have a grid, it's floated, it's intrinsicly sized 13:46:31 astearns: what if we wait to get more author feedback rather than just getting feedback from the author in the room 13:46:50 ojan: I would like to figure out if we can do what Gecko does 13:47:10 dbaron: the way table column width assignment is very similar to this 13:47:42 ojan: there are two things we can do offline: 1 get author feedback and 2 get desire to implement this from UAs 13:48:03 fantasai: we will keep the resolution and then spec out both and fix this in three months in Seattle 13:48:25 fantasai: mark it undefined so we can go to CR 13:48:33 I'll also note after what was minuted for what I said, Rossen asked if I'd object, and I said "yes" (somewhat apprehensively) 13:48:52 RESOLVED: %s in intrinsicly sized grids tracks and gaps will either get back computed or not 13:48:59 fantasai: we would like a transition to CR 13:49:05 RESOLVED: Grid to CR 13:49:56 (I was just asking fantasai about DoC etc and wide review) 13:50:26 Topic: Incubation in the CSSWG 13:50:40 Rossen: since we have a few people from Google in the room 13:50:56 Rossen: as you know we recently re-chartered 13:51:20 https://www.w3.org/Style/2016/css-2016.html 13:51:23 ... the current charter has we are allowing and encouraging incubation of new ideas in the WICG but not requiring it 13:52:01 relevant text from the charter: "The CSS WG may incubate speculative new work in the WICG, and may adopt promising CSS work developed in WICG, provided that RF patent commitments are in place for such work." 13:52:06 Rossen: there was a topic today that was incubated elsewhere with a relatively complete spec which was desired to be adopted under fonts L4. There was an objection by TabAtkins 13:52:20 liam has joined #css 13:52:27 Rossen: then a further statement that any new work should go into WICG 13:52:29 q? 13:52:39 TabAtkins: I don't think the spec is defined 13:52:43 cwilso has joined #css 13:53:03 q? 13:53:03 q+ to say this is a pretty good spec and of course has issues like all our specs 13:53:05 8 minutes total time 13:53:09 q? 13:53:13 q? 13:53:14 ack ChrisL 13:53:15 ChrisL, you wanted to say this is a pretty good spec and of course has issues like all our specs 13:53:32 ChrisL: I will say it's a pretty good spec, I've reviewed it, I've seen far worse specs that have gone to FPWD 13:53:37 q+ to note, incubation good, CSSWG should at least adopt an incubation methodology, whether or not we use WICG per se 13:53:39 q+ 13:53:52 dino: the topic is incubation not this particular spec 13:54:04 Rossen: I would like to hear a more formal policy behind this 13:54:42 slightlyoff: as many of you know, we work across many standards organizations. W3C is only one of them, I ended up with the role of ensuring the health of those groups was good 13:55:02 ... and it wasn't and most of it looked like design by committee 13:55:16 q+ to add more detail on scoping, baking, and the point of incubation. 13:55:26 slightlyoff: the proposals need a lot of momentum and community backing 13:55:41 q- 13:55:54 q+ 13:56:05 slightlyoff: this is a very large investment 13:56:06 q? 13:56:22 slightlyoff: this is the wrong place for design, my teams come prepared for resolving issues, not for designs 13:56:33 I would like to see it minuted that slightlyoff said that this spec *did* have a lot of momentum behind it 13:56:41 slightlyoff: starting with the CLA policy that the CG has in place, is perfect for these proposals 13:56:50 slightlyoff: we've done quite a few things for this already 13:56:51 q? 13:57:07 slightlyoff: intersectionObserver, web payments, resizeObserver 13:57:21 slightlyoff: this is to get the i's dotted and t's crossed 13:57:33 slightlyoff: but it's not just us, Microsoft has been there as well 13:57:51 q? 13:58:02 slightlyoff: allow for iteration where you can bring well formed proposals that can become standards 13:58:21 slightlyoff: I did recommend a blanket proposal for that inside of Blink, thus TabAtkins request 13:58:33 q? 13:58:34 newton has joined #css 13:58:37 ack tantek 13:58:37 tantek, you wanted to note, incubation good, CSSWG should at least adopt an incubation methodology, whether or not we use WICG per se 13:58:57 q+ 13:59:03 q+ 13:59:09 tantek: I like the WICG, I think this working group has tended to moving in that direction but haven't formally adopted this process 13:59:28 tantek: it would front load some of those questions that we ask at CR time, it should help us move more efficiently 13:59:47 tantek: it keeps from there being specs that live in limbo for a long period of time 13:59:58 tantek: WICG is one way of doing that, but there are many options 14:00:12 q+ 14:00:13 tantek: in general I'm in strong support of adopting an incubation first model 14:00:23 q+ 14:00:31 q- 14:00:34 q+ 14:00:37 tmichel has joined #css 14:00:42 ack cwilso 14:00:42 cwilso, you wanted to add more detail on scoping, baking, and the point of incubation. 14:00:47 q? 14:01:06 ChrisL: I'm actually co-char of the WICG and partner in the incubation first, Alex mentioned Microsoft but it actually started at Microsoft from Adrian Batemen 14:01:13 SteveZ has joined #css 14:01:20 s/ChrisL /cwilso 14:01:23 ChrisL: it enables us to embrace graceful failure 14:01:31 s/ChrisL /cwilso 14:01:36 q? 14:01:38 I don't thnk the CSSWG does that... our failures just end up as abandond draffts that we then put big red obsoletion notices. Granted, said notices are not very graceful. 14:01:51 cwilso: we are not saying the WICG is not the only group, it speeds up the need to create a new group, etc 14:01:53 But I don't think styling of the specs was the conern here 14:02:01 q? 14:02:32 cwilso: if you feel the problem needs to be solved and you've scoped it down to what/who needs to be involved and you know what the solution looks like 14:02:59 cwilso: that's really rare, but if it is then you don't necessarily need it to incubate 14:03:06 ack Florian_ 14:03:23 Florian_: during the short charter review I believe you asked for mandatory 14:03:28 Karen has joined #css 14:03:37 Florian_: I'm not opposed to incubation, but I'm against to a mandatory 14:03:57 Florian_: if Google wants to prove that incubation leads to better results, then do so 14:04:01 q- 14:04:05 q? 14:04:17 +1 14:04:17 Florian_: but the way this was handled was very unpleasant 14:04:30 ack frremy 14:04:40 frremy: I had a very same point to Florian_ I think it helps the community, it's a very good workflow 14:04:43 newton has left #css 14:04:45 plh has joined #css 14:05:23 frremy: they are an external partner that has a sound plan as they already have it designed for Windows/Mac that they'll point to CSS 14:05:25 q? 14:05:48 frremy: in this specific case I don't think it's necessary 14:05:57 q+ to ask a question. 14:06:07 frremy: they came to this group to ask us to work with them, and then asked them to go to WICG 14:06:12 q- 14:06:13 q+ 14:06:18 frremy: it seems like it's sending the wrong message 14:06:21 rachelandrew has joined #css 14:06:23 q? 14:06:31 frremy: exploring is for the WICG and I think the CSSWG is for refinement 14:06:41 q? 14:06:46 ack astearns 14:07:11 astearns: I'm all in favor in moving things to the WICG when we can, so they can be done in a small tight group 14:07:14 q+ 14:07:28 astearns: instead of setting up a subgroup or a TF, I prefer WICG 14:07:45 q? 14:07:47 q+ 14:08:08 q- 14:08:09 q+ 14:08:16 astearns: for this particular one it feels like a process speed bump, because things are passed the incubation phase, or relatively passed the incubation phase 14:08:17 q+ 14:08:19 q? 14:08:35 ack cwilso 14:08:35 cwilso, you wanted to ask a question. 14:09:34 (seems fair to me) 14:09:41 cwilso: the question I would suggest to the wg is: it's not to be a process speedbump but the new normal is that everything should start in incubation. The wg may want to define what should be in the WICG 14:09:48 ack Florian 14:09:49 (reacting to what cwilso just said) 14:09:54 fantasai: Alan gave an example of step sizing 14:10:18 I definitely agree we should have agreed-upon guidelines, so we don't rehash this every time new work appears 14:10:23 Florian: but this wasn't the case, it fits in this group 14:10:39 cwilso: that is not the bar, that you may need a new working group 14:11:07 hober: who do you mean by we? 14:11:28 cwilso: um, the WICG. Started with Microsoft, myself, Alex, Google, etc 14:11:51 q? 14:12:03 q? 14:12:08 ack dbaron 14:12:09 cwilso: the bar for incubation is much higher than starting a new working group for new features, it was to get a decent proposal to save the groups time 14:12:32 dbaron: I think one of the problems incubation solves, the way large groups discuss is not effective 14:12:59 dbaron: we have discussions about technical stuff and make decisions around stuff we at times don't even understand 14:13:24 dbaron: I think it's best to move the problem solving to the smaller groups so they have the right people that can make the right decisions 14:13:45 dbaron: now there is the flip side, that the group chosen to solve that problem are the wrong set of people 14:14:06 dbaron: so we can't just assume that a spec that was done in incubation may need to be completely redone 14:14:20 +1 14:14:42 wide review needs to happen in incubation as much or more than it does in a WG 14:14:46 dbaron: I would like to ensure that incubation feedback is done earlier enough and high level enough that we aren't stuck with something that was effectively done by one company 14:14:51 q? 14:14:54 q? 14:14:55 a? 14:15:09 dino: would round display of something that fits your narrative 14:15:17 dbaron: yes, it did get completely done 14:15:33 q? 14:15:38 dbaron: have the high level overview but not argue over syntax of each prop 14:15:51 ack fantasai 14:16:00 q+ 14:16:07 fantasai: one of the points I wanted to hammer on is it encourages people to go off in a corner and not get a lot of feedback 14:16:14 q- iank_ 14:16:28 fantasai: one of the benefits of this room is that you get a broad set of ideas 14:16:31 iank_, sorry, I declared the queue closed 8 mins ago 14:16:46 one other sentence: the set of people in this group isn't actually the right set of constituents that need to be talked to 14:16:46 Zakim, close the queue 14:16:47 ok, tantek, the speaker queue is closed 14:16:50 fantasai: there's a tension in standards around parallelizing and fragmentation 14:16:50 I would note that discussing something in WICG doesn't mean you can't be in the WG, nor that you will not discuss said incubation inside the WG or with other WG members. 14:17:06 fantasai: I think pushing everything into incubation will have another set of problem 14:17:12 +1 to cwilso's point 14:17:31 fantasai: and to some extent we've been doing this with telecons and side meetings 14:17:43 cwilso, indeed, I think CSS incubation could occur in the CSS WG itself, as long as the CSS WG formally adopts incubation as part of our work flow 14:17:44 s/telecons/individual threads/ 14:17:44 ack SteveZ 14:18:03 ----- 2 Minute Warning ----- (isn't this a forced time out?) 14:18:08 SteveZ: I actually agree with one point that Google made, we ought to have criteria that decides what does/doesn't go into the CSSWG 14:18:27 tantek: I'm not sure I agree, but depends on setup that is beyond the next 30 seconds of discussion. :) 14:18:40 SteveZ: we've come up with a bunch of criterion for other things, we should do that for this. We should spend some time on this 14:19:00 s/fragmentation/fragmentation; one of the advantages of discussing things in the entire WG is getting the broad expertise of a) people with different perspecives and b) people who have experience with many differnet parts of the technology and know how to integrate it and keep it self-consistent 14:19:08 SteveZ: I think it has to do with a number of the things that cwilso mentioned, like what the tech looks like 14:19:23 cwilso, sure, it's going to take some very deliberate work (especially on the part of the chairs) to institute, guide, and enforce a policy of incubation in the CSS WG. That's a non-trivial challenge. But doable. 14:19:34 SteveZ: such as regions, provided where we had discussion at a planery session and got feedback 14:19:48 q+ 14:20:13 cwilso, in addition, I think culturally there's a good chance that CSS WG will come up with a compatible at least in spirit/methodology way of incubating that is more efficient than WICG processes literally. 14:20:31 SteveZ: I think there are things that should be in incubation, but before we make forced decisions let's look at our history and come up with that 14:20:36 dauwhe has joined #css 14:20:44 Rossen: I hear a lot of sympathy and willingness to incubate 14:20:58 Rossen: there were strong preferences to where to incubate 14:21:35 Rossen: what are the consequences of not working on it where you prefer 14:22:13 slightlyoff: I would like to see the WG change and move to the incubation, we would have a hard time to follow this group if it doesn't change 14:22:36 slightlyoff: it worked for service worker, I'm less worried about where it happens more on how it happens 14:23:08 Florian: out of principle will Google block us 14:23:14 Florian: To the extent that Google wants to lead by example, that's okay 14:23:15 Rossen: please, let's not do this 14:23:28 Florian: But will Google block any progress that is willingily happening now out of principle? 14:23:35 ^14,06 Purple rain 14:23:36 Chris/Alex: we don't get to block you; we get the same vote everyone else does. 14:23:38 https://twitter.com/w3cmemes/status/778237649534521345 14:23:56 astearns: I'm willing to work on it 14:24:16 Rossen: that would be great, it would be good to cwilso and slightlyoff thoughts on the matter 14:24:43 astearns: we will have success criteria on when something gets past off to the CSSWG 14:25:07 tzviya has joined #css 14:25:08 fantasai: I would like to see it come back to us as well, I don't want silos 14:25:32 Rossen: we will come up with that process 14:25:36 s/as well/as well, not just after it's all considered "done" and competed in isolation somewhere else/ 14:25:57 Rossen: when it comes to the CSS Font spec we'll discuss this later, I want to close on this issue 14:26:32 Rossen: thank you slightlyoff and cwilso 14:27:53 bobbytung has joined #css 14:29:10 tzviya has joined #css 14:32:06 shepazu has joined #css 14:32:34 newton has joined #css 14:32:44 tzviya has joined #css 14:35:38 tzviya has joined #css 14:35:39 glazou has joined #css 14:36:08 tzviya has joined #css 14:36:08 Florian has joined #css 14:40:39 behdad has joined #css 14:45:51 newton has left #css 14:47:17 jensimmons has joined #css 14:48:51 liam has joined #css 14:49:43 Topic: Scroll linked animations 14:50:22 birtles: Dean sent a proposal years ago, but it wasn't complete. Google and Mozilla have come up with separate new proposals 14:50:43 birtles: I'll give a 1 minute demo, and list a few issues. 14:51:06 Mozilla's proposal - https://birtles.github.io/scroll-animations/ 14:51:18 Google's proposal - https://github.com/drufball/generalized-animations 14:51:44 birtles shows a custom build of Firefox with some scroll-linked demos 14:51:55 scribenick: dino 14:51:55 %C13,1 dino is scribing 14:52:45 myles: is there any script in this demo? 14:53:01 birtles: yes, it's a mix of both. declarative for easy stuff, script takes over after a while. 14:53:24 birtles shows a demo with a mix of scroll-based and time-based animations. switching between the two. 14:53:30 birtles: we've found three issues 14:53:37 birtles: 1. Transitions 14:54:10 birtles: in many cases you want to represent behaviour with transitions not animations. e.g. if you want something to appear, you need two animations for in and out. transitions is just a state change. 14:54:27 in other cases an animation is fine, since it is a run-once situation 14:55:03 jcraig has joined #css 14:55:28 birtles: it was a surprise to us that transitions were the most natural way to author many of these effects. this makes the animation-trigger feature less useful. 14:55:31 q+ 14:55:48 q? 14:55:50 Will someone please post the link to the New Yorker example and the other scroll jacking example? 14:55:51 birtles: we have drafted something called @trigger that can be used to change style based on scroll position 14:56:08 zakim, open queue 14:56:08 ok, ChrisL, the speaker queue is open 14:56:13 zakim, open the damn queue 14:56:13 I don't understand 'open the damn queue', Rossen 14:56:14 birtles: so issue 1 is do we need an @ rule or something 14:56:18 q+ 14:56:32 http://www.nytimes.com/projects/2013/tomato-can-blues/?hp 14:56:38 http://cuberto.com/ 14:56:47 birtles: 2. Layout cycles 14:57:10 birtles: once you have the idea of triggers that can affect layout, you can possibly have a cycle. 14:57:12 s/New Yorker example/New York Times example/ 14:57:28 birtles: we have some vague wording in the proposal about freezing the scroll offset for the frame 14:57:46 zcorpan has joined #css 14:57:55 birtles: this avoids a cycle within a frame, but you can still have flip-flop animations 14:58:01 dino: transitions already has this issue 14:58:13 birtles: 3. Describing the scroll points for triggering animations 14:58:30 birtles: maybe we can use the scroll snap points syntax, but i don't know how to do it 14:58:39 Rossen: you mean scroll-snap events? 14:58:55 birtles: no, about linking a scroll point to an element 14:59:00 tantek has joined #css 14:59:37 birtles describes how he wants something to happen based on the position of an element 15:00:13 fantasai: Scroll snapping lets you specify where a scroll for an element will be, but does not let you reference that from another rule. 15:00:25 q? 15:00:38 fantasai: have a new property that is "when the scroll snaps at my scroll point, then something happens" 15:00:54 ? 15:01:40 ack shane 15:01:48 Rossen: thanks for this introduction, we've been waiting for this for a long time 15:01:57 shane: we need to work out what we are going to do 15:02:19 shane: i suggest a small group of people in an incubator 15:02:38 Rossen: unlike fonts, this seems like a good example of something that could go to WICG and come back when it is more mature 15:02:55 Rossen: please, if you want to participate on this topic, do so! 15:03:27 astearns: doesn't need to be a small group. it should include the type of people who are solving this problems with scripts. 15:03:37 astearns: make it as wide as possible 15:03:49 Florian has joined #css 15:04:09 RESOLUTION: Accept this scroll linked animation work, to be done under the WICG 15:05:02 Topic: Writing Modes Level 3 Test Status 15:05:21 koji: The test status is linked from the agenda 15:05:22 http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-09.html 15:05:23 http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-09.html 15:06:01 There are 995 tests in the test suite, 118 of that have only 1 or less implementations. 15:06:02 koji: there are 995 tests in the suite. 118 tests do not have 2 passing implementations. 15:06:19 koji: i've categorized them. 15:06:48 koji: most of the 118 are related to this group. Only about 28 are not. 15:06:53 takeshi has joined #css 15:07:31 koji: the suite depends on 5 other specs. I excluded them from the 28. Then if I remove the MAY or SHOULD tests.... (form controls, etc) 15:07:42 koji: this leaves 13 tests that are blocking our exit 15:07:54 koji: of those 13, four categories... 15:08:12 koji: 1. synthesized baseline 15:08:28 nunoken1 has joined #css 15:08:31 of atomic inlines in vertical-lr 15:09:07 2. text orientation upright property 15:09:25 affects the used value of direction 15:09:30 there are 0 passing implementations 15:09:41 3. absolute positions 15:09:42 takamasa has joined #css 15:10:00 There are ~250 tests in this group, and 3 of them don't have 2 implementations 15:10:05 4. Glyph composition 15:10:28 edge case - text combine has a newline character, there is only one passing implementation 15:10:59 koji: these all seem minor to me, and we've made a lot of progress, i propose that we allow these failures and move to PR 15:11:23 ChrisL: we would make the case that 13 failures is ok. 15:11:29 s/would/could/ 15:11:52 fantasai: for number 2, were you testing the used or computed value? 15:12:00 fantasai: so upright text is in the wrong order? 15:12:14 astearns: could fantasai take a look at those 13 failures 15:12:30 ACTION fantasai to take a look at the 13 failing Writing Mode tests 15:12:30 Created ACTION-794 - Take a look at the 13 failing writing mode tests [on Elika Etemad - due 2016-09-27]. 15:12:46 astearns: have you filed browser bugs on these failures 15:13:04 koji: some of them, but since authors have not complained, i don't think they are real world issues 15:13:12 Rossen: you should still file the bugs 15:13:42 jet: We do have Gecko bugs for all these! I see that browsers only have at most 80% complete coverage. Is that enough? 15:14:06 astearns: the criteria is that each test has 2 passing implementations, not that there is interoperability between all tests. 15:14:10 q? 15:14:42 Florian: I've informally looked at changing writing mode on table cells and got weird results. Have we tested this enough? 15:14:44 koji: yes 15:15:27 bobbytung has joined #css 15:15:29 ACTION koji to file these writing mode test failures on the browsers 15:15:29 Created ACTION-795 - File these writing mode test failures on the browsers [on Koji Ishii - due 2016-09-27]. 15:15:32 I think categor 4 failing test is a weird edge case, don't need to worry so much. 15:15:38 Rossen: ChrisL, can we go to PR in this state? 15:15:44 I don't think that's the case for #2. Those should be fixed. 15:15:48 ChrisL: we are dropping all the at-risk features? 15:15:51 astearns: yes 15:16:14 ChrisL: we need to write up a clear rationale for us progressing. e.g. we've filed bugs, they are not show stoppers, etc 15:16:33 Florian: especially for the features that are at-risk, we've already got a +1 spec ready. 15:16:35 FWIW, when I started looking through the Gecko failures, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1244601 (which accounted for quite a few) but then didn't get further on filing additional bugs 15:16:37 ChrisL: that doesn't matter 15:16:51 newton has joined #css 15:16:51 koji: do you have an example of such a document? 15:16:58 ChrisL: an email to the group is enough 15:17:04 astearns: informed by fantasai's review 15:17:13 fantasai: The category 2 failures need to be fixed. 15:17:24 fantasai: that's right to left upright 15:17:28 koji: this is uncommon 15:17:36 fantasai: more common in hebrew than arabic 15:17:51 Rossen: any objections to the at-risk features? 15:18:19 fantasai: i think there are blocking tests. I don't think #2 are an edge case. 15:18:25 astearns: does it help to wait for the tests to pass? 15:18:39 astearns: why not move to a new draft now? 15:18:53 fantasai: i would prefer to wait. implementations might be doing the work now. 15:19:29 astearns: look at the test failures, see if we can address category #2, cut down the draft to features that have passing tests 15:19:35 astearns: what else is necessary? 15:20:04 ChrisL: for any comments we received since we last transitioned, we need to show that we handled them. i.e. we need a new DoC 15:20:26 ChrisL: it's fine to have the DoC say that it will be address in the new version 15:20:59 (discussion on what the transition process is) 15:21:08 s/discussion/clarification/ 15:22:28 fantasai: from the list of 13 tests, if we have implementors who will fix a few bugs, we should be able to transition 15:22:51 ACTION koji to prepare DoC for writing modes transition 15:22:51 Created ACTION-796 - Prepare doc for writing modes transition [on Koji Ishii - due 2016-09-27]. 15:24:17 scribenick: chrisl 15:24:58 for calling in: https://mit.webex.com/mit/j.php?MTID=md599def7295fc6e6be518db089d1afca 15:26:06 https://github.com/WICG/interventions/blob/master/scroll-anchoring/explainer.md 15:26:14 topic: Scroll Anchoring 15:26:30 ojan: doing this in WICG at interventions github 15:27:12 .. nitigate common experience of an ad loading and pushing content down. adjusts scroll position 15:27:36 ... during layout, store scroll position, adjust it back if it changed 15:28:09 ... anchor deepest element at top of page. restore to position after layout 15:28:23 ... as if user scroll, but browser scrolled 15:28:35 ... lots of webcompat issues, ugly hueristics 15:29:04 ... like poorly done sticky headers that jump 15:29:26 ... walk ancestor chain and any ancestor that modifies layout we don't do scrolling 15:29:47 ojan: they animate padding on body which works poorly, gives scroll loops 15:29:56 ... want to add a css property to control this 15:30:19 ... on by default, opt-out to current behaviour, or opt in for no hueristics 15:30:36 ... move to wicg in next 2 weeks 15:30:51 ... ignore fixed position elements 15:30:54 bobbytung has joined #css 15:31:04 ... should we do that for abspos as well 15:31:38 frremy: cN YOU ET INTERVENTION WHN ONLY SPECIFIC THINGS HAPPEN 15:31:43 oops caps sorry 15:32:17 fantasai: aware it is affected by align-content property? 15:32:19 https://drafts.csswg.org/css-align/#overflow-scroll-position 15:32:30 MaRakow has joined #CSS 15:32:37 Rossen: matt not on call yet 15:32:46 just got in 15:32:54 normal call-in number? 15:33:04 no 15:33:22 Meeting number: 15:33:22 646 865 453 15:33:22 Meeting password: 15:33:22 style 15:33:22 Meeting link: 15:33:23 Host key: 15:33:25 165017 15:33:27 Audio connection: 15:33:29 +1-617-324-0000 US Toll Number 15:33:31 Access code: 646 865 453 15:33:33 https://mit.webex.com/mit/j.php?MTID=md599def7295fc6e6be518db089d1afca 15:33:39 bobbytung has joined #css 15:33:40 topic: Media Feature: “reduce motion” user setting 15:34:24 newton has joined #css 15:34:58 on call now 15:34:58 jcraig: exposing user prefs through css media features 15:35:05 ... macos has this 15:35:10 kind of hard to hear though 15:35:23 ... flying animations that fly out 15:35:48 ... spinning starfield. chrome example. zooming (demonstrates pages) 15:35:58 ... make people ill,painful, vomit etc 15:36:17 ... this is called "reduce motion". want to expose to web 15:36:20 ?+ 15:36:26 ... prefers-reduced-motion 15:36:28 q+ 15:36:42 ... asked 3 years ago 15:37:15 ... what do ppl feel about exposing these. fingerprinting obv, outweighed by accessibility benefits 15:37:38 ... other ones are harder to do - contrast settings vary by platform 15:37:48 ... reduce transparency settings 15:38:16 ... (demonstrates a carousel) 15:38:34 ... allows page authors to decide how t handle it 15:38:38 Rossen: thanks 15:38:48 IanPouncey has joined #css 15:39:01 gregwhitworth: what about platforms with no motion control. return tru always? 15:39:22 jcraig: they will be asking support for it 15:39:44 ... may be a way to do with extensions or custom MQ short term 15:39:50 q? 15:39:53 ... prefer to avoid prefixing 15:40:08 dino: trivial to implement, huge benefits 15:40:11 q+ 15:40:15 ack bkardell_ 15:40:39 bkardell_: discussion earlier was uer prefs, that we need to invent new ways to set independent of OS 15:40:51 ... talking in cognitive acessibility taskforce 15:41:09 jcraig: dpub ig does not want to allow this (?) 15:41:10 q? 15:41:37 jcraig: we have had shipping settings for years while their taxonomy is thousands of possibilities 15:41:44 bkardell_: do they overlap 15:41:48 jcraig: maybe 15:41:51 ack Florian 15:42:02 Florian: useful to many, easy, should do 15:42:14 ... seems to be aina broader category of similar things 15:42:15 q? 15:42:21 q+ 15:42:27 ... coor contrast somewhere in between 15:42:41 ... not clear how toexpose to web platform 15:43:02 ... like to notice patterns before we settle on it 15:43:34 jcraig: did a high contrast text setting for example. microsoft can flip fg./bg. android have txt contrast enhancement 15:44:08 ... others related to contrast, reduce transparency to boost contrast 15:44:36 Florian: yo 15:44:37 Florian: whole area of incerted, boosted contrat etc. clear to do somethng but not what. 15:44:59 ... expressing a user pref, kind of tempted to put in the same group. but maybe jst do that one 15:45:01 q? 15:45:01 q? 15:45:07 q+ fantasai 15:45:15 ack esprehn 15:45:38 esprehn: like to see spec clarified first. monochrome, safari connects to acessibility setting, we connect to display driver 15:45:47 ... no-one on a mac has one 15:45:52 q+ 15:45:59 ... purpose of the mq was not clear 15:46:14 ... need to be clearer why it is 15:46:23 esprehn, I think that wasn't originally its purpose, but it has been effectively repurposed :) 15:46:38 TabAtkins: happy to put notes in, in general it is the output device 15:46:42 ericc has joined #css 15:46:44 esprehn: too vague 15:47:01 fantasai: was originally for monochrome monitors, got trpurposed 15:47:26 jcraig: toggled red square green circle for colorblind. considering collapsing that feature 15:47:47 esprehn: if it is tied tothe acessibility setting say so and then we know 15:48:02 ack fantasai 15:48:26 fantasai: agreeing with florian. in context of related stuff. want to see all the requests you have had, ina draft, figure out patterns 15:48:42 Florian: tied to acessibility so privacy 15:48:47 Rossen: already mentioned 15:48:53 glazou has joined #css 15:48:59 Karen has joined #css 15:49:00 ack Florian 15:49:08 Florian: suggested earlier that when a page has that from js, user gets a permission notification 15:49:14 [FYI: we're closing on this topic] 15:49:24 newton has joined #css 15:49:42 jcraig: screen reader directly exposes a disability. this is some benefit but used by many more people 15:50:04 jcraig: next steps? 15:50:27 dino: liting all queries is ok but os already has categories. no need to discuss them again 15:50:36 Florian: different ones have different lists 15:51:01 dino: reduce motion is unfuzz, easy to do. go ahead with that 15:51:14 hober: not let perfect be enemy of good 15:51:29 dino: some are fuzzy, changed between releases 15:51:32 tantek has joined #css 15:51:43 Florian: one on me to update draft 15:52:06 astearns: rather start with this one 15:52:13 ... asap 15:52:20 ericc has joined #css 15:52:34 fantasai: easier when we have all of them to look at.. this is brainstorming. 15:52:44 astearns: brainstorming should not go in draft 15:53:06 newton has left #css 15:53:19 astearns: we have a process. put in the things we are definite, add a note about vague stuff 15:53:36 fantasai: dont limit ourseles in early drafys 15:53:53 Florian: at least this one and reduced transparency 15:53:54 shepazu has joined #css 15:54:11 hober: editorial effort, if editors want to do that then great 15:54:20 Rossen: out of time 15:54:30 topic: scroll snap 15:54:37 present+ MaRakow 15:55:10 topic: CSS Scroll Snap 15:55:52 https://github.com/w3c/csswg-drafts/issues/395 15:56:14 fantasai: scoll snap padding change to more general scroll-padding 15:56:26 ... define which part of viewport is in view 15:56:45 ... not to see visibility but if it is in comfortable position for viewing 15:57:15 ... affects scrolling into view, through scrpt or interaction. page up/down. affects scroll from caret movement 15:57:35 ... similar things. no effect on layout or scroll origin except as affects snapping 15:57:56 fantasai: declarative replacement for js scroll hacking 15:58:02 to accommodate UI elements floating over the scrollable area. 15:58:19 fantasai: and request for caret operations 15:58:49 .. same effect for scroll snapping, but more interactions covered too and better UX 15:59:35 Florian: if we have this, it makes a couple of old proposals obsolete, and no need fr the proposd properties 15:59:55 ... simpler way to adress that 16:00:07 plh has joined #css 16:00:40 MaRakow: objections areound semantics of scroll snap for snapping purposes, usage patterns on scroll padding 16:00:58 ... cant use one without affecting the other, see github issue 16:01:17 ... do implementors have thoughts 16:01:52 sam has joined #css 16:01:54 dino: apple has no opinion 16:02:09 jet: hmmm 16:02:35 jet: will comment on github 16:02:44 fantasai: last blocking issue 16:02:54 Florian: since sydney at least 16:03:26 skk has joined #css 16:03:38 fantasai: matt argues that keeping things separate, odd because most use cases the valueis the same one on scroll padding so one prop for both 16:03:49 ... can separate by making a shorthand later if needed 16:04:15 ... mainuse case for attach to viewport is to block oyut things too close to the edge or covered byy UI 16:04:26 ... block out for all these scroll ops 16:04:52 ... if you do want difference then set scroll paddingbased viewport 16:04:59 q+ 16:05:23 ... and thenuse scroll-snap-margin on snapping element to giv e adifferent spacing 16:05:26 antonp has joined #css 16:05:43 fantasai: so all use cases adressed and common case is easy 16:06:01 ... so accept this proposal please and make it easy to do good scrolloing 16:06:05 TabAtkins: agreed 16:06:41 ... useful to solve things right now. same for scrolling and snapping, make it generic of overflow control 16:06:54 jet: is this from implementation? 16:07:02 ... we have an implementatiom 16:07:12 TabAtkins: no it is super old and crufty 16:07:52 fantasai: filed because of working through spec and seemed the author use cases not solved 16:08:14 ... all simply ysolved by widening this property 16:08:18 ... to more cases 16:08:22 q? 16:08:31 ack MaRakow 16:08:49 MaRakow: confirming no other strong ipinions 16:09:29 Rossen: no strong ones but tab leans towards eleika strongly now, as id dino 16:10:03 MaRakow: scroll snapping is specific alignement in the viewport while the functionality is a range in view so 16:10:24 andrey-rybka has joined #css 16:10:29 ... not gauranteed to be the same as the box that what 16:10:59 ... acessible end view box 16:11:09 s/end view/in view/ 16:11:53 TabAtkins: all approximately right and when a bit different, scroll-snap-margin handles just fine 16:12:15 MaRakow: could other implementorsread the issue and chime in 16:12:30 ... does syntax get overloaded 16:12:45 ... others seem to think not 16:13:01 +1 for Elika's proposal 16:13:14 fantasai: if you really want to do it with padding then we can split scroll padding into two longhands down the road. doubt we will 16:13:22 skk_ has joined #css 16:13:26 ... not seeing the mismatch you think exists 16:13:49 ... theoretical purity that should not overide author ease of use 16:14:11 +1 to that — one property that does many things. Not multiple properties that are similar. 16:14:16 MaRakow: not objecting strongly, want other opinions 16:14:44 ... on the githb issue 16:15:19 Rossen: so as this is the last issue holding us from CR and to move forard, call for consensus on current issue as stated by elika. so no sustained objection? 16:15:32 just a data point but what Elika proposed actually solves many use cases for Bloomberg 16:15:36 ... you want implementors to give a full read before making up their mind 16:15:50 astearns: more support of elikas proposal 16:16:08 dino: lets decie and adjust in CR if implementors findissues 16:16:13 Rossen: ok with that ? 16:16:43 astearns: this is the last open issue 16:16:51 MaRakow: no there are still some 16:17:26 fantasai: two renaming but no proposal so rejected. one editorial, conciseness. one resolved already 16:17:33 ... so just this one issue 16:18:02 Rossen: so appart from editorial ones, no outstanding design issues. matt, agreed? 16:18:10 MaRakow: offscreen mapping is one 16:18:26 fantasai: sitting with proposed text since june, at least 16:18:49 behdad1 has joined #css 16:18:49 ... accepted previously the text was not good 16:18:56 q? 16:19:09 MaRakow: don't know what you are objecting to 16:19:16 Rossen: almost out of time 16:19:22 s/MaRakow/fantasai/ 16:19:23 Rossen: call for consensus 16:19:38 ... any objections 16:19:46 (none heard) 16:19:56 resolved accept elika's proposal 16:20:26 fantasai: rename anything? no actual proposal 16:20:33 ... so leave as it 16:20:35 jcraig has joined #css 16:20:46 Rossen: can we live with mandatory and proximity 16:20:51 (no objections) 16:21:02 dauwhe has joined #css 16:21:10 IanPouncey has joined #css 16:21:12 fantasai: scroll-snap-stop normal and always, rename normal 16:21:52 (no objections to keeping those names) 16:22:37 fantasai: wording in section on scroll snap on top edge, if it is over here and i dont click this should not care that it happends to align top to top 16:22:50 (we film the interpretative dance) 16:22:55 (literally) 16:23:22 fantasai: if horizontally scrolled then down, do not trigger snap. that is what the section is about 16:23:38 fantasai: honestly dont know what the diaagreement is so can't fix it 16:23:42 Rossen: matt? 16:23:51 https://drafts.csswg.org/css-scroll-snap/#snap-scope 16:24:26 MaRakow: point of snapping is to point to snap totheings out of view currently and is this coridoor scrolling the feature only w=starts scrolling through the animation of the scroll 16:24:34 MaRakow: understand intention 16:24:57 ... outside x direction of the viewport is not contributing, not strictly true 16:25:28 Rossen: proposed text? 16:25:37 Florian: convinced this is not an issue 16:25:43 fantasai: different topic 16:26:12 MaRakow: might proposed something last time but not sure. path scroll would take .... considered for snapping 16:26:33 Rossen: ok fair if the spec does not say what exactly is considered outside, needs to be better defined 16:26:53 fantasai: depends on whic snap ositions you consider to land.this however is not that 16:26:57 s/convinced this is not an issue/I think this is the same issue as what I raised earlier about the wording problem regarding the corridor, for which I got convinced that it was fine/ 16:27:02 ... this positionis not a snapped position 16:27:21 fantasai: like the illustration in the spec, offset in the wrong axis so not snapped 16:27:43 ... whe looking for snap positions but can't snap to it unless also brought into view 16:28:01 ... so not taking coridoor into consideration. is it snapped? no it is not 16:28:34 MaRakow: have to choose one and need to know which are valid. scoped through custom scroll, intersection on x axis 16:28:46 fantasai: see the section on choosing snbnap positions 16:28:58 ... this cannot be chosen, it is not snapped 16:29:30 ... even if author anually aligns them there, ua is not snapped there 16:30:07 Rossen: this is in a different section 16:30:18 https://drafts.csswg.org/css-scroll-snap/#choosing 16:30:41 fantasai: section 6.2. this one is saying it is not in a snapped state 16:31:02 Rossen: just ended up there by chance anyway, still not considered snapped 16:31:11 Section in question - https://drafts.csswg.org/css-scroll-snap/#snap-scope 16:31:12 Rossen: make sense? 16:31:16 MaRakow: think so 16:31:23 Rossen: so this adresses your issue 16:31:28 MaRakow: think so yes 16:31:57 Rossen: minor editorial clarifications in CR, leys resolve to do so 16:32:12 Rossen: any objections to moving to CR? 16:32:21 s/leys/lets/ 16:32:40 fantasai: lets go to CR 16:32:50 (no objections) 16:32:52 +1 for CR 16:33:10 resolved, css scroll snap to go to CR 16:33:28 resolved to accept the text just discussed 16:33:49 ScribeNick: fantasai 16:33:51 Topic: Timing functions 16:33:52 rego has joined #css 16:34:01 birtles: Can we please start another spec 16:34:38 birtles: Wanted to define timing functions for both transitions and animations and web animations in one place 16:34:47 birtles: Currently in Transitions, it's kindof awkward 16:34:52 birtles: Talked about having a frame timing function 16:34:56 birtles: Apple has spring timing function 16:35:03 birtles: Also talked about things like script-defined timing functions 16:35:07 birtles: Multi-segment timing functions 16:35:11 birtles: all these things need to have a home 16:35:18 birtles: So proposal is we make another spec for timing functions 16:35:26 birtles: and take it out of CSS Transitions and put all that stuff there 16:35:31 [general agreement] 16:35:34 q+ 16:36:00 fantasai: I think it's a great idea 16:36:08 fantasai: I would like to see that if it's pulled out of Transitions Level 1 16:36:12 fantasai: We have two levels of this spec 16:36:22 fantasai: one with the interop stuff that should go tCR like 2 years ago 16:36:27 fantasai: And one with with all the new stuff 16:36:37 dauwhe has joined #css 16:36:57 bobbytung has joined #css 16:36:58 dino: Do we need an incubator? Can we just go 16:37:11 Rossen: this is work in progress in the current charter, just splitting. no need for incubation here 16:37:11 Rossen: This is existing work, just splitting work that's in one spec into another spec 16:37:15 Rossen: Continuing existing work 16:37:23 Rossen: Don't see any reason to incubate, nothing new there. 16:37:31 Rossen: Would ask Tab, would you agree with this statement or not 16:37:45 TabAtkins: Wasn't listening, so yeah sure 16:37:57 q? 16:37:58 shane: I want to answer for Tab, answer is it depends 16:38:06 ack shane 16:38:08 shane: Aple's spring timing funciton fundamentally breaks timing function model 16:38:14 shane: Would rather not see it in a timing function spec 16:38:30 shane: Think we could accommodate it with the same syntax Apple proposes declaratively in the scrolling animations spec, if we generatlize that 16:38:40 ??: Which aspect of it fundamentally breaks the timing model? 16:38:58 shane: Previously, timing functions couldn't alter the duration of the animation 16:39:00 s/??/sam/ 16:39:23 TabAtkins: More specifically, none of the timing functions had an opinion on what the duration is 16:39:35 TabAtkins: Have to do the math on spring, then set duration accordingly 16:39:42 TabAtkins: Otherwise looks stupid 16:39:52 dino: Ony looks stupid if you pick a stupid duration value 16:40:12 shane: I thought the way t works was to change duration 16:40:14 [confusion] 16:40:23 Rossen: Seems like agreement on continuing working on this 16:40:25 newton has joined #css 16:40:31 Rossen: Let's go back to request for splitting work so we can continue working on it 16:40:34 yup that is Sam Weinig 16:40:39 Rossen: Then we can decide on what stays and how it stays 16:40:45 Rossen: Do you agree with this, Shane? 16:41:03 shane: If the timing functions you want to consider require... 16:41:08 birtles: .... 16:41:11 shane: I'm fine with that 16:41:15 Rossen: Any objections? 16:41:50 birtles: we can decide on where spring() lives later 16:42:34 RESOLVED: Split out timing functions into own module, Level 1 to include functions that have been implemented for awhile, Level 2 to include newer functions/proposals 16:43:01 RESOLVED: birtles shane dino MaRakow to edit 16:43:28 Topic: Viewport API 16:43:36 rbyers: ... 16:43:43 rbyers: Got some compete pictures and stuff, but short summary 16:43:59 rbyers: Trying to incubate a new API that will finely explain pinch zoom 16:44:06 rbyers: Not trying to make all browsers beahve the same 16:44:11 rbyers: Not trying to fully space 16:44:37 rbyers: But incremental step to expose a simple API that lets you reason separately about the space that the page is laid out into and the space that the viewer sees 16:44:49 rbyers: So, basically relative geometry and position of the layout and visual viewports 16:44:55 rbyers: Worked with websites, bunch of bugs 16:45:03 rbyers: Sites are broken because make assumptions about this 16:45:08 https://docs.google.com/presentation/d/1VxLlMTgrq11Q-ltPXyg5_7YuDAo00sbdElsRe752sQg/edit#slide=id.g861a184b2_2_237 16:45:13 rbyers: Think simple API can be used to address these cases 16:45:15 newton has left #css 16:45:22 Needs access 16:45:26 rbyers: Demo/presentation 16:45:41 rbyers: Get a sense of the behavior 16:45:42 q+ 16:45:57 https://github.com/WICG/ViewportAPI 16:46:01 rbyers: Talking a lot with MaRakow , he's given a lot of feedback on the API 16:46:05 rbyers: Here's the repo 16:46:06 dauwhe has joined #css 16:46:15 rbyers: Trying to get barebones simple bit, incubate and iterate 16:46:28 rbyers: Experimental implementation of this in Chrome now if you turn on experimental features 16:46:30 liam has joined #css 16:46:40 Florian: Looked over, seems good to me. Happy to keep in WICG 16:47:01 Florian: I think the terms visual viewport and layout viewport should go into device-adaptation because more than just you is depending on these terms 16:47:13 Florian: Please file issues against me on specific things you need 16:47:35 rbyers: Most CSS specs need to be updated to say which viewport for every place they say viewpot 16:47:47 rbyers: And no two browsers agree on which one for these things 16:47:59 astearns: Florian, will you join the WICG group? 16:48:01 Florian: Yeah 16:48:53 Rossen: Wanted to revisit the font variations discussion 16:49:05 Rossen: My proposal is to continue this work in Fonts Level 4. Any objections? 16:49:20 Rossen: I really don't want this to be the precedent for the chair override feature... 16:49:27 hober: I support this proposal 16:49:40 TabAtkins: I'll tell you later, for now proceed 16:49:51 RESOLVED: font variance is part of Fonts Level 4 16:50:03 Rossen: Going back to the agenda, we have 10 minutes left 16:50:43 https://github.com/w3c/csswg-drafts/issues/319 16:51:05 Florian: Have a thing selected, and then click something with user-select:none 16:51:13 Florian: Should it unselect? Should it?? or ??? 16:51:19 Florian: I was tasked to ask the editing task force 16:51:34 Florian: multiple ppl said doing things inside user-select:none shouldn't affect selection 16:51:43 Florian: Think we should resolve on that. 16:51:49 hober: I think it should match platform convention 16:52:13 Florian: What is native behavior of clicking "user-select: none" 16:52:35 hober: Behavior of clicking on an non-selectable areaof the UI 16:52:51 Florian: Safari already doesn't match wat Mac OS does 16:53:13 johannes: ... when you cannot select them, you should not lose your exiting selection 16:53:31 esprehn: user-select:none causes us to unselect things, and we want to change that behavior 16:53:59 Florian: I think that's a eparate issue. No interop, chrome and edge said they'd match Firefox, and editing TF agreed 16:54:16 Florian: If you click or click and drag in select:none doens't affect existing selection 16:54:34 Rossen: Any objections? 16:54:46 tm has joined #css 16:54:50 +1 to resolve 16:54:54 RESOLVED: If you click or click and drag in user-select:none area, doens't affect any existing selection 16:55:04 dino: There should be an escape clause for platform convention 16:55:24 dino: There are definitely parts of UI that are non-selectable in the platform. 16:55:49 Florian: The fact that different browsers behave differently was confusing JS users, so request was to harmonize browsers. 16:56:04 Florian: Safari would have to change, but after change would match its own platform better. So what's the problem? 16:56:33 https://github.com/w3c/csswg-drafts/issues/423 16:57:00 Florian: outline-color has two color values. One is 'invert', which is initial value. If can't 'invert', defined to fall back to initial color. 16:57:21 Florian: There are two implementations, one relevant (Edge), two irrelevant (IE, Opera). No process block 16:57:31 Florian: Browsers are allowed to not do that if impractical. 16:57:41 Florian: Don't see any value in removing the value. But ppl have asked to remove the value. 16:58:35 Florian: Use case that justifies this value is real, and we have a relevant current implementation. Would rather not drop it. 16:58:52 Florian: Fact that Edge/IE have this feature and want to continue having it, I think we should keep it. 16:58:59 Florian: If they want to drop it, then we should of course drop it. 16:59:33 fantasai: So proposed rsolution: keep invert unless Edge decides to drop, n which case we drop 16:59:52 RESOLVED: Keep outline-color: invert unless Edge decides to drop, in which case we drop. 17:01:13 fantasai: wrt text-underline thickness/position, has to be separate property from the existing -possition property, because that one is lang-dependent and intended to inherit through independently fromother props 17:01:21 fantasai: probably want an -offset property for position control 17:01:30 Meeting adjourned. 17:01:39 -offset +1 17:01:48 trackbot, end meeting 17:01:48 Zakim, list attendees 17:01:48 As of this point the attendees have been tantek, Rossen, dholbert, eae, jihye, gregwhitworth, glazou, dauwhe, bradk, Florian, antonp, myles, dael, Rossen__, dbaron, tgraham, 17:01:51 ... myles_, antenna, astearns, plinss, alex_antennahouse, SteveZ, Bert, hober, iank_, rachelandrew, Rossen_, fantasai, fremy_, TabAtkins, vollick, ChrisL, smfr, zcorpan, antonp[, 17:01:51 ... fremy, plh, SteveZ_, MaRakow, joone, Liam_Quin, bkardell_, gsnedders, jensimmons, leaverou, skk, ++++++++1, Guest, LiamQuin, p, tmichel, AndroUser, btw, liam, arybka, 17:01:53 ... (finally), andrey-rybka, surma, skhrshin, tzviya, Charles_LaPierre, ivan_herman, David, Wood, Vlad, Karen, Leonard, Bill_Kasdorf, Paul_Belfanti, Heather_Flanagan, kuettel, 17:01:53 ... MichielBijl, MichaelC, birtles, SimonSapin, dino, richardschwerdtfeger, Janina, (Francois, REMY, Microsoft), (Emil, Eklund, Google), tomalec, nainar, Shintaro, Sakahara, BPS, 17:01:53 ... Takamasa, Ikeda, Behdad, Esfahbod, Gottfried, Zimmermann, Invited, expert, APA, jcraig, RMurillo 17:01:55 hmmm, you're requiring that clicking someplace else *not* clear an existing selection? 17:01:56 RRSAgent, please draft minutes 17:01:56 I have made the request to generate http://www.w3.org/2016/09/20-css-minutes.html trackbot 17:01:57 RRSAgent, bye 17:01:57 I see no action items