/irc-logs / w3c / #css / 2015-08-25 / end

Options:

# Session Start: Tue Aug 25 00:00:00 2015
# Session Ident: #css
# [00:01] * Joins: dauwhe (~dauwhe@public.cloak)
# [00:11] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [00:12] * Rossen_away is now known as Rossen
# [00:15] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [00:29] * Joins: dauwhe (~dauwhe@public.cloak)
# [00:31] * Joins: Florian (~Florian@public.cloak)
# [00:40] * Joins: adenilson (~anonymous@public.cloak)
# [00:45] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [00:45] * Joins: Florian (~Florian@public.cloak)
# [00:52] * Rossen is now known as Rossen_away
# [00:55] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [00:55] * Joins: Florian (~Florian@public.cloak)
# [00:58] * Joins: jdaggett (~jdaggett@public.cloak)
# [01:02] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [01:08] <TabAtkins> plinss: Yo, all the CSS specs are broken. Please force-generate them twice?
# [01:09] <TabAtkins> plinss: And also plz make them force-generate always; any time certain "core" specs break, they cause cascading breakage that can't be fixed.
# [01:18] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [01:18] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [01:29] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [01:29] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [01:31] * Quits: darktears (~darktears@public.cloak) ("Leaving...")
# [02:01] * Joins: jdaggett (~jdaggett@public.cloak)
# [02:06] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [02:10] * Joins: tantek_ (~tantek@public.cloak)
# [02:10] * Quits: tantek (~tantek@public.cloak) (Client closed connection)
# [02:10] * tantek_ is now known as tantek
# [02:11] <fantasai> jdaggett: You might know the answer to this magic and how we can make sure it's allowed per spec? http://lists.w3.org/Archives/Public/www-style/2014Jun/0426.html
# [02:14] <jdaggett> that's a ken question
# [02:15] <jdaggett> guessing that it's simply part of the way the font is designed
# [02:15] <fantasai> How would it get triggered, though?
# [02:15] <fantasai> TCY uses upright glyphs, so it's not a vertical alternate...
# [02:15] <jdaggett> as in, it's the default placement of the glyph
# [02:15] <jdaggett> "uses upright glyphs"???
# [02:15] <fantasai> Or should it use valt?
# [02:16] * fantasai sorry
# [02:16] <fantasai> I meant "horizontal text glyphs"
# [02:16] <jdaggett> hmmm
# [02:17] <jdaggett> glyphs are the same typically, horizontal/vertical
# [02:17] <jdaggett> vert glyphs are a small subset
# [02:17] <jdaggett> vertical/horizontal *metrics* are different but i doubt there are special digits for vertical
# [02:18] <jdaggett> best way is simply to test with any decent CJK font
# [02:18] <jdaggett> i.e. not normal Linux CJK fonts... :P
# [02:18] <jdaggett> try source han sans...
# [02:19] <jdaggett> yikes
# [02:19] <jdaggett> can you send work mail to moz addr?
# [02:19] <jdaggett> fantasai: ^
# [02:20] <fantasai> sorry, didn't notice it was the wrong address
# [02:20] <jdaggett> :P
# [02:20] <fantasai> (on the plus side, that was off-list)
# [02:21] <jdaggett> heh
# [02:21] <jdaggett> ok, sent a mail so that ken replies to the right addr
# [02:22] <jdaggett> fantasai: is there something about TCY that's still an issue?!?
# [02:22] * fantasai going through the DoC right now
# [02:22] <fantasai> there's several issues filed against it, yeah
# [02:22] <jdaggett> by who?
# [02:22] <fantasai> various people
# [02:22] <jdaggett> hmmm
# [02:23] <fantasai> I'll know once I've finished triaging :)
# [02:23] <jdaggett> implementers? epub folks? or gerard?
# [02:23] * fantasai doesn't have a more accurate answer atm
# [02:23] <jdaggett> kk
# [02:23] <fantasai> mix
# [02:23] <fantasai> all of the above, I think
# [02:23] <fantasai> :)
# [02:23] * jdaggett groan
# [02:23] <jdaggett> that property already has too much magic
# [02:23] <fantasai> well, this one's invalid
# [02:24] <jdaggett> my vote is for less magic
# [02:24] <jdaggett> ok, good good
# [02:24] <fantasai> but still, more issue s:)
# [02:24] <jdaggett> any "let's add additional magic" issue should be frowned upon...
# [02:24] <jdaggett> and all the crazy inheritance issues, meh
# [02:24] <jdaggett> sooooo not important
# [02:27] * Quits: tantek (~tantek@public.cloak) (tantek)
# [02:27] * jdaggett goes back to enjoying being the only one in the office this morning...
# [02:27] <jdaggett> :D
# [03:09] * fantasai finishes triaging the first half of the writing modes issues and decides it's now bedtime
# [05:08] * Quits: myles (~Adium@public.cloak) ("Leaving.")
# [06:02] * Joins: antonp (~Thunderbird@public.cloak)
# [06:10] <koji> fantasai: regarding the MacFan, I suppose fonts do it, both in horizontal and vertical as John suggested. ANSI characters in CJK fonts (esp. publishing quality fonts) have adjusted glyphs to match better to be used in CJK text. Just use the right font is the answer I guess...
# [06:24] * Joins: estellevw (~estellevw@public.cloak)
# [06:51] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [06:58] * Joins: estellevw (~estellevw@public.cloak)
# [07:28] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [07:34] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [07:34] * Quits: dholbert (~dholbert@public.cloak) ("dholbert")
# [07:47] * Joins: zcorpan (~zcorpan@public.cloak)
# [07:49] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [07:49] * Joins: zcorpan (~zcorpan@public.cloak)
# [07:56] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [08:00] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:05] * Quits: kwkbtr (~kwkbtr@public.cloak) (Ping timeout: 180 seconds)
# [08:09] * Joins: dauwhe (~dauwhe@public.cloak)
# [08:10] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [08:12] * Rossen_away is now known as Rossen
# [08:12] * Joins: dholbert (~dholbert@public.cloak)
# [08:17] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [08:25] * Joins: lajava (~javi@public.cloak)
# [08:26] * Joins: Florian (~Florian@public.cloak)
# [08:39] * Joins: jdaggett_ (~jdaggett@public.cloak)
# [08:39] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [08:40] * Joins: Florian (~Florian@public.cloak)
# [08:44] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [08:44] * jdaggett_ is now known as jdaggett
# [08:44] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:45] * Joins: dauwhe (~dauwhe@public.cloak)
# [08:47] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [08:50] * heycam|away is now known as heycam
# [08:58] * Rossen is now known as Rossen_away
# [09:01] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:04] * Joins: hober (~ted@public.cloak)
# [09:06] * Joins: ed_paris (~ed@public.cloak)
# [09:08] * Joins: skk (~skk@public.cloak)
# [09:09] * Quits: skk (~skk@public.cloak) ("Page closed")
# [09:09] * Joins: tantek (~tantek@public.cloak)
# [09:11] * Joins: dael (~dael@public.cloak)
# [09:13] * Joins: Florian (~Florian@public.cloak)
# [09:15] * Joins: Zakim (zakim@public.cloak)
# [09:15] * Joins: RRSAgent (rrsagent@public.cloak)
# [09:15] <RRSAgent> logging to http://www.w3.org/2015/08/25-css-irc
# [09:16] <plinss> zakim, this will be style
# [09:16] <Zakim> I do not see a conference matching that name scheduled within the next hour, plinss
# [09:16] <plinss> rrsagent, make logs public
# [09:16] <RRSAgent> I have made the request, plinss
# [09:17] * Joins: andrey-bloomberg (~andrey-bloomberg@public.cloak)
# [09:17] * Joins: hyojin (~hyojin@public.cloak)
# [09:19] * dauwhe it will be a red-letter day, judging from the scribe's laptop :)
# [09:19] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:20] * dael dauwhe :D
# [09:21] * Ms2ger waves at Paris
# [09:21] * Florian is now known as Paris
# [09:21] * Paris waves at Ms2ger
# [09:21] * Paris is now known as Florian
# [09:22] * Bert thinks we've never had this large a meeting, have we?
# [09:22] * Ms2ger If anyone is bored during the meeting: https://github.com/w3c/csswg-test/pull/829
# [09:23] <dael> scribeNick: dael
# [09:23] * Joins: dbaron (~dbaron@public.cloak)
# [09:23] * Rossen_away is now known as Rossen
# [09:23] * Joins: jh_hong (~jh_hong@public.cloak)
# [09:23] * Joins: skk (~skk@public.cloak)
# [09:24] * Quits: skk (~skk@public.cloak) ("Page closed")
# [09:24] * Joins: haletuse (~haletuse@public.cloak)
# [09:24] * Joins: skk (~skk@public.cloak)
# [09:24] * Joins: MaRakow (~MaRakow@public.cloak)
# [09:25] <dael> plinss: First topic, agenda.
# [09:25] * TabAtkins Ms2ger You in Paris at all?
# [09:25] <dael> plinss: Req to do FX topics first
# [09:25] <dael> hober: Dino will be here on Thursday.
# [09:25] <dael> plinss: FX on Thursday?
# [09:25] * Ms2ger TabAtkins, nope, actually getting work done :)
# [09:25] <dael> heycam: We'll still be here Thursday...we can just pop downstairs
# [09:25] * TabAtkins spoilsport
# [09:25] <dael> plinss: FX thursday morning?
# [09:25] <dael> [general yes]
# [09:26] <dael> plinss: So we'll do FX Thursday
# [09:26] * Joins: tkonno (~chatzilla@public.cloak)
# [09:26] <dael> plinss: anyone with time constraints?
# [09:26] <dael> fantasai: Writing modes not today
# [09:26] <dael> michaelmiller: inline not today.
# [09:26] <dael> hober: Simon wanted to do will-change so he's here Thursday.
# [09:27] * dbaron realize we didn't move the sound absorbing materials back when we reset the room layout this morning
# [09:27] <dauwhe> s/michaelmiller/Steve Zilles/
# [09:27] <dael> hyojin: Display tomorrow?
# [09:27] <dbaron> s/Display/Round display/
# [09:27] <dael> johannes: page floats on Thursday if possible
# [09:28] * Joins: SteveZ (~SteveZ@public.cloak)
# [09:28] * Joins: esprehn (~sid10445@public.cloak)
# [09:28] <dael> shans: Can I propose a topic? We'd like to talk about animations 2
# [09:28] <dael> plinss: Time constraints?
# [09:28] <dael> shans: I don't think so.
# [09:28] <dael> hober: Is that Thursday?
# [09:28] * Joins: johanneswilm (~johannes@public.cloak)
# [09:28] <dael> plinss: We're shoving a lot off to Thursday.
# [09:29] <astearns> s/michaelmiller/SteveZ/
# [09:29] * astearns oh, dauwhe already caught that
# [09:29] * dauwhe astearns but Steve wasn't on IRC then :(
# [09:30] <tantek> present+ tantek
# [09:30] <TabAtkins> Present+ Tab Atkins, Google
# [09:30] <zcorpan> Simon Pieters, Opera Software
# [09:30] * Joins: weinig (~weinig@public.cloak)
# [09:30] <fantasai> Present+ Elika J Etemad, Invited Expert
# [09:30] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [09:30] <dauwhe> present+ Dave Cramer, Hachette
# [09:30] <plinss> present+ Peter Linss, HP
# [09:30] <zcorpan> present+ Simon Pieters, Opera Software
# [09:30] <Florian> Present+ Florian, Invited Expert
# [09:30] <MaRakow> present+ Matt Rakow, Microsoft
# [09:30] <skk> Hiroshi Sakakibara, from BPS co.LTD, and Keio University.
# [09:30] <dael> present+ Dael Jackson, Invited Expert
# [09:30] <gregwhitworth> present+ Greg Whitworth, Microsoft
# [09:30] <hober> present+ Edward O'Connor, Apple
# [09:30] <shane> Present+ Shane Stephens, Google
# [09:30] <astearns> present+ Alan Stearns, Adobe
# [09:30] <andrey-bloomberg> < Andrey Rybka
# [09:30] <tantek> present+ Tantek Çelik, Mozilla
# [09:30] <weinig> present+ Sam Weinig, Apple
# [09:31] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [09:31] <birtles> present+ Brian Birtles, Mozilla Japan
# [09:31] <Bert> present+ Bert Bos, W3C
# [09:32] <dael> plinss: UI today?
# [09:32] <dael> Florian: That's fine.
# [09:32] <SimonSapin> present+ Simon Sapin, Mozilla
# [09:32] <dael> plinss: Morning/afternoon? Let's do afternoon.
# [09:32] <dael> plinss: Anything else time constrained?
# [09:33] <dael> plinss: Let's just do times. There's the github conversation.
# [09:33] <dael> fantasai: I think we should save that.
# [09:33] <fantasai> s/that/that for when we're technically worn out/
# [09:33] * Joins: ed_work_ (~ed@public.cloak)
# [09:34] <dael> plinss: snapshot, prefix policy?
# [09:34] <dael> plinss: We're pushing a lot to Thursday.
# [09:34] * Joins: tkonno_ (~chatzilla@public.cloak)
# [09:34] <dael> plinss: Let's not do that on Thursday.
# [09:34] * Ms2ger fantasai: enjoy the feeling :)
# [09:34] <dael> fantasai: We could do it after lunch. Not in the morning.
# [09:34] <dael> plinss: This afternoon?
# [09:34] <dael> fantasai: We could.
# [09:35] <dael> plinss: Grid issues?
# [09:35] <dael> fantasai: Tomorrow? I'd rather Flexbox today.
# [09:35] * TabAtkins fantasai quit mumbling
# [09:35] <dael> fantasai: We could even do that this morning.
# [09:35] <dael> plinss: User style sheets, clilly isn't here yet.
# [09:35] <dael> plinss: CSS IG?
# [09:35] * Quits: tkonno (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [09:35] <dael> fantasai: That can fill in whenever. It's not super important.
# [09:35] <hyojin> present+ Hyojin Song, LG Electronics
# [09:35] <dael> plinss: Cascade to LC.
# [09:35] <dael> fantasai: That's 10 minutes.
# [09:35] * tkonno_ is now known as tkonno
# [09:35] * Quits: ed_paris (~ed@public.cloak) (Ping timeout: 180 seconds)
# [09:35] <dael> plinss: Fragmentation
# [09:36] <dael> fantasai: We have one issue left, it's naming. You can drop that where it's appropriate.
# [09:36] <jh_hong> present+ Jihye Hong, LG Electronics
# [09:36] <dael> plinss: % heights and abspos, is that part of Flexbox?
# [09:36] <dael> fantasai: Can be any time.
# [09:36] <dael> fantasai: Is scroll snapping on the agenda?
# [09:36] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [09:36] <dael> fantasai: We should prob. do that today. Is Simon coming?
# [09:37] <dael> plinss: Thursday.
# [09:37] <dael> fantasai: We should waint until he's here.
# [09:37] <dael> hober: WE can prob. do it then.
# [09:37] <dael> fantasai: Does he want to call in?
# [09:37] <dael> hober: Prob. not. I can ask.
# [09:37] <dael> hober: Let's plan for tomorrow and if he says he wants to be there we'll push back.
# [09:37] <dael> plinss: Keyframe interactions
# [09:38] <dael> TabAtkins: I was waiting on Moz to say yes, that's cool.
# [09:38] <dael> plinss: uoby?
# [09:38] <dael> s/uoby/Ruby
# [09:38] <dael> fantasai: Ruby has a large chunk of issues and I'm not sure they're prep for WG discussion. I think we can put that off until the telecons.
# [09:39] <dael> astearns: Except I put them on the agenda because on the telecon we said we should discuss it at the F2F.
# [09:39] <dael> fantasai: If I get through all the other things we can do Ruby.
# [09:39] * Joins: vollick (~vollick@public.cloak)
# [09:39] <dael> plinss: fill-available sizing?
# [09:39] <dael> fantasai: I'm not prep. today
# [09:39] <dael> plinss: Tomorrow afternoon?
# [09:39] <dael> fantasai: Sure.
# [09:40] * Quits: dholbert (~dholbert@public.cloak) (Ping timeout: 180 seconds)
# [09:40] <dael> plinss: Control character status.
# [09:40] <dael> gregwhitworth: Should be short
# [09:40] <dael> plinss: Japanese interest group
# [09:40] <dael> Florian: Short.
# [09:40] <dael> plinss: CSS text 4?
# [09:40] <dael> fantasai: Maybe this afternoon or after the break?
# [09:40] <dael> plinss: Pagination
# [09:41] <dael> dauwhe: This is mixed up with houdini, but I thought there should be a discussion during CSS because some is extremely related.
# [09:41] <dael> plinss: CSS apply rule
# [09:41] <dael> TabAtkins: Whenever.
# [09:41] <dael> plinss: How long?
# [09:41] <dael> TabAtkins: 45 min
# [09:41] <dael> plinss: Tomorrow morning.
# [09:42] <dael> fantasai: I forgot to put selectors on the agenda. We can do that this morning.
# [09:42] <dael> Florian: Perhaps some other time? I'd like to review first.
# [09:42] <esprehn> present+ Elliott Sprehn, Google
# [09:42] <dael> fantasai: If we need to do topics to pull earlier we can do that. We likely have to go back to it, but there's a bunch of issues we can go through.
# [09:42] <dael> plinss: Animations 2?
# [09:42] <dael> plinss: It's on the agenda.
# [09:43] <dael> shane: I thought we had said Thursday.
# [09:43] <dael> hober: I guess it depends what we should talk about.
# [09:43] <dael> shane: It would be better if dino is there.
# [09:43] <dael> hober: dino threatened to come tomorrow, so he may.
# [09:44] <dael> shane: Do we have room Thursday?
# [09:44] <dael> plinss: Maybe.
# [09:44] <dael> shane: Wednesday afternoon?
# [09:44] <dael> SimonSapin: jdaggett's e-mail said he'd prefer the afternoon for call.
# [09:44] <dael> plinss: Which topic
# [09:45] <jdaggett> css-inline, dpub, writing modes
# [09:45] <dael> SimonSapin: writing modes and digipub priorities and css-inline
# [09:45] * Ms2ger plinss: https://github.com/w3c/csswg-test/issues/830 please advise
# [09:45] * Joins: dholbert (~dholbert@public.cloak)
# [09:45] * jdaggett SimonSapin: thanks!
# [09:45] <dael> fantasai: WE could do the github this afternoon. WE can do digipub and inline this afternoon.
# [09:46] <fantasai> s/github/digipub/
# [09:46] <dael> dauwhe: I think Steve asked for inline tomorrow.
# [09:47] * Joins: BogdanBrinza (~BogdanBrinza@public.cloak)
# [09:48] <dael> plinss: The only thing we haven't picked is user stylesheets and CSS interest group
# [09:48] <dael> s/picked/picked a time for
# [09:48] <dael> plinss: wiki is edited.
# [09:48] <dael> Topic: CSS cascade
# [09:49] <dael> plinss: Whose topic?
# [09:49] <dael> TabAtkins: Cascade is ready for CR, but we want to first pub as a last WD for review just so that anything can be sussed out before we go to CR.
# [09:49] <dael> Florian: So you're doing a WD?
# [09:49] <dael> fantasai: Yeah, there's no open issues.
# [09:50] <dael> TabAtkins: We'll do a WD and ask for CR is a bit. Just ot make sure there's no final obj.
# [09:50] <dael> plinss: Anyone opposed?
# [09:50] <dael> RESOLVED: Publish a new WD for CSS Cascade
# [09:50] <dael> fantasai: Do we want a deadline for comments?
# [09:50] <dael> Florian: 4 weeks?
# [09:50] <dael> fantasai: Sure.
# [09:50] <dael> astearns: Are you asking anyone becides the WG to look?
# [09:50] <dael> TabAtkins: I don't think there's any WG this is of interest.
# [09:50] <dael> fantasai: HTML?
# [09:51] <dael> Florian: This is pretty internal.
# [09:51] <dael> tantek: Do you need 4 weeks?
# [09:51] <dael> fantasai: We have almost no comments. It would be useful to collect comments one way or antother since we need wide review to go to CR.
# [09:51] <dael> plinss: Anything else on cascade?
# [09:51] <dael> Topic: Fragmentation
# [09:52] <dael> fantasai: We have one open issue. The naming of the any and always values fro break-before and break-after
# [09:52] <dael> fantasai: It's kind of confusing what either of these things mean.
# [09:52] <dael> SteveZ: The last time we talked on the phone I don't remember what tantek suggestion was, but I liked it. You had a problem because you fealt it was confusing
# [09:52] <dael> fantasai: Nearest. it implies that it's distance wise, not lateral.
# [09:53] <dael> SteveZ: I think that issue is deeper than all and any. Nearest would still be better. I understand there's confusion, but it's less.
# [09:53] <dael> fantasai: So nearest and farthest?
# [09:53] <dael> Florian: I was thinking yesterday. I'm not sure, but break-shallow and break-deep for any and all
# [09:54] <dael> TabAtkins: He asked me what I thought it meant and I wasn't paying attention and I got it right, so it seems reasonable.
# [09:54] <fantasai> s/break-shallow/break-before: shallow/
# [09:54] <fantasai> s/break-deep/break-before: deep/
# [09:54] <dael> fantasai: Other thoughts?
# [09:54] <dael> hober: I like the compond names with force.
# [09:54] <dael> fantasai: force-page and force-column
# [09:55] <dael> fantasai: WE don't use force as a prefix for page or column. WE should have.
# [09:55] <dael> dauwhe: It's widely used.
# [09:55] <dael> tantek: When did we last talk about this on telecon?
# [09:55] <dael> Rossen: A month ago.
# [09:55] <dael> tantek: I remember trying to draw sim. to page break prop.
# [09:55] <dael> astearns: It was on 29 July
# [09:56] <dael> fantasai: Do you know if the always values are widely used?
# [09:56] <dael> dauwhe: We tend to use page-break before always a lot.
# [09:56] <fantasai> s/page-break-before/
# [09:56] <dael> fantasai: page break prop won't change, they're being folded in but keeping their own syntax.
# [09:57] * fantasai oops
# [09:57] <fantasai> s/page-break before/page-break-before/
# [09:57] <tantek> 2015-07-29 minutes https://lists.w3.org/Archives/Public/www-style/2015Jul/0459.html
# [09:57] <dael> fantasai: This is for break-before and break-after. I don't htink they're widely used. they're not in browsers.
# [09:57] <dael> fantasai: They'd only be in AH and Prince
# [09:57] * Joins: MozParis (~MozParis@public.cloak)
# [09:58] <fantasai> (Not used on the Web)
# [09:58] <dael> dauwhe: I'm looking in prince right now. They just have column and page. They don't have pure break-before and break-after
# [09:58] <dauwhe> Prince has page-break-before/after: auto | always | avoid | left | right
# [09:58] <dael> fantasai: AH I think is just the break-before and break-after....well, we can put this on a board somewhere and people can think.
# [09:58] <dael> SteveZ: Basically any solution is better than any and all.
# [09:59] <dael> hober: I like shallow and deep. It's confusing, but a bit more obvious.
# [09:59] <dael> dauwhe: It aids in understanding if you have a certain level of knowledge.
# [09:59] * Joins: skk_ (~skk@public.cloak)
# [09:59] <dael> hober: Can we change those now since they're an improvement and leave a note saying if you have better ideas prop them?
# [09:59] <zcorpan> non-zero usage on the web for page-break-before / page-break-after https://github.com/search?l=css&q=page-break-before+OR+page-break-after&ref=searchresults&type=Code&;utf8=✓
# [09:59] <dael> fantasai: So resolve change to shadow and deep unless there's a better idea?
# [09:59] <dael> Bert: I can't say I like it.
# [10:00] <dael> SteveZ: Relative to the tree.
# [10:00] <tantek> I think I need to see the previous discussion before that telcon
# [10:00] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [10:00] <dael> Bert: But I don't like to think about the tree. A page is more like a seq. then the tree.
# [10:00] * astearns much happier with shallow/deep than shadow/deep, which is what I misheard
# [10:00] <dael> fantasai: But this is about nested frag context. if you have multicol in a region in a paged media, shallow is just the colomn, deep is the page.
# [10:01] <dael> Bert: How about soon or first available.
# [10:01] <dael> fantasai: We could also drop these values.
# [10:01] <dael> Rossen: That was a prop resolution. We've been sttuck on this for weeks for a name.
# [10:01] <dael> tantek: Who was asking for this level?
# [10:01] * Quits: fabioth (~fabioth@public.cloak) (Ping timeout: 180 seconds)
# [10:02] <dael> fantasai: We had an always because someone copied it into a CR spec and then we got an issue of what does it mean.
# [10:02] <dael> Rossen: And to have sym with always we added any. You can have context that's agnostic.
# [10:02] <dael> tantek: So we can drop both?
# [10:02] * dauwhe css-wg-decision: undo;
# [10:02] <dael> fantasai: Prob. We only have one impl of always. We'd have to re-pub multi-col.
# [10:02] <dael> Rossen: The prop was to push any to the next level and keep always for backwards compat.
# [10:03] <dael> Florian: But there's no backwards compat. I'm not okay with punting just one because then you're stuck with it.
# [10:03] <dael> fantasai: So defer always and any to next level and also resolve to replub multical without the break prop
# [10:03] <dael> SteveZ: Doe sanyone else becides bert obj to renaming to deep and shallow.
# [10:03] <dael> tantek: I don't like them.
# [10:04] <dael> Rossen: I'm not a huge fan.
# [10:04] * Quits: BogdanBrinza (~BogdanBrinza@public.cloak) ("")
# [10:04] <dael> dauwhe: I think the deep and shallow on the next level will be better with having examples. I think we need drawings.
# [10:04] <dael> tantek: Agreed.
# [10:04] <Florian> s/stuck with it/stuck with the naming of half the pair/
# [10:04] <dael> tantek: So we're dropping break before and break after?
# [10:04] <iank> present+ Ian Kilpatrick, Google
# [10:05] <dael> astearns: Just those values.
# [10:05] * Joins: BogdanBrinza (~bbrinza@public.cloak)
# [10:05] <dael> tantek: Before re-raising the values someone should produce real world use cases.
# [10:05] * TabAtkins forgot to bring up the topic "Should we switch back to just 2 meetings + TPAC next year?" - can we get that on the agenda?
# [10:05] * TabAtkins plinss ^^^
# [10:05] <dael> fantasai: astearns poitned out there's one issue about we're doing this does it make sense and maybe dauwhe you can take a look at that.
# [10:05] <tantek> let's make that the burden for "new information" for re-raising those values, you must provide real world use cases with diagrams to justify re-introducing values like any/all/shallow/deep
# [10:06] <dael> plinss: So we're removeing those values from frag and removing breaks from multi-col and repub it as CR.
# [10:06] <dael> fantasai: Yes, and hopefully publish this as CR soon.
# [10:06] <dael> plinss: So removing the entire breaks section?
# [10:06] <fantasai> s/and hopefully/when we/
# [10:06] <fantasai> s/soon//
# [10:06] <dael> Florian: Last time I talked to morgan he wanted to do mantainence of multi-col.
# [10:07] <dauwhe> s/morgan/Håkon/
# [10:07] <dael> Rossen: Yes, but we have a resolution from Tuscon to add me as a co-editor
# [10:07] <dael> Florian: And we have me as level 2.
# [10:07] <dael> Florian: So we can ping him and then we can take over.
# [10:07] <dael> Rossen: Before I was able to do the edit, he read the thread and made the edit.
# [10:08] <dael> Florian: He made some recently for a resolution we made a while back.
# [10:08] <dael> fantasai: If he's active then okay.
# [10:08] <dael> RESOLVED: Drop any and always from level 3 fragmentation
# [10:08] * TabAtkins dael, you can also call him "howcome" when relevant, if it's easier to type in ascii
# [10:09] <dael> RESOLVED: drop break before and after from multi-col and reference frag definitions and republish as CR
# [10:09] <dael> action dauwhe to look at the last issue in fragmenetation
# [10:09] * trackbot is creating a new ACTION.
# [10:09] <trackbot> Created ACTION-703 - Look at the last issue in fragmenetation [on Dave Cramer - due 2015-09-01].
# [10:09] <zcorpan> http://krijnhoetmer.nl/irc-logs/css/20150825
# [10:10] <dael> Rossen: Is issue 13 resolved?
# [10:10] * Joins: CSSWG_LogBot (~csswg_logbot@public.cloak)
# [10:10] <dael> fantasai: I don't remember, I have to check.
# [10:10] <dael> Rossen: I think you replied on ML.
# [10:10] <Florian> logs are missing from here: http://logs.csswg.org/irc.w3.org/css/ from Sunday onwards
# [10:10] <dael> fantasai: Then we just need to update DoC.
# [10:10] <dael> fantasai: Once we get dauwhe feedback and update the DoC we'll come back for the resolution to go to CR
# [10:11] <dael> Topic: keyframes
# [10:11] <dael> fantasai: That's just can dbaron look at this.
# [10:11] <dael> dbaron: What is this?
# [10:11] * Quits: haletuse (~haletuse@public.cloak) (Ping timeout: 180 seconds)
# [10:11] <dael> TabAtkins: Remember some time ago when we were talking on IRC and everyone had diff ideas of how keyframes should be parsed in different situations. I wrote it up.
# [10:11] <dael> dbaron: I need to read it.
# [10:11] <dael> TabAtkins: So revisit tomorrow?
# [10:11] <dael> dbaron: I don't know if I'll have time.
# [10:12] <dael> TabAtkins: moz is the only one left for a yes/no call.
# [10:12] <dael> dbaron: Do you have a URL?
# [10:12] <dael> TabAtkins: I'll send.
# [10:12] <dael> Topic: control char status update.
# [10:12] <gregwhitworth> http://logs.csswg.org/irc.w3.org/css/2015-02-08/#e520447
# [10:12] * TabAtkins dbaron: https://lists.w3.org/Archives/Public/www-style/2015Jul/0391.html
# [10:13] <dael> gregwhitworth: We all resolved, bascially every UA agreed to impl control characters blocks 0 and 1 as hexboxes if they have them.
# [10:13] <dael> gregwhitworth: We've done it for C0. For almost every browser they throw away C1 blocks. We were looking to see if other browsers were doing this. I wanted to get an update.
# [10:13] <dael> TabAtkins: We haven't done the work but we're fine with going ahead.
# [10:13] <dael> fantasai: We wanted to release this all together.
# [10:14] <dael> dbaron: Jonathan Q would know, maybe Jet.
# [10:14] <dbaron> s/Q/Kew/
# [10:14] <fantasai> TabAtkins, do you guys have someone assigned to it?
# [10:14] <dael> gregwhitworth: I'll follow up witht he list on the C1 issue. Maybe put in the spec that if you have a new browser, you should throw out C1.
# [10:14] <dael> hober: I don't remember, but dino will be here soon.
# [10:15] <dael> gregwhitworth: So TPAC it should be in everyone's code and do the PR to announce it.
# [10:15] * Joins: rachelandrew (~59cacb34@public.cloak)
# [10:15] <dael> Bert: Do you find many console characters in the style sheets?
# [10:15] <dael> gregwhitworth: We haven't shipped it out witht he flag so we don't know. There are some sites, I don't know how they're getting it in there. That's why we need to do the PR hit, actually for the customers, not the devs.
# [10:15] <dbaron> s/console/control/ (?)
# [10:15] <dael> plinss: So do we need to come back?
# [10:16] <dael> gregwhitworth: I'll talk to dino.
# [10:16] <dael> Topic: Japanese industry meetup
# [10:17] <dael> Florian: We were talking about this yesterday. Since the next F2F is in Japan and there's lots of companies in Japan int. in this group, espeically writing modes, so it seemed to make sense to have a meet-up next to the WG meeting. Maybe on Sunday before TPAC have a room somewhere.
# [10:17] <dael> Florian: We can have the members of the WG that are interested meet with Japanese business people. Maybe have it mixed langauge.
# [10:17] <dael> ??: I talked to the site manager today and he can set up a room for that. Please let me know.
# [10:17] <dbaron> present+ David Baron, Mozilla
# [10:17] <dael> fantasai: Does everyone think this is a good idea.
# [10:17] <astearns> s/??/hiroshi/
# [10:18] <dael> dauwhe: I like the idea, but I'm concerned a lot of us have made travel plans.
# [10:18] <dael> astearns: Would an evening work? Instead of during the day of sunday, meet after the TPAC sessions?
# [10:18] <dael> hiroshi: Yes.
# [10:18] <dael> SteveZ: Monday night doesn't have an event.
# [10:18] <dael> fantasai: Is that enough time?
# [10:18] <dael> fantasai: It'll be 4 hours at most.
# [10:19] <dael> Florian: I'm not sure having ti during the meeting is as good.
# [10:19] <dael> Florian: Personally I'm good with any random time.
# [10:19] <dael> fantasai: Who is interested in attending?
# [10:19] <astearns> interested
# [10:19] <hober> +0.5
# [10:19] <fantasai> interested
# [10:19] <dauwhe> interested
# [10:19] <Rossen> interested
# [10:19] <Bert> interested
# [10:19] <birtles> interested
# [10:19] <Florian> intreseted
# [10:19] <plinss> +1
# [10:19] <johanneswilm> possibly
# [10:19] <skk_> interested
# [10:19] <Rossen> Rossen Atanassov, Microsoft
# [10:19] <shane> interested
# [10:20] <SteveZ> I would be interested in attending a Japanese Meet-up
# [10:20] <hyojin> interested
# [10:20] <jet> interested
# [10:20] <iank> interested
# [10:20] <SimonSapin> interested
# [10:20] <dael> fantasai: Of those interested who has travel plans.
# [10:20] <dael> bert and dauwhe
# [10:20] <dael> fantasai: Can you make a sunday?
# [10:20] <dael> Bert: I arrive sunday early afternoon.
# [10:20] <dael> fantasai: So if we did it in the evening and not have dinner, we can do 2 hr. If we include dinner we have 4 hr
# [10:21] <dael> Florian: Are we doing TPAC with the gigantic lunch break?
# [10:21] <dael> dauwhe: Didn't we ignore that?
# [10:21] <dael> astearns: We did.
# [10:21] <dael> Florian: We were offered the options to meet from 9-11 and resume at 3 with joint sessions.
# [10:21] <dael> hober: We only meet for 2 days.
# [10:22] <dael> fantasai: So we can do 2 hours, 4 hours if we get catered, and that can be monday evening. We can do a large chunk of Wednesday. Or we do Sunday and have a schedule conflict with Bert and dauwhe. I suspect 2 hr is too short
# [10:22] <dael> Florian: And if we do 4hr we can do the thing were you mingle with food. So 3 hr of meeting and 1 hr of food.
# [10:23] <dael> dbaron: How many people would travel to Sapporo for the 2 hr meeting?
# [10:23] <dael> hiroshi: 20 or 30 people
# [10:23] <dael> fantasai: I think 4 hours is too short with lots of questions
# [10:23] <dael> Rossen: How much time would you prefer to have?
# [10:23] <dael> hiroshi: I have no idea.
# [10:23] <dael> Rossen: Is 2 hours enough?
# [10:23] * dauwhe but we can't do odd numbers of hours
# [10:23] <dael> fantasai: We can do 2 hr, 4 hr, or 6-8hrs
# [10:24] * astearns but only even numbers of hours
# [10:24] <dael> hiroshi: I want to talk with some guys in Japan to answers.
# [10:24] <dael> Florian: I think we shouldn't do it Sunday because the conflicts.
# [10:24] <dael> fantasai: It'll depand on what they need.
# [10:24] <dael> fantasai: So we have several options and we need to know from the community what they want.
# [10:25] <dael> hiroshi: I understand the options and I can talked to the community and have answers tomorrow.
# [10:25] <dael> hober: Before we move on, dino will be here half the day tomorrow.
# [10:25] <dael> plinss: So maybe now is break time?
# [10:25] <dael> fantasai: Any other random topics?
# [10:26] <dael> TabAtkins: A few years ago we switched to 3 meetings/year plus TPAC. I think the WG is moving abit slower and I was suggesting 2016 switches to 2 meetings plus TPAC.
# [10:26] <dael> fantasai: I think we might want to wait until TPAC to make that decision.
# [10:26] <dael> TabAtkins: Okay, put it in everyone's head to think about it.
# [10:26] <dael> tantek: Is the based on metrics or a feeling?
# [10:27] <dael> TabAtkins: We're not doing as much work as we were a month ago.
# [10:27] <dael> dbaron: We could schedule for May/June and decide if we're scheduling for Spetember later.
# [10:27] <dael> tantek: You could also look at things we can measure.
# [10:27] <dael> fantasai: And do we consume all the agenda or are we filling time.
# [10:27] <dael> Florian: We've had several with light agenda.
# [10:27] <dael> Rossen: NY had overflow.
# [10:28] <dael> hober: It seems like we've expanded to a 5 day F2F.
# [10:28] <dael> TabAtkins: I think we can expand to fill any space.
# [10:28] <dael> fantasai: There have been meetings were we've been scrounging for topics.
# [10:28] <hober> s/5 day F2F/5 day F2F including Houdini/
# [10:28] <dael> dauwhe: It could also be an issue of do we need three days.
# [10:28] <dael> fantasai: I think we should wait until later to figure out.
# [10:29] <dael> SteveZ: May be a good exercise for Thursday afternoon to help ID things that need work.
# [10:29] <TabAtkins> s/a month ago/a year or two ago/
# [10:29] <dael> <break=15min>
# [10:29] <fantasai> s/that decision/that decision because I've been increasing my hours recently/
# [10:30] <fantasai> s/with light agenda/with light agenda, but not this one/
# [10:30] <fantasai> s/5 day F2F/5 day F2F with Houdini/
# [10:30] <fantasai> s/There have been/No, there have been/
# [10:31] <fantasai> s/need three days/need three days, could do 3 meetings 3 days or 4 meetings 2 days/
# [10:35] * Joins: liam (liam@public.cloak)
# [10:38] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [10:39] * Quits: weinig (~weinig@public.cloak) (weinig)
# [10:39] * Ms2ger suggests agenda+ https://lists.w3.org/Archives/Public/public-css-testsuite/2015Aug/0000.html
# [10:41] * Joins: antonp1 (~Thunderbird@public.cloak)
# [10:44] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [10:44] * antonp1 is now known as antonp
# [10:45] * Quits: rachelandrew (~59cacb34@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [10:46] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [10:52] * Joins: weinig (~weinig@public.cloak)
# [10:54] * Joins: johanneswilm (~johannes@public.cloak)
# [10:55] <fantasai> Ms2ger: Those tests should be updated, yes.
# [10:56] <fantasai> Ms2ger: We can't always predict when invalid stuff will become valid in future CSS specs. :)
# [10:56] <fantasai> Ms2ger: So it's good the tests were written, to make sure implementations didn't use e.g. quirks mode color processing in CSS.
# [10:57] <fantasai> Ms2ger: But now that we have a valid interpretation of 4/8 digit hex colors, we should update the CSs2.1 tests to pass when those are correctly implemented
# [10:57] <Ms2ger> r? https://github.com/w3c/csswg-test/pull/814
# [10:57] * Joins: rachelandrew (~59cacb34@public.cloak)
# [10:58] <Ms2ger> fantasai, and I believe https://github.com/w3c/csswg-test/issues/830 is about a test you wrote :)
# [10:58] <dael> plinss: Let's get started
# [10:58] * Parts: kwkbtr (~kwkbtr@public.cloak)
# [10:58] <dael> Topic: Flexbox
# [10:58] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [10:58] <fantasai> Ms2ger: You should have double match references for that test, so it passes if either one matches.
# [10:59] <dael> fantasai: Let me pull up the DoC
# [10:59] <fantasai> Ms2ger: Since a 2.1 client should parse those as invalid, and L4 UA should parse and interpret the color as 4/8 color hex
# [10:59] <plinss> https://drafts.csswg.org/css-flexbox/issues-lc-20140925
# [10:59] <Ms2ger> Mm
# [10:59] <dael> fantasai: Okay. It's a long issues list since I updated it.
# [11:00] <fantasai> https://drafts.csswg.org/css-flexbox/issues-lc-20150514
# [11:01] <dael> fantasai: We've got a couple of open issues.
# [11:01] <dael> fantasai: First one is if min and max content size of flex containters should consider the flex basis or just work off the max content.
# [11:02] <dael> fantasai: I think dholbert was leaning to what the spec currently says. If I have a flex item whose flex basis is 50px and the max content is 10px, when I shrink should it be 50 or 10.
# [11:02] <dael> TabAtkins: 50.
# [11:02] <dael> fantasai: It's flex basis so it can shrink or grow.
# [11:03] <dael> fantasai: So if I have a flex cont. with one item and that item has "hi" and I give flex basis of 10em and I shrinkwrap should it be 2em or 10em?
# [11:03] <dael> dbaron: What do existing impl do.
# [11:03] <dael> dbaron: We've been shipping this for a while.
# [11:03] <dael> gregwhitworth: I think this one we're all over the map.
# [11:03] <dael> gregwhitworth: Flex is just shrink/grow?
# [11:03] <dael> fantasai: Yeah.
# [11:04] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20%20*%20{%20border%3A%20solid%3B%20}%0A%3C%2Fstyle%3E%0A%3Cdiv%20style%3D%22display%3A%20flex%3B%20float%3A%20left%3B%22%3E%0A%3Cp%20style%3D%22flex%3A%201%201%2050px%22%3Eem%3C%2Fp%3E%3C%2Fdiv%3E
# [11:04] <dael> dbaron: With flexbox it seems like the issues should have test cases and results when they come up for discussion. A year ago when we made an imcompat change, we had a lot of problems and we're not going to do that again.
# [11:04] <dael> Rossen: You're not alone.
# [11:04] <dael> fantasai: This test case uses max content size. That's fine with me.
# [11:05] <dael> fantasai: There's an issue on % inside flex items with min size auto which we've discussed. There were 3 options. 1 was tech impossible. 2nd was make % not resolvable 3rd is 2 pass layout. It looks like impl are converging on 2 pass and we don't have a preference. We'd like impl to get together and decide.
# [11:06] <dael> fantasai: Does anyone else have anything. I plan to get gregwhitworth and dholbert and Christian on a call and have them figure it out.
# [11:06] <dael> dbaron: I'm a bit concerned about perf characteristics of flexbox right now, but that's all.
# [11:06] <dael> fantasai: I have no opinion. It's perf vs author expecations.
# [11:07] <dael> action fantasai to get people on a call to make a decision about % inside flex items with min size auto
# [11:07] * trackbot is creating a new ACTION.
# [11:07] <trackbot> Created ACTION-704 - Get people on a call to make a decision about % inside flex items with min size auto [on Elika Etemad - due 2015-09-01].
# [11:07] <dael> fantasai: Last one, if you have a flex container and you put two table cells in it, they won't become flex items independantly. They'll wrap in an anon table and that will be flex. Chrome has impl so that each item is flex.
# [11:07] <dael> dbaron: They do anon box after?
# [11:08] <dael> fantasai: Not at all.
# [11:08] <dael> dbaron: So it turns the table cells into blocks.
# [11:08] <dael> fantasai: I've seen at least one presentation at a conf where they took advantage of this to create fallback behavior for a flex
# [11:09] <dael> dbaron: But that only works in chrome
# [11:09] <dael> fantasai: Yes.
# [11:09] <dael> Rossen: Sounds like a terrible hack.
# [11:10] <dael> fantasai: That indicates to me that there are people taking advantage of this and could be a useful behavior. Do we want to change the spec to use chrome's behavior?
# [11:10] <dael> Rossen: They are doing fixup, but they're creating 2 anon tables instead of one according to your code.
# [11:10] <dael> smfr: You could get table layout with non level layout.
# [11:10] <dael> fantasai: That won't work because flex isn't a value for display.
# [11:10] <astearns> s/smfr/zcorpan/
# [11:11] * plinss changes topic to 'F2F Agenda - https://wiki.csswg.org/planning/paris-2015#agenda'
# [11:11] <dael> [discussion that resolves in chrome not doing fixup]
# [11:11] <dael> ??: The conversion we do for position absolute, we're doing it for flex
# [11:12] <dael> dbaron: Some of this is a function of what hte order of the fixup steps are.
# [11:12] <dael> TabAtkins: The spec has been explicit for a long time about when you do fixup. It's not the chorme behavior.
# [11:12] <astearns> s/??/ojan/
# [11:12] <dbaron> s/hte/the/
# [11:13] <dael> ojan: We didn't violate the spec when we impl that, the spec changed. We're open to fixing it. I think this is better and simplier, it's better for when we do custom layout.
# [11:13] <dael> fantasai: I don't think there's a strong arguement one way or the other. Webcompat would swing it. I had brought this up about people may want to do this backwards compat thing.
# [11:13] <dael> dbaron: So it sounds like we shoulds witch to coercing the block.
# [11:14] <dael> fantasai: I don't know how much it's an issues, but it would be safer to switch to webkit behavior. I can't think of a good use case of putting a table in a flex unless you're trying to do this fallback. If you're not trying to trigger fallback, I don't know why you'd put a bunch of table cells in flex and get it wrapped in anon stuff.
# [11:14] <dael> ojan: It sounds like no one is opposed to changing.
# [11:14] <dael> Rossen: So we'll want to do the same thing for grid.
# [11:15] <dael> fantasai: So proposal is: Don't wran an anon table around consecutive flex of a flex container.
# [11:15] <dael> TabAtkins: In the paragraph that spec the other behavior.
# [11:15] <hober> s/wran/wrap/
# [11:15] <dael> fantasai: We'll have to dig into what about having a table row.
# [11:16] <dael> ojan: I'll share with you the code Chrome uses. Somewhere the cooercing behavior needs to be expalined.
# [11:16] <dbaron> https://drafts.csswg.org/css2/visuren.html#dis-pos-flo
# [11:16] <rachelandrew> slide 39 in this deck is an example of display:table as a fallback http://www.slideshare.net/zomigi/enhancing-responsiveness-with-flexbox-css-day
# [11:16] <dael> TabAtkins: If you have two siblings and one is pos abs it should be a part of the table.
# [11:16] <dael> dbaron: I think a bunch of the coercing behavior is in that link
# [11:16] <TabAtkins> s/should/shouldn't/
# [11:16] <ojan> Here's what chrome does: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp&q=equivalentBlockDis&sq=package:chromium&l=58
# [11:16] <dael> fantasai: There's an eq section in display spec
# [11:16] <fantasai> https://drafts.csswg.org/css-display/#transformations
# [11:17] <dael> plinss: So everyone is okay with making the change.
# [11:17] <ojan> And I believe that's what WebKit does as well.
# [11:17] <dael> RESOLVED: Just blockify the children of flex and grid containers. Don't do anon box fixup
# [11:18] <dael> fantasai: I think the resolution to the first item was no for issue 2
# [11:18] <fantasai> https://drafts.csswg.org/css-flexbox/issues-lc-20150514#issue-2
# [11:18] * Zakim excuses himself; his presence no longer seems to be needed
# [11:18] * Parts: Zakim (zakim@public.cloak)
# [11:19] <dael> RESOLVED: no for issue 2 because it most closly matches existing behavior
# [11:19] <dael> s/closly/closely
# [11:19] <dael> fantasai: There's a couple things where we need to edit. Last issue is the % margin stuff.
# [11:20] <dael> TabAtkins: It's a good idea to do now.
# [11:20] <dael> TabAtkins: Soooo....
# [11:22] <dael> TabAtkins: At several previous meetings we've talked about how vert % margins and paddings are defined. LAst meeting I tried to convince people where making it behave against height. One of the strongre arguements that's comeout if the behavior of an abspos element. If it currently uses the legacy behavior, if you have an abspops block where the containing block is grid or flexbox, what do you do? If you have legacy you have a off thing where fixed uses height.
# [11:22] <dael> TabAtkins: Currently the only thing a block cares about is it's size. The only thing it cares about is that's it's a block and the thigns that make it a containing block.
# [11:22] * Joins: fabioth (~fabioth@public.cloak)
# [11:22] <dael> TabAtkins: Other than writing mode, abspos are ambiv about the containing block. Either abspos are inconsitant, or their behavior changes based on what ancestor has position relative. Also, no one cares about this so we can keep it simple witht he old legacy behavior.
# [11:23] <dael> ojan: It's more that moz has a number of bugs where web authors ask for legacy.
# [11:23] <dael> TabAtkins: We have no bugs for the new behavior.
# [11:24] <dael> tantek: This is really going to hurt the kind of people that aren't filing bugs, it's going to hurt new people.
# [11:24] <dael> TabAtkins: Aspect ratio hack is in tutorials.
# [11:24] <dael> tantek: They're not beginners.
# [11:24] * dauwhe looking forward to the beginner profile of CSS
# [11:24] <dael> gregwhitworth: I think that people do use % margins.
# [11:24] <dael> ojan: I've asked for the list of sites and I don't have it.
# [11:24] <dael> gregwhitworth: I'll get it to you.
# [11:25] <dael> shane: Is it inside flexbox or outside flexbox?
# [11:25] <dael> gregwhitworth: I don't know.
# [11:25] <dael> Rossen: I wanted to go back to your opening about how abspos is supposed to work in oblivious way of what the layout type of the containing block.
# [11:26] <dael> Rossen: That is almost true, it's a bit of a simplistic view. I would disagree with your statement because, by adding flexbox and grid and all their properties, you are taking dependancy on that layout type. I agree in the ideal case abspos should be simple canvas layout. It's the simpliest layout.
# [11:27] <dael> Rossen: If that's the only lang I have to express my layout, then there is a layout type which the only thing it cares about is the 2d containing block. Witht he addition of flex and grid, these items are speaking a different lang. Such as BTW when you're setting up this rectangle, I what to take up this number of columns. You're starting to take some dependency and context.
# [11:27] <tantek> I tend to agree with Rossen's analysis
# [11:28] <dael> Rossen: At the end of the day you're saying you're still predending to be only in the 2d space. YOu either have abspos which was nothing to do with grid and flex, but we're not there. We've made abspos items able to speak in terms of grid and flex and we are extending this simple layout to be more.
# [11:28] <dael> TabAtkins: There's nothing in flex that makes abspos care. We have static defined, but that's not difference. Grid 2, abspos don't care unless they opt in with grid behavior. Nothing else with abspos changes when you make a grid cont the cont block. You don't have a prop that changes to a different type of behavior.
# [11:28] <dael> TabAtkins: So grid sin't a great example, flexbox isn't great.
# [11:29] <dael> Rossen: It is because you are allowing prop of grid.
# [11:29] <dael> TabAtkins: We are allowing grid prop, we're not chaning the behavior of any other properties. If you explicitly want an abspos to live in a grid, you can. But we don't make width act differently because it's ain a grid. The rest of abspos works the same.
# [11:30] <dael> TabAtkins: Whatever is used as the positioning block is arbitary. That can change with simple page layout. YOu attach it to whatever positions as you need.
# [11:30] <dael> Rossen: How does aligning work?
# [11:30] * fantasai agrees mostly with Tab's analysis -- it's weirdly, and unexpectedly, inconsistent
# [11:30] <dael> TabAtkins: It just cares about wha thte continaing block is and aligns insude.
# [11:30] <dael> Rossen: I don't believe this is what we talked about for flex items abspos whose containing isn't flex.
# [11:31] <dael> TabAtkins: Every display mode defines static position.
# [11:31] <dael> ojan: For the static position it's controlled by parent.
# [11:31] <dael> TabAtkins: Yes.
# [11:31] <dael> TabAtkins: Mainining the prop is nice because it means that the layout doens't change because if you change from abspos to fixedpos nothing changes. But here it would.
# [11:32] <tantek> There's no need to change abspos behavior here.
# [11:32] <dael> Florian: If you're thinking in terms of encapsulation, you are trying to applyt he same style to them that's different if you're in grid. That's not great. If you're in two types they're different and that's not good.
# [11:33] <dael> TabAtkins: We vary particulrly made it so taht if you're doing a flexbox it's similar to a block. They will change layout if you switch to abspos in a minor but random way.
# [11:33] <dael> fantasai: I thinkt he behavior is more logical if we had started that way.
# [11:33] <dael> TabAtkins: I don't nec agree. Having the ability to do consistant padding is nice too.
# [11:33] <dael> fantasai: This is true.
# [11:34] <dael> iank: I've been running a small script 2% is using % margin padding and they're all aspect ratios for iframes.
# [11:35] <dael> gregwhitworth: I had something two weeks ago. I know there are sites out there. i'm not going to claim the % margin hack isn't the most common use, but it's not the only use. I think we've all made out points on this. I stand by it's the more logical case and they reason we switched is it's more modern layout. I agree it's confusing, but I guess in all honestly, I hear youre arguement, but I don't htink it's that strong.
# [11:36] <dael> fantasai: I think a key point that's different is it also affects abspos elements, weither or not it should. We can conclude on that. We can make abspos consistant across layout modes, but abspos won't be consistent with other tiems in grid. Or we can make them inconsistant to themselves.
# [11:36] <dael> dbaron: I would pick option 1
# [11:36] * Joins: tkonno_ (~chatzilla@public.cloak)
# [11:36] <dael> TabAtkins: Where abspos always uses legacy?
# [11:36] <dael> dbaron: Yes.
# [11:36] <dael> tantek: The other option seems like a strawman.
# [11:36] <dael> fantasai: People were seriously proposing that.
# [11:37] <dael> TabAtkins: If they're always legacy your grid items having different layout if they're abspos item.
# [11:37] <dael> fantasai: If a abspos item is positioned against the grid should it have the same % interp for margins and padding as if it was positioned against any other box.
# [11:37] <dael> tantek: Rossen, why did you argue the other way.
# [11:37] <dael> Rossen: Consistancy in grid. So if you have two items, you want consistancy.
# [11:38] <dael> fantasai: Abspos can position in relation to grid lines. They don't effect the sizing, but they can position as a grid item in certain ways.
# [11:38] <dael> tantek: So they're top/left bottom/right aligned.
# [11:38] <dael> Rossen: Yes, plus grid properties.
# [11:39] * Quits: tkonno (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [11:39] * tkonno_ is now known as tkonno
# [11:39] <dael> fantasai: So abspos positioned to a grid container can have some abilities of a grid item which is why Rossen argued they should have the same behavior. I think consistancy is good here, but consistancy across abspos is a good thing too.
# [11:39] <dael> TabAtkins: We have one self-consistant option.
# [11:39] <dael> TabAtkins: So you'll intimated before there might be legacy grid prob with microsoft using MS grid. Can we fix that without infecting standardized CSS
# [11:40] <tantek> we don't have any one self-consistent layout across all layout methods. e.g. table layout (in particular cells) is already very different
# [11:40] <dael> fantasai: One thing you could do is have boxes whose containing block is a grid cont whose display value of MS-grid would have the % behavior you have, but ones with the standard prefix would follow standard rules. They would be sep. values internally.
# [11:40] <dael> Rossen: We'd prefer to drop the prefix if we can.
# [11:41] <dael> fantasai: But the content out there depends on the prefic as well.
# [11:41] <dael> TabAtkins: in so far as people are going to update their content...we're well aware people don't update content.
# [11:41] <dauwhe> s/prefic/prefix/
# [11:42] <dael> fantasai: A lot of the content they're depending on isn't web content. Those are less likely to be doing anything becides what's coded in a MS enviroment.
# [11:42] <dael> Florian: And it makes no sense to future-proof in that enviroment.
# [11:42] <dael> fantasai: Anyone else have something to add.
# [11:42] <dael> ojan: I haven't been here for the previous conversations. Has the possibility of adding a new prop to control this been considered?
# [11:43] <dael> fantasai: Yeah, and we hate that idea.
# [11:43] <dael> Rossen: I had a mock-up
# [11:43] <dael> gregwhitworth: I'm against it.
# [11:43] <dael> tantek: So add a switch instead of a unit.
# [11:43] <dael> TabAtkins: Unit doesn't let us retrofit old content.
# [11:43] <dael> Rossen: And if you have the unit you have to deal with it everywhere.
# [11:43] <dael> fantasai: Let's not go there.
# [11:44] <dael> ro
# [11:44] <dael> Rossen: The two options on the table are, usetop and bottom % margin and padding as they're spec for inline grid and flex and don't do for abspos
# [11:44] <dael> Rossen: That would be because we want to leave abspos as legacy beahvior
# [11:44] <dael> Rossen: 2nd is make all the layout types ot be legacy behavior including grid and flex items.
# [11:45] <dael> Rossen: 3rd is where we are, everything is following inside of grid and flex, they resolve against height even for abspos.
# [11:45] <dael> Rossen: So it's all new, all legacy, or mixed where inline flex and grid behave new and abspos behaves legacy.
# [11:46] <dael> [whiteboarding of options]
# [11:47] * Parts: kwkbtr (~kwkbtr@public.cloak)
# [11:47] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [11:48] <dael> tantek: There's a strong arguement for Rossen 3rd option. This is the basis of the NY arguement. New authors coming to CSS are then able to use not just flex and grid from the top down and have that consistant treatment, they can also reuse abspos elements in a way thtat is also consistant. That almost gives us an opportunity to continue repairing that maistake form the past.
# [11:49] <dael> TabAtkins: You're assuming there's a pop of authors that are fed up with the behavior
# [11:49] <dael> tantek: That was the miority. It was new authors. Ever single new author.
# [11:49] <dael> astearns: They're confused by how % of top and bottom resolve into width and height.
# [11:49] <dael> TabAtkins: There are a lot of parts of CSS that are confusing.
# [11:49] <dael> Rossen: Which is what where' trying to repair.
# [11:50] <astearns> s/and height//
# [11:50] <dael> dbaron: ONe point is block layout has two directions that are fundimentally different whereas flex in more neutral.
# [11:50] <dael> fantasai: So's abspos.
# [11:50] <dael> dbaron: Not as much.
# [11:50] * Joins: ChrisL (clilley@public.cloak)
# [11:50] <dael> dbaron: It does a bunch of stuff that is biased to top left or right.
# [11:50] <dael> fantasai: We do lots of stuff that's biased.
# [11:50] <dael> fantasai: We have 3 options.
# [11:51] <dael> fantasai: 1 is keep it all consistant. 2 is make the block inline calc as width. 3 is [missed]
# [11:51] <iank> http://pastebin.com/5MZyq1gc
# [11:52] <dael> Florian: I was convinced by tantek last time and TabAtkins is strong. Neither sounds great to me.
# [11:52] <dael> tantek: I'm talking about B. The method I'm trying to take is from the new author perspective. I like less the implementor way. We're solving for new authors.
# [11:53] <dael> ojan: I think the new authors are doing the aspect ratio hack. They search for how to do it and copy/paste.
# [11:53] <dael> tantek: I disagree on gregwhitworth data and every time I teach CSS this confuses people.
# [11:53] <dael> ojan: It's not 100% the aspect ratio, but the vast majority is. I'm not saying 100%. There are some sites that don't.
# [11:54] <dael> fantasai: Helping new authors, having 2 diff behaviors depending on layout mode isn't helping authors either. It would be great if we could switch everything...
# [11:54] <dael> tantek: I disagree.
# [11:54] <dael> tantek: New authors don't load the whole world into your head.
# [11:54] <dael> TabAtkins: You have to teach a confusing behavior
# [11:54] <dael> TabAtkins: Are you trying to claim we can't teach block anymore.
# [11:55] <dael> TabAtkins: Flexbox isn't replacing block.
# [11:55] <dael> zcorpan: You have to learn that behavior.
# [11:55] <dael> TabAtkins: They're not legacy display.
# [11:55] <dael> tantek: For % margins they are.
# [11:55] <dael> TabAtkins: I don't see why that's a flexbox thing
# [11:55] * dauwhe We should break the web every seven years.
# [11:55] <dael> tantek: They're more useful.
# [11:55] <Florian> q+
# [11:56] <dael> tantek: This author focus is important. You teach them the subset of stuff that is useful, not the crap before. We don't teach the spacers, we teach them the subset that works and is consistant and they can model. We want to cut stuff out over time if it's confusing, in terms of what we teach.
# [11:56] <dael> ojan: I would cut % margin and padding from the model, thought I agree with you we should work toward the future where we should cut the crap.
# [11:57] <dael> tantek: It does because you either don't teach it or teach the piece that just works. Or you end up with the proposal to drop
# [11:57] <dael> fantasai: I think you end up teaching them how it works on grid and flex and then they try and do it elsewhere.
# [11:57] <dael> tantek: And then they realize that's old CSS is broken.
# [11:57] <dael> fantasai: It's not broken, it's used.
# [11:58] * Joins: Zakim (zakim@public.cloak)
# [11:59] <dael> dbaron: I guess I feel like we're overdesigning here. All this stuff ends up getting used in ways...we've gotten to the point where the major use case for % margins is a hack. Why are we adding more features that are designed in a WG meeting. Maybe we should try and make progress on houdini instead. I don't think grid is something we, moz, should work on because I don't think flexbox went well.
# [11:59] * astearns next topic: how box-decoration-break interacts with percentage margins in grid containers fragmented in named flows
# [11:59] <dael> dbaron: I'd rather put in the resources to houdini and I think that we'll wait until it's stable and do it then for webcompat.
# [11:59] <dael> fantasai: You're off topic.
# [11:59] <dael> dbaron: I think this comes up because of grid, though. We have features, but they don't use them for the things we've intended.
# [12:00] <dael> iank: Is there more strategy beyond this...for ex there's vertical align. There's vert-align where people go to that, but it doesn't do what they think. What things will we change the behavior of so that it makes more sense.
# [12:00] <astearns> s/iank/esprehn/
# [12:01] <dael> tantek: I think for this there's just a strong reaction to " what, this doesn't make sense" meanwhile vertical align doesn't make sense to anyone.
# [12:01] <dael> fantasai: People have expectations of what top-center should do, but we can't fix it since it's been in the langauge so long.
# [12:01] * Quits: BogdanBrinza (~bbrinza@public.cloak) ("")
# [12:02] <dael> tantek: If you ID other parts of the platform where you can alter in some way or a new prop like box sizing to better match...that's good. If 90% think that it should work a different way, we've screwed up.
# [12:02] <dael> ojan: This is the not. problem where you can't center on the web.
# [12:02] <dael> tantek: I think vertical align in general is confusing.
# [12:02] <dael> esprehn: As we release do we plan to keep doing this?
# [12:03] <dael> TabAtkins: My answer is no.
# [12:03] <dael> esprehn: Do we switch the box model...what fixups do we change to meet author expectations?
# [12:03] <dael> tantek: For a new author it's not a switch.
# [12:03] <dael> TabAtkins: People still use block.
# [12:04] <dauwhe> q?
# [12:04] * Zakim sees no one on the speaker queue
# [12:04] <dael> SimonSapin: You talk about legacy things that are wrong like blocks as things people don't use anymore?
# [12:04] <dael> tantek: I think that's right, I'd tell authors not to use it because it's broken.
# [12:04] <TabAtkins> We're not adding `div { display: flex; }` to our stylesheets.
# [12:05] <SimonSapin> s/not to use it/not to use percentage margins and padding/
# [12:05] <SimonSapin> TabAtkins, UA stylesheet?
# [12:05] <dael> Florian: So, based on your arguement that we shouldn't teach authors the broken pieces...I don't think the situation where grid items are and aren't abspos behave differently, I don't think it makes anyone happy.
# [12:05] <TabAtkins> SimonSapin: trololol
# [12:06] <dael> tantek: My initial reaction to making abspos based on context is kind of odd. Rossen arguement is as soon as you start nesting abspos or putting them in a grid layout you're going to be using things that are gird specific.
# [12:06] <dael> TabAtkins: Not nec. You'll often treat it as an ordinary item.
# [12:06] * ChrisL suggests we give authors all the options, and make the initial value ua-specific
# [12:06] <dael> fantasai: You might have a new banner. You want to put it on any top of the box, doesn't matter the type.
# [12:06] <dael> fantasai: We have two authors in the room.
# [12:07] <dael> ??: I think, I've done a lot of work with grid. When we talk about new authors, they're sitting down and learning bootstrap and working out how to do things in CSS from that framework. People will have a legacy understanding of CSS because those frameworks use it.
# [12:07] <astearns> s/??/rachelandrew/
# [12:08] * Ms2ger fantasai: r? https://github.com/w3c/csswg-test/pull/831
# [12:08] <dael> rachelandrew: Being able to use a fragement anywhere is important. You don't want that position to change through any context. You don't want that to be different. It's going to take people a very long time to change how they have been thinking for years.
# [12:08] <dael> rachelandrew: People's understanding is very much based around those frameowkrs.
# [12:08] <tantek> q+ re: frameworks
# [12:08] * Zakim sees tantek on the speaker queue
# [12:09] <dael> fantasai: leaverou?
# [12:09] <dael> leaverou: I just got here.
# [12:09] * TabAtkins Proposal to rename us to the %MWG
# [12:09] * ChrisL resolved: discuss again at meeting n+1
# [12:09] <dael> fantasai: So we have % top and bottom margins that are measured against the heights. A few new arguements have been brought up. The prop was to have flex and grid interp differently. There was an arguement for consistancy across CSS or the arguement about making flex and grid easy
# [12:10] * MaRakow we can discuss it again when the meeting is 75% done
# [12:10] <dael> fantasai: The other thing was what about abspos items. abspos items follow the same layout as blocks. The question is what if youre abspos item containing block is a grid container. Is it like a grid item or as an abspos everywhere else.
# [12:10] * ChrisL the number of layout models is *too damn high*
# [12:11] * Joins: BogdanBrinza (~bbrinza@public.cloak)
# [12:13] * TabAtkins http://cdn.meme.am/instances2/500x/1543923.jpg
# [12:13] <dael> fantasai: Before we could say there's one consistancy break. Abspos creates a bridge where abspos parented to a block with behave like a blokc. Should they be different then abspos parented to a grid? Is abspos internally consistant or consistant to the containing block.
# [12:13] * Joins: vollick (~vollick@public.cloak)
# [12:13] <dael> fantasai: Abspos have special properties when they are parented to a grid container. So some of the positioning will work the same as a grid item, but % margin and padding will behave differently. Somewhere there will have to be a break if we want flex and grid to be consistant.
# [12:13] * dauwhe remind me not to ask for % value for widows/orphans
# [12:13] <dael> fantasai: So there could be consistancy across all. Or there's a break in how abspos behave, or inflow and out of flow grid items.
# [12:13] <dael> fantasai: That's what's here on this chart.
# [12:15] * tantek sees leaverou look over with a confused look
# [12:15] <tantek> q?
# [12:15] * Zakim sees tantek on the speaker queue
# [12:15] <dael> leaverou: As long as grid acts differently it will be inconcstant no matter what we pick. I do see why there should be an exception there.
# [12:15] <dael> tantek: I think everything dbaron said and rachelandrew said were signored.
# [12:15] * Quits: ed (~ed@public.cloak) (Ping timeout: 180 seconds)
# [12:15] * dauwhe we prefer "classic" CSS.
# [12:15] <dael> tantek: The point about frameworks is very important. New authors more and more have been switching toward using frameworks. I'm going to include SaaS as a frameowkr. I thinkw e should ask why is that happening. I would hypothosize that part of why is that CSS has gotten too big and complex. Also too many features that are handled in bizaro ways.
# [12:15] * Quits: hyojin (~hyojin@public.cloak) (Ping timeout: 180 seconds)
# [12:15] * Quits: fabioth (~fabioth@public.cloak) (Ping timeout: 180 seconds)
# [12:15] * Joins: fabioth_ (~fabioth@public.cloak)
# [12:16] * Quits: Bert (bbos@public.cloak) (Client closed connection)
# [12:16] * Joins: Bert (bbos@public.cloak)
# [12:16] <dbaron> s/SaaS/Sass/
# [12:16] <dael> tantek: Authors look at their options for the bizarre CSS rules or the framework that just has these simple features, they choice is obvious is that they go to the frameworks. Everyone needs to ask is do they care about making something authors can do directly or do you want to make more frameowkrs?
# [12:16] <dael> tantek: I think that the second option is for houdini. I think we should make CSS able to do it's own thing.
# [12:16] * Ms2ger Stylesheets as a Service?
# [12:17] <dael> leaverou: I think I agree with tantek. We need to make the language easy to use.
# [12:17] <dael> tantek: I am trying to fix that.
# [12:17] <dael> fantasai: You argue for consistancy, but you're arguing against consistancy.
# [12:17] <leaverou> s/leaverou: I think I agree/leaverou: I completely agree/
# [12:17] <dael> tantek: You keep reframing this as something different from what I'm proposed.
# [12:17] * Joins: hyojin (~hyojin@public.cloak)
# [12:17] <dael> andrey-bloomberg: tantek which option would a framewokr use?
# [12:18] <dael> tantek: We don't have a framework author here. They have to build on top of whatever randomness we build and figure out what is the common use case.
# [12:18] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [12:18] * Joins: dbaron (~dbaron@public.cloak)
# [12:19] <dael> fantasai: Let's consider that someone is a framework author and they're building a grid layout framework. They're basing it off flexbox, but they have a lot of fallback behaviors. Let's say we release the grid spec and they author says they can use grid where it's supported, flexbox where it's not, and float layout as the last choice.
# [12:19] <Florian> s/andrey-bloomberg/zcorpan/
# [12:19] <dael> fantasai: If they author puts a % margin on their items, it will be one way on flex and grid, but differenly on floats.
# [12:19] <dael> tantek: I think your ex has too many assumtions.
# [12:20] * Joins: ed (~ed@public.cloak)
# [12:20] <dael> SteveZ: A framework is to hide the complexity. I don't think from a framework author pov we can answer this. They'll figure out how to calculate it for %.
# [12:20] <dael> ojan: Except they can't because the author will do that.
# [12:20] <dael> tantek: The author will do it, it'll break, and they'll look in the framework community for an answer.
# [12:21] <dael> fantasai: How would you like this strawpoll framed?
# [12:21] <dael> tantek: They're in the minutes.
# [12:21] <dael> tantek: Rossen proposed how every person was advocating it.
# [12:22] <dael> Rossen: Option 1: Keep everything consistant in terms of % resolution- that was aligned with your option a
# [12:23] <dael> Rossen: Option 2: Mixed where abspos items are an exception inside grid and flex in terms of % margin
# [12:23] <dael> Rossen: Option 3: Everything we did in grid and flex, inc abspos is following the new model
# [12:23] <tantek> Option 1: Keep vertical % margins/padding always dependent on horizontal metrics
# [12:24] <dael> Rossen: From the PoV of the layout type, not abspose.
# [12:24] <tantek> "consistent" is an oversimplification in option 1
# [12:24] <dael> fantasai: tantek are you happy?
# [12:24] <dael> tantek: I think it's better to make clear that option 1 vertical % margins/padding always dependent on horizontal metrics
# [12:25] <dael> tantek: I think that's important to call out.
# [12:26] <astearns> option 1: keep old mistakes everywhere, option 2: keep old mistakes in some places, option 3: fix old mistakes everywhere we can
# [12:27] * leaverou thinks one weird rule is better than 1 weird rule + a bunch of exceptions, so leaning towards option 1
# [12:27] * Joins: ChrisLilley (clilley@public.cloak)
# [12:28] * Florian we are about to take a straw poll about which straw poll we should take?
# [12:28] <tantek> leaverou: it's about do we want to try to keep making CSS more usable over time, or do we want to forever shackle ourselves with bad decisions of the past?
# [12:28] * leaverou Florian yo dawg, I heard you like straw polls… :P
# [12:28] <dael> Rossen: One more point for impl.: as soon as you start adding logical properties you will find yourself wishing you had choosen the symmetry.
# [12:29] <dael> Rossen: Espeically for vertical mode in horizontal.
# [12:29] <leaverou> tantek: but it's not about making CSS more usable, it's making it more internally inconsistent
# [12:29] <shane> https://usercontent.irccloud-cdn.com/file/xkTN5ySI/IMG_20150825_122812.jpg
# [12:29] <dael> fantasai: To be clear this chart is the logical width and height.
# [12:29] <leaverou> tantek: given that we are not going to change the past behavior
# [12:29] <leaverou> exceptions are hard to teach
# [12:29] <TabAtkins> The idea that making the language inconsistent in tiny ways in successive waves, is "making the language more usable", is incorrect.
# [12:29] <tantek> leaverou: I disagree, it's about making the set of modern CSS more usable
# [12:29] <leaverou> TabAtkins++
# [12:29] <dael> Florian: So what strawpoll do we take?
# [12:29] <tantek> which is a subset of making the platform as a whole more usable over time
# [12:29] <TabAtkins> We should only be inconsistent with legacy when the new behavior is actually strongly good.
# [12:29] <dael> fantasai: We do 1 2 or 3.
# [12:29] <TabAtkins> Like switching to using Promises over callbacks.
# [12:30] <tantek> which requires us to drop / obsolete / or even ignore bad things in the past - just don't teach them to authors
# [12:30] <shane> https://usercontent.irccloud-cdn.com/file/1kuGPaOM/IMG_20150825_122940.jpg
# [12:30] <dael> Bert: I prefer #1
# [12:30] <Ms2ger> Except that authors need to be able to edit existing code
# [12:30] <dael> esprehn: #1
# [12:30] <dael> Rossen: 3
# [12:30] <dael> tantek: 3
# [12:30] <dael> astearns: 3
# [12:30] <dael> fantasai: 1
# [12:31] <leaverou> tantek: it's not universally a bad thing. Having it depend on horizontal metrics is useful sometimes for e.g. equal spacing between items (horizontally and vertically)
# [12:31] <dael> jet: 1
# [12:31] <dael> andrey-bloomberg: abs
# [12:31] <dael> SimonSapin: abs
# [12:31] <dael> TabAtkins: 1
# [12:31] <dael> Florian: 1
# [12:31] <leaverou> tantek: it's confusing in many cases, sure, but exceptions are even more
# [12:31] <dael> leaverou: 1
# [12:31] <dael> ChrisL: 1
# [12:31] <dael> zcorpan: 1
# [12:31] <tantek> leaverou: we avoid exceptions by dropping the past broken things
# [12:31] <dael> hober: abs.
# [12:31] <dael> ??: abs
# [12:31] <dael> dauwhe: 1
# [12:31] <hober> s/??/weinig/
# [12:31] <dael> SteveZ: 3
# [12:31] <dael> plinss: abs
# [12:31] <leaverou> tantek: we are never going to drop the past broken thing here Tantek, it would break too many things. Unless you think we're gonna drop block altogether
# [12:32] <dael> hyojin: 3
# [12:32] <tantek> leaverou: we always drop past broken things, like using tables+gifs for layout
# [12:32] <dael> ojan: 1
# [12:32] <tantek> by "drop" I mean what we teach authors
# [12:32] <tantek> modern web practices
# [12:32] <leaverou> tantek: in that case it's dropping a methodology, not the tech. The tech is still there to do layout by tables
# [12:33] <tantek> leaverou: that's the author-centric point of view, that we drop things effectively by dropping them from how we teach
# [12:33] <leaverou> tantek: so we're gonna stop teaching block?
# [12:33] <tantek> that's basically what frameworks do, they drop all of the platform
# [12:33] <tantek> no, we stop teaching % margins/padding on block
# [12:33] <dael> johanneswilm: 1, greg: 3, matt: 3, brian: abs, iank: 1, shans: 1, rachelandrew: 1 dbaron: 2 or 3
# [12:34] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [12:34] <leaverou> tantek: people will try them anyway. IF anything, by changing something from grid to block and forgetting to change the margin
# [12:34] <dael> plinss: Is there anyone voting for 3 that obj to 1
# [12:34] <leaverou> tantek: but mostly because "they work here, why wouldn't they work there?"
# [12:34] <dael> tantek, Rossen yes
# [12:34] <dael> plinss: And the reverse?
# [12:34] <dael> TabAtkins: Yes.
# [12:34] <dael> tantek: We did have resolution consensus before.
# [12:34] <dael> TabAtkins: Then we'll obj to the current situation.
# [12:35] <dael> fantasai: There's sig. new information.
# [12:35] * leaverou thinks we need some kind of web app for straw polls. This is very inefficient.
# [12:35] <dael> ojan: The resolution from last time was option 2.
# [12:35] <dael> dbaron: Did the discussion last time distinguish between 2 and 3?
# [12:35] <dael> tantek: No.
# [12:35] * astearns perhaps webex has a polling thingy, so we don't have to rely on the web?
# [12:35] <tantek> The resolution from last time was effectively (2 or 3)
# [12:36] <dael> plinss: I'm open to suggestions on how to move forward.
# [12:36] <tantek> what we found out today is that 3 is a clarification of the past resolution
# [12:36] * leaverou thinks the abspos issue makes it even more weird to have an exception there, so it makes sense that the consensus has changed
# [12:36] <dael> TabAtkins: If I understand, MS main objection is dealing witht he legacy content. I'm looking for a solution that keeps your content working and lets this move forward. If we knock that out, does it remove enough obj that you're okay with it?
# [12:36] <dael> Rossen: No.
# [12:36] <dael> TabAtkins: We're at an impass.
# [12:36] <tantek> leaverou - I'd like to understand how you'd propose making CSS *better* for authors, not just consistent with all legacy
# [12:37] <dael> Rossen: The abspos information doesn't bring anything new because we're already doing #3.
# [12:37] <dael> Rossen: But it's a thing we needed to clarify.
# [12:37] * astearns we're at an "impasse" because we're in Paris
# [12:37] <dael> dbaron: I think one reality is that in a lack of consensus we go with impl market share. Does safari match chrome?
# [12:37] <dael> TabAtkins: Yeah.
# [12:37] <leaverou> tantek: I don't think you realize how hard exceptions make CSS to understand and teach.
# [12:38] <dael> gregwhitworth: But they said they'd switch.
# [12:38] <dael> Rossen: He said he would switch on the telecon.
# [12:38] <dael> TabAtkins: It's easier to not switch.
# [12:38] <dael> TabAtkins: We can make it officially undefined.
# [12:38] <tantek> leaverou: unfortunately I do realize how painful that is and hence want to avoid teaching authors the bad ways of old
# [12:38] <hober> s/He said/Hyatt said/
# [12:38] <dael> fantasai: Either way we're closing this with a formal objection.
# [12:39] <dael> Florian: Is leaving it undefined and let it converge work?
# [12:39] <leaverou> tantek: Having one consistent but suboptimal rule is better than having that in most cases, but not in grid, but wait, it's different if you have abspos etc etc
# [12:39] <dael> tantek: I'd rather have that then an arbitrary top-down decision
# [12:39] <dael> shane: Is it possible to remove % margins from flexbox?
# [12:39] <dael> TabAtkins: Taking out doesn't mean it's not unspec.
# [12:40] <dael> shane: It means there's no expectation on when it should be impl.
# [12:40] <ChrisLilley> no but going to loo so will search
# [12:40] <dael> TabAtkins: We'll have to say % margins do not work in this context.
# [12:40] <dael> tantek: Or ignored.
# [12:40] <dael> fantasai: You can't ignore because you have to parse in.
# [12:40] <dael> plinss: Earlier we rejected a user switch
# [12:40] <dael> fantasai: I disagree with switch.
# [12:41] <dael> hober: I think it's a terrible idea.
# [12:41] * ChrisLilley okay so does anyone know where the water fountain is, since that was meant for a private channel obvs.
# [12:41] <dael> Florian: Can we consider the option of leaving it undefined? Let the market sort it out.
# [12:41] <dael> SteveZ: But then you don't have interop
# [12:41] <dael> hober: You eventually do.
# [12:41] * astearns there's water in the coolers outside the glass doors
# [12:42] <dael> gregwhitworth: With the rest of the CSS2.1 stuff we're dealing with I'd rather not.
# [12:42] <tantek> block-percentage ?
# [12:42] <dael> gregwhitworth: We're stuck, I'd rather we circle back and talk again later.
# [12:42] <tantek> leaverou: % margins and padding are *already* inconsistent with % height
# [12:42] <tantek> this is trying to fix that
# [12:42] <dael> gregwhitworth: I think we should move on to the next item.
# [12:42] <leaverou> tantek: yes, but you will have this inconsistency *anyway*!
# [12:42] <dael> plinss: I agree. We're not getting anywhere.
# [12:43] * dauwhe New process: have a straw poll. If no consensus, drink one beer. Repeat until consensus reached.
# [12:43] <dael> TabAtkins: So the spec if currently listing th ebehavior that we're not happy with. We can't push to CR as it is with and active obj from a major impl. I will just undefine it if we leave it as it is.
# [12:43] * leaverou dauwhe I propose shots. We will reach consensus faster.
# [12:43] <dael> gregwhitworth: I was suggesting we go sit around a table and talk about this.
# [12:43] <dael> TabAtkins: Assuming nothing comes out of a conversation we undefine it.
# [12:43] <dael> plinss: So a timeline?
# [12:43] <dael> gregwhitworth: I was thinking tomorrow
# [12:44] <dael> TabAtkins: A day or two is fine. I don't want to hold up the spec.
# [12:44] <dael> plinss: Let's do that.
# [12:44] <dael> plinss: Other flexbox issues?
# [12:44] <dael> fantasai: No, we've got some editing to do.
# [12:45] <dael> Topic: Old tests that are invalid
# [12:45] * Bert ... 'padding: 20% height' vs 'padding: 20%' == 'padding: 20% width'
# [12:46] <dael> SimonSapin: We've seen that happen in two cases. One is that for hex colors we have tests in 3 or 4 or 8 are not supported, but in color 4 they are supported so the old tests fail. What should we do about such tests?
# [12:46] <dael> SimonSapin: Should tests be updated if a later version of the spec changes behavior
# [12:46] * heycam is now known as heycam|away
# [12:46] <dael> ChrisLilley: We usually remove the text or change to point to where ever the new spec is.
# [12:46] <astearns> s/text/test/
# [12:46] <dael> SimonSapin: If that's okay for everyone, we should change the tests.
# [12:47] <dael> fantasai: Fo that test you have two permissable renderings. If you're a 2.1 agent you treat it one was, if you're level 4 you render another way.
# [12:47] * tantek bert box-percentage: symmetric | width | 2.1
# [12:47] <dael> ChrisLilley: I don't think CSS2.1 UA is a concept.
# [12:48] <dael> fantasai: I think there's impl that aren't caught up and they shouldn't be flagged as failing for that. If you mark something as invalid it should last. We tested for this because there was a quirky method of doing hex and we wanted to test for that.
# [12:48] <dael> fantasai: So this is an importat test to make sure people that don't support colors 4 parse correctly.
# [12:48] <dael> fantasai: For ref tests we can have two references and you have to match either one.
# [12:49] <dael> SimonSapin: Okay.
# [12:49] <dael> fantasai: For a given UA they'll only have one reference, but for the test suite at w3c we should have two references.
# [12:49] <dael> dbaron: It would be useful to have a resolution to fix old tests that fail due to new specs.
# [12:50] <dael> TabAtkins: Is anyone actioned to update?
# [12:50] <dbaron> ... so that they pass either way
# [12:50] <dael> plinss: We havea pull request
# [12:50] <dael> gregwhitworth: How are the tests attached?
# [12:50] <ChrisLilley> s/remove the text/remove the test/
# [12:50] <dael> fantasai: There's metadata that tags to a specific section in the spec. You'll have a tag to however many specs you're testing.
# [12:50] <dael> SimonSapin: So each test is in a seperate test suite.
# [12:51] <SimonSapin> … per spec
# [12:51] <ChrisLilley> @ gregwhitworth https://wiki.csswg.org/test/format#specification-links
# [12:51] <dael> RESOLVED: We want to update old tests but leaving the old pass conditions in tact
# [12:51] <gregwhitworth> ChrisLilley: Thanks
# [12:52] <dael> SimonSapin: And the other case is that we sited the way to go...and declaration including style rules should only accept @rule like @page does. Even if there is no such @rule defined yet because it makes a difference in the error recording.
# [12:52] <dael> SimonSapin: There's a CSS2.1 test that fails there.
# [12:52] * Quits: tkonno (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [12:52] <dael> dbaron: That's a case where we should fix CSS level 2.
# [12:53] <dael> fantasai: That should be backported.
# [12:53] <dael> SimonSapin: I sent an e-mail to the list asking to include an erratta.
# [12:53] <dael> Bert: I missed that, but there is something strange about that. It allows @keywords inside declarations which is disallowed by CSS2.
# [12:53] <dael> TabAtkins: It's fine by syntax.
# [12:53] <dael> Bert: We're breaking a promise that's explicite in a spec
# [12:54] <dael> SimonSapin: It's a declaration that contains @rules
# [12:54] <dael> Florian: It is a breaking change.
# [12:54] <dael> fantasai: It won't break any impl.
# [12:54] <dael> SimonSapin: I made that change in FF and the test doesn't pass anymore
# [12:54] <dael> TabAtkins: Like dbaron said we should fix 2.1 to no longer say the opposite and then fix the test suite.
# [12:55] <dael> SimonSapin: I wrote an eratta and there was a resolution.
# [12:55] <Florian> s/I made that change in FF and the test doesn't pass anymore/I made the change in FF a coule years ago, and the only bug report is that the test doesn't pass anymore/
# [12:55] <dael> plinss: So we just need that reincorporated.
# [12:55] <dael> Bert: I have the text. I'll put in the errata.
# [12:55] <dael> plinss: That takes us to lunch.
# [12:55] <SimonSapin> Change proposed in https://lists.w3.org/Archives/Public/www-style/2013Apr/0506.html , resolved on in https://lists.w3.org/Archives/Public/www-style/2013May/0783.html
# [12:56] <dael> <lunch - return at 2pm>
# [12:56] <dbaron> <br type="lunch" duration="calc(64*60s)">
# [12:57] * Quits: weinig (~weinig@public.cloak) (weinig)
# [12:57] <ChrisLilley> s/no but going to loo so will search//
# [12:59] * Quits: rachelandrew (~59cacb34@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [13:00] * Quits: hyojin (~hyojin@public.cloak) (Ping timeout: 180 seconds)
# [13:02] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [13:02] * Quits: skk_ (~skk@public.cloak) (Ping timeout: 180 seconds)
# [13:08] * Quits: jh_hong (~jh_hong@public.cloak) (Ping timeout: 180 seconds)
# [13:09] * heycam|away is now known as heycam
# [13:10] * Quits: andrey-bloomberg (~andrey-bloomberg@public.cloak) (Ping timeout: 180 seconds)
# [13:10] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [13:15] * Joins: skk (~skk@public.cloak)
# [13:20] * Quits: ChrisLilley (clilley@public.cloak) (Ping timeout: 180 seconds)
# [13:23] * heycam is now known as heycam|away
# [13:29] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [13:30] * Joins: jdaggett (~jdaggett@public.cloak)
# [13:34] * Joins: johanneswilm (~johannes@public.cloak)
# [13:38] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [13:43] <jdaggett> lunch time?
# [13:44] <skk> yes
# [13:44] <skk> till 21:00 JST.
# [13:45] <jdaggett> thanks!
# [13:46] <skk> :)
# [13:52] <jdaggett> skk: そのNHKの記事が面白い！それと写真ありがとう！
# [13:55] * Joins: Ms2ger` (~Ms2ger@public.cloak)
# [13:55] * Quits: Ms2ger (~Ms2ger@public.cloak) ("Leaving")
# [13:56] * Quits: tantek (~tantek@public.cloak) (tantek)
# [13:58] * heycam|away is now known as heycam
# [13:59] * Joins: tkonno (~chatzilla@public.cloak)
# [14:15] * ed_work_ is now known as ed_paris
# [14:17] * Joins: ChrisLilley (clilley@public.cloak)
# [14:18] * Joins: weinig (~weinig@public.cloak)
# [14:19] <dael> plinss: Let's get started
# [14:20] <dael> Topic: CSS UI
# [14:20] * Joins: MaRakow (~MaRakow@public.cloak)
# [14:21] * Joins: tantek (~tantek@public.cloak)
# [14:22] * Joins: hyojin (~hyojin@public.cloak)
# [14:22] <dael> Florian: There's a few subtopics
# [14:23] <dael> Florian: Tab sent a mail with some feedback that we can address as a group
# [14:23] <hober> https://lists.w3.org/Archives/Public/www-style/2015Aug/0238.html
# [14:23] * Joins: rachelandrew (~59cacb34@public.cloak)
# [14:24] * Joins: jihye (~jihye@public.cloak)
# [14:24] <dael> Florian: There is a note...We added on a request from the WG a note on user-select:none about how the combo of that and content:editable was supposed to behave b/c there are use cases where this is reasonable and we wanted to capture this req.
# [14:24] <dael> Florian: Given the way the editing TF is progressing I'm thinking we should drop it b/c how it will be addressed.
# [14:24] <tantek> s/content:editable/contenteditable=true
# [14:24] * Quits: rachelandrew (~59cacb34@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [14:25] <dael> Florian: There's no near-term plan to sync what every browser does for contenteditable=true. However, what is happening is there will be a number of events dispashed that will let a JS react to anything that is happening and cancel if the author wants something else to happen.
# [14:25] * Joins: rachelandrew (~59cacb34@public.cloak)
# [14:25] <dael> Florian: If they are editing the kind of JS we had in mind we should do it. If they're doing something different, the semantics in the note would not even apply.
# [14:26] <dael> Florian: If it belongs somewhere, it's there, but authors will be able to do what they want to so we should drop the note.
# [14:26] <dael> Florian: I agree that it should be possible, but we don't tend to put that in our specs
# [14:26] <dael> tantek: It's an exception, not a rule
# [14:26] <dael> Florian: Given where conteneditable is going, the note isn't needed.
# [14:27] <dael> tantek: However we spec user-select, it allows the editing folks to use it how they need to.
# [14:27] <dael> Florian: But the people writing the editing spec will not make it behave any way. The JS authors will be able to control it. If they're writing a code editor, they won't care about this use case. It's not an evil note, I think it's not applicaple.
# [14:28] <dael> tantek: Then leave it out.
# [14:28] <dael> johanneswilm: As someone in the TF, the problem with the note is that it's the only one aimed at JS editors, not browser vendors. It would be new for JS.
# [14:29] <dael> johanneswilm: No matter where the note is, if you want to target the old contenteditable then it makes sense. If you want to target the new stuff, you're talking to the JS editors who build this stuff. That's fine, but it should be somewhere that pulls a bunch of things about how to pull a JS editor. The only reason JS editors are reading this is to find bugs.
# [14:30] <dael> Florian: Proposal is to drop the note.
# [14:30] <dael> TabAtkins: Obj?
# [14:30] <dael> RESOLVED: Remove the note regarding user-select and contenteditable
# [14:30] <dael> Florian: We also desc renaming user-select: element to user-select:contain. We had general agreement, but I think we were pending agreement from MS.
# [14:31] <johanneswilm> s/pull/build
# [14:31] <dael> Florian: You used element under a flag, we were waiting for you to let up know.
# [14:31] <dael> Florian: On a sep topic, we also mentioned that user-select: text is terrible because it selects more than text, but everyone supported that for a while. TabAtkins suggested a new name.
# [14:32] <dael> TabAtkins: We can drop it for now.
# [14:32] <dael> RESOLVED: user-select: text stays named as-is
# [14:32] <dael> Florian: Another comment was they had reviewed appearance and it was fine except they didn't want the bottom value.
# [14:33] <dael> Florian: The current version has none, auto, and a long series of many values that are used to make form controls look the way they should. There's been no sucess on sync browsers on that. The new appearance has none and auto and just has magic for the form controls.
# [14:34] <dael> Florian: It's either none and you can't style or auto and you get the magic. There's a handful of values that are useful, for ex. button so you can say this link looks like a button. I put that in there because I don't think it's a crazy usecase.
# [14:34] <dael> Florian: MS also recently created support for -webkit's appearance. I took that support as evidence that the web needs it. Google doesn't like it.
# [14:34] <dael> tantek: Does Google support the back compat?
# [14:35] <dael> TabAtkins: And we're investigating the usage.
# [14:35] <dael> ojan: We'd like to drop as much as we can and whatever is left for backcompat can go in the spec.
# [14:35] <dael> gregwhitworth: I have no interest in standardizing for backcompat
# [14:35] <dael> esprehn: It implies more than BG image. On mac there's padding and windows it doesn't. There's a bunch of heuristic behavior that's scrange to spec.
# [14:36] <dael> Florian: If we spec appearance button, this lets an author opt into appearing like a native button, whatever that means.
# [14:36] <dael> esprehn: For layout, is there a give me the padding that may be on every platform. THat seems author hostile.
# [14:36] <dael> Florian: Except when the author asks for it.
# [14:36] <dael> gregwhitworth: We don't want to cement that.
# [14:37] <dael> tantek: I'd rather drop and spec a backcompat.
# [14:37] <dael> ??: WE often when going from prefix to non-prefix is to fix that.
# [14:37] <dael> dbaron: For backcompat we'll need to deal with a lot of prefix prop
# [14:37] <dbaron> s/deal with/spec/
# [14:38] <dael> fantasai: If we have a prefix we need to have a path forward for those that want to move the path forward.
# [14:38] <dael> ??: There's a clear path forward.
# [14:38] <tantek> s/??/greg
# [14:38] <dael> Florian: I'm not married to the button. If you want it off I'm okay removing it. If Chrome is investigating what's nec. we might as well wait.
# [14:38] <zcorpan> https://github.com/search?l=css&q="appearance+button"&type=Code&;utf8=✓ github search for "appearance button"
# [14:38] <dael> fantasai: The reason not to use it is it doesn't behave like a form.
# [14:38] <dael> TabAtkins: If you wrap it in a form with the method=git
# [14:39] <dael> plinss: I would rather not put in extra values until we've proven we must have them
# [14:39] <dael> tantek: Agreed.
# [14:39] <dael> Florian: I'm okay with that.
# [14:39] <dael> gregwhitworth: If you test our browser you'll find more, but hopefully that's not a perm. thing.
# [14:39] <TabAtkins> s/git/GET/
# [14:40] <dael> Florian: so do we resolve to drop all the values except none or auto
# [14:40] <dael> gregwhitworth: I'm looking for bugs, but if we're doing them they're in as stop gaps. There is a button tag. Because it exists doesn't mean it has to be standardized.
# [14:40] * Quits: weinig (~weinig@public.cloak) (weinig)
# [14:40] <dael> tantek: So let's drop everything except all and none.
# [14:40] <dael> plinss: Obj?
# [14:41] <dael> RESOLVED: Drop all values except for auto and non
# [14:41] <dael> s/non/none
# [14:42] <dael> Florian: A while back I put a blink time prop which controls how the caret blinks. I was told this was a bad idea and we should expore this using CSS animations. Having explored that, the conclusion was that's overkill. We might just need caret-animation auto and none. TabAtkins suggested fade. Just a limited list.
# [14:42] <dael> ChrisLilley: I don't think theyre should be a caret specific property.
# [14:43] <dael> Florian: If we have the prop as spec now, caret animation is auto by default. If you want to do something specific, such as you don't want it to blink. If caret color is a color which exists you can't animation.
# [14:43] <dael> Florian: There's bunch of text editors that let you control caret.
# [14:43] <dael> ???: Does anyone let you control the caret? On windows?
# [14:43] <dael> gregwhitworth: We only have 3 values.
# [14:44] <TabAtkins> s/???/sam/
# [14:44] <dael> fantasai: If you have no blinking and the caret is animatable you can do anything you want.
# [14:44] * Joins: weinig (~weinig@public.cloak)
# [14:44] <fantasai> s/caret/caret-color/
# [14:44] <ChrisLilley> s/I don't think theyre should be a caret specific property./I don't like the animation model for caret being different to the rest of animation/
# [14:44] <dael> Florian: Right now the caret-color can cange to match the text. I don't think we should work to make something stop working that already does.
# [14:45] <dael> sam: What's the use case for not blinking?
# [14:45] <dael> Florian: a11y
# [14:45] <dael> sam: Then that's the browser that should control. It just seems like a...
# [14:45] <dael> Florian: You said OSX doesn't have controls at the API? There's terminal
# [14:45] <dael> sam: terminal is non-standard. It's completely custom.
# [14:46] <dael> tantek: The only use case is a11y?
# [14:46] <dael> Florian: That's the main one. There's minor use cases for blinking in and fading out. Like when you're doing retro things.
# [14:46] <dael> tantek: I think in those cases you rebuild your own caret.
# [14:46] <dael> hober: I think that the a11y is better as a system setting.
# [14:47] <dael> Florian: I think the homepages of 2 WG members have a blocky caret. People are doing it and so it's out there.
# [14:47] <dael> TabAtkins: A number of text editors offer minor control over this.
# [14:48] <dael> Florian: There's a bunch of web text editors that would want to behave like regular text editors. I think it would be wrong...it's open ended. Having a limited set to choose from, though, is good.
# [14:48] * leaverou case in point re: WG member pages with styled carets http://www.xanthir.com/
# [14:48] <dael> tantek: I don't think there's sufficent use case in this group. I think we should punt ot the editoring task force and say if you want it, you spec it. If you guys need it write the requirement. Otherwise we'll drop it.
# [14:49] <dael> tantek: You cited web based text editors, so that's what made me think of it.
# [14:49] <dael> fantasai: What if they come back and say let Florian spec this?
# [14:49] * dauwhe what's the emacs equivalent of Godwin's Law?
# [14:49] <dael> tantek: Then we cross that bridge.
# [14:49] * Zakim excuses himself; his presence no longer seems to be needed
# [14:49] * Parts: Zakim (zakim@public.cloak)
# [14:50] * Joins: Zakim (zakim@public.cloak)
# [14:50] <dael> johanneswilm: The main problem in some browsers is you couldn't put anything on top of the caret. I don't know if that's still the case, but it had an infinate-z. If you could put something on top if it you could animate to whatever.
# [14:50] <dael> fantasai: We can animate it, but it intersects with blinking.
# [14:50] <dael> johanneswilm: Editing has the major JS editors.
# [14:50] <dael> Florian: WE don't have the people that write the code editors.
# [14:51] <dael> johanneswilm: We have them. Martin wasn't at the meeting, but he's on the task force.
# [14:51] <dael> Florian: How do you want that action/resolution to be phrased, tantek?
# [14:51] <dael> tantek: We resolve that we drop the prop. We action you to go to the editing TF to ask if it's a requirement and to document it if it is.
# [14:52] <dael> RESOLVED: drop the caret-animation property
# [14:52] <dael> ACTION Florian to figure out with the editing TF if there are and what are the requirements for caret-animation
# [14:52] * trackbot is creating a new ACTION.
# [14:52] <trackbot> Created ACTION-705 - Figure out with the editing tf if there are and what are the requirements for caret-animation [on Florian Rivoal - due 2015-09-01].
# [14:52] <johanneswilm> s\Martin\Marijn Haverbeke
# [14:53] <Florian> https://lists.w3.org/Archives/Public/www-style/2015Aug/0010.html
# [14:53] <dael> Florian: Next topic is this e-mail
# [14:53] <tantek> dael - and drop caret-blink-time to be precise
# [14:54] <tantek> - drop all properties to do with caret animation
# [14:54] <dael> Florian: We got a test case contributable that was trying to test that if you set the cursor on the select element and you set the cursor to something else on the parent of the select element and you click and it shows the dropdown. Some versions of IE show the parent. In general the spec says what to do when cursor is in an element, but it doesn't say anything about overlapping. We might need to clarify and I don't know how to explain that.
# [14:55] <dael> Florian: So you're overlapping several things and this has something to do with which thing would get the event if you click, which we also don't define. It's def. undefined and would be worth clarifying if we could
# [14:55] <dael> tantek: We've punted on this because it's hit testing.
# [14:56] <dael> Florian: So should I write nothing, or write that it depends on the overlapping element.
# [14:56] <dael> tantek: I don't think you need to write a test case.
# [14:56] <dael> Florian: We've written tests to find out UA behavior to find out how to spec it.
# [14:57] <dael> tantek: So we can accept the test. We've resolved not to accpt hit testing in UI 3 and I'd advise against it in 4.
# [14:57] <dael> ChrisLilley: I don't think this has to be hit testing. One thing we should say is what part of the cursor has to be over something.
# [14:57] <dael> tantek: That I'd be okay clarifying.
# [14:57] <tantek> that the hotspot of the cursor is what should be in the border box
# [14:58] <dael> ChrisLilley: The prop from the guy wasn't sufficent. You've got two items in a stacking context. Things can be overlapping for different reasons. If there's two abspos elements we know what's on top.
# [14:58] <dael> tantek: I don't want any hand waving about hit testing
# [14:58] <dael> ChrisLilley: I said which renders on top.
# [14:58] <dael> zcorpan: If the cursor depends on hit testing, what appears on top doesn't matter.
# [14:58] <dael> ChrisLilley: If we have 2 abspos elements we know what's on top.
# [14:58] <dael> Florian: Hit testing depends on what's on top and other things
# [14:59] <dael> tantek: And you want it to matter, the hit testing.
# [14:59] <dael> Florian: Now the test was written because there was a disconnect between the testing. IE had a version where the cursor would click in the dropdown, but looked like the cursor behind it. Even if we don't define hittesting we can refer to it.
# [15:00] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [15:00] <dael> MaRakow: When was hit testing dropped?
# [15:00] <dael> Florian: I think we have a resolution that chrsaid about using hot spots.
# [15:00] <dael> chrislilley: I'd prefer to refer to hit testing.
# [15:00] <dael> tantek: I don't know how without opening a can of worms because people will ask where to look for it.
# [15:01] <dael> Florian: Interop with hit testing is still something worth striving for and specing eventually, but hit testing is still something that's used. However you do hit testing, use that to pick the element for the cursor.
# [15:01] <dael> Florian: And then I can accept the test with spec justification.
# [15:01] <dael> Florian: So I'm tempted to put that in the spec.
# [15:01] <MaRakow> s/MaRakow: When was hit testing dropped?/MaRakow: The cursor hit testing through the select dropdown was a bug, not design/
# [15:02] <dael> tantek: So rather than leave it undefined, we refer to something undefined?
# [15:02] <leaverou> s/Florian: We've written tests to find out UA behavior to find out how to spec it./ChrisLilley: We've written tests to find out UA behavior to find out how to spec it./
# [15:02] <dael> Florian: Yes, it lets us refer to several different ways of testing.
# [15:02] <dael> tantek: Sure, let's try it.
# [15:02] <dael> Florian: So two resolutions to talk about hit testing and hot spots
# [15:03] <dael> tantek: And to say the hot spot is what matters and in the case of overlapping elements what's clicked is what counts, and to not define that.
# [15:03] <dael> Florian: If we do that we can try and use the term.
# [15:03] <zcorpan> cssom view refers to hit testing in e.g. https://drafts.csswg.org/cssom-view/#dom-document-elementfrompoint
# [15:03] * zcorpan Florian ^
# [15:03] <dael> Florian: Side question, can this be a way that UI level 4 is more precise, or should this go in level 3? I think we can just say level 4.
# [15:04] <dael> tantek: If it's a detail that there's interop, I think add it to level 3. It's a clarification, not a CR breaking change.
# [15:04] <dael> Florian: I wouldn't want to break CR.
# [15:04] * zcorpan we can add an inline issue about hit testing not being defined
# [15:04] <MaRakow> +1 zcorpan
# [15:04] <dael> fantasai: You're in the new process. You're just republishing.
# [15:04] * leaverou thinks but what if the hotspot of the current cursor is over an element with a different cursor and once it changes the hotspot is no longer over that element? Cycles!!!!11
# [15:04] <dael> tantek: It's a clirification, not a sig. change.
# [15:04] * Joins: ChrisL (clilley@public.cloak)
# [15:05] <dael> RESOLVED: Clarify that we're using the hotspot to determine which element is relevant
# [15:05] <tantek> "within the element's border edge"
# [15:05] <dael> RESOLVED: depend on hit testing
# [15:06] <dael> RESOLVED: Do not define hit testing
# [15:06] <ChrisL> http://w3cmemes.tumblr.com/image/127554590107
# [15:06] <dael> Florian: it was brought up with should have text-overflow-fade. We have ellipsis, but if it's a line another desirable effect is to fade to transparancy.
# [15:07] <dael> Rossen: We have a resolution on this from Seoul. We added this, you just need to add the text.
# [15:07] <dael> Florian: You're sure we resolved?
# [15:07] <dael> Rossen: I clearly remember we had the fade added to ellipsis.
# [15:07] <dael> astearns: We talked about it, but there was no resolution.
# [15:07] <dael> Rossen: There was the whole discussion about adding the pseudo element.
# [15:07] <dael> ChrisL: Can we resolve it now?
# [15:08] * dauwhe we resolve to not forget to resolve
# [15:08] <dael> fantasai: Maybe there was a proposed resolution with no final resolution.
# [15:08] * tantek is questioning WG's resolve.
# [15:09] <dael> astearns: I don't see a prop resolution in the minutes.
# [15:09] <dael> Florian: There was discussion about how long the fade should be.
# [15:09] <dael> tantek: Who was asking for this?
# [15:09] <dael> TabAtkins: Bloomberg.
# [15:09] <dael> Florian: And now there's someone else on the mailing list
# [15:10] <dael> Bert: Can someone remind me, I wasn't there.
# [15:10] <dael> Florian: Instead of doing ... at the end, you would just fade out.
# [15:10] <dael> tantek: You would render the characters but where the ellipsis would go, you would fade them out.
# [15:11] <dael> plinss: Rather than some random set of prop, I'd rather see a pseudo element that can be styled
# [15:11] <dael> fantasai: I think we were planning to do that too, but this was a stop-gap. You can instead content witht he pseudo, not remove it.
# [15:11] <dael> Florian: The pseudo matches the existing...
# [15:11] <astearns> s/instead/insert/
# [15:11] * MaRakow can I put it on my <marquee>?
# [15:12] <dael> fantasai: There's no way to do this with existing properties. We cannot just add a pseudo element to get this.
# [15:12] <dael> tantek: Do you have screenshots of this?
# [15:12] * astearns :-pseudo instead of ::pseudo
# [15:12] <dael> TabAtkins: Yeah, it's everywhere.
# [15:12] <dael> andrey: The tabs in chrome do this is you have narrow enough text.
# [15:12] <Florian> http://snook.ca/archives/html_and_css/handling-overflow
# [15:12] <dael> fantasai: Even if we added pseudo magic, we'd want a keyword for common behaviors.
# [15:13] <fantasai> s/behaviors/behaviors and this is clearly one of them/
# [15:13] <dael> Florian: CSS UI level 4 isn't near CR yet. I think we can resolve to edit and I come back later with text. I'll read the notes from the last meeting.
# [15:13] * Joins: andreyr (~andreyr@public.cloak)
# [15:13] <dael> tantek: When does dino get here? When we talked about this in Sydney, dino had particularly strong inputs on this.
# [15:14] <dael> hober: We basically do it in the location bar.
# [15:14] <leaverou> I'm not sure why we need to spec the fade. If we give them an equivalent of -webkit-line-clamp, they can do the fade themselves with a mask or pseudoelement and customize it as they want, no?
# [15:14] <dael> fantasai: They wanted more control over where the ellipsis happens. That kind of thing is stuff they need, but we won't do it immediatly.
# [15:15] <dael> Florian: Can we resolve that we add it somehow or do we resolve nothing? I think we agree that we want it.
# [15:16] <dael> fantasai: I think this makes sense to add. Even if we have a more sophisticated mech we want to have a short keyword to do this. I imagine this being a keyword to decide on for whatever we do in the future. I'm in favor of adding it.
# [15:16] <dael> Florian: Objections?
# [15:16] <dael> RESOLVED: add text-overflow-fade and let Florian figure out the details
# [15:16] * Joins: dino (~textual@public.cloak)
# [15:17] <dael> Florian: With the exception of having not written the text for the last resolution, I don't have intentions to add more to CSS UI 4, so I think we should go to FPWD soonish. Does anyone have a requirement of something they'd like to have as a part of UI 4 that should be added?
# [15:17] <dael> ChrisL: If someone has a prop they can do it for the next draft. Let's go for it.
# [15:17] <dael> plinss: objections?
# [15:17] <dael> RESOLVED: publish FPWD of CSS UI 4
# [15:18] * tantek Florian ok with CSS UI 4 as a diff spec right?
# [15:18] * Joins: antonp2 (~Thunderbird@public.cloak)
# [15:18] <dael> Florian: Does this let me pub now and add fade later?
# [15:18] <dael> plinss: publish early, publish often.
# [15:18] <dael> fantasai: Do whatever you want
# [15:18] <dael> dbaron: FPWD has implication on patent
# [15:18] <dael> astearns: So better to put it in.
# [15:18] <dbaron> s/patent/patent policy/
# [15:19] <dael> Florian: That's all for CSS UI today. You're all welcome to read the doc.
# [15:19] <dael> Topic: css-text-4
# [15:19] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [15:20] * antonp2 is now known as antonp
# [15:20] * Joins: plh (plehegar@public.cloak)
# [15:21] <dael> Florian: In NY we were discussing whitespace pre-wrap and we resolved to add a pre-wrap-auto and for pre-wrap to have a specific value and to add that to level 3. WE also resolved to add pre-wrap-trim to level 4 which would drop the spaces at the end of the line. White space is a simple prop in 3, but a shorthand of two prop in level 4.
# [15:21] <dael> Florian: So how is pre-wrap-auto and -trim related to these new longhands.
# [15:21] <dael> fantasai: So we resolved to you can see the spaces?
# [15:22] <dael> Florian: We discussed three. pre-wrap, pre-wrap-auto, and pre-wrap-trim which drops the spaces at the end of the line.
# [15:22] <dael> fantasai: Why are we not using three lines.
# [15:22] <dael> Florian: What we didn't discuss in NY is that the whitespace is a shorthand of two longhands and I don't know how to express that. I have two options. The new option 3 is that the longhands were a bad idea and lets get rid of them.
# [15:23] <dael> Florian: So, first, do we want whitespace to have long hands?
# [15:23] <dael> zcorpan: usecase for longhands?
# [15:23] <dael> fantasai: They seemed useful, but I don't remember the exact use case.
# [15:23] <dael> tantek: Did you have an option you pref?
# [15:24] <ChrisL> s/useful/orthogonal/
# [15:24] <dael> Florian: I've been back and forth. I think I prefer what I called option 2 which is to not change text space collapse prop.
# [15:24] <dael> fantasai: I prefer option 1. But I can merge them back in.
# [15:24] * Joins: antonp1 (~Thunderbird@public.cloak)
# [15:24] * Quits: jihye (~jihye@public.cloak) ("Page closed")
# [15:25] <dael> fantasai: At this point we have 3 prop that are related. There's text-space-collapse, -trim, and text-wrap.
# [15:25] <dael> Florian: And the reason it's tricky is with prewrap auto things aren't entirely orthogonal. The wrapping and collapsing are not different concepts. If you do collapse the space you won't wrap.
# [15:25] <dael> fantasai: I think option 1 makes more sense because how you wrap depends on how you collapse, not the other way around.
# [15:26] <dael> fantasai: I'd be happy with option 1. As far as longhands or not, they're very orthogonal things. If you ever want the set to cascade independantly, I'm not sure. But wrapping and spaces are two independant variables.
# [15:26] <dael> Florian: So re-reading, I prefer option 1.
# [15:26] <dael> fantasai: Any other opinions?
# [15:27] <dael> tantek: I think we should try and make option 1 work and report back if it doesn't.
# [15:27] <Florian> https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html
# [15:27] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [15:27] * antonp1 is now known as antonp
# [15:27] <dael> fantasai: dbaron can you have a shorthand that has inheriting and non-inheriting prop?
# [15:27] <dael> dbaron: We haven't and I prefer not to, but it could be done. We've done all.
# [15:27] <dael> fantasai: I think whitespace should be in trim as well. If you reset to normal it should do all the normal things.
# [15:28] <dael> Florian: So, resolve option one?
# [15:28] <fantasai> s/whitespace should be in trim/text-space-trim should be in white-space shorthand/
# [15:28] <dael> Florian: If we do that option 3 isn't excluded anymore. If we make whitespace trim that that part is possible. It might be an option, but it's not a good idea.
# [15:29] <dael> fantasai: No, that wouldn't work because you need it to inherit.
# [15:29] <dael> fantasai: I thinkw e also have a resolution that we need to add the other two longhands of white-space if we're adding white-space-trim
# [15:29] <dael> RESOLVED: Use option 1
# [15:29] <tantek> Try option 1, report back if you run into problems.
# [15:30] <dael> fantasai: So should write-space-trim be added longhand which I think yes.
# [15:30] <dael> astearns: It makes sense that white space needs to be a shorthand. I'm not sure we need the longhands.
# [15:30] <dael> fantasai: It needs to reset to normal.
# [15:30] <dael> Florian: So astearns are you saying pre-wrap auto and trim should not exist or only as longhands?
# [15:31] <dael> astearns: I'd prefer not to add any values unless they're needed. We aren't goingto add values to the shorthand unless there's a demonstrated need.
# [15:31] <dael> Florian: For that I'd be okay for trim, but auto is justified on the shorthand because it gets you browser behavior. Also we have it on level 3 and there's no long hand on level 3.
# [15:32] <dael> Florian: So keep the behavior of white-space-trim but only on the long hand. Is that okay with you, Bert?
# [15:32] <dael> Florian: We'd still have the behavior, but you need a long hand.
# [15:32] <dael> Bert: I'm not sure. I see you have the functionality, but I'm not sure I want whitespace to become a short hand. I don't have a def. opinion.
# [15:32] <dael> Bert: It's at the level I want to spec things.
# [15:33] <dael> fantasai: New lines and spaces are in the same longhand. The first one is how you collapse and the second is how you wrap.
# [15:33] <dael> fantasai: It allows you to set wrap independanlty of how you collapse. I agree with you that the previous XSL had three different prop and it was confusing.
# [15:34] <dael> Florian: With a bit of discomfort with the shorthands being linked to different longhands with behavior...it's weird.
# [15:34] * Rossen is now known as Rossen_away
# [15:34] * Joins: jihye (~jihye@public.cloak)
# [15:34] <dael> fantasai: Once place is where they get conflated is trim has a trim inner prop.
# [15:34] <dael> fantasai: If you're using consume before and after you might want that inherited sep. Or reset.
# [15:34] <astearns> s/prefer not to add any values/prefer not to add any shorthand values/
# [15:35] <dael> fantasai: I'm not sure and I don't feel too strongly about that.
# [15:35] <fantasai> s/inherited/cascaded/
# [15:35] <dael> Florian: But we're not on my issue anymore
# [15:36] <dael> fantasai: I guess for simplicity lets group it under the shorthand and if there's an issue people can raise it.
# [15:36] <dael> RESOLVED: text-space-trim, text-space-collapse, and text-wrap are longhands of whitespace
# [15:37] <dael> and people can raise issues if that's a problem.
# [15:37] <dael> Florian: astearns I think a while about you tried to get the WD out of text level 4.
# [15:37] <dael> dauwhe: I'll prob have suggestions for features around hyphenation
# [15:38] <dael> fantasai: I've been told it's all wrong, but asked him to list them on the ML and never heard back.
# [15:39] * leaverou the naming convention for shorthands has completely gone out of the window in the past few years :/
# [15:39] <dael> plinss: Anything else on text?
# [15:39] * fantasai it's not true, but we can't do much about legacy
# [15:39] <dael> Florian: Does this change if we should do FPWD?
# [15:39] <dael> fantasai: Go, we should.
# [15:39] <dael> RESOLVED: FPWD for text 4
# [15:40] <dael> Topic: user stylesheets
# [15:40] <dael> ChrisL: There was some discussion about user stylesheets that originated about customization. I did a twitter survey and most people didn't know this feature exists. It's a developer feature that we pretend is for authors, but they can't use it.
# [15:41] <dael> ChrisL: It seems to be a misfeature that's mostly, but not always implemented. I think Chrome removed it.
# [15:41] <dael> TabAtkins: Yep. All we have is UA styles and page styles
# [15:41] <dino> Safari has them
# [15:42] <dino> you can pick one at a time
# [15:42] <Florian> q+
# [15:42] * Zakim sees Florian on the speaker queue
# [15:42] <dino> not really a great UI
# [15:42] <dael> ChrisL: I was asked if this feature is going to be extended or depricated by the group. I'm aware for someusers that need customization they're not using that mech. Do we have any evidence it's being used? Should we leave it alone? Should we drop and make something better?
# [15:42] <dael> ChrisL: I wanted to surface that discussion
# [15:42] <dael> SimonSapin: There's a FF extension called stylish that types in CSS and I think it uses the user stylesheet.
# [15:42] <dael> ChrisL: Does it use our doc?
# [15:42] <dael> TabAtkins: Yes.
# [15:43] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [15:43] <dael> dbaron: It may or may not. We have user stylesheets for extensions. I think we now have a per page one.
# [15:43] <dael> ChrisL: A lot could have been done with user stylesheets and it wasn't. For example bookmark could have used the stylesheet. It could be a mech where people trade their stylesheets.
# [15:44] <dbaron> actually, not sure about the API; might just be thinking about https://bugzilla.mozilla.org/show_bug.cgi?id=988266
# [15:44] <dael> Florian: There's nothing wrong witht he design of user stylesheet. What's been missing is a UI for this. I don't think it's impossible, I think it hasn't been an important feature for broswers.
# [15:44] <dauwhe> q+
# [15:44] * Zakim sees Florian, dauwhe on the speaker queue
# [15:44] <plinss> ack florian
# [15:44] * Zakim sees dauwhe on the speaker queue
# [15:45] <dael> Florian: I think you have something that lets you apply user stylesheets. I think this is a good feature for a11l and good for people who want to customize their stylesheet. I think it's fine if people want to use it. Or here's a variant of the dev tools. Let people experiment or ignore.
# [15:45] <dael> hober: Chrome means that the user style is always just 0.
# [15:46] <dael> esprehn: There's little evidence that people want it. It's been Safari for years and people weren't using it, it wasn't powerful enough. The Safari sheet applies to everything. You want something powerful like stylish so you can have if statements and the like. That might be out of scope
# [15:46] <johanneswilm> Marijn Haverbeke (the person behind the CodeMirror editor): CodeMirror's vim mode does use a custom caret (in non-contentEditable
# [15:46] <johanneswilm> mode), which currently doesn't work in contentEditable mode, so sure,
# [15:46] <johanneswilm> this would be nice to have. But that use case, where the caret needs
# [15:46] <johanneswilm> to overlay the character after it, might be more than browser vendor
# [15:46] <johanneswilm> are willing to chew. See http://codemirror.net/demo/vim.html
# [15:47] <dael> ChrisL: That's one of the comments I got. When people want to over-ride they want rules.
# [15:47] * Joins: MaRakow (~MaRakow@public.cloak)
# [15:47] <dael> Florian: Once we have this, the rest is UI
# [15:47] <dael> ChrisL: And there's various things that use browser engines. If they want per user they need it.
# [15:47] <dael> hober: We provide support for user stylesheets.
# [15:47] <dael> Florian: And one of the epubs that lets you change the background
# [15:48] <plinss> ack dauwhe
# [15:48] * Zakim sees no one on the speaker queue
# [15:48] <dael> dauwhe: I think ebook is a huge usecase. ebook devs right now are putting a lot of work into trying to detect night or day mode, there's a lot of work into that and lots of misunderstandings.
# [15:48] <dael> dauwhe: I just hope for a wide API or something to make it easier for ebooks.
# [15:49] <dael> Florian: It wouldn't be a JS API for web authors, it's for people that edit the engine into a larger application.
# [15:49] <dael> Florian: I think we're missing that doc and UI innovation. It'll always be a niche issue, but it's not ever used.
# [15:49] <dael> fantasai: Day and night mode, there's a spec for that
# [15:49] <dael> astearns: Amazon isn't letting them use it, was dauwhe's point.
# [15:50] <dael> hober: I guess the question is, what is the ongoing burdon of retaining this.
# [15:50] <dael> ??: I'd say 0
# [15:50] <dael> hober: So there's some value to it and no reason to get rid of it.
# [15:50] <dael> esprehn: From our view this should be solved by UAs
# [15:50] <zcorpan> s/??/Florian/
# [15:51] <fantasai> day/night spec - http://www.idpf.org/epub/altss-tags/
# [15:51] <dael> esprehn: We don't care about the spec. Chrome has an extension API that lets you build this feature yourself and we support authors building those tools because it will benefit devs.The low level stylesheet facility is too complicated. THe people that want to use this want to pick a them.
# [15:52] <dael> hober: The point is user stylesheets have an implication for how specificity is calculated. If we go into the spec and say have some way to specify style, it's a loss.
# [15:52] <dael> Florian: Once we have a WG that standardizes browser extensions, we don't need this.
# [15:52] <dael> esprehn: I don't believe we should standardize how browser stylesheets interact with user stylesheets.
# [15:52] <dael> sam: So my proposal was not to change the spec.
# [15:52] <dael> esprehn: We're not going to add it back.
# [15:53] <fantasai> tantek++
# [15:53] <dael> tantek: It also represents preferences, such as the font. It's all user stylesheets.
# [15:53] <dael> TabAtkins: Some of those are not. What you want your serif to be isn't represented that way.
# [15:53] <dael> TabAtkins: It's not true from Chrome, it never has been.
# [15:53] <dael> tantek: It was 15 years ago.
# [15:54] <dael> fantasai: You can't communicate the mapping of a font to a serif family.
# [15:54] <dael> tantek: I'm not saying that is, I'm saying that things like link color are.
# [15:54] <dael> tantek: So if you have a thing that says pick a user stylesheet, you still have to cascade like you have it.
# [15:54] <dael> dauwhe: There's lots of complaining in the ebook about how author and user stylesheets interact.
# [15:54] <dael> TabAtkins: I prefer having that control.
# [15:55] <fantasai> s/serif family/to the generic serif family/
# [15:55] <dael> hober: It's unfortunitly nec.
# [15:55] <dael> Florian: given that the difference between the browser not impl and impl and not loading is the same to the user, I think keeping it in the spec is the right way
# [15:56] <dael> ChrisL: So the conclusion is that it should stay in the spec. It doesn't need changes or improvement.
# [15:56] <dael> Florian: I wouldn't say that. @document would make this more useful. UAs that think it would be useful to expose this to their user should innovate at the wide level. There may be other ways that go through extensions, but that's not a part of the WG.
# [15:56] <dael> ChrisL: That was the discussion I wanted to have.
# [15:56] <dauwhe> s/complaining in the ebook/complaining in the ebook developer community/
# [15:57] <dael> Bert: Can we be more concret about the @document. I'd like to see it.
# [15:57] <dael> TabAtkins: It was in conditional rules
# [15:57] <dael> dbaron: It was dropped because there were parts we didn't know how to spec and it was holding up the rest of the spec. We might be able ot do a better job with URL comparision, but I think that was the main issue.
# [15:57] <dael> Florian: That' was my memory.
# [15:58] <dauwhe> http://www.w3.org/TR/2011/WD-css3-conditional-20110901/#at-document
# [15:58] <dael> Bert: So we can spec this @document so I'd like to raise the priority.
# [15:58] <dael> hober: Anna has been working on adding a couple of comparision functions to the URL spec.
# [15:58] <fantasai> fantasai: Bert, would you volunteer to edit css-conditional-2?
# [15:58] <astearns> s/Anna/Anne/
# [15:58] <dael> SimonSapin: I believe these are compare a URL or the fragment.
# [15:58] <dael> TabAtkins: Also just the host.
# [15:59] <dael> hober: Someone should file a bug on the URL spec then.
# [15:59] <leaverou> http://www.w3.org/TR/2012/WD-css3-conditional-20120911/#at-document
# [15:59] <dael> sam: What was the matching granualrity intended to be? prefix?
# [15:59] <SimonSapin> s/a URL or the fragment/an entire URL or a an URL without the fragment/
# [15:59] <dael> dbaron: There were three in the spec. URL, URL prefix, and domain. There's also regex in gecko. There's some issues with that. That does go away if we don't expose it to author stylesheets.
# [15:59] <zcorpan> <annevk> zcorpan: https://url.spec.whatwg.org/#url-equivalence no API yet
# [15:59] <zcorpan> <annevk> zcorpan: if you have specific use cases, I recommend filing issues
# [15:59] <leaverou> dbaron: "excluding any fragment identifiers"?! Why? This could be very useful
# [16:00] <dael> sam: Was it a full regex or a subset?
# [16:00] <dael> dbaron: Full as in calls the JS engine and tells it to deal with it.
# [16:00] <dael> sam: This is where your URL comparision question comes in, how connonization is dealt with?
# [16:01] <dael> sam: I don't think Anne's spec deals with regex but we may want to ask them to deal with it.
# [16:01] * ChrisL imagines a url fragment containing eval()
# [16:01] <Bert> (Re: editing css-conditional-2: I'd be OK to edit css-conditional-2 if I'm guaranteed that that is the only new feature. :-) )
# [16:01] <dael> <break=15min>
# [16:02] <fantasai> Bert, I think it would be
# [16:06] <leaverou> Bert: are you really asking for a guarantee of stagnation? :P
# [16:06] <Ms2ger`> Bert, if you finish it quickly enough, you can push for -3 :)
# [16:11] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [16:16] * Quits: rachelandrew (~59cacb34@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [16:17] * Quits: dino (~textual@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [16:18] * Joins: rachelandrew (~59cacb34@public.cloak)
# [16:18] * Quits: weinig (~weinig@public.cloak) (weinig)
# [16:22] <TabAtkins> Trying to figure out what this is a meme for http://openpuppies.com/#3V37Hqr
# [16:23] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [16:27] * Joins: weinig (~weinig@public.cloak)
# [16:32] <fantasai> btw, Ms2ger++++++++++++++++++++++
# [16:32] <fantasai> (thank you for all the test suite cleanup)
# [16:34] <Ms2ger`> I try :)
# [16:35] <Ms2ger`> fantasai, if you can get people to review https://github.com/w3c/csswg-test/pull/829 , that'd be great :)
# [16:35] <dael> plinss: Let's get started
# [16:36] <dael> Topic: Snapshot 2015 and prefix policy
# [16:37] <dael> TabAtkins: There's a question of what criteria do we use to include in the snapshot. Things in CR, things widely implemented? I think the latter is more useful to authors.
# [16:37] * dauwhe virtual CR
# [16:38] <dael> fantasai: The org purpose of the snapshot is we had a bunch of specs in CR and a bunch that we're but kinda were, but the CSS statuses didn't mean a lot. We're a lot better at not having things in CR that shouldn't be. But we also have some things in WD that are a bit behind. The previous snapshot was things in CR and had been in CR long enough that we were sure things weren't going to change much.
# [16:39] * Ms2ger` (only four commits per attendee, and they're all trivial)
# [16:39] <dael> fantasai: So we had impl experience through out all the tests. We could see all of it being impl and most issues being shaken out. We knew all the parts had been tested and impl to some extent.
# [16:39] * Joins: johanneswilm (~johannes@public.cloak)
# [16:40] <dael> fantasai: So we agree the spec isn't wrong and it is pretty stable. Flexbox when it hit CR wouldn't have been in the snapshot because we didn't have the experience yet. At this point, flexbox is really stabilizing and in the next 6 months we would be able to say its pretty stable and won't have many changes.
# [16:41] <dael> fantasai: I think that's a useful delimited. To get into PR and REC you have to have two passes of everything and a lot of the time we're waiting on bug fixes. That spec is still almost as stable as REC, we're just not there. The snapshot is to break the CR into two different pieces.
# [16:41] <dael> fantasai: It's kind of like when we have WD where it's exporatory and things lock down toward the end and that's not reflected in W3C process. I think that's a useful distinction in the snapshot and we should maintin that. We might want to include more and have all the spec in CR and the stuff that's stable.
# [16:42] <dael> TabAtkins: Sure. Okay. Seems reasonable.
# [16:42] <dael> Florian: We've also suggested that the intro of what CSS is would fit in the snapshot well.
# [16:42] <dael> fantasai: I think that's a great idea and we shouldn't work on it right now.
# [16:42] <dael> Florian: And CSS 2.1 hasn't been completely replaced.
# [16:43] <dael> fantasai: We've inforporated all the property indexes. We split down the list and put a short description of what are all these specs.
# [16:43] <dael> TabAtkins: If you were to look chapter 4 is an index of all the terms we've included.
# [16:43] <fantasai> https://drafts.csswg.org/css-2015/#css
# [16:43] <dael> fantasai: And it maps all the things in 2.1 that have been replaced. That's what's in the snapshot right now.
# [16:43] <dael> fantasai: So questions for the group:
# [16:44] <dael> fantasai: One is transitions and animations. How far are the edits behind the resolutions?
# [16:44] <dael> dbaron: animations is a bit behind. transitions I don't htink there's resolutions, it's just going through e-mail backlog.
# [16:44] <dael> fantasai: Should we pub an update to transitions?
# [16:44] * Joins: ChrisL (clilley@public.cloak)
# [16:44] <dael> dbaron: We have a resolution to pub a CR, but I have to do a DoC first.
# [16:44] <dael> dbaron: I don't know that that much has been updated from the last draft.
# [16:44] <dael> fantasai: What about transforms?
# [16:45] <dael> hober: I can't remember...
# [16:45] * astearns hmm - section 4.1 would look nice as a series of two-column 80vh regions…
# [16:45] <dael> dbaron: There were a bunch of preserve-3d changes that need to be edited in. They're still scary in terms of web compat. I think there's some other issues with the spec not explaining it well.
# [16:46] <dael> fantasai: So what I think would be a good idea, we did resolve on a list of things to add to the snapshot, but I would rec that we put transitions, animations and flexbox into the snapshot as things that are impl widely, but not quite stable yet.
# [16:46] <hober> s/hober: I can't remember...//
# [16:46] <dael> TabAtkins: Can we just base it on the work status of the spec? That would auto-update the snapshot. We'd have to make sure work statuses are used correctly.
# [16:47] <dael> fantasai: I think we could, but the text we're using and the order is significant, so we couldn't auto-gen right now. Maybe for next year?
# [16:47] <dael> TabAtkins: We could do it now.
# [16:47] <dael> fantasai: I don't want to deal with all this text that needs to stay in. I'd like transitions, animations, transforms, and flexbox into a section os snapshot that's marked as not stable.
# [16:47] <dael> dbaron: I'm not convinced it needs to be stable.
# [16:48] <dael> TabAtkins: The web is depending on it.
# [16:48] <dael> fantasai: But the spec isn't synced to the web.
# [16:48] <dael> hober: Should the specs be in, yes. How you orgniaze it I don't think we need to talk about.
# [16:48] <dael> dbaron: If you create more categories, there's more categories for us to argue about what goes into them so we're better off not creating more.
# [16:49] <dael> fantasai: I just feel that if we put them in as-is, it's just here's bunch of stuff that you can use as is. The job of this thing is to tell you what's stable.
# [16:49] <dael> hober: I hear you saying we organize this in a way to make it useful. Sure.
# [16:49] <dael> dbaron: At the level the snapshot audience is going to look at it, it's fine.
# [16:49] <dael> fantasai: There's a variety of audiences. There's Japanese market and digipub market and they're going to look at it differently.
# [16:50] <dael> fantasai: The snapshot is for us to communicate with other people in the industry.
# [16:50] <dael> hiroshi:Is the writing-mode in this document?
# [16:51] <dael> fantasai: Not yet. Hopefully writing-mode and flexbox will be stable by the end of the year.
# [16:51] <dael> Florian: so writing-mode is not yet, but soon.
# [16:51] <dael> hiroshi: OKay. That one is important for me.
# [16:51] <dael> fantasai: That's most of the issues other then prefixing.
# [16:52] <dael> Florian: While we're talking about stability, different communities care about different levels. Japan's industry and publishing want things that have a big stamp that says it's ready.
# [16:52] <dael> fantasai: I think the snapshot level is what they want to be looking at. I think for them the distinction i nthe snapshot is a useful one.
# [16:52] * Joins: adenilson (~anonymous@public.cloak)
# [16:53] * Ms2ger` wonders if css-2015 will ship this year
# [16:53] * fantasai :p
# [16:53] * fantasai it really depends on the next discussion
# [16:53] <fantasai> https://drafts.csswg.org/css-2015/#experimental
# [16:53] <dael> fantasai: So, implementation of unstable and prioritry features
# [16:53] <dael> TabAtkins: Prefixing policy.
# [16:54] <dael> TabAtkins: I believe gregwhitworth had some obj to the text in the prefixing policy
# [16:54] <dael> gregwhitworth: Obj is strong, but yes I sent some.
# [16:54] <Florian> https://lists.w3.org/Archives/Public/www-style/2015Jul/0447.html
# [16:55] * Ms2ger` hah
# [16:55] * Ms2ger` hopes they'll be turning off the lights at 5pm
# [16:55] <Florian> q+
# [16:55] * Zakim sees Florian on the speaker queue
# [16:55] <dael> gregwhitworth: I believe someone, I think hober or SimonSapin, shared the concerns that CSS shouldn't get into how or where people ship things. I think we should leave it out and that we just ultimatly don't want prefixes. I think the TAG needs to be a part of this. I think it should be up to the UA on how they handle shipping things. If it's reg keys or no matter the mech.
# [16:56] <dael> Florian: I think you are correct that the issue isn't CSS specific, but I think the solution might be lang specific. To the extent that the previous policy is being replaced, giving it the same title makes sense.
# [16:56] <dael> gregwhitworth: And that's what I said. I do understand that. Just try and make it as broad as poss.
# [16:57] <dael> Florian: I don't think anyone here has the delusion that the W3C can boss around browsers. It is useful to doc what, as of today, the WG and broswer community feels is the best policy to release things. There will be exceptions, there will have to be, but it's important to say.
# [16:58] <dael> Florian: Getting this wrong, as we've done it in the past, significnatly hampers our ability to do things in the future. The best way to release a work in progress is worthwhile to document. If you do it the way we describe but sometimes for business reasons you can't, that is life.
# [16:58] <dael> hober: I think I agree/disagree with both of you.
# [16:59] <dael> hober: I basically agree with Florian. We cshouldn't characterize contingent facts of one browser's implementation policy as fact. I preferred gregwhitworth's wording. I tallows heterogenious release. It doesn't have you must haves.
# [16:59] <dael> hober: In the current snaposhot, 3.3.1 [reads the draft]
# [16:59] <Ms2ger`> As long as we make it clear that shipping prefixed properties is bad
# [17:00] <dael> hober: This assumes there's such a thing as a non-release build.
# [17:00] * TabAtkins Ms2ger` I think that's what Ted's trying not to say. ^_^
# [17:00] <Ms2ger`> Then he's wrong :)
# [17:00] <fantasai> gregwhitworth, https://hg.csswg.org/drafts/diff/a8ffa9d7d989/css-2015/Overview.bs ?
# [17:01] <dael> Florian: The word might not be great, but if unfinished products are exposed finding a term to cover that, sure. The wording in gregwhitworth mail is too vauge, saying that authors should only be allowed to experiment with those. What does that mean? Is that what we've been doing and users are a part of the experiment?
# [17:01] * tantek smiles at the finger-wagging at authors.
# [17:02] <dael> gregwhitworth: So let's say we have a feature that we think is great. We do a prefix, it's behind the flag, but we give you a key and it lets us turn it on for 10% of your users. That gives us live data and it doesn't handcuff us for years.
# [17:02] <hober> s/basically agree with Florian/basically agree with Florian's intent/
# [17:02] <hober> s/cshouldn't/shouldn't say/
# [17:02] <hober> s/implementation policy as fact/implementation policy as the best practice/
# [17:02] <dael> gregwhitworth: I don't think you should constrict it. I only stress this because we're trying to do responsible work. I don't think anyone disagrees with the goal, but we carry the burdon of you're not using the spec. If I want to opt-in to a solution that should be possible.
# [17:03] <dbaron> I think there's an important piece missing in greg's email. Things that are shipped should also come along with the ability for others to implement them, which includes specifications that are good enough for other implementors for implement from.
# [17:03] <hober> s/I tallows/It allows for/
# [17:03] <dael> TabAtkins: If you have a good reason not to follow spec, you can.
# [17:03] <hober> s/It doesn't have you must haves.//
# [17:03] <dael> fantasai: We have two problems with prefixing. 1 is if you don't support that prefix prop and the author assumes everybody is webkit, the site breaks. second is that we lock people in because it's on production websites that aren't updating.
# [17:04] * Joins: ed_work_ (~ed@public.cloak)
# [17:04] <dael> gregwhitworth: The example I gave is contract based...it's something we spitballed in TPAC. WE won't have a one size fits all solution. Instead of constraining it, we should be more open. Have a note saying please don't prefix.
# [17:05] <dael> ojan: What you're both saying is shipping vendor prefixes ends up shipping a feature. If the CSS spec should be weighing in on that is a sep question.
# [17:05] <dael> Florian: People starrted shipping prefixes because we said that the previous suggestion was bad.
# [17:05] <dael> gregwhitworth: So remove the prefix suggestion
# [17:06] * Rossen_away is now known as Rossen
# [17:06] <dael> dbaron: I wrote this in IRC a few minutes ago, but I think it's important that if you do ship something you provide what's nec to let others ship that too. In some cases that's a spec that you bring to the WG to say here's the thing we shipped.
# [17:06] <dael> gregwhitworth: I'm not seeing how my statement disagrees.
# [17:06] <dael> dbaron: It doesn't, it's just something that should also be said.
# [17:06] <dael> gregwhitworth: Okay, I agree.
# [17:07] <dael> Florian: And if you ship something with your name on it, we all feel back when we have to impl prop that have the word webkit in it.
# [17:07] <dael> gregwhitworth: I think we agree, I'm just saying don't constrain as much as these. You say release vehicle and I can't guar that there will be.
# [17:07] * dauwhe https://twitter.com/dauwhe/status/636192266978230272
# [17:07] * ChrisL -edge-webkit-(like_mozilla)-stupid-non-experimental-property-X
# [17:07] <dael> fantasai: We don't want to release things that are unstable and non-standard for production use and we don't want to relsease it in a general way until it's stable.
# [17:07] <zcorpan> s/feel back/feel bad/
# [17:08] <dael> fantasai: So maybe the wording change is "should not be released for production use"
# [17:08] <dael> gregwhitworth: current-color is an example of where we'd violate the spec but it worked in our case.
# [17:08] <dael> fantasai: This is for use on the web, that's the key here.
# [17:09] <dael> Florian: That's a distinction we're trying to do. Yes, CSS is also used on not-web and it's alos in that case useful to have some guidelines indicating the best way to do this. If you're going to do something not exposed to the web and you release something, you might be dumb. Prefixes are great in a non-web space.
# [17:10] * Quits: ed_paris (~ed@public.cloak) (Ping timeout: 180 seconds)
# [17:10] <dael> Florian: Things not built for web content would be things that are good not to be able to be used on the web. Maybe later you want that on purpose.
# [17:10] <dael> Florian: Trying to phrase around web and non-web is difficult.
# [17:10] <dael> SteveZ: I don't understand the web distinction. If i'm writing tutorials I can put anything on the web.
# [17:10] <dael> fantasai: What we mean is for use in and enviroment where you'll be interacting with other CSS applications.
# [17:10] <dael> TabAtkins: We mean in a browser
# [17:11] <dael> fantasai: Not just that.
# [17:11] <fantasai> s/interacting/interoperating/
# [17:11] <fantasai> s/applications/implementations/
# [17:11] <dael> Florian: So if you add a CSS prop for specifically Firefox's UI, it's not from a HTTP server.
# [17:11] <dael> SteveZ: So when MS word started putting out it's stuff, it added prop for use in word, but they could be in the web.
# [17:11] <dael> TabAtkins: But that's when you choose HTML.
# [17:12] <dael> Florian: That's exposing to the web.
# [17:12] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [17:12] <dael> SteveZ: You're dealing with an impossible situation. It takes years to standardize.
# [17:12] <dael> TabAtkins: If it's not standardized you can't use it.
# [17:13] <dael> SteveZ: I don't see the disnction. I want to put everything I'm doing on the web. I agree about not polluting hte namespace, but you're a level beyond. I understand the webkit prefix policies. I also support that you ought to come in with a spec if you think you could standardize. It's unrealistic for a vendor to wait to have something stanardized.
# [17:13] <dael> TabAtkins: Then you're not publishing to the web.
# [17:14] <dael> gregwhitworth: It sounds like you want 3 hthings. If you want to pub something propriatary, bring it to us, if the group says that's stupid and we have business reasons to, we tried.
# [17:14] <dael> Florian: The wording doesn't constrain you from that.
# [17:14] <dael> hober: So he's saying he'll ship things anyone. If he does do it unprefixed.
# [17:15] <dael> Florian: If you can't standardize, don't prefix.
# [17:15] <dael> gregwhitworth: It sounds like being a good web citizen. So just try and put it on standard track and go from there.
# [17:15] <dael> fantasai: I changed ot to rec for best practices.
# [17:15] <dael> gregwhitworth: You changed the title?
# [17:15] * astearns s/recommends/timidly suggests/
# [17:15] <fantasai> "To avoid clashes with future stable CSS features, the CSSWG recommends the following best practices for the implementation of unstable features and proprietary extensions to CSS. "
# [17:15] <dael> fantasai: The first sentence. That's the only place policy appeared.
# [17:16] <dael> fantasai: I only fied the first paragraph
# [17:16] <dael> Florian: As for generally replacing the content for something more general is okay, but I don't want to say be reasonable please.
# [17:16] <dael> s/fied/fixed
# [17:17] <dael> gregwhitworth: I want to have prefixes are bad.
# [17:17] <dael> Florian: If you're writing UI specific that won't be sent to the web, do use prefixes. That's useful because they won't clash with anything and won't render on the web.
# [17:17] <dael> gregwhitworth: It feels like we've talked about it, don't want prefixes, so that's what this should say.
# [17:18] <dael> gregwhitworth: Also, we want it but we can't hold anyone accountable, so why write it?
# [17:18] * Joins: darktears (~darktears@public.cloak)
# [17:18] <dael> fantasai: We want to express a lot of things to people like don't impl something in FPWD and never make any changes. We do that because we want people to have better ideas and to help us improve before anything ships. It's a nightmare for authors to have all these different stages.
# [17:20] <dael> Rossen: You're implying something targetable by content. If it's something like UA flags, all the behavior you just explained is implementable. I would argue early impl are very useful to drive spec and clarify hurdles. What you're implying is that the holdback mech that was prefixes sucks. No one has aregued that using prefixes as holdbacks sucks. Flags or experimental features are better and we're starting to use them.
# [17:21] <dael> Rossen: Whether or not, gregwhitworth 3rd point, during the early phases of dev and playing witht hte feature we also want to collect user feedback. There are features that allow lighting up of those for random users. That's different and an experimental way of using holdback without exposing to everyone.
# [17:21] <dael> TabAtkins: We agree, we should have something like that. But in the meantime we know prefixes are a terrible way of doing this.
# [17:21] <dael> Florian: But we agree they're terrible, but the sentence we prop you didn't like.
# [17:21] <dael> fantasai: We all fundimentally agree of what we're trying to do.
# [17:22] <dael> hober: People think gregwhitworth wording is underconstrained, the current is thought overconstrained. Let's go away and make edits and come back.
# [17:22] <dael> Florian: Yes, but not having a wording means the curent snapshot is 5 years old. Should we say the old policy is bad and please hold on a new one.
# [17:23] <dael> fantasai: I think those of us interested should wordsmith this and come back to the group.
# [17:23] <dael> Florian: The current wording was from this.
# [17:23] <dael> fantasai: That was five years ago.
# [17:23] <dael> Florian: So, let's do that.
# [17:23] * Parts: kwkbtr (~kwkbtr@public.cloak)
# [17:23] <dael> fantasai: We had flags in the five years ago.
# [17:23] <fantasai> 2012
# [17:23] <fantasai> 2012
# [17:23] * Quits: weinig (~weinig@public.cloak) (weinig)
# [17:24] <dael> fantasai: We were intending for flags to be the way forward, but if we failed to do that we failed to do that.
# [17:24] <fantasai> http://www.w3.org/blog/CSS/2012/08/30/resolutions-53/
# [17:24] * Joins: weinig (~weinig@public.cloak)
# [17:24] <dael> fantasai: We didn't fully resolve because we hadn't worked out wording yet. We're working on translation right now. I get the sense we agree what we're trying to do so we should wordsmith it and make sure we get what's in all our heads. If we find a real difference of opinion we should come back to the group.
# [17:25] <dael> SteveZ: I think I now understand why I obj to the use of the web. You're telling me it's okay to use prefixes for features used for non-interop features.
# [17:25] <dael> Florian: I'm not sure. There has been an ex of apple adding something to iphone and telling people to make websites with it, but then they say they don't intend it to be used elsewhere.
# [17:26] <dael> Florian: I'm not trying to exclude these.
# [17:26] <fantasai> s/for non-interop features/for implementations not intended to interoperate/
# [17:26] <dael> SteveZ: The web is a mythical thing. I think the wording you have will be misinterp by everyone. It didn't suggest to me what we're trying to include.
# [17:26] <dael> Florian: You can join the convo when we fix that.
# [17:26] <dael> plinss: WE should exclude content on public websites using prefixes.
# [17:27] <dael> tantek: It should be HTP
# [17:27] <dael> plinss: But there's intranet.
# [17:27] <dael> tantek: I'm saying that's the bar.
# [17:27] * dauwhe today: define the web. tomorrow: define pages.
# [17:27] <dael> gregwhitworth: I think we're trying to define the web.
# [17:27] <dael> fantasai: I'd we're serving it over HTP.
# [17:28] <dael> plinss: If HP makes a propriaty server for a client that can browser the web, but it can also suck down these hp things, who gives? It's walled off to yourself and not exposed.
# [17:28] <fantasai> HTTP
# [17:28] <tantek> s/HTP/HTTP
# [17:28] <dael> Florian: This is hard to wordsmith, but it's meant to be the web.
# [17:28] <dael> plinss: If it's somehwere people can get ot it shouldn't be using prefixed.
# [17:28] * MaRakow contain: experimental-features
# [17:28] <dael> SteveZ: I don't see why you can't have a propriatry content
# [17:29] <dael> plinss: Then you have the iphone web and the kindle web.
# [17:29] * Joins: BogdanBrinza_css (~bbrinza@public.cloak)
# [17:29] * Ms2ger` will-change: gradient-syntax
# [17:29] <dael> SteveZ: What's bothering me is this body because a gateway for what people can do and we don't move fast enough.
# [17:29] <dael> Bert: This is for a small part of the web. Just CSS.
# [17:30] <Ms2ger`> A pretty essential part
# [17:30] <fantasai> Bert: You can make your own format, MyCustomizedCSS, and do whatever you want with that
# [17:30] <dael> SteveZ: When we get to the houdini meeting it gets worse, I don't know what you do.
# [17:30] * Quits: BogdanBrinza (~bbrinza@public.cloak) (Ping timeout: 180 seconds)
# [17:30] * Bert .oO "content-type: text/vnd.microsoft.css" (and now it's the IETF's problem :-) )
# [17:30] <dael> plinss: If you expect the prop to work you ship the code along witht he prop and that can run one anyone's browser.
# [17:30] <dael> SteveZ: There's still the standardization and namespace polution issue.
# [17:30] <skk> CSS is only for online manner? How about for offline situation? (if it's not the point, sorry)
# [17:30] <dael> plinss: Houdini isn't the way to make a new prop, it's a new custom property.
# [17:31] <dael> SteveZ: How do I know?
# [17:31] * Joins: ChrisLilley (clilley@public.cloak)
# [17:31] * fantasai thinks skk has a good point, too, we need to make sure this policy translates to worlds like EPUB
# [17:31] <dael> plinss: Prefix. That one prefix we've disignated for that process.
# [17:31] <dael> plinss: So you guys will wordsmith and come back?
# [17:31] <dael> Florian: We'll try.
# [17:31] <dael> tantek: Should we doc current objections?
# [17:31] <fantasai> Steve's phrase, something like "intended for an environment with multiple interoperable implementations", captures our target, I think.
# [17:32] <dael> Florian: That's going to take too long. We'll do it over beer.
# [17:32] <dael> esprehn: Can we talk about this in terms of population size instead of prefixing? If you ship it to enough people that other people have to impl too.
# [17:32] <dael> fantasai: If you're intending to send this page to an enviroment where there's multiple interop, you shouldn't prefix.
# [17:32] <dael> dbaron: I don't think number of people isn't the criteria.
# [17:33] <dael> gregwhitworth: I think he means impact.
# [17:33] <dael> tantek: The current text talks about preventing accental lock-in
# [17:33] <dael> hober: I don't think it's the place of the WG to go too much into how you determine lock-in.
# [17:33] <dael> tantek: I don't know how you improve the wording right now.
# [17:33] <dael> fantasai: We just need to improve the first sentence.
# [17:34] <dael> tantek: It doesn't sound like we're that far.
# [17:34] <dael> plinss: Are we done on this?
# [17:34] <dael> fantasai: For now. I think we should resolve by the end of the meeting.
# [17:34] <dael> tantek: So you'll come back by the end of the meeting.
# [17:34] <dael> fantasai: Yes.
# [17:35] <dael> Topic: @apply rule
# [17:36] <dael> TabAtkins: So I just sent the thing and haven't e-mailed the WG, but it's a tiny spec.
# [17:36] <dael> TabAtkins: polimer and post-css have used variables in an interesting way to port chunks of style.
# [17:37] <dael> [shows example 1]
# [17:37] <dael> TabAtkins: That is totally valid.
# [17:37] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [17:37] <dael> TabAtkins: Polimer has things like the apply rule that lets you refer to this and inlines them. This seems like a fine application and there's reasons to have reusable styles in a variable.
# [17:38] <dael> TabAtkins: These seems like a nice easy application of custom prop. That shouldn't be too hard to work with.
# [17:38] <dael> dbaron: It seems annoyingly cyclic
# [17:38] <dael> TabAtkins: No more so than var. There is an issue where if you define that property in there it would be cyclic.
# [17:38] <dael> dbaron: I don't see how they do this with pre-processing.
# [17:39] <dael> TabAtkins: It's not full fidelity. Maybe they pack it into JS.
# [17:39] <dael> TabAtkins: This is the entire example.
# [17:39] <dael> dbaron: It seems nice.
# [17:39] <dael> TabAtkins: We do want to make sure we deal with setting variables in the theme used by @apply.
# [17:39] <leaverou> for anyone else who can't see the screen: http://tabatkins.github.io/specs/css-apply-rule/
# [17:40] <dael> SimonSapin: In variables in custom prop you have a declaration that contains var. You don't pass it yet. It's only when you do all the variables that you pass it. You have integration of the property and that's why you need the cascade. For here, for @apply rule you don't know what prop make sense. In differnet places in the tree it could have different rules
# [17:40] <dael> TabAtkins: You can't resolve until computed value time and you have multiple instances.
# [17:41] <dael> dbaron: This would require us to do the work we decided to avoid doing in variables by taking the worst solution in cascading.
# [17:41] <dael> TabAtkins: Where we did the default fallback rather than cascading fallback.
# [17:41] <dauwhe> s/polimer/Polymer/
# [17:41] <fantasai> s/worst/worse/
# [17:41] * fantasai thinks
# [17:41] <dael> TabAtkins: Yeah. We did decide that for the var function. That may have killed this.
# [17:41] <dael> shane: Maybe there's a default fallback you can do that works.
# [17:42] <dael> TabAtkins: Thank you for bringing that up. We'll see if there's anything you can do that's reasonable.
# [17:42] <dael> shane: If we can make this work you said it looked interesting
# [17:42] <dael> dbaron: How important is it to use cascading variables rather than system.
# [17:42] <dbaron> s/system/global variables/
# [17:42] <dael> esprehn: Cascading variables seems counterintutive.
# [17:42] <dael> TabAtkins: We have it so you can override the them for some things.
# [17:43] <dael> TabAtkins: Like that you can do with variables where you could say inside a toolbar it's red in error state and this packages it up nicely.
# [17:43] <dael> shane: One of the uses that Polymer adopted it's just like custom prop you inherit down.
# [17:43] <fantasai> ^TabAtkins shows example with --tolbar-title-theme, which is set to one set of rules on :root, and differently on .warning
# [17:44] <dael> TabAtkins: That's why it's important to use with cascade. It's uing variables for theming and that's cumbersome with variables. This lets you package them up in a way that could obviate how you do something like shadow styling.
# [17:44] <dael> esprehn: Can I use a var in @apply?
# [17:44] * Joins: skk` (~user@public.cloak)
# [17:44] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [17:45] <dael> TabAtkins: No. There's nothing nievely preventing that. It has enough context, but it might involke circularity. This is an early bound variable, it takes the value theme from the root element.
# [17:45] <dael> esprehn: So you don't have to remix the variables.
# [17:45] <dael> TabAtkins: It's just one big custom property.
# [17:45] <dael> TabAtkins: Okay.
# [17:45] <dael> Florian: Try and fix it, it looks useful.
# [17:46] <dael> TabAtkins: Copying hte defaulting of current variables might work. We need to have something where you need to maintain a shape for a style.
# [17:46] <dael> Florian: Some kind of typing where each rule has the same set?
# [17:46] <dael> TabAtkins: Yes.
# [17:46] <dael> Florian: That seems strange and restraining.
# [17:46] <dael> TabAtkins: It might be nonsense too.
# [17:46] <dael> TabAtkins: Right now we can take the custom prop, remove the opening and closing brakcets, and span it out.
# [17:46] * fantasai wonders when the CR of Variables is going to get published
# [17:47] <dael> SimonSapin: If you [missed]
# [17:47] <dael> TabAtkins: That might be. Maybe we can do that. It lets you do the theming. You're namespacing variables in a more compact way.
# [17:47] <dael> TabAtkins: I know that will work, but let's see if we can make less space work.
# [17:47] <dael> shane: If that will work can you specify all.
# [17:48] <dael> TabAtkins: If your custom prop isn't valid, you'd lose all of them. You'd get unset for everything.
# [17:48] <dael> SimonSapin: So don't forget your speciificity.
# [17:48] * Joins: Chris_Lilley (clilley@public.cloak)
# [17:48] <dael> shane: Wouldn't be ba able to add another toolbar?
# [17:48] <dael> TabAtkins: If your specificity is okay, yes.
# [17:49] <dael> TabAtkins: Another issue, here in the CSSOM. Modifying CSS styles OM to allow @rules, we can't just do what I said because CSS grouping rule. UNless we decide that it doesn't matter and it's at the end, which I don't like. We need a different way of representing it.
# [17:49] <dael> Florian: And the declaration is aligning?
# [17:50] <dael> TabAtkins: Yes. We need a new way of defining. It's pretty trivial, but it's something we'd have to write.
# [17:52] * Disconnected
# [17:53] * Attempting to rejoin channel #css
# [17:53] * Rejoined channel #css
# [17:53] * Topic is 'F2F Agenda - https://wiki.csswg.org/planning/paris-2015#agenda'
# [17:53] * Set by plinss on Tue Aug 25 11:11:05
# [17:54] <dael> TabAtkins: They're just custom properties. We in the future want late binding vars.
# [17:54] * Joins: paul___irish (~paul___irish@public.cloak)
# [17:54] <dael> leaverou: It would be good if the option is resolved at the time they're used. This would be like mixes and would help authors use mixes.
# [17:54] <dael> TabAtkins: I agree, I'm just going for the simpliest form now.
# [17:54] <Chris_Lilley> s/mixes/mixins/
# [17:54] <Chris_Lilley> s/mixes/mixins/
# [17:54] * Quits: krijnhoetmer (~krijnhoetmer@public.cloak) (Ping timeout: 180 seconds)
# [17:55] <dael> TabAtkins: Okay, sounds pretty good. We know some issues. Assuming we can resolve these issues are people interested?
# [17:55] * Quits: ChrisLilley (clilley@public.cloak) (Ping timeout: 180 seconds)
# [17:55] <dael> leaverou: Can this be nested?
# [17:55] <dael> TabAtkins: Yeah.
# [17:55] <dael> leaverou: And apply rule inside the declaration of the prop.
# [17:55] <dael> TabAtkins: You can use the var itself.
# [17:55] <dael> Florian: That will insert extra.
# [17:55] <dael> TabAtkins: I haven't spec it, but that's the direction.
# [17:56] <dael> Florian: If you have an @aplly inside the custom prop, it doesn't seem poss to make it work.
# [17:56] <dael> dbaron: On the inner you'll get the value of the variable it's getting applied to.
# [17:56] * Quits: BogdanBrinza_css (~bbrinza@public.cloak) (Ping timeout: 180 seconds)
# [17:56] <dael> shane: So maybe applying late would be better.
# [17:56] <dbaron> ... rather than the value where it was declared
# [17:56] <dael> Florian: You need to define it now to make it clear.
# [17:56] <leaverou> s/leaverou: If you use variables in these props are they defined in the scope they're in?/leaverou: If you use variables in these property sets are they resolved from the scope they’re defined in or the scope they’re used in?/
# [17:56] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [17:56] <dael> TabAtkins: My current def is bracket wrapped block of prop, which obviously isn't a real set.
# [17:57] <dael> fantasai: When is variables getting pub as CR?
# [17:57] <dael> dbaron: I thought it was. Did we just resolve to publish and not do it?
# [17:57] <dael> fantasai: Let's put this in a pipeline please.
# [17:57] <dael> TabAtkins: I'll talk with Chris.
# [17:57] <dael> dbaron: We shipped it on the basis of the resolution.
# [17:57] <dael> fantasai: I think that's okay.
# [17:57] <dael> TabAtkins: I'm not changing anything about variables.
# [17:58] <dael> plinss: You can have multi @apply and they don't interact?
# [17:58] <leaverou> s/It would be good if the option is resolved at the time they're used. This would be like mixes and would help authors use mixes./It would be good if variables are resolved where they are used. @apply is already trying to give authors mixins, and this would even give them parameterized mixins/
# [17:58] <dael> TabAtkins: They cascade normally.
# [17:58] <dael> TabAtkins: I should add an example of that.
# [17:58] <dael> zcorpan: Can you use @apply in other @rules?
# [17:58] <dael> TabAtkins: No.
# [17:58] * fantasai answer to dbaron's question was "yes"
# [17:58] <dael> dbaron: I feel lik eyou have previous prop that did some of this?
# [17:59] <dael> TabAtkins: A long time ago I had an @mixin that was someone similar, but a global rules.
# [17:59] <leaverou> s/And apply rule inside the declaration of the prop./I mean @apply rules inside the property set/
# [17:59] <dael> TabAtkins: You couldn't reset based on certain parts of your tree.
# [17:59] <dael> shane: It's also, the same thing happened with global variables that people didn't like.
# [17:59] <dael> dbaron: I think we have recognized that some of these things need to be global.
# [18:00] <dael> TabAtkins: That's what custom MQ are, really. There's use cases for things like that.
# [18:00] * Joins: myakura (~myakura@public.cloak)
# [18:00] <dael> fantasai: You may also consider file-scope stuff. Like selector variables might be a good case for that. Like the chance of you using the same selector variable is different.
# [18:00] * Quits: weinig (~weinig@public.cloak) (weinig)
# [18:00] <dael> TabAtkins: It's the same as style nesting.
# [18:01] <dael> fantasai: There's cases like :matches blah blah and you want to use that as the child.
# [18:01] <dael> TabAtkins: You can do that.
# [18:01] <dael> fantasai: As a subject of the selector.
# [18:01] <dael> TabAtkins: Yes.
# [18:01] * zcorpan only hears "bla bla bla" at this point
# [18:01] <dael> fantasai: I think that requires you to have your styles in a particular configuation.
# [18:01] <dael> fantasai: I might want to have all my sidebars together and not organize it by what I'm styling.
# [18:02] <dael> TabAtkins: That's a good point.
# [18:02] * Quits: BogdanBrinza (~bbrinza@public.cloak) ("")
# [18:02] * MaRakow @apply bla
# [18:02] <leaverou> btw authors are pretty excited about the idea https://twitter.com/leaverou/status/636202346259836928 (15 RTs and 9 faves in a just few minutes)
# [18:02] <dael> TabAtkins: Right now I'm doing global variables in a lot of context specific ways.
# [18:02] * Joins: BogdanBrinza (~bbrinza@public.cloak)
# [18:02] <fantasai> s/all my sidebars together/all my sidebar rules together and all my article rules together and all my front page rules together/
# [18:02] * Parts: BogdanBrinza (~bbrinza@public.cloak)
# [18:02] <dael> TabAtkins: Okay, I'll bring this up to the WG again after fixing these issues.
# [18:02] <fantasai> s/what I'm/which element I'm/
# [18:03] <dael> plinss: Okay, we're adjorned
# [18:03] <leaverou> s/adjorned/adjourned/
# [18:04] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [18:04] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:04] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [18:05] * Quits: rachelandrew (~59cacb34@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [18:05] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [18:05] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:06] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [18:06] * Quits: jihye (~jihye@public.cloak) ("Page closed")
# [18:07] * Joins: Florian (~Florian@public.cloak)
# [18:08] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [18:09] * Joins: Florian (~Florian@public.cloak)
# [18:09] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [18:10] * Quits: skk_ (~skk@public.cloak) (Ping timeout: 180 seconds)
# [18:11] * Quits: Chris_Lilley (clilley@public.cloak) (Ping timeout: 180 seconds)
# [18:12] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:13] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [18:14] * Quits: dael (~dael@public.cloak) ("Page closed")
# [18:14] * heycam is now known as heycam|away
# [18:16] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [18:17] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [18:17] * Quits: hyojin (~hyojin@public.cloak) ("Page closed")
# [18:18] * Quits: tkonno (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [18:19] * Quits: ed_work_ (~ed@public.cloak) (Client closed connection)
# [18:20] * Rossen is now known as Rossen_away
# [18:21] * leaverou is now known as leaverou_away
# [18:22] * Quits: tantek (~tantek@public.cloak) (tantek)
# [18:25] * Joins: weinig (~weinig@public.cloak)
# [18:26] * Joins: Florian (~Florian@public.cloak)
# [18:27] * Joins: tantek (~tantek@public.cloak)
# [18:27] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [18:27] * Joins: Florian (~Florian@public.cloak)
# [18:32] * Joins: skk (~skk@public.cloak)
# [18:32] * Quits: weinig (~weinig@public.cloak) (weinig)
# [18:34] * Joins: weinig (~weinig@public.cloak)
# [18:34] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [18:45] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [18:45] * Joins: skk_ (~skk@public.cloak)
# [18:49] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [18:53] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [18:55] * Joins: antonp1 (~Thunderbird@public.cloak)
# [18:58] * Quits: weinig (~weinig@public.cloak) (weinig)
# [18:59] * Joins: renoirb (renoirb@public.cloak)
# [19:00] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [19:00] * antonp1 is now known as antonp
# [19:13] * Quits: Ms2ger` (~Ms2ger@public.cloak) ("nn")
# [19:23] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [19:23] * plh is now known as plh-away
# [19:30] * Zakim excuses himself; his presence no longer seems to be needed
# [19:30] * Parts: Zakim (zakim@public.cloak)
# [19:30] * Joins: tantek (~tantek@public.cloak)
# [19:47] * Joins: myles (~Adium@public.cloak)
# [20:00] * Quits: skk_ (~skk@public.cloak) (Ping timeout: 180 seconds)
# [20:29] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [20:47] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:02] * Quits: tantek (~tantek@public.cloak) (tantek)
# [21:06] * Quits: nvdbleek (~nvdbleek@public.cloak) (Client closed connection)
# [21:10] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [21:10] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [21:11] * Joins: myakura (~myakura@public.cloak)
# [21:16] * Quits: nvdbleek (~nvdbleek@public.cloak) (Client closed connection)
# [21:16] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [21:29] * Joins: johanneswilm (~johannes@public.cloak)
# [21:33] * Joins: skk (~skk@public.cloak)
# [21:38] * Joins: Florian (~Florian@public.cloak)
# [21:38] * Quits: nvdbleek (~nvdbleek@public.cloak) (Ping timeout: 180 seconds)
# [21:58] * Quits: darktears (~darktears@public.cloak) ("Leaving...")
# [21:59] * Joins: darktears (~darktears@public.cloak)
# [22:00] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [22:00] * Joins: Florian (~Florian@public.cloak)
# [22:05] * Joins: Florian_ (~Florian@public.cloak)
# [22:07] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [22:13] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
# [22:13] * Joins: Florian (~Florian@public.cloak)
# [22:20] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [22:23] * Joins: Florian (~Florian@public.cloak)
# [22:33] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [22:33] * Joins: Florian (~Florian@public.cloak)
# [22:34] * Joins: Florian_ (~Florian@public.cloak)
# [22:40] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [22:45] * Quits: plh-away (plehegar@public.cloak) ("Leaving")
# [23:00] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [23:12] * Joins: dauwhe (~dauwhe@public.cloak)
# [23:12] * Joins: tantek (~tantek@public.cloak)
# [23:22] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
# [23:22] * leaverou_away is now known as leaverou
# [23:23] * Quits: tantek (~tantek@public.cloak) (tantek)
# [23:24] * Joins: Florian (~Florian@public.cloak)
# [23:26] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [23:26] * Joins: tantek (~tantek@public.cloak)
# [23:26] * Joins: Florian (~Florian@public.cloak)
# [23:28] * Quits: renoirb (renoirb@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [23:30] * Joins: Florian_ (~Florian@public.cloak)
# [23:33] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [23:34] * Joins: tkonno (~chatzilla@public.cloak)
# [23:34] * Joins: dbaron (~dbaron@public.cloak)
# [23:37] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
# [23:42] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [23:42] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [23:45] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [23:45] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [23:45] * Joins: zcorpan (~zcorpan@public.cloak)
# [23:52] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [23:56] * Quits: tkonno (~chatzilla@public.cloak) (Client closed connection)
# [23:59] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# Session Close: Wed Aug 26 00:00:00 2015

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn