15:34:13 <RRSAgent> RRSAgent has joined #css
15:34:13 <RRSAgent> logging to http://www.w3.org/2015/06/10-css-irc
15:34:18 <glazou> Zakim, this will be Style
15:34:18 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 26 minutes
15:34:23 <glazou> RRSAgent, make logs public
15:40:09 <renoirb> renoirb has joined #css
15:45:46 <glazou> glazou has joined #css
15:47:21 <antenna> antenna has joined #css
15:57:54 <dael> dael has joined #css
15:58:00 <dbaron> dbaron has joined #css
15:58:08 <stakagi> stakagi has joined #css
15:58:35 <glazou> Zakim, code?
15:58:35 <Zakim> the conference code is 78953 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), glazou
15:58:37 <Zakim> Style_CSS FP()12:00PM has now started
15:58:41 <Zakim> +plinss
15:58:43 <Zakim> +dael
15:58:44 <dael> ScribeNick: dael
15:59:10 <bcampbell> bcampbell has joined #css
15:59:18 <alex_antennahouse> alex_antennahouse has joined #css
15:59:31 <dael> dael has joined #css
15:59:33 <Zakim> + +34.93.016.aaaa
15:59:37 <antonp> Zakim, aaaa is me
15:59:37 <Zakim> +antonp; got it
15:59:54 <Zakim> +dauwhe
15:59:58 <Zakim> +[IPcaller]
16:00:06 <Zakim> + +1.479.764.aabb
16:00:09 <bcampbell> Zakim, [IPcaller] is me
16:00:09 <Zakim> +bcampbell; got it
16:00:11 <Zakim> + +1.631.398.aacc
16:00:18 <Florian> Zakim, I'm one of these
16:00:18 <Zakim> I don't understand 'I'm one of these', Florian
16:00:22 <Zakim> +fantasai
16:00:25 <antonp> Zakim, mute me
16:00:25 <Zakim> antonp should now be muted
16:00:31 <Zakim> - +1.479.764.aabb
16:00:34 <Zakim> +??P13
16:00:45 <Zakim> + +33.1.39.21.aadd
16:00:50 <Zakim> +??P7
16:00:50 <antenna> zakim, aaaa is me
16:00:50 <Zakim> sorry, antenna, I do not recognize a party named 'aaaa'
16:00:51 <glazou> Zakim, aadd is me
16:00:51 <Zakim> +glazou; got it
16:01:01 <tantek> tantek has joined #css
16:01:10 <antenna> zakim, aacc is me
16:01:10 <Zakim> +antenna; got it
16:01:13 <Zakim> + +1.479.764.aaee
16:01:17 <Florian> Zakim, I am aaee
16:01:17 <Zakim> +Florian; got it
16:01:29 <Zakim> +hober
16:01:38 <glazou> Zakim, mute me
16:01:38 <Zakim> glazou should now be muted
16:01:45 <BradK> BradK has joined #CSS
16:01:46 <tgraham> zakim, P13 is me
16:01:46 <Zakim> sorry, tgraham, I do not recognize a party named 'P13'
16:02:01 <tgraham> zakim, ??P13 is me
16:02:01 <Zakim> +tgraham; got it
16:02:37 <Zakim> +BradK
16:02:38 <Zakim> + +1.415.231.aaff
16:02:43 <glazou> coughing even
16:02:58 <koji> zakim, +1.415.231.aaff is me
16:02:58 <Zakim> +koji; got it
16:03:16 <Zakim> +[Bloomberg]
16:03:24 <alex_antennahouse> zakim, +1.479.764.aabb may be me
16:03:24 <Zakim> sorry, alex_antennahouse, I do not understand your question
16:03:31 <alex_antennahouse> zakim, +1.479.764.aabb is me
16:03:31 <Zakim> sorry, alex_antennahouse, I do not recognize a party named '+1.479.764.aabb'
16:03:43 <andrey-bloomberg> andrey-bloomberg has joined #css
16:03:53 <glazou> some good news to note : https://twitter.com/mollydotcom/status/608652644224081921
16:04:05 <glazou> Zakim, aabb is alex_antennahouse
16:04:05 <Zakim> sorry, glazou, I do not recognize a party named 'aabb'
16:04:17 <Zakim> + +1.281.305.aagg
16:04:22 <TabAtkins> Zakim, aagg is me
16:04:22 <Zakim> +TabAtkins; got it
16:05:12 <dael> plinss: Let's get started.
16:05:17 <dael> plinss: Anything to add?
16:05:22 <dael> Florian: I think koji posted something
16:05:25 <dael> plinss: I saw that.
16:05:35 <dael> Topic: CSS UI 3 LC comment
16:05:54 <Zakim> +dbaron
16:06:00 <dael> Florian: We have one more week in unofficial LC. We've had two comments. SOme of them were non-controversial and I changed them.
16:06:02 <Florian> https://wiki.csswg.org/spec/css3-ui#current-issues
16:06:12 <Florian> s/two/some/
16:06:13 <dael> Florian: Her'es the ones that need discussion
16:06:51 <dael> Florian: If we start with the first one, #94 he is suggested that the default HTML stylesheet should have resize: both as a default. I think all browsers that have this do it, so I'm fine, but I don't care that strongly
16:06:57 <dael> Florian: what does the group think?
16:07:12 <dael> Florian: IE doesn't impl resize so they don't have it, but the browsers that do impl have it.
16:07:13 <dbaron> sounds fine to me
16:07:22 <dael> TabAtkins: Yeah, it's demonstrated to exist basically, so you should.
16:07:31 <dael> Florian: Anyone form MS here?
16:07:40 <dael> [silence]
16:07:43 <dael> Florian: I guess not.
16:07:44 <Zakim> +??P2
16:07:45 <tantek> dialing in
16:07:53 <tantek> zakim, ??p2 is me
16:07:53 <Zakim> +tantek; got it
16:08:12 <dael> Florian: This impl that for this to work means overflow is something other than visable, but I think they are.  I ahven't seen a text-area:overflow. I believe it's overflow auto
16:08:15 <dael> TabAtkins: They're auto
16:08:20 <dael> Florian: I'm pretty sure there's scroll
16:08:37 <dael> Florian: I think they're visable. Overflow scroll in IE. THat's okay for this.
16:08:42 <dael> TabAtkins: It's auto in chrome.
16:08:57 <dael> Florian: I think it's auto everywhere except overflow y scroll in IE, but no one has it visable.
16:09:03 <dael> Florian: I'm hearing weak agreement.
16:09:16 <dael> tantek: That's not informative so we can change at any point.
16:09:23 <dael> Florian: No one obj so I suggest we put it in.
16:09:38 <dael> RESOLVED: Add the sugestion about resize: both
16:09:44 <murakami> murakami has joined #css
16:09:50 <dael> Florian: next is #95
16:10:33 <dael> Florian: The word Ellipsed as a word isn't i nthe dictionary, but I have have found it in some dictionaries, but Ellipsized is only in Android docs. But he still thinks go with it because it doesn't mean what we say.
16:10:42 <dael> TabAtkins: Yeah, I think it means give it an ellipsis.
16:10:48 <dael> Florian: No dictionary has what we want.
16:11:08 <dael> tantek: I would reject these grammar/spelling ocmments unless it's a very strong case. That's our job as editors to get it right.
16:11:09 <Zakim> +??P4
16:11:12 <SimonSapin> Zakmi, ??P4 is me
16:11:14 <dael> Florian: I agree, but I wanted other opinions.
16:11:23 <SimonSapin> Zakim, ??P4 is me
16:11:23 <Zakim> +SimonSapin; got it
16:11:29 <dael> TabAtkins: I've dealt with this before, but I've jsut invented a word using standard english rules.
16:11:41 <dael> tantek: I think the wording is fine. I would reject that kind of request.
16:11:52 <dael> Florian: That's my inclentation too
16:11:57 <dael> RESOLVED: Reject issue 95
16:12:14 <dael> Florian: Issue 96
16:12:45 <dael> Florian: He thinks the at-risk section isn't clear enough. He wanted the section about text-overflow explaining it's about ellipsis and having direct links to the rest of hte spec
16:12:55 <dael> tantek: The ellpsis part of text overflow isn't at risk.
16:13:05 <dael> Florian: I think that isn't the right place to remind people what it does.
16:13:15 <fantasai> I think this is editorial, doesn't need WG discussion
16:13:32 <dael> Florian: He also wanted pointers to the exact parts of the spec and we're pointing to the beginning of the section. I think it's good enough.
16:13:51 <dael> tantek: I agree with fantasai that this level of editorial feedback should just be fixed and not do telecon.
16:14:05 <dael> Florian: I just wanted to have agreement to reject, but if you think it's not we can move ahead.
16:14:18 <dael> TabAtkins: plinss do we need WG approval for editorial, or jsut non-editorial?
16:14:21 <dael> plinss: I'm not sure.
16:14:34 <dael> tantek: If it's okay witht he WG I'd like to focus on normative in telecon time.
16:14:35 <glazou> or Bert
16:14:37 <dael> plinss: I agree.
16:15:17 <glazou> Zakim, unmute me
16:15:17 <Zakim> glazou should no longer be muted
16:15:17 <dael> fantasai: The editorial stuff, if the commenttor objects to your resolution bring it to the WG, otherwise just fix. If it's termonology, maybe bring it to the WG because we like to have consistent termonology.
16:15:32 <dael> plinss: If the change crosses specs it needds to get out there.
16:15:34 <fantasai> terminology
16:15:54 <dael> Florian: I brought it up because I wanted to reject, but I'll do it without group time. The other issues are similar.
16:16:15 <dael> tantek: We'll be making other changes before CR anyway. I think we can take that as editorial perrogative.
16:16:30 <dael> Florian: Okay. timeless and I had back and forth, but he was disagreeing with what I was proposing.
16:16:42 <dael> plinss: let's move on.
16:16:51 <dael> Topic: user-select
16:16:55 <glazou> can you hear me?
16:17:05 <glazou> argl
16:17:21 <dael> tantek: On that note, since we are nearing the end of the LC, I'd like to try and get group concensus on pub CR the tuesday after next.
16:17:25 <dael> tantek: That's the 30th
16:18:19 <Zakim> -glazou
16:18:20 <dael> fantasai: You can't pub CR< it has to go through a process with telecons.  Once you complie the DoC and can get a resolution form the WG that they agree with the resolution of comments, you'll turn it over to the chairs and they'll get it published later. You can get it in the pipeline, but it'll get pub a bit later. CR takes longer.
16:18:33 <dael> fantasai: You can get group concensus to pub CR, but not on a date.
16:18:49 <Zakim> +glazou
16:18:50 <dael> tantek: So the hopes of getting CR through pipeline, I'm asking for group consensus to pub CR
16:18:56 <dael> plinss: I'm okay, but we need a DoC
16:19:05 <dael> Florian: We have it in the wiki but it needs to be cleaned.
16:19:12 <dael> tantek: We don't have the formal red/green.
16:19:24 <dael> TabAtkins: bikeshed makes that easy for you with the issues list command.
16:20:15 <dael> Florian: There's one point we might want. One of the editorial was a11y. There was author level that said they mustn ot remove outlines on focus level. They want us to ahve a lot stronger of a threat i nthat. It's editorial, but people get more touchy about a11y.
16:20:30 <dael> fantasai: You might also link to the guidelines and make it brightly colored.
16:20:47 <dael> tantek: On that note, we should make a pollicy that CSS specs do not make laws or something :)
16:21:06 <dael> Florian: Anyway, move on?
16:21:12 <dael> tantek: We want consensus on CR.
16:21:14 <glazou> +1
16:21:17 <Zakim> -dbaron
16:21:17 <tantek> +1
16:21:19 <dael> plinss: Obj to taking UI to CR?
16:21:20 <Florian> +1
16:21:20 <dauwhe> +1
16:21:28 <dael> RESOLVED: Take CSS UI 3 to CR
16:21:28 <dbaron> why did Zakim just hang up on me?
16:21:40 <dael> tantek: Thanks everyone
16:21:45 <dael> topic: user-select
16:21:58 <Zakim> +dbaron
16:22:10 <dael> Florian: I had an action to try and make some variations around user-select none so that if you select the parent you either would or would not include the none.
16:23:28 <dael> Florian: I've beed through the bugzilla of FF and webkit and I don't think we should do this. FF has it so that if you have a child the user-select: none isn't included and there is no bug asking for it to be the other way, but webkit has bugs asking for the FF way. There's no evidence people wan tthe webkit way so I don't think we should provide. If your browser can't do multi-part you don't, but if you can you do.
16:23:28 <glazou> fine by me
16:23:44 <Florian> https://lists.w3.org/Archives/Public/www-style/2015Jun/0002.html
16:23:46 <dael> plinss: Objections?
16:24:17 <dael> resolved: don't offer varients of user-select: none that Florian was actioned to investgate
16:24:20 <Florian> https://lists.w3.org/Archives/Public/www-style/2015May/0306.html
16:24:24 <dbaron> I think it sounds fine as long as that's not what -moz-user-select: -moz-none is... but I think I discussed that with Florian at some point.
16:24:38 <dael> Florian: next is something else I had an action on.
16:25:14 <stakagi> stakagi has joined #css
16:26:07 <dael> Florian: It was to put a note saying user-select: none is useful in template in an editor setting because you have an overall editable area with a specific area that's not ditable or deliable like a disclamer. The way content: editable typically works is if you have a non-editable thing you can still delete it. But by having user-select: none you can't delete. But I really don't think I can say that in here.
16:26:26 <dael> Florian: It looks a bit out of scope. If you still want a note I have proposed wording, but I'm not conviced we should have it.
16:26:28 <Florian> Note: user-select:none on a non-editable descendant of an editable element means that in addition to not being editable, that descendant is also not deletable, neither directly nor by attempting to include it in a broader selection and then deleting that selection. This matter for example in template-based editing, where an editable template may contain sections which must be preserved.
16:26:36 <dael> Florian: : [reads his proposal from the e-mail]
16:27:11 <dael> Florian: It can be a note, but I'm wondering if it's out of scope.
16:27:26 <dael> TabAtkins: It sounds fine to me, but I don't have an opinion of out of scope. If we keep it it's fine.
16:27:36 <dael> glazou: I was re-reading it and I'd like to keep it.
16:27:48 <dael> glazou: If nobody obj of course. It's non-normative anyway.
16:28:11 <dael> Florian: What makes me nervious is it's useful if targeted at people writing the spec, but if they do something else it could set up the wrong expectation
16:28:37 <dael> glazou: But the people dealing with those in a template enviroment will read both specs. I prefer having the note in one place instead of nowhere.
16:28:39 <dael> Florian: Okay.
16:28:59 <dael> glazou: If there are obj I'm happy to withdraw, but I think it's fine to leave it if no one objects.
16:29:02 <BradK> No objection
16:29:04 <dael> plinss: Objections?
16:29:13 <dael> RESOLVED: Add Florian proposed text to user-select
16:29:18 <Florian> https://lists.w3.org/Archives/Public/www-style/2015Jun/0012.html
16:29:24 <dael> Florian: Next up is this
16:30:11 <Zakim> -antonp
16:30:27 <dael> Florian: user-select isn't actually inherited, it's pseudo-inherited and goes through the auto keyword. If the browser wants to support it ::first-line we have to make sure how it works. But I think using it on ::first-line or ::first-letter is wrong. If you're trying to use this correctly it's through a UI element.
16:30:36 <dael> Florian: I'd like toe xplicitly say it doesn't apply there
16:30:43 <dael> tantek: I think not-applying is the default.
16:30:55 <dael> Florian: They have a list that says UAs may apply other stuff.
16:31:02 <dael> tantek: You want it to be must not apply
16:31:03 <glazou> +1
16:31:04 <dael> Florian: Yes
16:31:06 <dael> tantek: Okay.
16:31:09 <dael> TabAtkins: Agreeed.
16:31:12 <dael> fantasai: Yes.
16:31:19 <dael> tantek: I would add before/after
16:31:30 <dael> fantasai: I don't think it's the same problem
16:31:38 <dael> tantek: I'd liek to force someone to havea  use case for it.
16:31:44 <dael> tantek: No use case, no feature.
16:31:50 <glazou> no chocolate either
16:31:57 <dael> dbaron: I think it's extra work to make them not apply
16:32:05 <Zakim> +antonp
16:32:07 <dael> tantek: I think it's a compat problem to let them apply for action.
16:32:09 <antonp> Zakim, mute me
16:32:09 <Zakim> antonp should now be muted
16:32:18 <tantek> s/for action/by accident
16:32:21 <dael> fantasai: I don't think anyone is setting user-selecto on :before/:after
16:32:24 <glazou> Zakim, mute me
16:32:24 <glazou> WHAT
16:32:24 <Zakim> glazou should now be muted
16:32:34 <dael> dbaron: There's the problem that selection doesn't work with UI anyway.
16:32:46 <dael> plinss: I'm a bit uncomfortable to before/after because it's different use.
16:32:47 <dbaron> s/UI/::before and ::after/
16:33:16 <dael> Florian: I'm not sure it's so different. These things aren't actual content. They could be coming form selection because they're not part of the content, but I don't care that strongly.
16:33:25 <dael> plinss: I've heard people argue they can't select them.
16:33:26 <glazou> Zakim, unmute me
16:33:26 <Zakim> glazou should no longer be muted
16:33:51 <dael> TabAtkins: They're not selectable because impl limitations at the moment. If they're selectable in chrome they'd be selectable everywhere in chrome like normal text.
16:34:08 <dael> Florian: I think we have consensus on ::first-line/::first-letter but not the others.
16:34:28 <dael> RESOLVED: user-select must not apply to ::first-line/::first-letter
16:34:40 <dael> Florian: That's it for user-select
16:34:44 <dael> Topic: MQ
16:35:03 <dael> Florian: We recieved 2 e-mails from the same person asking for the same thing on custom media features.
16:35:44 <dael> Florian: He thinks it's ambig if it's a mydia type or media feature and adding parans makes it obvious. I fdon't really care, but I see where he's coming from. We should answer, though.
16:36:15 <dael> TabAtkins: I'm inclined to say no. Any other customer definitions in CSS syntax like alias style won't ahve wrapping syntax. I think it would be wierd to break just for custom-media
16:36:29 <dael> Florian: On the syntax you need to use has nothing to do with where you declare.
16:36:45 <dael> Florian: I'm okay with rejecting, I wanted to make sure we agreed to reject.
16:36:49 <dael> plinss: Other opinions?
16:37:06 <dael> RESOLVED: Reject custom-media definition change.
16:37:11 <dael> topic: sideways-left
16:38:18 <dael> koji: There are issue with the implementation functioning interop. The idea is to have it move to a property sideways-left
16:39:10 <dael> fantasai: I don't think this is a good idea because...we don't havea  problem so long as we have sideways-right and not sideways or we change the meaning of sideways to mean sideways-right and have an auto value. THere are reasons to have sideways-left as an inline thing eventually so it doesn't make sense long term
16:39:18 <dael> koji: What are the reasons?
16:39:32 <dael> fantasai: There are uncommon use cases for which is should be inline
16:39:39 <dael> koji: Is the rtl cjk?
16:39:49 <dael> fantasai: That and...
16:40:06 <dael> Florian: Why can you do taht on the block level? The rtl inside cjk? doesn't that need to be inline?
16:40:26 <dael> koji: You can do inline block that does it clearly.
16:40:33 <dael> Florian: Inline block brings other things as well.
16:41:18 <dael> fantasai: I don't think this is solving a significant problem. If there's a major problem with having sideways only meaning sideways right and have sideways auto do what sideways is doing. I don't want to chang ethe writing mode in such a way...I don't like mixing it up.
16:41:49 <fantasai> s/sideways only/then we can have sideways only/
16:41:49 <dael> koji: It's really complecated and we don't want to intorduce conplexity. If you don't like adding the value we can add the new one [?]
16:42:02 <koji> s/one [?]/property/
16:42:15 <dael> Florian: I'm a bit confused. I thought we agreed at the F2F that we could keep it the way we had. What's new?
16:42:22 <dael> koji: How did we agree?
16:42:57 <dael> Florian: We brought up that sideways-right was correct by most people but sideways and sideways-left was not and we might want to rename or get rid of some of them. After the session we agreed it was fine the way it was.
16:43:16 <dael> koji: What we discussed is that the value of sidewyas depends on the value of sideways left.
16:43:30 <dael> Florian: Okay. I understand now.
16:43:50 <dael> fantasai: I don't think it's intractable, but might be more difficult, so maybe this gets defered to next level.
16:44:00 <dael> koji: I don't want ot impl this in the next level.
16:44:08 <dael> Florian: Is sideways-right an issue, or just left?
16:44:39 <dael> koji: Right is very clearly defined. Sideways-left requires additional resources for the baseline and it's really complicated.
16:44:55 <dael> Florian: I'm tempted to say it's at-risk and that's fine, but I'm not impl.
16:45:09 <glazou> Zakim, mute me
16:45:09 <Zakim> glazou should now be muted
16:45:12 <dael> plinss: I'm not hearing consensus
16:45:31 <dael> plinss: Are we rejecting? THink about it?
16:45:53 <dael> koji: rejecting meas we have to address other issues and complexities.
16:46:07 <dael> fantasai: I don't htink we have any open issues. We jsut need to clairfy the spec
16:46:28 <dael> koji: He doesn't want to change, why isn't that an issue?
16:47:35 <dael> Florian: I think koji is brining up an issue that you raised that sideways-left is an issue if it can be applied inline. And fantasai and I were sayign it's more complicated, but also useful and it's at-risk anyway.
16:48:03 <dael> dbaron: It feels like there are use cases. It is harder and we're not doing it now. My issue is that there is a bunch of other wording in the spec that needs to be adgested.
16:48:24 <dael> fantasai: And that's something I need to fix, but we don't have to change the values and feature set, it's clarifying the spec
16:48:33 <dael> koji: How will they understand how it works?
16:48:47 <Florian> s/it/floats/ ?
16:48:48 <koji> s/it/float/
16:49:29 <dael> fantasai: It's not going to be too hard, but I need to sit down and spend like a month fixing the wording because there are a lot of areas that aren't precise enough.
16:49:53 <dael> koji: Is there anyting other than rtl appearing in cjk overflow? If this is really complicated, I don't think that's worht the complexity
16:50:07 <koji> s/overflow/vertical flow/
16:50:42 <dael> Florian: Could we try and identify the its that need fixing and look at the list and see if it's too small a use case?
16:51:37 <dael> fantasai: The one thing here is the float rules are one or two paragraphs. There are other aspects of the spec that need cleaning, I don't think this is intractable, but it does need to be done. As far as, like, there are a couple of use cases where we could make it s block level thing and if you want those handled you have to use inline block
16:51:58 <dael> fantasai: but also it makes the model fo the user more complicated because for things that are similar there is more than one switch.
16:52:46 <Florian> q+
16:52:58 <dael> fantasai: Right now the effect is localized to inside the line box. If we make it block-level when we switch we can say you ignore text orentation or try and integrate it into writing mode, but that conflates the two switches that are currently only doing seperate things. I'd prefer not to do that because it makes it less clear cut.
16:53:14 <dael> fantasai: If we decide it's toocomplicated, I'd rather set up rule on how you ignore values on inline elements.
16:53:51 <dael> koji: What we're trying to do for right also requires writing modes. It sounds inconsistant so I prefer the other way.
16:54:11 <dael> fantasai: I don't htink authors think in terms of switching baselines. They think of how their glyph is orientated.
16:54:17 <dael> koji: It depends on the people
16:54:22 <Florian> q-
16:54:33 <fantasai> I don't think people associate upright typesetting with a sideways baseline orientation
16:54:52 <dael> Florian: If I understand, sideways-left at the inline level is a problem and -right is not. The natural way to use right within a vertal text is in the inline elemt
16:55:29 <dael> Florian: Instead of relying on mixed orientation. If i understand correctly I think this should stay in inline level switch. I think I'd rather not have sideways-left instead of not having this be an inline level switch
16:56:04 <dael> plinss: I'm not hearing consensus. I'm thinking you go off and do some spec work to sort things out. Anyone have anything else to say?
16:56:17 <dael> Topic: spec pubilication
16:56:26 <dael> plinss: We need chrisl and bert, so we have to defer.
16:56:34 <dael> plinss: Anything else?
16:56:58 <dael> koji: I'm not very confortable with why we're editing the spec
16:57:12 <dael> plinss: We don't have consensus on if we'll change so we should go offline
16:57:21 <dael> tantek: Should we capture the options in the spec?
16:57:45 <dael> fantasai: spec is in CR and the options have been there for a while. People are discovering it's complex as they try and impl.
16:57:47 <glazou> in CR, adding such prose will not be editorial and will trigger a re-eval of CR...
16:57:53 <dael> tantek: I'm a fan of capturing the issues.
16:58:04 <dael> tantek: If we're not making quick progress it's good to mark it in the spec.
16:58:11 <dael> fantasai: The feature is marked as at-risk.
16:58:22 <dael> tantek: I mean the issues we've come up with that we're not resolving.
16:58:34 <dael> tantek: Someone outside the group may have insights.
16:58:56 <dael> fantasai: One issue is that we need clarification. I will do that. Koji wants to move one thing to another property to make it easier to implement.
16:59:11 <dael> tantek: For that we should put a note on it that we don't have consesnsus and we welcome input.
16:59:19 <dael> plinss: I would agree, but we're in CR.
16:59:30 <dael> Florian: W can put it in the ED which exists even if we're in CR.
16:59:42 <Zakim> -hober
16:59:43 <dael> plinss: Is that sufficent or do we republish with that?
16:59:57 <dael> tantek: WOuld it being put in the ED be a good step for you koji?
17:00:14 <dael> koji: Okay. I think there have been years without progress.
17:00:22 <dael> tantek: That's why I want it in the draft.
17:00:35 <dael> Florian: I think I disgree witht he proposal, I am okay with it being in the spec.
17:00:41 <dael> tantek: I jsut want to move the discussion forward.
17:00:42 <fantasai> dbaron, I think the argument is that it wouldn't have the varying BFC issue you raised?
17:01:05 <dael> plinss: Let's list the issue in the ED
17:01:14 <dael> tantek: I'm okay iterating on the CR with that.
17:01:25 <dael> plinss: It sounds like we have to publish the CR once there's edits on it.
17:01:34 <dael> fantasai: The CR will have to go through a few iterations.
17:01:35 <Zakim> -dbaron
17:01:37 <glazou> bye
17:01:39 <Zakim> -TabAtkins
17:01:42 <Zakim> -glazou
17:01:43 <dael> plinss: That's the top of the hour. Thanks everyone.
17:01:44 <Zakim> -dauwhe
17:01:45 <Zakim> -tantek
17:01:46 <Zakim> -BradK
17:01:47 <Zakim> -fantasai
17:01:48 <Zakim> -[Bloomberg]
17:01:48 <Zakim> -tgraham
17:01:49 <Zakim> -plinss
17:01:49 <Zakim> -bcampbell
17:01:51 <Zakim> -koji
17:01:52 <Zakim> -antenna
17:01:53 <Zakim> -SimonSapin
17:01:54 <Zakim> -dael
17:01:57 <Florian> s/I am okay with/I support/
17:02:03 <BradK> BradK has left #css
17:02:20 <Zakim> -antonp
17:02:28 <Florian> s/it being in the spec/it being recorded as an issue in the spec/
17:02:29 <Zakim> -??P7
17:02:34 <Zakim> -Florian
17:02:35 <Zakim> Style_CSS FP()12:00PM has ended
17:02:35 <Zakim> Attendees were plinss, dael, +34.93.016.aaaa, antonp, dauwhe, +1.479.764.aabb, bcampbell, +1.631.398.aacc, fantasai, +33.1.39.21.aadd, glazou, antenna, +1.479.764.aaee, Florian,
17:02:35 <Zakim> ... hober, tgraham, BradK, koji, [Bloomberg], +1.281.305.aagg, TabAtkins, dbaron, tantek, SimonSapin
17:08:43 <Florian> Tantek, can you have a look at timeless's email and the remaining open issues for CSS3-UI?
17:09:16 <tantek> yes
17:09:29 <Florian> I've already made some adjustemnts based on his suggestions, but what's left is what I'd rather not do. If you agree to reject, then we can make an official statement
17:09:30 <tantek> I agree with capturing all these as separate issues btw - to be clear
17:09:37 <tantek> because those all feed into the disposition of comments
17:09:57 <tantek> as a general rule I'm going to back / agree with your rejections
17:10:15 <tantek> re: what's left - issue #s?
17:10:38 <Florian> 96 97 98
17:11:19 <Florian> 97 I've partly agreed and adjusted already, but he wants me to adjust more than I've already done, and I don't think that's right.
17:11:56 <plh> plh has joined #css
17:12:08 <Florian> I am ok with rephrasing to make things clearer, I am not ok with statements like "If you don't conform, such and such party may refuse to do business with you, and such and such user group may hate you"
17:12:38 <tantek> yeah I totally agree with you
17:12:48 <tantek> that kind of assertion is out of scope for a w3c spec
17:13:04 <Florian> yep
17:13:04 <tantek> which is a good reason to raise it to the WG as a general policy for CSS specs
17:13:17 <tantek> and frankly, I'm happy to accept that as an item to raise to the AB as a general policy for W3C specs
17:13:49 <tantek> despite TabAtkins's not-so-hidden agenda :P
17:14:48 <Florian> An AB resolution could be nice, as a thing to point to
17:15:01 <Florian> but then you'd need to be very careful about how it's phrased
17:15:51 <tantek> well the way that would typically work is for a WG to adopt a policy first
17:15:54 <tantek> by consensus in the WG
17:16:04 <tantek> and the AB could look at it and say, hey this is a good idea that we should generalize
17:16:14 <Florian> "You MUST do X. If you don't, you should do Y instead." is a useful thing to state in a spec. "You MUST do X, or else!!!" is not.
17:16:21 <tantek> lol
17:17:56 <Florian> All right, dinner time. Then I'll roll in todays resolutions.
17:21:11 <SimonSapin> Florian: an extension to MUST (BUT WE KNOW YOU WON'T) ?
17:22:22 <Florian> SimonSapin: must (and He will know if you don't, and you shall repent).
17:23:01 <adenilson> adenilson has joined #css
17:23:15 <tantek> SimonSapin: is there an April fools RFC for that?
17:23:22 <tantek> like a variant of 2119?
17:27:18 <TabAtkins> tantek: 6919
17:28:57 <tantek> Florian_away: in short: 96, we can make some editorial clarifications. 97, we can editorially clarify importance, threat request rejected as out of scope for a W3C spec. 98, agreed, reject. Editing the wiki accordingly.
17:30:35 <tantek> updated
17:30:39 <tantek> wiki updated rather
18:12:22 <dauwhe_> dauwhe_ has joined #css
18:34:32 <antonp> antonp has joined #css
18:49:40 <glazou> glazou has joined #css
18:58:05 <Zakim> Zakim has left #css
19:04:47 <antonp> antonp has joined #css
19:11:00 <antonp1> antonp1 has joined #css
19:13:34 <Florian_away> tantek, you're still there?
19:14:25 <Florian> For 97, I've already changed the style to make it stand out (class=advisement)
19:15:02 <Florian> "Keyboard users, which includes people with disabilities who may not be able to interact with the page in any other fashion, depend on the outline  being visible on elements in the :focus state, thus authors must not make the outline invisible on such elements without making sure an alternative highlighting mechanism is provided."
19:15:09 <Florian> I suggest also rephrasing to the above
19:20:16 <dauwhe> dauwhe has joined #css
19:20:19 <tantek> Florian: WFM
19:20:38 <tantek> oh, slight native speaker fix
19:20:43 <Florian> as for 96, I am not against clarifying, but I don't quite see how.
19:20:49 <Florian> please
19:21:19 <tantek> Keyboard users, in particular people with ...
19:21:51 <tantek> slight semantic, "which" tends to apply to things/objects, and it's slightly more polite to not use it for references to people
19:23:46 <Florian> Thanks, that does sound better.
19:25:08 <Florian> I'll use that
19:25:20 <Florian> for 96, do you get what improvement we can make?
19:26:19 <antonp> antonp has joined #css
19:38:31 <tantek> for 96, I can attempt some rewordings, or I'll give up and say so :)
19:39:41 <Florian> I've made the edits for 94 and 97
19:40:56 <tantek> great
19:41:28 <Florian> should I let timeless know which suggestions we accepted and which we rejected already, or do you want to fix up 96 first
19:43:30 <Florian> for wiki / DoC purposes, should I could 97 as accepted or rejected, since we accepted part of the comment (make it clearer and make it stand out), but not some other part (make threats)?
19:44:31 <Florian> I'm thinking of counting it as rejected, since that's what important to track. Accepted editorial changes are not that imortant to keep track individually when we already have about 100 issues on record.
19:47:46 <tantek> in the past I've noted such in DoCs as partially accepted / rejected and used yellow
19:47:59 <tantek> maybe even in the previous CSS3 UI CR DoC!
19:48:04 <Florian> :)
19:48:46 <Florian> the status lines indicates partially accepted / rejected, and I've put it in the "Rejected" section of the wiki just to make sure we don't make it green by accident.
19:49:10 <tantek> oh hey I had a whole rainbow code
19:49:11 <tantek> http://www.w3.org/Style/css3-updates/css3-ui-comments :)
19:49:57 <tantek> now I remember what I did to solve that problem
19:50:32 <tantek> anything that I partially accepted / rejected, I split into smaller subcomments that I marked explicitly wholly accepted or rejected
19:51:42 <Florian> sounds reasonable. For now we have all the info in the wiki. We can massage it into the right shape later
19:52:24 <Florian> I'll send a mail to timeless about the ones we've rejected, to ask if he objects or can live we that.
19:52:43 <Florian> Do we have a template for asking this by the way? I think I've seen one at some point.
19:59:55 <stakagi> stakagi has joined #css
20:00:35 <tantek> asking what?
20:01:50 <dbaron> dbaron has joined #css
20:12:14 <Florian> tantek: a template for "Please tell us if you can live with that, or if you formally object"
20:12:57 <tantek> I've avoided a template for such to instead force myself to personalize each message and make it seem less likea  "form letter" response/rejection
20:13:24 <tantek> Totally anecdotal: I have found that personalized response tend to get more sympathetic follow-up than form-like responses
20:14:07 <tantek> also, practicing writing such deliberate politeness is probably a good thing for all of us editors
20:14:12 <tantek> especially when we reject things
20:14:25 <tantek> even if it's slower
20:18:09 <liam> inviting formal objection escalation is also best not done too soon
20:18:42 <tantek> yeah I wouldn't even ask them "if you formally object" - no need to suggest that option
20:19:02 <tantek> it sounds like a "or else you could escalate" which sounds a bit too confrontational/uncooperative
20:19:07 <liam> better is, "If this is acceptable there's no need to do anything, otherwise please reply to this message with more details - thank you"
20:19:15 <tantek> thanks liam - that's good
20:19:32 <liam> yw :)
20:20:55 <liam> Florian, see above suggestion.
20:21:27 <tantek> Florian, also ok to reply with work-in-progress and to say still working on remaining questions/issues
20:21:31 <Florian> liam, tantek: Is it good? I believe we actually need an answer saying "I'm ok with this" when we reject a comment, and I am not sure we can assume that silence means agreement.
20:21:45 <Florian> tantek: Yes, for WIP, I plan to state that
20:22:02 <tantek> Florian: I think that's why I came up with all the different colors in the previous DoC
20:22:17 <Florian> plinss: can you comment on the above discussion?
20:22:27 <tantek> http://www.w3.org/Style/css3-updates/css3-ui-comments
20:22:43 <tantek> in particular I think it's ok to document silence as absence of further objection
20:22:45 <plinss> Florian: in TAG telcon, will look in a few...
20:22:49 <tantek> but explicitly note that it was silence
20:22:51 <tantek> hence *yellow*
20:22:55 <tantek> instead of green
20:23:01 <tantek> which should be ok
20:23:07 <Florian> tantek: I think "we asked if it was ok, and got no answer" is acceptable, but we actually need to ask for an answer
20:23:33 <liam> Florian, you only have to make clear they can say no
20:23:40 <liam> you don't need a formal "yes"
20:23:44 <tantek> Florian, we don't actually have to ask
20:23:49 <tantek> though it is nice to do so
20:24:16 <tantek> e.g. if you look through the previous DoC, many times I cited others' emails as responses to issues, which did not ask for any follow-up
20:24:38 <liam> it also heads off a possible 'did the person know they could respond" question, ahtough that wouldn't be an issue with timeless of course
20:24:52 <tantek> heh yeah - hence why personalized responses are important
20:25:04 <tantek> right, with timeless I would focus on polite brevity
20:25:18 <liam> and please someone offer him a job :-)
20:25:31 <tantek> with others I might be more up front about making sure they knew they could follow-up
20:25:40 <Florian> I am not in the position to offer anyone a job
20:25:42 <tantek> depends greatly on how shy they might be/sound
20:26:12 <liam> Florian, no, that wasn't directed at anyone in particular, but I think he was laid off from Nokia, not sure exactly
20:29:02 <Florian> Ok, I'm going to go with this as the intro, follow by a response on each issue:
20:29:13 <Florian> Hi timeless,
20:29:13 <Florian> This is an update on the status of the issues you raised
20:29:13 <Florian> which had not yet been addressed. Some of your suggestions
20:29:15 <Florian> have been rejected by the working group. Please reply to
20:29:17 <Florian> this message with more details if this is not acceptable.
20:29:40 <Florian> s/follow/followed/
20:30:41 <Florian> Liam, tantek: ^ sounds ok?
20:31:53 <tantek> yes - and cite the minutes for "rejected by the working group"[n]
20:33:14 <Florian> Minutes are not out yet. Point to IRC / Wiki, or wait for the mintues.
20:33:16 <Florian> Minutes are not out yet. Point to IRC / Wiki, or wait for the mintues.?
20:33:29 <Florian> s/.?/?/
20:34:59 <liam> i'd tone it down slightly for most other people
20:35:16 <liam> since there's a middle ground between totally unacceptable and perfectly OK
20:35:27 <liam> wait for the minutes if possible
20:35:29 <tantek> agreed
20:35:33 <tantek> on both counts
20:35:44 <tantek> the less confrontational you can make it sound, the better
20:36:41 <liam> "Thank you for your comments. We accepted some of your suggestions and not others - please see the minutes and respond on the list if you have more questions."
20:37:01 <liam> (with link to minutes of course)
20:37:42 <liam> i know i know, bikeshed :-)
20:38:41 <myles> myles has joined #css
20:42:29 <Florian> Thanks. Enough bikesheding now. I'll send something close to that once the minutes are out.
20:44:10 <adenilson> adenilson has joined #css
20:45:31 <SimonSapin> can bikeshed generate email responses to comments? :]
20:49:57 <dauwhe_> dauwhe_ has joined #css
20:54:22 <plinss> Florian: we often have transition calls without responses to rejections, we do presume no response is consent but it’s better if we get an OK back
20:57:08 <Florian> plinss: Thanks. I'll mention in the mail that we would appreciate an explicit OK if acceptable to him.
20:57:23 <Florian> (while keeping the message in line with what Liam suggested)
20:57:24 <dbaron> dbaron has joined #css
21:11:42 <liam> Florian, sounds fine
21:11:51 <liam> timeless is very cooperative & helpful.
21:53:38 <Florian> Florian has joined #css
21:54:37 <TabAtkins> SimonSapin: I refuse to cross the "become an email server" boundary.
21:54:51 <SimonSapin> haha
21:55:00 <TabAtkins> fantasai: We're thinking of unprefixing our Sizing keywords. Thoughts?
21:55:33 <SimonSapin> TabAtkins: http://www.catb.org/jargon/html/Z/Zawinskis-Law.html
21:55:50 <TabAtkins> Yeah, that's what I was referencing.
21:56:34 <liam> ahh Jamie
21:56:46 <liam> and was it gnu "echo' that had a built-in mail reader?
22:01:43 <SimonSapin> `cat` can read mbox files…
22:02:53 <Florian> Florian has joined #css
22:03:24 <liam> true :)
22:06:52 <TabAtkins> wut
22:08:10 <TabAtkins> Also: why does tac exist
22:16:15 <liam> someone was feeling silly i expect
22:16:47 <liam> plus it's easier than using num (or cat -n) and sort -nr and sed to remove the line numbers
22:35:49 <jdaggett> jdaggett has joined #css