14:54:26 RRSAgent has joined #css 14:54:26 logging to http://www.w3.org/2015/07/22-css-irc 14:54:32 RRSAgent, make logs public 14:54:36 Zakim, this will be Style 14:54:36 I do not see a conference matching that name scheduled within the next hour, glazou 14:54:48 Zakim, I sometimes forget you’re dead 14:54:48 I don't understand 'I sometimes forget you’re dead', glazou 14:58:46 dholbert has joined #css 15:16:24 hober has joined #css 15:22:44 hober has joined #css 15:37:30 shepazu_ has joined #css 15:44:49 hober has joined #css 15:45:41 TabAtkins, fantasai: Does "behind an off-by-default flag in a release build" count as released for the purpose of https://drafts.csswg.org/css-2015/#responsible ? 15:49:22 Florian has joined #css 15:49:47 antenna has joined #css 15:53:39 dael has joined #css 15:57:43 ScribeNick: dael 15:57:54 murakami has joined #css 15:57:54 present+ astearns 15:57:56 Present+ dael 15:58:02 present+ glazou 15:59:03 Regrets: leaverou, hyojin, rossen, Chris, gregw 15:59:09 Present+ Florian 15:59:09 Present+ dauwhe 15:59:44 bkardell_ has joined #css 15:59:55 Present+ dbaron 16:00:00 Present+ antenna 16:00:15 lol 16:00:21 adenilson has joined #css 16:00:42 Present+ tgraham 16:00:45 alex_antennahouse has joined #css 16:01:02 smfr has joined #css 16:01:02 Regrets: plinss 16:01:56 Present+ smfr 16:02:08 Present+ antonp 16:02:10 Present +adenilson 16:02:31 Present+ bkardell_ 16:02:47 bcampbell has joined #css 16:02:54 PResent+ hober 16:03:13 simonsapin 16:03:13 Present+ SimonSapin 16:03:32 present+ Florian 16:03:43 Present+ Plh 16:04:10 gregwhitworth has joined #css 16:04:48 glazou: Let's start 16:05:00 Present+ koji 16:05:02 glazou: We havea few additions to the agenda. There was a msg from fantasai I think a few hours ago. 16:05:13 glazou: Adding CSS cascade and selectors 4 to the agenda. 16:05:32 glazou: She'd also like to remove one item that's answered and one that's f2f. anything else? 16:05:44 Florian: Clarification, the two items that are if I sent a mail, I haven't. 16:05:52 https://lists.w3.org/Archives/Member/w3c-css-wg/2015JulSep/0035.html 16:05:53 Topic: CSS Cascade 4 publication 16:06:18 +1 for a new WD 16:06:29 +1 for new WD 16:06:31 SteveZ has joined #css 16:06:37 fantasai: We had one outstanding issue on lvl 4 which was to rename default, we picked revert. I'm prop a new WD and treat as a LC. There's no more issues and only 2 additions from level 3. revert and support syntax for @import. 16:06:45 +1 16:06:48 q+ 16:06:48 fantasai: If there's no comments between pub and f2f we can go to CR> 16:06:49 +1 16:06:53 glazou: I'm in favor. comments? 16:07:03 +1 16:07:07 plh: Question from me. Oh, wait. Mine is for selectors. 16:07:12 glazou: Other comments? 16:07:14 glazou: Obj? 16:07:15 Present+ Bert 16:07:26 RESOLVED: Publish new WD for CSS Cascade lvl 4 16:07:32 Topic: Selectors 4 update 16:07:35 https://lists.w3.org/Archives/Public/www-style/2015Jul/0296.html 16:07:48 glazou: plh sent a message about a new WD for selectors 4 because the one of TR is large and the time. 16:08:04 glazou: fantasai posted a prop for features to keep and to defer/drop 16:08:10 q+ 16:08:14 tantek has joined #css 16:08:20 present+ tabatkins 16:08:26 glazou: There was a proposal about defering :has to level 5 that had a lot of conversation 16:08:29 ack plh 16:08:34 Present+ murakami 16:08:38 andrey-bloomberg has joined #css 16:08:50 plh: I said that because the DOM spec was linked to Selectors 4. I was also wondering about hte stability of the path. 16:09:27 smfr has joined #css 16:09:35 bkardell_: I could, yes 16:09:45 plh: For the purpose of defining query-selector and query-selector all how to deal with scoped elements we don't use a :scope selector, but we do talk about scope selection so I was wondering if those parts are stable or nowhere near stable and will move to 5 for ex. 16:10:00 fantasai: Is there anything specific you needed to keep that wasn't on my list? 16:10:10 plh: We didn't talk about the parsing of selectors. Is that kept? 16:10:24 fantasai: Yes. All the other stuff will be kept. We'll keep everything that wasn't on the defer list. 16:10:29 plh: And the scoped selector? 16:10:33 fantasai: Absolutely. 16:10:46 glazou: For the people that missed it on the ML, I would like to repeat what I said about :has 16:11:37 bradk has joined #css 16:11:44 glazou: The prop from fantasai is to defer to lvl 5. The proposal for this feature is >15years. We've put it in documents sevseral times and we've been advertising it for years and we've been so vocal that web authors are demanding it. deferring now would give a bad picture. 16:12:07 q+ 16:12:13 me daniel: your connection drops sometimes. mostly fine, but some drops here and there. 16:12:17 glazou: It's a question of the image of this WG. In the past we had a bad image because we couldn't deliver. I'm afraid deferring :has will give us that image. We have to deliver or say we can't and drop 16:12:22 s/me/ /me / 16:12:44 myles has joined #css 16:12:47 q+ 16:12:49 TabAtkins: It's not any different staus than yesterday. We'd dropping out the parts taht aren't stable so we can push to CR. We're not doing anything different with :has than we were doing yesterday. 16:13:15 glazou: To answer greg's question, it's been on and off for 15 years because [missed] It was at risk and then people proposed again and it's just been a cycle. 16:13:22 gregwhitworth: So it's not impl complexity? 16:13:37 gregwhitworth 16:14:02 smfr_ has joined #css 16:14:05 glazou: No, the inital refusal was impl complexity. That's why I'm saying in the ML that the current arguement to refuse it is the same as 15 years ago and if we can't impl we have to drop it. It's not fair to let web authors expect this if we can't do it. 16:14:34 This is what happens when the reaction to "not sure if we can implement it" is "well, let's put it in the spec and see what happens". 16:15:07 bkardell_: 2 things. 1 is going into a little bit more of the history of this, to do it in CSS as org prop it's really difficult. We have ideas, but they will take a long time. Conseptually it's plain as day you want that feature. But it is really hard and that's what kept it out. In the meantime we've come up with qsa and varients taht let you do this in JS. 16:15:08 dbaron: absolutely 16:15:11 I thought it was "let's put it in the spec for broader review / feedback" 16:15:44 present+ tantek 16:15:57 bkardell_: Query has had :has and people have been clamoring for it more. Because it's concpetually obvious that people want this, this has been a long running thing. Any time it's mentioned people get excited. Doing it in the static profile isn't very complex. It's a couple of days work by an impl. 16:16:29 just mark it at risk and let's move on 16:16:43 bkardell_: That was hard fight to get that far. My second point I feel like it sends bad messages to authors. dropping or, I mean, deferring it seems to send subtile signals. If it's in level 5 people think it's not as important. 16:16:56 how is it not well defined?!? 16:16:57 TabAtkins: It can't be in the CR because it's not stable. It's either dropped or in level 5. 16:17:09 q+ 16:17:17 what are the open issues on :has ? 16:17:24 fantasai: We're going to CR. That doesn't mean every feature has to be completely impl. If everyone says they will impl and don't expect issues, we can keep it in the draft. 16:18:06 fantasai: What concerns me more about :has, there have been discussions about having different syntax from query or something like that. As long as that's not resolved the feature isn't stable. If the discussion about what we're going to do isn't final we have a consistantsy problem. 16:18:34 smfr has joined #css 16:18:40 fantasai: I would like for us to work throught he issues before :has is in CR. If we want to leave it for now and drop it if we can't work through the issues before everything else is done that's fine. 16:18:51 fantasai: :has hasn't existed in a CSS draft before it was in JQuery 16:19:10 glazou: I prop on the ML to keep working on :has until the Aug F2F and make a decision at that time. 16:19:22 fantasai: That's poss, but it depends on the rate of discussion on the ML. 16:20:16 fantasai: The other features in the draft that we want to keep, if we remove everything else that's unstable, publish with :has and than work on all the open issues, as it happens we can discuss has and we can decide to drop at CR transition. We can leave a note saying that if the issues aren't resolved we'll drop at CR transition. 16:20:24 q+ 16:20:26 fantasai: There is still some refining for the rest of the draft anyways. 16:20:29 +1 to that plan 16:20:31 glazou: I prefer that plan, I think. 16:20:40 q- 16:20:42 ack bkardell_ 16:20:45 ack Florian 16:21:02 q+ 16:21:33 q- 16:21:36 I am for keeping more features in CR and labeling them at-risk, especially if *anyone* has expressed implementation interest. 16:21:43 Florian: Agreeing with something fantasai said earlier, as to if something without impl can go to CR depends on the issues. In the list of things to defer to level 5 I think there are things to keep. focus-within has a resonable chance of impl soon and it's straight forward enough to keep at-risk. I think there are morethings like read-only. I don't think we'll change and we might impl soon. 16:21:49 Thus I support Florian's proposal to keep :focus-within, and general criteria. 16:21:49 ack plh 16:21:52 Florian: That's the criteria I'd apply here. 16:22:09 plh: +1 to what flo said. We can keep at-risk and push to CR sooner because we can still drop. 16:22:34 fantasai: A lot of the things on this list were because they had open issues or we're not sure because we didn't have enough feedback to know if the issues had a chance to be ironed out. 16:22:45 putting things into CR is a way to iron out issues too - because some issues are only ironed out when implementations try to build it! 16:22:49 fantasai: If people have thoughts on any individual thing I'd like them to reply and talk about it. 16:23:03 ACTION everyone to review this document and make comments. 16:23:03 Error finding 'everyone'. You can review and register nicknames at . 16:23:27 q+ 16:23:33 glazou: Both bkardell_ and I made a comment about the image of the WG. If we do decide to drp :has I'd like to work with plh to craft a blog as to why we decide to drop it. 16:23:55 smfr_ has joined #css 16:24:17 plh: Sure, I agree with you. I wasn't a part of the debate before, but one of the comments W3 hears a lot is that we're not listening to devs enough. Devs want :has and we're not getting impl of this. I don't know why there's such decrepency. 16:24:19 ack tantek 16:24:42 the static profile is actually a compromise between the two (authors and vendors) 16:24:59 +1 to tantek's comment 16:25:10 well said 16:25:24 +1 to tantek, IF we are sure that it is specified the way we want it 16:25:35 +1 too 16:25:38 tantek: So that's why we should not drop :has from CR> Since there is high demand the right answer is don't politically drop it, leave it in CR at-risk and put up a proactive blog post saying that it's at-risk because there's 0 impl and if you want this feature you need to go rally your favorite browser and push the community to push the impl and that the WG is a conduit to the communication. If the community cares they can rally for it. 16:25:55 tantek: Then the browser vendors prioritize and it's hard or they don't prioritize and explain why. 16:26:55 fantasai: I'd 100% agree with you if the reason not to include it in CR is impl issues. The reason I'd drop if we were going to CR tomorrow, it's that there are issues as to if the impl even want to go in that direction. It's not likew e havea feature and they're prop to add a different feature, it's also about what about doing it this way instead and that's an open issue about the design of the deature. 16:27:08 smfr has joined #css 16:27:27 tantek: If it is documented as an open issue, that should be docuemnted in a blog post today. :has might not make it because there's open issues and if you care help us resolve it. 16:27:32 Yes, we has no has() 16:28:02 Should be haz() 16:28:04 q? 16:28:11 glazou: I'm hearing a majority that doesn't want to drop :has. Second, we need some time to work on this and push on impl or devs. It's another signal saying lets give us a few weeks and pub a CR with better feedback. We have a F2F in Aug and that's the time to do this. 16:28:46 tantek: If we agree to decide inAug, anyone bloggin now should point out that itmeline to the community. Say hey we're going to make a call at this meeting and you need to give feedback before that. 16:28:51 q+ 16:28:57 ack plh 16:28:59 just made a MS Edge uservoice: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8977591--has 16:29:06 glazou: I'll use my superpower of chairmainship to pub that on my blog and draw taht atten. 16:29:37 +1 updated WD 16:29:40 plh: I believe you ahev all the rights to pub on the W3C blog too. I'm happy witht he plan, but in the meantime can we update the WD in /tr? I'm not asking CR just updating the issues draft and publish it in CR. 16:30:28 fantasai: The next pub will be a WD and we'd rather soon, but I need to go through the draft. Before we pub I want to make sure everything is correct. I think we might want to defer non-controversial things so there's less to review. We'll keep :has in the next WD, but I'dlike us to go through some of the other items. 16:30:53 plh: If you can do it in the week that would be nice. The draft in tr is just too old. The sooner we can update the better. 16:31:06 fantasai: A week isn't reasonable because it takes a week to pub and I have to review. maybe 2 weeks. 16:31:06 is Selectors still using the old pub system? 16:31:17 plh: I was asking you to give a +1 to publish next week. 16:31:45 fantasai: If I go through the entire doc and there's nothing that needs fixing we can resolve to pub next week. I likely will have a bunch of issues and have to push it off. 16:31:52 tantek: What's the delay with another WD? 16:32:18 fantasai: I don't know of anyone else that was reviewed the changes in this WD over the last years. I'd like someone to review it to make sure that nothing has been dropped. 16:32:26 glazou: Publishing the WD is a call for the review. 16:32:32 smfr_ has joined #css 16:32:45 fantasai: I'm an editor and either we can remove me as an editor or we can wait until I review. 16:33:03 dbaron: A bunch of what's in here hasn't been discussed in the group. It's stuff where there was a ML post and it got intot he draft. 16:33:22 q+ to note general criteria is it better than prev TR draft or not? with editor comfort ;) 16:33:23 glazou: Yes. It's sometimes more of an idea sink. That's why the list from fantasai has almost a dozen features to drop. 16:33:56 ack tantek 16:33:56 tantek, you wanted to note general criteria is it better than prev TR draft or not? with editor comfort ;) 16:33:57 fantasai: The list in the draft are ones that have been discuessed in the WG. 16:34:34 Regrets+ sanja 16:35:01 tantek: The right criteria for TR is if it's better then the last. I find it hard to believe that publishing this wouldn't be better than having a draft that's 2 years old. However I sympathize with fantasai concenrs about not having reviewed as a co-editor. Can you consider what's the min level of review you need to pub. I understand wanting to be through, but I think we need to update. 16:35:14 fantasai: If I review I'm going to be through. The changes that need review are detailed. 16:35:15 I'd want section 3.2 either removed or rewritten if we're going to publish on TR. 16:35:17 tantek: Okay, fair. 16:35:48 dbaron: The thread on 3.2 died off waiting for a response from you, iirc 16:35:54 s/be through/be thorough 16:35:59 Topic: CSS 2015 prose and prefixing policy 16:36:02 https://lists.w3.org/Archives/Public/www-style/2015Jul/0261.html 16:36:19 glazou: So fantasai and Florian requested review. 16:36:34 q+ to wonder if using "browser" instead of "UA" will lead to problems later. 16:36:57 smfr__ has joined #css 16:37:04 TabAtkins, there's one message from you in the thread, to which I replied 16:37:06 Florian: It was fantasai and TabAtkins, but I was a part of writing an older draft. I have reviewed the latest and it matches my memory, but I didn't review enough to speak on details so I'd like another week. High level, though it's good to me. 16:37:07 ack Bert 16:37:07 Bert, you wanted to wonder if using "browser" instead of "UA" will lead to problems later. 16:37:51 Bert: I like it overall. It's a bit late, but I'm not sure that can be helped. It mentioned browser instead of UA and I'm wondering if that could be a problem for the features that are only done by UA. 16:38:15 s/late/vague in some places/ 16:38:32 Florian: There's a difference between things exposed to the web and things that aren't. So if we define browser as something exposed to the web...we need to clarify, but we need to clarify the difference between exposed to web and not. 16:38:48 glazou: A batch processor prints something without a dynamic envireoment. 16:38:54 Florian: It should be a browser. 16:38:59 glazou: It's going to be tricky. 16:39:04 Florian: That's why I want a week. 16:39:09 I hear hober? 16:39:27 hober 16:39:30 hober: The blog post write-up I think makes assumptions about how browsers are shipped that aren't nec. true. 16:39:55 https://twitter.com/briankardell/status/623892832953200641 16:40:14 hober: I think we shouldn't as a WG impose specific release strat on browsers. In section B there's a line that says "experimental features ship only in non-release builds" which assumes there's a thing as a non-release build and I don't think we should demand that. 16:40:21 TabAtkins: It's an implicit case. 16:40:31 hober: Where do you ship experimental features? 16:40:38 fantasai: You don't. YOu're not allowed. 16:41:08 astearns: place caret inside textfield after it appears :-( crappy UI 16:41:25 Florian: You could tweek the wording to allow a flag. Taking one step back I remember what you said and when trying to word that I remember that the general way to do it didn't match with Apple and it was generally a you should do this rather then a you must do this. 16:42:02 hober: I think your suggestion of a run-time flag improves the degrees of freedom that we're giving browsers. What I was trying to say is it's a mistake for the WG to impose a release strategy so allowing a diversity is better. 16:42:09 smfr_ has joined #css 16:42:29 TabAtkins: We want a policy that works well for the web in the future. If it's something like that make a suggestion in the thread and we'll word-smith it. 16:42:39 TabAtkins, there is not necessarily anger in "this might be an issue, let’s fix it?". Sorry if terseness indicated anger 16:43:01 smfr is making good points 16:43:28 smfr: Historically iOS apple hasn't had experimental releases so we can't ship if we follow these rules. So we wouldn't have shipped transitions, animations, etc. It feels like it's impeading progress. I understand wanting less prefixing, but I don't want to prevent browsers from innovating. 16:43:33 TabAtkins: ROFL 16:43:48 OTOH we're now stuck with having to support -webkit- prefixes for some properties on mobile because they've taken root in some geos 16:44:10 Note: transitions/animations/etc, while great, are PRECISELY THE SITUATION WE'RE TRYING TO AVOID because of how crazy annoying and painful they've been to iron out inconsistencies that were baked in due to early shippping. 16:44:32 TabAtkins it's a tradeoff - no easy answer :( 16:44:35 MUST (BUT WE KNOW YOU WON'T) 16:44:45 Florian: We considered this specific case. It was good that safari pushed for innovation, but the standardization wasn't good. That's why in general the prefixing policy says you shouldn't relsease what hasn't been discussed. It also has if you end up doing it, here's how you prefix and here's how others should react. Re realize you will and it's innovative, but will also screw up with standardization 16:45:04 smfr: I think that's why we're okay since it's a should. Another high level question, is any of the text actually normative? 16:45:14 Florian: Given that it's shoulds and must is sounds normative. 16:45:31 fantasai: This is the in the boiler plate for every module. IN that instance it's most definitly normative. 16:46:27 fantasai: WE discussed how the snapshots used to be WD because we wanted it to be non-normative. The WG resolved to make it a note. You can conform to a note, but it's not a rec. In regards to a note it's status isn't rec track. So you can conform, but I don't know what the W3C thinks of that. 16:46:47 fantasai: We do need this stuff to be normative. You're non-conforming if you, for ex, parse things you don't support. 16:47:01 smfr: That sounds fine. I think that this will appear in every spec means we must agree. 16:47:14 smfr has joined #css 16:47:22 gregwhitworth: TabAtkins have you spoken with chris wilson and the other people that were working on it so that authors can rely on it working? 16:47:35 TabAtkins: We've discussed, but not beyond maybe this is a cool idea. 16:48:07 gregwhitworth: It might be good to loop those people in. Come up with even above the WG so authors can have the flags and can turn them on so real users are supplying real feedback. 16:48:17 TabAtkins: It might be good to bring to TAG so they can discuss. 16:48:34 fantasai: This is intended to reflect a bunch of resolutions 3 years ago and a bunch of discussion we had around this. 16:49:07 hober: I haven't clicked through to the minutes, but I was surprised to see that we thought this was resolved. My recollection was we didn't resolve anything. It was 3 years ago so I can be mis-remembering. 16:49:43 Florian: We did on some high level concepts but not all the details. Based on the agreeed high level ideas I was tasked to write it, I did it with fantasai, passed it on to SimonSapin and we've juggled it. 16:49:45 hober: yeah, you're right, we didn't put final approval on it 16:49:51 hober: due to lack of proposed text 16:49:53 yeah, agreed 16:50:15 hober: Okay, that makes sense. It seems risky to resolve without details. I guess if we resolved on a bunch of things without details that could effect how people felt. 16:50:23 antonp1 has joined #css 16:50:54 Florian: There's tension between dicussing and shipping first and deciding later. The rules are drafted in favor of browsers who can discuss before shipping, but they don't ignore that it happens. 16:51:11 hober: I like what you just said. I wish this said that. If you can do it, do blah. If you can't, don't. 16:51:28 smfr__ has joined #css 16:51:29 Florian: The intent is the same. It's details in the wording and that's important, so let's take a week or two and decide. 16:51:40 fantasai: While we're here, Florian would you like to be an editor. 16:51:43 Florian: Sure. 16:51:45 glazou: Obj? 16:51:55 RESOLVED: add Florian as an editor to the snapshot 16:52:01 fantasai: Can we add TabAtkins ? 16:52:06 glazou: And objections? 16:52:15 RESOLVED: add TabAtkins as an editor to the snapshot 16:52:21 glazou: We have 8 minutes. 16:52:32 Florian: And we've done topic 1. 16:52:40 hey, we pre-emptively dropped a bunch of topics already! 16:52:46 https://lists.w3.org/Archives/Public/www-style/2015Jul/0285.html 16:52:47 Topic: CSS BReak 16:53:36 fantasai: I'llsummerize. 1st issue is a concern about break-before any and always. 2nd is margins. When you have a forced break and you preserve the margins after the break. If you're doing unforced we collapse the margin into the page break so your content is flush with the top 16:54:17 antonp has joined #css 16:54:25 fantasai: Because of how cloning works you might have a clone margin at a forced break and you might end up with it at the top of the page. I wanted to add a rule that drops the cloned margins even if you're at a forced break, because the element requsting the margin isn't the one forcing a break. 16:54:41 fantasai: Just wanted to make sure people are okay with that or if anyone has a different opinionon how things work. 16:55:01 Florian: Conceptually I understand, but I can't recide without examples to look at. You're prob right, but it's too abstract for me. 16:55:20 fantasai: So do cloned margins ever get kept at page breaks at the top of the page or do we always drop them. 16:56:11 SteveZ: I think you're moving in the corect direction. I jsut had troble understanding hte wording you put it as saying that. My concern is a bit like Florian. I'd like to make sure you're still preserving the behavior on first pages, but not when it's not quite first page. It's not clear to me that it's only the cloning case. 16:56:19 fantasai: It's just the clone case. 16:56:34 SteveZ: I'm happy with that, but people need to look atht he wording. 16:56:43 bradk: Could htis be solved with collapsing the page margins? 16:56:53 fantasai: Sort of. That's sort of what happens. 16:57:08 bradk: There are really big margins if you want it off the top of the page. 16:57:15 SteveZ: These are fragmenets, not elements. 16:57:27 fantasai: Please continue to think about it and if you're still not sure next week we can talk more. 16:57:40 smfr has joined #css 16:57:40 glazou: So let's defer to next week. 2 minutes on the call. 16:57:48 glazou: I don't think we have a 2 minute item. 16:57:51 Topic: #7 16:57:55 https://lists.w3.org/Archives/Public/www-style/2015Jun/0132.html 16:58:33 I think the abuse is more likely than the valid use-cases, thus I'm leaning towards drop 16:58:49 Florian: user-select: none, should we have it. I think we should, but a number of people say it can be abused horribly as copy-protection. Given it's been raised a couple of times it would be good for the WG to decide. It can be abused, it has valid cases, there are warnings not to misuase it and permission to browsers to work around the abuse. 16:59:04 glazou: I'd like a week of review. I want to make absolutely sure it won't harm my software. 16:59:06 especially since there's already sites working even harder to block users 16:59:12 the evidence is there that sites would abuse 16:59:15 let's not make abuse easier 16:59:17 Florian: If you disagree with how it befaves we can keep working on it. 16:59:22 TabAtkins: We consider it a useful feature. 16:59:38 if you consider it a useful feature, then perhaps we need specific documentation of such use-cases 16:59:44 Florian: So if we agree it's useful and we may need to tweek, but won't drop, I want a WG resolution that I can point to 16:59:50 glazou: I consider it a useful feature. 16:59:56 tantek: I have that in the spec already 17:00:00 SteveZ: abstain 17:00:06 glazou: Anyone else? 17:00:14 smfr__: I think in webkit we have valid use cases. 17:01:10 tantek: I have mixed feeligns. I simpathize with useful features, but the evidence I have from sites that try to hone the experience more make me think that if we lower the barrier to abusive sites it makes it more likely sites will be abusive. I'm not sure the usefulness outweights the abuse 17:01:21 TabAtkins: It's been in webkit and blink for years and there isn't much abuse 17:01:27 tantek: Okay. That's a good data point. 17:01:41 glazou: Can you live with it's a useful feature and we don't drop it. 17:01:44 tantek: Yeah. 17:01:45 0 17:01:47 glazou: Any obj? 17:01:54 Mozilla has had it as well for years. 17:01:57 RESOLVED: user-select: none is a useful feature and we don't drop it. 17:02:07 glazou: Thank you for today, talk to you next week. 17:03:29 smfr_ has joined #css 17:08:06 smfr_ has joined #css 17:11:25 bradk has left #css 17:11:35 smfr__ has joined #css 17:33:29 dholbert has joined #css 17:52:39 hober has joined #css 18:43:05 dholbert has joined #css 18:47:06 adenilson has joined #css 18:56:56 shepazu has joined #css 19:01:03 dbaron has joined #css 19:24:39 Zakim has left #css 20:28:00 lajava has joined #css 20:59:12 dbaron has joined #css 21:01:05 rego has joined #css 21:32:12 adenilson_ has joined #css 22:09:14 dbaron has joined #css 22:22:35 zcorpan has joined #css 22:24:41 myles has joined #css 23:11:26 dholbert has joined #css 23:44:53 dauwhe has joined #css