/irc-logs / w3c / #css / 2014-10-27 / end

Options:

# Session Start: Mon Oct 27 00:00:00 2014
# Session Ident: #css
# [00:19] * Joins: dwim (~dwim@public.cloak)
# [00:20] * Quits: ArronEi (~ArronEi@public.cloak) (Ping timeout: 180 seconds)
# [01:00] * Joins: jdaggett (~jdaggett@public.cloak)
# [01:44] * Joins: kangil (~kangil@public.cloak)
# [01:51] * Joins: arronei (~arronei@public.cloak)
# [01:59] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [02:05] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [04:03] * Joins: jdaggett_ (~jdaggett@public.cloak)
# [04:07] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [04:07] * jdaggett_ is now known as jdaggett
# [04:12] * Joins: dbaron (~dbaron@public.cloak)
# [05:45] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [06:53] * Joins: liam (liam@public.cloak)
# [07:31] * Joins: dauwhe (~dauwhe@public.cloak)
# [07:36] <dauwhe> Is there a general TPAC channel on IRC?
# [07:59] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [07:59] * Joins: dauwhe (~dauwhe@public.cloak)
# [07:59] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [08:30] * Joins: dauwhe (~dauwhe@public.cloak)
# [08:31] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:41] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [09:01] * Joins: bobtung (~bobbytung@public.cloak)
# [09:05] * Joins: rego (~smuxi@public.cloak)
# [09:05] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [09:18] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [09:24] * Joins: dauwhe (~dauwhe@public.cloak)
# [09:32] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [10:19] * Joins: dauwhe (~dauwhe@public.cloak)
# [10:21] * Quits: Ms2ger (~Ms2ger@public.cloak) ("bbl")
# [10:26] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [11:03] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [11:11] * Joins: lajava (~javi@public.cloak)
# [11:13] * Joins: dauwhe (~dauwhe@public.cloak)
# [11:17] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [11:20] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [12:07] * Joins: dauwhe (~dauwhe@public.cloak)
# [12:12] * Joins: darktears (~darktears@public.cloak)
# [12:14] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [12:15] * Quits: tommyjtl (~tommyjtl@public.cloak) (Client closed connection)
# [12:15] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [12:22] * Quits: tommyjtl (~tommyjtl@public.cloak) (Ping timeout: 180 seconds)
# [12:23] * Joins: antonp (~Thunderbird@public.cloak)
# [12:36] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [12:39] * Joins: antonp (~Thunderbird@public.cloak)
# [12:40] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [13:01] * Joins: dauwhe (~dauwhe@public.cloak)
# [13:06] * Joins: antonp1 (~Thunderbird@public.cloak)
# [13:08] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [13:08] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [13:10] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [13:13] * Quits: tommyjtl (~tommyjtl@public.cloak) ("brb")
# [13:15] * Joins: antonp (~Thunderbird@public.cloak)
# [13:15] * Quits: antonp1 (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [13:24] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [13:55] * Joins: dauwhe (~dauwhe@public.cloak)
# [14:02] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [14:05] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [14:36] * Joins: dauwhe (~dauwhe@public.cloak)
# [14:36] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [14:36] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [14:44] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [14:47] * Joins: dauwhe (~dauwhe@public.cloak)
# [14:50] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [14:54] * Joins: lajava (~javi@public.cloak)
# [15:10] * Joins: dauwhe (~dauwhe@public.cloak)
# [15:22] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [15:33] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [15:35] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [15:46] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [15:50] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [15:51] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [15:54] * Joins: rbyers (~sid31141@public.cloak)
# [15:58] * Quits: zcorpan_ (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [16:04] * Joins: dauwhe (~dauwhe@public.cloak)
# [16:10] * Joins: ArronEi (~ArronEi@public.cloak)
# [16:11] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [16:19] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [16:29] * Joins: dael (~dael@public.cloak)
# [16:30] * Joins: Hiroto (~Hiroto@public.cloak)
# [16:35] * Joins: Cyril (~chatzilla@public.cloak)
# [16:36] * Joins: smfr (~smfr@public.cloak)
# [16:36] * Quits: Hiroto (~Hiroto@public.cloak) ("Page closed")
# [16:37] * Joins: Hiroto (~Hiroto@public.cloak)
# [16:42] * Joins: nsakai2 (~nsakai2@public.cloak)
# [16:43] * Joins: glazou (~glazou@public.cloak)
# [16:43] <glazou> test
# [16:43] <glazou> test again
# [16:45] * Joins: smfr_ (~smfr@public.cloak)
# [16:47] * Joins: yamamoto (~yamamoto@public.cloak)
# [16:47] * Joins: vollick (~vollick@public.cloak)
# [16:48] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [16:48] * smfr_ is now known as smfr
# [16:48] * Joins: liam (liam@public.cloak)
# [16:49] * Joins: jrossi (~jrossi@public.cloak)
# [16:49] * Joins: andreyr (~andreyr@public.cloak)
# [16:49] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:49] * Joins: MaRakow (~MaRakow@public.cloak)
# [16:50] * Joins: dino (~textual@public.cloak)
# [16:51] * Joins: bobtung (~bobbytung@public.cloak)
# [16:52] * Joins: murakami (~murakami@public.cloak)
# [16:53] * Joins: Hyojin (~Hyojin@public.cloak)
# [16:53] * Joins: bradk (~bradk@public.cloak)
# [16:55] * Joins: bradk_ (~bradk@public.cloak)
# [16:56] * Parts: bradk (~bradk@public.cloak) (bradk)
# [16:56] * smfr changes topic to 'https://wiki.csswg.org/planning/tpac-2014#proposed-topics'
# [16:57] * Parts: bradk_ (~bradk@public.cloak) (Be back later ...)
# [16:57] * Joins: bradk_ (~bradk@public.cloak)
# [16:57] * Parts: bradk_ (~bradk@public.cloak) (Be back later ...)
# [16:58] * Joins: babatakao (~babatakao@public.cloak)
# [16:59] * Joins: bradk (~bradk@public.cloak)
# [16:59] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
# [16:59] * Joins: florian (~Florian@public.cloak)
# [16:59] * Joins: glenn (~gadams@public.cloak)
# [17:00] * Joins: hiroshi (~hiroshi@public.cloak)
# [17:00] * Joins: bradk (~bradk@public.cloak)
# [17:01] * Joins: Hyojin_ (~Hyojin@public.cloak)
# [17:01] * Joins: SteveZ (~SteveZ@public.cloak)
# [17:03] * Joins: hiroshi_ (~hiroshi@public.cloak)
# [17:03] * Joins: jet (~junglecode@public.cloak)
# [17:04] * Joins: hiroshi2 (~user@public.cloak)
# [17:04] * Quits: Hyojin (~Hyojin@public.cloak) (Ping timeout: 180 seconds)
# [17:04] * leaverou_away is now known as leaverou
# [17:04] * Joins: myakura (~myakura@public.cloak)
# [17:04] * Joins: plh (plehegar@public.cloak)
# [17:04] * Joins: iank (~iank@public.cloak)
# [17:05] * Parts: jet (~junglecode@public.cloak) (jet)
# [17:05] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [17:06] * Joins: kurosawa (~chatzilla@public.cloak)
# [17:06] * Parts: iank (~iank@public.cloak)
# [17:06] <dael> glazou: Let's start. Welcome to the first day of TPAC. As usualy we'll address the agenda first.
# [17:06] * Joins: iank_ (~iank@public.cloak)
# [17:06] <dael> glazou: We dont have too much, but there are time constraints.
# [17:07] * Joins: KeshavP (~KeshavP@public.cloak)
# [17:07] <dael> glazou: plinss and I will disappear from time to time. For tomorrow we need to go to lunch at 1pm and not before. It's a special lunch.
# [17:07] * Quits: hiroshi (~hiroshi@public.cloak) (Ping timeout: 180 seconds)
# [17:07] <dael> glazou: Apart from that, welcome!
# [17:08] <dael> [intros]
# [17:09] <gregwhitworth> Greg Whitworth, Microsoft
# [17:09] <iank_> Ian Kilpatrick, Google
# [17:09] <vollick> Ian Vollick, Google
# [17:09] <astearns> Alan Stearns, Adobe
# [17:09] <dauwhe> Dave Cramer, Hachette Livre
# [17:09] <krit> Dirk Schulze, Adobe
# [17:09] <zcorpan_> Simon Pieters, Opera Software
# [17:09] <rbyers> Rick Byers, Google
# [17:09] <bobtung> Bobby Tung, invited expert
# [17:09] <hiroshi2> Hiroshi Sakakibara, BPS,Japan
# [17:09] <Bert> Bert Bos, W3C
# [17:09] <SteveZ> Steve Zilles, Adobe Systems
# [17:09] <ArronEi> Arron Eicholz, Invited Expert
# [17:09] <glazou> Daniel Glazman (Disruptive Innovations, Co-chair)
# [17:09] <dino> Dean Jackson, Apple
# [17:09] <florian> Florian Rivoal, Invited Expert
# [17:09] <fantasai> Elika Etemad aka fantasai, Invited Expert
# [17:09] <MaRakow> Matt Rakow, Microsoft
# [17:09] <jrossi> Jacob Rossi, Microsoft
# [17:09] <yamamoto> Kazutaka Yamamoto, NTT
# [17:09] <KeshavP> Keshav Puttaswamy, Microsoft
# [17:09] <bradk> Brad Kemper, Invited Expert
# [17:09] <babatakao> Takao Baba, BPS
# [17:09] <andreyr> Andrey Rybka, Bloomberg
# [17:09] <nsakai2> Narumichi Sakai, Toshiba
# [17:09] * Joins: shans__ (~shans@public.cloak)
# [17:09] <shans__> Shane Stephens, Google
# [17:09] <SimonSapin> Simon Sapin, Mozilla
# [17:09] <smfr> Simon Fraser, Apple
# [17:09] * zcorpan_ is now known as zcorpan
# [17:09] <murakami> Shinyu Murakami, Vivliostyle/AntennaHouse
# [17:10] <plinss> Peter Linss, HP
# [17:10] * fantasai dael, this should also give you all the IRC auto-completing nicknames :)
# [17:10] <glazou> https://wiki.csswg.org/planning/tpac-2014#proposed-topics
# [17:10] * Joins: r12a (rishida@public.cloak)
# [17:10] * dael fantasai, thanks
# [17:10] * Joins: alant (~alant@public.cloak)
# [17:10] <r12a> Richard Ishida, W3C
# [17:11] <alant> Alan Turransky, IAB
# [17:11] * Joins: AH_Miller (~mike@public.cloak)
# [17:11] <leaverou> Lea Verou, Invited Expert
# [17:11] * Joins: anssik (~uid10742@public.cloak)
# [17:11] <dael> glazou: Any time constraints for people?
# [17:11] <AH_Miller> Michael Miller, Antenna House
# [17:11] <dael> krit: Some of the topics are with joint meeting.
# [17:12] * Joins: koji (~koji@public.cloak)
# [17:12] <dael> glazou: We have an e-mail from sylvaing__ saying... (something about time he can call)
# [17:13] <dael> [agenda wrangling continues]
# [17:14] * Joins: murakami_ (~murakami_@public.cloak)
# [17:14] <dael> glazou: Start with Media Queries?
# [17:15] * TabAtkins told plinss that I'll be on late this morning. 10ish
# [17:15] * TabAtkins had to pick up his rental car for the week.
# [17:15] * krit glazou FX meeting Thursday afternoon starting at 14.00
# [17:16] <dael> florian: CSS3 ui, ::selection?
# [17:16] <dael> Topic: CSS3 UI
# [17:16] <dael> florian: I was looking at this doc that's been stagnating
# [17:17] * Joins: adenilson (~anonymous@public.cloak)
# [17:17] * Joins: RSheeter (~RSheeter@public.cloak)
# [17:17] <dael> fantasai: I propose adding florian as editor.
# [17:17] <dael> rossen: That's what happens when you look at document.
# [17:17] <dael> glazou: tantek used to be editor. Did you ping him?
# [17:17] * Joins: kuettel (~kuettel@public.cloak)
# [17:17] <dael> florian: Nope.
# [17:17] <dael> fantasai: He's not around.
# [17:17] * Joins: nyshadh (~nyshadh@public.cloak)
# [17:18] <dael> glazou: No, he's not, but you should let him know. Learning about it from a resolution isn't good.
# [17:18] <dael> glazou: So no obj?
# [17:18] <dael> RESOLVED: Add florian as editor to CSS3 UI
# [17:18] <dael> florian: I'll dive in deeper, but while we're on it there is a bunch of things about pseudo classes that are all in selectors.
# [17:19] <dael> florian: I don't think they should stay, they're better speced elsewhere. Can we remove dup?
# [17:19] <dael> SteveZ: What's the status of them?
# [17:19] <dael> florian: Some are in 3, but all are in 4.
# [17:19] <dael> SteveZ: What's your expectation for progress? The main reason we stick things is in for progress.
# [17:19] <dael> florian: It makes sense elsewhere.
# [17:19] * Joins: Rossen_ (~Rossen@public.cloak)
# [17:19] <dael> SteveZ: But it's for progression. It make sense in selectors, but if you need things to progress they should stay.
# [17:20] <glazou> RRSAgent, make logs public
# [17:20] <RRSAgent> I have made the request, glazou
# [17:20] * Joins: Zakim (zakim@public.cloak)
# [17:20] <dael> fantasai: If CSS UI was close to CR it would make sense to leave it, but I can't tell what would make it to CR first. They both need cleanup.
# [17:20] <dael> SteveZ: So based on that, pull them out and you can put them back if nec.
# [17:20] <dael> fantasai: And they're already in selectors.
# [17:20] <dael> glazou: So the last on TR is from 2012.
# [17:20] * Joins: grieger (~grieger@public.cloak)
# [17:21] <dael> florian: The ED is more recent, but needs to be cleaned before pub.
# [17:21] <dael> florian: For pseudo the selectors text is newer.
# [17:21] <dael> florian: While we're in selectors, there's also pseudo-elements in the spec. They seem reasonable, but doesn't seem to have interest. Anyone care about what to do with them?
# [17:21] <dael> fantasai: What are they>
# [17:22] * Joins: bkardell_ (~uid10373@public.cloak)
# [17:22] <dael> florian: Value shoices, repeat item, repeat index.
# [17:22] <dael> fantasai: If there's no impl we should drop.
# [17:22] <dael> Bert: It's hard to find impl info b/c it's not in browsers. I think Steven Pemberton is here and we can ask him.
# [17:22] <dael> florian: That's my feeling. It's prob not something used, but it's not inheretly wrong.
# [17:22] <dael> action Bert find Steven Pemberton and ask him about impl
# [17:22] * trackbot is creating a new ACTION.
# [17:22] <trackbot> Created ACTION-656 - Find steven pemberton and ask him about impl [on Bert Bos - due 2014-11-03].
# [17:23] <dael> fantasai: If there's none we should drop.
# [17:23] <dael> florian: We also have a content prop extension. The value is icon and lets you use icon which is to an image and lets you use that instead of having it be a child.
# [17:23] <dael> florian: Right now it's dec as applying to pseudo and elements, but as far as I know it's not web compat for the content prop to apply.
# [17:24] <dael> fantasai: We have impl in print world. It stays and we need to figure out web compat.
# [17:24] <dael> florian: And why is it called icon?
# [17:24] <dael> fantasai: Idea is that it allows you to associate something that represents that element.
# [17:24] * Joins: shepazu (schepers@public.cloak)
# [17:24] <dael> florian: The ability to have a replaced element. That's reasonably nice. That images normally used on content aren't replaced make it hard to style.
# [17:25] <dael> fantasai: This wasn't intended to solve that use case.
# [17:25] <dael> dauwhe: Should ew omve to generated content?
# [17:25] <dael> fantasai: Does anyone use icon?
# [17:25] <dael> fantasai: So we say this was a nice idea and we'll put it in the list of CSS4 ideas. I'm surprised it's still there.
# [17:25] <dauwhe> s/ew omve/this move/
# [17:25] <dael> florian: It's marked as at risk.
# [17:26] <dael> florian: About text-overflow, there's prob a lot of issues. Superfisially it references CSS3 marquee. It prob shouldn't. Don't know if we need resolution. Also when you use two value variant which lets you decide overflow at beginning and end
# [17:26] <andreyr> http://www.w3.org/TR/css3-ui/#text-overflow
# [17:26] <dael> florian: Currently it says left and right, should we change to beginning and end?
# [17:27] <dael> Rossen_: Should be start and end.
# [17:27] <dael> florian: Prob. start and end, yes.
# [17:27] <dael> glazou: Basic support is impl. 2 value syntax is only FF and we don't have dbaron i the room. I'd love to hear from dbaron.
# [17:27] <dael> florian: Sounds fair.
# [17:27] <dael> glazou: But in theory we should do that.
# [17:28] <dael> glazou: We do have consensus. It could be resolved, but he should be here and h's late.
# [17:28] <dael> florian: There will be much more to come, but for this morning we're good.
# [17:28] <dael> smfr: There's many cases where it's (outlne) is for drawing boxes.
# [17:29] <dael> florian: I think it belongs here.
# [17:29] <dael> fantasai: tantek leans toward objecting to a new co-editor.
# [17:29] <smfr> smfr: I think box-sizing nad text-overflow do not belong on this spec
# [17:29] <dael> glazou: There are no updates in 11 months and we need to make progress so we'll drop it. I'd rather add florian.
# [17:29] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [17:29] <dael> glazou: Do you know where he is?
# [17:29] * Joins: adenilson (~anonymous@public.cloak)
# [17:29] <dael> fantasai: I don't.
# [17:30] <dael> glazou: Can you ask him to pay us a visit?
# [17:30] <dael> fantasai: Yes.
# [17:30] <dael> Bert: Can we go back to text overflow? Where did you see left/right/start/end?
# [17:30] <dael> florian: It says left/right.
# [17:30] <dael> Bert: Where? It jsut says elipsis.
# [17:30] * Joins: lajava (~javi@public.cloak)
# [17:30] <dael> plinss: It uses both terminologies.
# [17:30] <dael> Bert: Ah, got it.
# [17:31] <dael> plinss: It's inconsistant. t's bad.
# [17:31] <dael> s/t's/It's
# [17:31] <dael> glazou: I have a question. The resize property...at leasst 2 browsers don't impl it. Opera is listed as not impl because presto. IE, are you planning to impl?
# [17:32] <dael> Rossen_: I think it's on our backlog. It's under consideration.
# [17:32] <dael> florian: It's not objected to?
# [17:32] <dael> Rossen_: I don't think so, nope.
# [17:32] <dael> glazou: Anything else on CSS3 UI?
# [17:32] <dael> florian: Not for now.
# [17:32] <dael> glazou: You're palnning new stuff?
# [17:32] <dael> florian: Starting with a cleanup.
# [17:32] * Joins: tantek (~tantek@public.cloak)
# [17:32] <dael> fantasai: tantek says if florian wants to help he can start on the wiki.
# [17:33] <dael> glazou: I think the group had consensus from the group because we think it'll be more productive to have him. I suggest we stick to our decision. Is that okay for everyone?
# [17:33] * dauwhe is there an objection to the objection to the objection?
# [17:33] <dael> [silence]
# [17:34] <dael> glazou: Okay. We have consensus -1. It's a good consensus.
# [17:34] * bkardell_ likes the idea of specs that fit on twitter
# [17:34] <dael> smfr: To come back to resize, what was the suggestion?
# [17:34] <dael> glazou: I was jsut asking if IE would impl.
# [17:34] <smfr> s/smfr/krit
# [17:35] <dael> Topic: ::selection
# [17:35] <tantek> good morning - I'm co-chairing the #social WG today and tomorrow but will be on IRC here too
# [17:35] <dael> fantasai: Okay. Let me get the spec.
# [17:35] * krit jealous about my british accent?
# [17:36] * krit smfr—^
# [17:36] <tantek> ::selection latest info is in CSS3-UI issues wiki page
# [17:36] <fantasai> http://dev.w3.org/csswg/css-pseudo
# [17:36] <tantek> https://wiki.csswg.org/spec/css3-ui#issue-30
# [17:36] <fantasai> for the minutes https://dvcs.w3.org/hg/csswg/raw-file/9591381784e1/css-pseudo/Overview.html
# [17:36] <tantek> still awaiting tests to answer questions raised in http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
# [17:36] <tantek> until we have those tests, it doesn't make sense to try again with a spec
# [17:37] <dael> fantasai: We have dbaron's e-mail. Let's project the spec.
# [17:37] <fantasai> dbaron's requirements were:
# [17:37] <fantasai> 1. selection style shouldn't vary on least common ancestor
# [17:37] <dael> fantasai: His requirements were 1) selection style shouldn't vary on greatest/least common ancestor
# [17:37] <fantasai> 2. default selection style should be representable by UA rules
# [17:37] <dael> fantasai: [types them in IRC]
# [17:37] <fantasai> 3. Authors should override systems default style
# [17:37] * Joins: estellevw (~estellewyel@public.cloak)
# [17:38] <tantek> please capture any conclusions regarding ::selection in this CSS3UI issue: https://wiki.csswg.org/spec/css3-ui#issue-30 - I'll read changes there afterwards - can't follow line-by-line here in IRC right now.
# [17:38] <fantasai> 4. bg color and text color always cover original color
# [17:38] <fantasai> 5. authors can change within a particular element
# [17:38] * Joins: glazou_ (~glazou_@public.cloak)
# [17:38] <dael> fantasai: I did some browser testing. I don't think we can solve the problem in #2
# [17:38] <dael> fantasai: I'll go through and we can talk about individual issues.
# [17:39] <dael> fantasai: First 2 are we want to add other types of selection ie spelling errors.
# [17:39] <dael> fantasai: 2nd is we don't have a way of distinguishing active and inactive selectors
# [17:39] <dael> fantasai: I'll skip 3 for now.
# [17:39] <dael> ??: What is inactive
# [17:39] <dael> fantasai: When the window is inactive.
# [17:40] <dael> fantasai: Issue 5 is which prop are here. I think just color and background color
# [17:40] <dael> leaverou: text shadow.
# [17:40] <dael> fantasai: I'll add that.
# [17:40] <dael> action fantasai Add text-shadow
# [17:40] * trackbot is creating a new ACTION.
# [17:40] <trackbot> Created ACTION-657 - Add text-shadow [on Elika Etemad - due 2014-11-03].
# [17:40] <astearns> s/??/bkardell/
# [17:40] <dael> fantasai: Anything else we should be considering?
# [17:40] <dael> glazou: caret from CSS3 UI?
# [17:40] <dael> fantasai: Okay.
# [17:40] <leaverou> glazou: this caret? http://lists.w3.org/Archives/Public/www-style/2011Nov/0772.html
# [17:40] <dael> bkardell_: Would opacity make sense?
# [17:41] <dael> fantasai: That would add stacking, but we can use RGBA
# [17:41] <dael> glazou: We don't have caret yet, but it will be prop at some point in future.
# [17:41] <dael> fantasai: So caret color and text shadow. Anything else? Def not layout stuff
# [17:41] <dael> ??: Maybe an issues link so we can open bugs in spec?
# [17:42] <glazou> s/??/adenilson
# [17:42] <dael> fantasai: Yes, I think an issues list makese sense.
# [17:42] <dael> adenilson: I jsut found a typo.
# [17:42] <fantasai> fantasai: point to Tantek's wiki
# [17:42] <dael> richard: Do we have to worry about arabic joins being broken
# [17:42] <dael> fantasai: Anything written here needs to handle discontinuity.
# [17:43] <dael> glazou: Is your idea to discuss how middle will be traded. Some systmes that's the case.
# [17:43] <tantek> fantasai - it's not "my wiki" - it's the CSS3UI issues list on the CSSWG wiki
# [17:43] <dael> richard: And I ould guess CSS is a level above that.
# [17:44] <dael> smfr: Webkit allows you to style text-emphasis with the color and text fill color.
# [17:45] <dael> fantasai: The next issue is right now in impl if you don't spec a color than text actual is used and no background is transparent. If you don't spec either you get system default. That means you can't have a default UA that rep system color, it needs to be some kind of magic.
# [17:45] <dael> fantasai: Seems like everyone represents it that way.
# [17:45] <dael> fantasai: Blink webkit and presto seem to do that. If IE doesn't it's possible to change things for req. #2. But that's where we're at.
# [17:46] <dael> fantasai: If we did change it we might be able to use current-color keyword so that behaviour is representable. I think compat might be an issue here.
# [17:46] <dael> fantasai: It seems Z index and selection color is right over everything else, but under positions things. That prob needs a bit more testing.
# [17:47] <dael> fantasai: It seems impl redraw text decorations over the shadow. I think if you're selecting text you should just see text. if you spec decorations you should see those. That the color being opaque doesn't hide text decorations seems wierd to me.
# [17:47] <dael> fantasai: What do others think?
# [17:48] <dael> SimonSapin: Does it look bad to redraw shadows/decorations?
# [17:48] <dael> fantasai: It does since they maintain org color.
# [17:48] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3E%3Cu%3Eselect%20me%3C%2Fu%3E
# [17:48] <dael> fantasai: Let me give you a test case.
# [17:48] <dael> fantasai: Black text w/ underline. Select it text becomes white, line stays.
# [17:48] <SimonSapin> s/SimonSapin/zcorpan/ (Simon Pieters)
# [17:48] <dael> fantasai: When you have decorations it might obscure text and make it hard to read. Other people might have a diff perspective.
# [17:49] * Quits: murakami_ (~murakami_@public.cloak) (Ping timeout: 180 seconds)
# [17:49] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22font-size%3A%20200%25%3B%20text-shadow%3A%20red%203px%203px%203px%22%3E%3Cu%3Eselect%20me%3C%2Fu%3E
# [17:49] <dael> fantasai: This one has text shadow
# [17:49] <dael> fantasai: The coloring changes and text flattens to the two colors, but the text decoations are wild.
# [17:49] <dael> smfr: This isn't how webkit works on a mac.
# [17:50] <dael> fantasai: I noticed, but no one else does that.
# [17:50] <dael> Bert: FF on mac is the same.
# [17:50] <dael> fantasai: If you do an alpha thing on top, showing through makes sense.
# [17:50] <dael> fantasai: Linux it's repainted on top of that background.
# [17:50] <Bert> 4x
# [17:50] <dael> Rossen_: What do you prop?
# [17:51] <dael> fantasai: The background color of the selection obscures text decorations as if it's painted on top. So you draw the selection BG color over the text and repaint the text.
# [17:51] <dael> Rossen_: So you'd have shadows bleed behind the selection?
# [17:51] <dael> fantasai: If your selection color is opaque you don't see shadows.
# [17:51] <dael> Rossen_: And if it extends beyond?
# [17:51] <dael> fantasai: You'd see it beyond.
# [17:51] * Bert that wasn't me. I don't remember who said it, though :-(
# [17:52] <astearns> s/Bert/astearns/
# [17:52] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [17:52] <dael> fantasai: If you have a red blurry shadow on your text and you select it, the section becomes the default colors. I feel either you shouldn't see the colors or it should be a color that belongs to the text selection.
# [17:53] <dael> Rossen_: I think most of the...our selection is highly optimized to be as cheap as poss for render so we don't reblend most of the things that we do for other types of changes when we do selection
# [17:53] <dael> Rossen_: If this is something we need to worry about today I'm not sure.
# [17:53] <dael> Rossen_: Historically our selection was just the selection BG witht he text and that's it.
# [17:53] <bkardell_> maybe it would be good to show visual representations of these rather than verbal descriptions... I think it should be like this picture, not this one.
# [17:53] <dael> fantasai: I'll look at what you did.
# [17:54] <dael> fantasai: So. Next thing is for what I tested does a semi-transparent wash over what you've selected. FF and I think Opera just uses default selection color. Webkit uses same color as selection BG. But if it's transparent you can't tell the replaced item is selected.
# [17:54] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [17:55] <dael> fantasai: I took what they did. For non replaced conent the UA should honor, but for replaced they should do a wash and if it's transparent you should use the color to create the wash.
# [17:55] <dael> fantasai: Replaced can be foreground or background or a mix. I think it's better if you don't have a color you can tell what's selected and you're in the same color scheme.
# [17:55] <dael> fantasai: I'll take comments on that. If you don't like it we can use system color. I don't know.
# [17:56] * Joins: Guest (~textual@public.cloak)
# [17:56] * fantasai wonders where dbaron is
# [17:56] * Guest is now known as notbenjamin
# [17:56] <dael> zcorpan: If you spec where the BG should be painted and it doesn't match the platform, that seems wierd.
# [17:57] <dael> fantasai: We do require that...I have to say something about where you're drawing. I say you have to cover the text and may do more.
# [17:57] <dael> fantasai: I have a min set of requrements as to what you cover which is the m-box of all the text, but you can do more than that.
# [17:57] <dael> fantasai: If we need looser wording a can do that, but having a guideline makes sense.
# [17:58] <adenilson> fantasai: look at your left.
# [17:58] <dael> fantasai: So let's go back to dbaron's issue now that he's here.
# [17:59] * Joins: jcraig (~jcraig@public.cloak)
# [17:59] <dael> fantasai: There were 3 solutions to dbaron's req. First was each element is it's own ::selection and if you style them all they paint on top of eachother. Prob is if you have bg color with alpha they start to stack as you get deep into tree.
# [17:59] <dael> fantasai: No one impl and it's bad.
# [18:00] <dael> fantasai: Second two options were the selectable area of each element belongs to innermost element. What happens if you have two elements styling the same thing? If you have rules doing both how do you sort between the two?
# [18:00] * Joins: dbaron (~dbaron@public.cloak)
# [18:01] <dael> fantasai: Browsers do solution B. Check the tree depth as most important to decide color. Downside is if you style ::selection and than p::selection if you have a p with a span, t would have ::selection style b/c it applies to all the elements.
# [18:01] <dael> fantasai: We wanted the default style represented...It wold have to be :root::selection to get correct. It seems where I tested (and I didn't do IE) all followed B. So it's not incompat and it's easier.
# [18:01] <dbaron> I presume the email you're talking about is http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
# [18:02] <dael> glazou: I'm confused. You have a p with a span inside. You said you don't need the p::selection
# [18:02] <dael> fantasai: Because it's shorthand. They both get the ::selection. p has a more spec rule, but the span has its own rule and that wins within the span.
# [18:02] * dbaron RRSAgent, pointer?
# [18:02] * RRSAgent See http://www.w3.org/2014/10/27-css-irc#T17-02-29
# [18:02] <dael> glazou: Why is that?
# [18:03] <dael> fantasai: It was confusing to some people. When this was written witht he various solutions, was there a way to have ::selection not have strange behaviour. This is consistant and we have interop on standard behaviour. So casscade by depth than specificity.
# [18:03] <jcraig> why not just change the selector to "p::selection, p *::selection"
# [18:03] <dael> dbaron: Do browsers match the details of option B? Specificity stuff?
# [18:04] <dael> fantasai: Yes. I think so
# [18:04] <dael> fantasai: Let me double check.
# [18:04] <dael> fantasai: I did the testing yesterday.
# [18:04] <dael> dbaron: I guess. Okay. I believe that. C was the crazy thing.
# [18:04] <dael> fantasai: We seem to have interop on B. I think that's what we should go with.
# [18:05] <dael> fantasai: Trying to desc B is hard. Anyone interested should read it and tell me if there's a better way.
# [18:05] <dael> fantasai: One req was sys colors should be rep as a UA. Right now if you don't set color or BG, we treat BG as transparent and we don't fall back to default.
# [18:05] <dael> dbaron: Is that introp?
# [18:05] <dael> fantasai: On many, but I haven't tested IE.
# [18:05] <dael> dbaron: b/c that sounds weird.
# [18:06] <dael> fantasai: If IE doest aht we prob can't change it.
# [18:06] <fantasai> s/can't/can/
# [18:06] <fantasai> er
# [18:06] <fantasai> s/can/can't/
# [18:06] <dael> s/doest aht/does that
# [18:06] <fantasai> fantasai: But if it doesn't do that, then we're saved and we can fix that
# [18:07] <dael> fantasai: I think that's an overview of all the issues.
# [18:07] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [18:07] * dbaron apologizes for lateness. My 6am alarm decided to make light but not sound and I woke up at 6:19am, didn't get out of my apartment until just before 8am, and then spent 1 hour and 53 minutes on the road (on a route google maps said was 1 hour 14 minutes with traffic 10 minutes or so before I left, though I had to stop for gas). Ugh.
# [18:07] <dael> fantasai: Oh, one more. Each element draws it's own portion of the highlight. When multi conflict, the winning belongs to innermost after cascade.
# [18:08] <dael> fantasai: What do we want inheret to inheret from. So one option was to inheret from the original. The other is ::selection pseudo inheret through own trait.
# [18:08] <dael> fantasai: If you want to unset things, we have an unset keyword so that's poss.
# [18:08] <astearns> s/inheret/inherit/
# [18:08] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [18:08] <dael> dbaron: That would need to be defined pretty carefully for background inherit
# [18:09] <dael> fantasai: Yeah. Now that I think about it color has to inherit through ::selection tree. Initial behaviour is inherit. What is the value if it's not...
# [18:09] * Joins: plh (plehegar@public.cloak)
# [18:09] <dael> dbaron: You could deifne them as not having inheritance and just cascade.
# [18:09] * Quits: tantek (~tantek@public.cloak) (tantek)
# [18:10] <dael> dbaron: Or with B with cascade by tree depth as lonng as it happens before inheitence you don't have to worry if you say tree depth is part of cascading process. Then it's moot.
# [18:10] <dael> fantasai: Right. Okay...
# [18:10] <dael> fantasai: I guess the q is which sounds worse. Making tree depth a cascading thing or having inheritence through ::selection tree.
# [18:10] <dael> dbaron: I don't know and you can prob distinguish through testing which is worth doing.
# [18:11] <dael> fantasai: I know. I have implementations for both, basically.
# [18:11] <dael> dbaron: If there's impl for both I don't have a strong opinion.
# [18:11] <dael> fantasai: I'll oke around with IE. I don't have any testing on that yet.
# [18:11] <dael> s/oke/poke
# [18:12] <dael> glazou: So are we done?
# [18:12] * Quits: grieger (~grieger@public.cloak) (Ping timeout: 180 seconds)
# [18:12] <dael> fantasai: I think that's all the issues.
# [18:12] <dael> glazou: Before we move on, I suggest we do the first coffe break.
# [18:12] <dael> fantasai: We could do pseudo spec overall
# [18:12] <dael> fantasai: I bikeshedded the whole spec, I cleaned the first style bits. There was a CSS OM section that I haven't deleted. I didn't know of the WG wanted it there.
# [18:13] <dael> glazou: I don't know if it makes sense if you removed multi before/after.
# [18:13] <dael> astearns: Some of it does not.
# [18:13] <dael> glazou: I can take an action to review.
# [18:13] <dael> action glazou review pseudo spec based on edits.
# [18:13] * trackbot is creating a new ACTION.
# [18:13] <trackbot> Created ACTION-658 - Review pseudo spec based on edits. [on Daniel Glazman - due 2014-11-03].
# [18:14] <dael> glazou: Anything else?
# [18:14] <dael> [15 minute break]
# [18:14] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [18:14] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [18:14] * Quits: smfr (~smfr@public.cloak) (smfr)
# [18:14] * Quits: bradk (~bradk@public.cloak) ("Be back later ...")
# [18:14] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [18:15] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [18:15] * Joins: bradk (~bradk@public.cloak)
# [18:16] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [18:17] * Joins: emalasky (~Adium@public.cloak)
# [18:17] * Quits: kuettel (~kuettel@public.cloak) (Ping timeout: 180 seconds)
# [18:18] * Joins: tantek (~tantek@public.cloak)
# [18:20] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [18:20] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [18:20] * Quits: iank_ (~iank@public.cloak) (Ping timeout: 180 seconds)
# [18:20] * Quits: RSheeter (~RSheeter@public.cloak) (Ping timeout: 180 seconds)
# [18:20] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [18:20] * Quits: babatakao (~babatakao@public.cloak) (Ping timeout: 180 seconds)
# [18:21] * Quits: nsakai2 (~nsakai2@public.cloak) (Ping timeout: 180 seconds)
# [18:21] * Joins: babatakao (~babatakao@public.cloak)
# [18:21] * Quits: hiroshi_ (~hiroshi@public.cloak) (Ping timeout: 180 seconds)
# [18:21] * Quits: dael (~dael@public.cloak) (Ping timeout: 180 seconds)
# [18:21] * Quits: hiroshi2 (~user@public.cloak) (Ping timeout: 180 seconds)
# [18:22] * Quits: bradk (~bradk@public.cloak) (Ping timeout: 180 seconds)
# [18:23] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [18:24] * Joins: dael (~dael@public.cloak)
# [18:24] * sylvaing__ wonders where the call info is....
# [18:24] <dael> ScribeNick: dael
# [18:25] * Joins: smfr (~smfr@public.cloak)
# [18:25] * Quits: nyshadh (~nyshadh@public.cloak) (Ping timeout: 180 seconds)
# [18:25] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [18:25] * dael sylvaing__ We're on a break, but we didn't have anyone on the phone earlier so I don't think it's set up yet.
# [18:25] * Joins: bradk (~bradk@public.cloak)
# [18:25] * sylvaing__ dael, check.
# [18:25] * Joins: jcraig (~jcraig@public.cloak)
# [18:26] * Joins: tantek (~tantek@public.cloak)
# [18:26] * Quits: bradk (~bradk@public.cloak) (Client closed connection)
# [18:27] * Joins: bradk (~bradk@public.cloak)
# [18:27] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [18:27] * plinss for call in, use Zakim
# [18:27] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [18:28] * plinss have zakim call the room “SantaBarbara”
# [18:30] * Joins: jet (~junglecode@public.cloak)
# [18:30] * Joins: jcraig_ (~jcraig@public.cloak)
# [18:30] * Quits: notbenjamin (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [18:31] * Joins: tantek_ (~tantek@public.cloak)
# [18:32] * Quits: jet (~junglecode@public.cloak) (jet)
# [18:33] * Quits: jcraig (~jcraig@public.cloak) (Ping timeout: 180 seconds)
# [18:33] * jcraig_ is now known as jcraig
# [18:33] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [18:33] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [18:33] * tantek_ is now known as tantek
# [18:33] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [18:34] * Joins: bradk_ (~bradk@public.cloak)
# [18:34] * Joins: darktears (~darktears@public.cloak)
# [18:37] <plinss> zakim, this is style
# [18:37] <Zakim> sorry, plinss, I do not see a conference named 'style' in progress or scheduled at this time
# [18:38] * Quits: bradk (~bradk@public.cloak) (Ping timeout: 180 seconds)
# [18:38] * Joins: bobtung (~bobbytung@public.cloak)
# [18:38] <bradk_> huh
# [18:39] * Quits: bradk_ (~bradk@public.cloak) ("Lingo: www.lingoirc.com")
# [18:40] * Joins: bradk (~bradk@public.cloak)
# [18:40] <sylvaing__> Zakim, room for 1?
# [18:40] <Zakim> sylvaing__, 1 port isn't enough; you must want to talk with at least one other person
# [18:40] <sylvaing__> Zakim, room for 2?
# [18:40] <Zakim> ok, sylvaing__; conference Team_(css)17:40Z scheduled with code 26631 (CONF1) for 60 minutes until 1840Z
# [18:40] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [18:41] <Zakim> Team_(css)17:40Z has now started
# [18:41] <Zakim> +SGalineau
# [18:41] <sylvaing__> Zakim, call SantaBarbara
# [18:41] <Zakim> ok, sylvaing__; the call is being made
# [18:41] <Zakim> +SantaBarbara
# [18:41] * Joins: nsakai2 (~nsakai2@public.cloak)
# [18:42] * Joins: iank (~iank@public.cloak)
# [18:44] <dael> glazou_: Lets start again
# [18:44] * Joins: florian (~Florian@public.cloak)
# [18:44] * Joins: andreyr (~andreyr@public.cloak)
# [18:44] <dael> glazou_: sylvaing__ are you on?
# [18:44] <dael> sylvaing__: I am.
# [18:45] <dael> glazou_: Since you're on the call, I suggest we do Animations
# [18:45] <dael> Topic: Animations
# [18:45] * Joins: vollick (~vollick@public.cloak)
# [18:45] <dael> sylvaing__: Let me paste the issue
# [18:45] <sylvaing__> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14788
# [18:45] * Joins: Rossen_ (~Rossen@public.cloak)
# [18:45] * Joins: shans__ (~shans@public.cloak)
# [18:45] * Joins: hiroshi2 (~user@public.cloak)
# [18:46] * Joins: hiroshi (~hiroshi@public.cloak)
# [18:46] * Joins: lajava (~javi@public.cloak)
# [18:46] <dael> sylvaing__: The question was, we have 3 issues let. In this one if you do a findRule can you use a comma sep list. Today the answer is not really. Most browsers don't
# [18:46] * Joins: murakami (~murakami@public.cloak)
# [18:47] <dael> sylvaing__: You need to be able to do it. Some rules will be comma sep. So if a rule is 25%, 40% there is no notion of if you want the rule for each. You'll only get a rule that has both keys. It attempts to match the whole string
# [18:47] * Joins: notbenjamin (~textual@public.cloak)
# [18:47] * Joins: SteveZ (~SteveZ@public.cloak)
# [18:47] <dael> sylvaing__: The org question was if you can get more than one rule by patching in multi values.
# [18:47] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [18:47] * Quits: notbenjamin (~textual@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [18:47] * Joins: notbenjamin (~textual@public.cloak)
# [18:47] <dael> glazou_: My problem wth finding only on complete key is that you need to have access to all the keys and parse them for individual values if you have two inside a key. that will be tricky for Animation editors
# [18:48] <dael> glazou_: I'd rather have findRule work on indi keys. That leaves an issue for deleteRule
# [18:48] * Joins: adenilson (~anonymous@public.cloak)
# [18:48] <dael> sylvaing__: Right now...it's not super hard, it is extra work.
# [18:48] <dael> sylvaing__: The bigger question is if you...you want multiple rules to come back, right?
# [18:49] <dael> sylvaing__: Meaning you don't expect just the selector to be sep items. You expect to be able to delete/find more than one. That's a bigger challange.
# [18:49] <dael> glazou_: Everything comes from that we want to delete a rule. The old works on indexes. THe new OM there is a way to delete based on a rule itself.
# [18:49] <dael> TabAtkins: I don't know.
# [18:50] <dael> glazou_: It was a suggestion. That way you can find the rule, check if it's made of the individual key, and then either delete or change the individual key you found.
# [18:50] <dael> glazou_: That's simplier. Different, but better.
# [18:50] <dael> sylvaing__: Right now you find/delete by selector and it's not super friendly.
# [18:51] <dael> TabAtkins: I kinda probose we figure out hte reasonable, compat bahaviour, spec that, say it's depricated, and make methods that don't suck.
# [18:51] <dael> glazou_: I agree if browsers impl.
# [18:51] <dael> sylvaing__: There's an intermediate possibility. You can add the ability to get a list of all the keys. You can get them all and do find, find, find.
# [18:52] <dael> sylvaing__: The other rule...nevermind.
# [18:52] <dael> glazou_: You still need to browse the keyframes, split from the comma, and trim. We could add that.
# [18:52] <dael> TabAtkins: Yes.
# [18:52] <dael> glazou_: So that's getKeys on the keyframes rule
# [18:52] <dael> TabAtkins: Or have a forward attr.
# [18:52] <dael> sylvaing__: You have that with CSS Rules
# [18:53] <dael> TabAtkins: We could have a sep one that gives you a list or array and make the existing one a put forwards of that.
# [18:53] <glazou> DOMTokenList ?
# [18:53] <dael> sylvaing__: So saying you have a rule 25%, 50% and you get did key. Now if you do delete 25%, do we fail or do we suceed and it's there with only 50%
# [18:53] <dael> glazou: I suggest second
# [18:53] <dael> sylvaing__: I wondered about browser vendors.
# [18:53] <dael> TabAtkins: That's what I'd want
# [18:53] * Joins: iank_ (~iank@public.cloak)
# [18:54] <dael> glazou: If we don't spec that way, authors will do it themselves
# [18:54] <dael> sylvaing__: There's a bunch of issues. If yu have a selector with multi values, if you can delete with only one value, you should be able to find the same way.
# [18:54] * Parts: hiroshi2 (~user@public.cloak) (ERC Version 5.3 (IRC client for Emacs))
# [18:55] <dael> sylvaing__: You'd have to give findRule 25%, 50% to get it. I think we should find it with just 25%. Once we go down the road of providing all the keys as an array and giving people access to rules, we get to a point of redoing the API.
# [18:55] <dael> TabAtkins: That's what I said.
# [18:55] <dael> glazou: But depricating doesn't work and these things will stick forever and be used forever. Depricate is only in our vocab, not users.
# [18:56] <dael> TabAtkins: People respond to deprication when writing tutorials. The don't do it with copy/paste. That's why it's not remove.
# [18:56] <dael> florian: It means we have a better thing to use.
# [18:56] <astearns> s/depric/deprec/
# [18:56] <dael> glazou: If we depricate findRule, what will be the name
# [18:56] <dael> TabAtkins: findRules
# [18:56] <shans__> findRuleEx
# [18:57] <TabAtkins> findRuleBis
# [18:57] <dael> TabAtkins: or find-Rule
# [18:57] <dael> dbaron: I think we want them more different. I'm also happy with just doc what they do and design better.
# [18:57] <dael> glazou: Okay. Is everyone okay with that strategy?
# [18:57] <dael> shans__: So will someone work out with the browsers?
# [18:58] <dael> glazou: So there's two steps.
# [18:58] <dael> glazou: sylvaing__ will you document existing behaviour?
# [18:58] <dael> sylvaing__: Yeah.
# [18:58] <dael> glazou: What about the second. The next version that's better.
# [18:58] <leaverou> s/depricating/deprecating/
# [18:58] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [18:58] <dael> sylvaing__: To be clear, the first step is describing existing in level 1 and doing better in level 2 or something else?
# [18:58] <dael> glazou: What you said.
# [18:59] <dael> sylvaing__: Can we resolve in lvl 1 we describe the current behaviour.
# [18:59] * Joins: hiroshi2 (~user@public.cloak)
# [18:59] <dael> shans__: And we hope the browsers are doing it the same. Even if we document we hope someone will change. I don't know if they are.
# [18:59] <dael> ??: I think does that lets us know where our issues are.
# [18:59] <shans__> s/shans__/dino/
# [19:00] <dael> glazou: Will you make a note that it will change?
# [19:00] <dael> sylvaing__: Yeah, I think we decided to do that last week.
# [19:00] <dael> glazou: I can help
# [19:00] <dael> TabAtkins: I can help too
# [19:00] <gregwhitworth> s/??/gregwhitworth
# [19:00] <dael> RESOLVED: lvl 1 we describe the current behaviour
# [19:00] <dael> sylvaing__: The next one....
# [19:00] <sylvaing__> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25035
# [19:01] <dael> sylvaing__: The question here is, if we append a rule with an existing key, what should happen?
# [19:01] <dael> TabAtkins: Can you just append it. Goes to the end?
# [19:02] <dael> sylvaing__: I think glazou thought it would update existing, but we can redo that. Have more than one rule witht he key and append at the end, recascade and recompute.
# [19:02] * Quits: KeshavP (~KeshavP@public.cloak) ("Page closed")
# [19:02] <dael> sylvaing__: This one is for clairification. I think to follow the existing API it just adds at the bottom. I believe that's what browsers do.
# [19:02] * Joins: KeshavP (~KeshavP@public.cloak)
# [19:02] <dael> glazou: To be clear, I have not pref, I just want it defined.
# [19:02] <dael> sylvaing__: Yeah.
# [19:03] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [19:03] <dael> sylvaing__: So any objections to making append rule always add at the end of the keyframe no matter if the key is existing?
# [19:03] <dael> TabAtkins: As long as that's consistent.
# [19:04] <dael> RESOLVED: making append rule always add at the end of the keyframe no matter if the key is existing
# [19:04] <TabAtkins> s/consistent/consistent with implementations/
# [19:04] <sylvaing__> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25670
# [19:04] * Quits: estellevw (~estellewyel@public.cloak) (estellevw)
# [19:04] * Quits: bradk (~bradk@public.cloak) ("Be back later ...")
# [19:04] <dael> sylvaing__: Last one is about making the CSS keyframes rule inherit from grouping rule. It sounds like yes for next version from the discussion we've had.
# [19:04] * Joins: bradk (~bradk@public.cloak)
# [19:04] <dael> TabAtkins: I'm fine with making the change in spec now, but I'm not really bothered about it.
# [19:05] <dael> sylvaing__: I can't image it would bug anyone. Would it?
# [19:05] * Quits: bradk (~bradk@public.cloak) (Client closed connection)
# [19:05] <dael> dbaron: One issue is they both have a deleteRule method.
# [19:05] * Joins: bradk (~bradk@public.cloak)
# [19:05] <dael> sylvaing__: Ah yes. It wouldn't be so clear. once we inherit we're chaning the API. I think it's good to move to the next version.
# [19:05] <dael> dbaron: I don't know if that will be webcompat.
# [19:05] * Quits: bradk (~bradk@public.cloak) (Client closed connection)
# [19:05] <dael> sylvaing__: CSS Grouping is recent.
# [19:06] <dael> dbaron: The problem would be changing keyframes rule's deleteRule method.
# [19:06] * smfr deleteRule(DOMString key); vs deleteRule (unsigned long index);
# [19:06] * Joins: bradk (~bradk@public.cloak)
# [19:06] <dael> sylvaing__: I'm hearing this won't happen for a little while?
# [19:06] <dael> glazou: Everyone agrees?
# [19:06] <dael> RESOLVED: no change for now
# [19:06] <dael> sylvaing__: Than we have resolution on all issues.
# [19:06] * Quits: bradk (~bradk@public.cloak) (Client closed connection)
# [19:07] * Joins: bradk (~bradk@public.cloak)
# [19:07] <dael> sylvaing__: Next step is I'll edit this week and then there's the one from Sophia that I need you all to figure out. once that's done we can do LC.
# [19:07] <dael> glazou: Is that all for animations?
# [19:07] * Quits: AH_Miller (~mike@public.cloak) (Ping timeout: 180 seconds)
# [19:07] <dael> sylvaing__: That was the only 3 issues left.
# [19:07] <dael> glazou: There was a bullet on the wiki about Animations lvl 4.
# [19:08] <dael> dino: That was to discuss the proposal. That's additive and cumulative Animation. Maybe tomorrow for Brian.
# [19:08] <dael> glazou: Can you attend tomorrow sylvaing__ ?
# [19:08] <dael> sylvaing__: 11 to 3 is good.
# [19:09] <dael> dino: There's a bunch of scrolling stuff. Even if that's animations we can wait for Brian.
# [19:09] <dael> ??: Theres a bunch of other people who want to attend.
# [19:09] <dael> dino: It would go for more than an hour.
# [19:09] <dael> glazou: Tomorrow 11am?
# [19:09] <dael> dino: We break at 1 tomorrow?
# [19:09] <dael> glazou: Yes. sylvaing__ good for you?
# [19:09] <dael> sylvaing__: Yes.
# [19:10] <dael> dbaron: Does that overlap AC?
# [19:10] <dael> glazou: I don't think so.
# [19:10] <dael> glazou: We hve a problem. AC meeting is between 11 and 3. It means a bunch of people won't be here.
# [19:11] <dael> sylvaing__: That's okay. There may be background noise. Afternoon is better for me.
# [19:11] * Joins: estellevw (~estellewyel@public.cloak)
# [19:11] <dael> dino: The new animation suggestion is not level 1.
# [19:11] <dael> sylvaing__: If you think it can happen, it can. It can happen...I can do it before 11, but there will be noise.
# [19:11] <dael> dino: And do you want to listen into scrolling stuff. I'm sure dbaron does.
# [19:11] <dael> TabAtkins: Can you link your e-mails on the wiki?
# [19:11] <dael> dino: Yes.
# [19:11] <dael> glazou: So tomorrow.
# [19:12] * smfr changes topic to 'https://wiki.csswg.org/planning/tpac-2014#agenda'
# [19:12] <dael> glazou: Prob. after 3. After AC meeting.
# [19:12] <dael> glazou: That closes Animation.
# [19:12] <dael> glazou: Can we do layout this afternoon and MQ now?
# [19:12] <dael> Topic: Media Queries
# [19:12] * Quits: Hiroto (~Hiroto@public.cloak) (Ping timeout: 180 seconds)
# [19:12] <dael> florian: First has been discussed before, but not concluded.
# [19:13] <dael> florian: One is miscrosoft high contrast extension. THe other is ink saving mode while printing
# [19:13] <dael> florian: Both inform about an intent. There is a request from the user. It doesn't jsut indicate a request, it indicates that something has been done to the page.
# [19:14] * Joins: plh (plehegar@public.cloak)
# [19:14] <dael> florian: I think in general the right thing to do is nothing. Browser has adjusted. Sometimes the author can say I know how to respond. You need to be aware the user has requested and have to be able to say that the browser shouldn't do it's thing, I have magic to do.
# [19:14] <dael> florian: This property lets you say don't do the magic, I have a better solution.
# [19:14] * Joins: andreyr (~andreyr@public.cloak)
# [19:14] <dael> florian: Microsoft has high-contrast with auto and none. If you say none you can do your thing.
# [19:14] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [19:15] <dael> glazou: So the UA can override platform settings.
# [19:15] <jcraig> q+ to mention that the microsoft proposal is very specific to Microsoft's implementation and does not account for OS X and iOS
# [19:15] * Zakim sees jcraig on the speaker queue
# [19:15] <dael> smfr: I don't think that's doable on all
# [19:15] <dael> TabAtkins: It's per type of feature.
# [19:15] <dael> florian: There's another disucssion about type of high contrast. This is the thing that modifies.
# [19:15] <glazou> Zakim, ack jcraig
# [19:15] <Zakim> jcraig, you wanted to mention that the microsoft proposal is very specific to Microsoft's implementation and does not account for OS X and iOS
# [19:15] <Zakim> I see no one on the speaker queue
# [19:16] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [19:16] <dael> jcraig: I think you're thinking about the old increase contrast. On iOS8 and 10 there's things that allow changes of colors. It's a lot more subtile.
# [19:16] <dael> florian: Microsoft's is more subtile.
# [19:16] <dael> jcraig: It's not because this is more nuanced. It doesn't drop to bianary.
# [19:17] <dael> florian: Even though you know the UA is adjusting to make higher contrast, you don't know how. The only way to respond is do nothing or turn of auto adjustment. Trying to overlay won't work nicely.
# [19:17] <dael> jcraig: WE have some idea. I'm not saying it's a bad idea, but they need to be extending to account for more platform differences. Or reconcilled so we can check on bg/foreground.
# [19:18] <dael> jcraig: I like don't adjust for this value. But I think it should be don't adjust background or something specific.
# [19:18] <dael> florian: You want to do spec properties?
# [19:18] <dael> jcraig: I was thinking more specific things. That's the major problem with Microsofts where it removed background images and we've seem a lot of problems.
# [19:19] <dael> TabAtkins: I was talking with James about OSX10's accessibility and it's impressive.
# [19:19] <jcraig> s/check on bg/foreground./check for user bg/foreground colors./
# [19:19] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [19:19] <dael> TabAtkins: I think we should basically find the union of these things, more or less. It's not huge, and spec a big block of a11y media quiries. Some are I'm requesting someting, some of them are I'm doing something to you. Some of them are a per-element, others are pix level.
# [19:19] * Joins: dbaron (~dbaron@public.cloak)
# [19:20] <dael> TabAtkins: I think we should sit down with these and set some meaningful conventions. We should then come to the group with a solid proposal in a month.
# [19:20] <dael> florian: And if you do this at prop level saying I've done this to you, do we still want a rop to disable.
# [19:20] <jcraig> q+ to mention some of the other features
# [19:20] * Zakim sees jcraig on the speaker queue
# [19:20] <dael> TabAtkins: Generally you'll need one to disable the adjustment. Mac has one to adjust to "not quite as white"
# [19:21] <dael> TabAtkins: So it's har dot hit everything there.
# [19:21] <dael> florian: So you're agreeing witht eh general attention, but what more specific
# [19:21] <dauwhe> s/quiries/queries/
# [19:21] <dael> TabAtkins: And I want to spend time with a systematic proposals
# [19:21] * Joins: myakura (~myakura@public.cloak)
# [19:22] <dael> jcraig: We have reduce motion setting, a setting to turn off transparancy. These are things we wouldn't override, but if a page can detect and adjust automatically.
# [19:22] <glazou> Zakim, ack jcraig
# [19:22] <Zakim> jcraig, you wanted to mention some of the other features
# [19:22] <Zakim> I see no one on the speaker queue
# [19:22] <dael> jcraig: Some of the others are....increased contrast and that's more of a preference to allow the webpage to know the user prefers that.
# [19:22] <dael> TabAtkins: There's enough things around I want to spend time, but your direction is the right way.
# [19:22] <dael> TabAtkins: Do people think it's okay to spend time on this?
# [19:23] <dael> fantasai: I think looking together is a good idea.
# [19:23] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [19:23] <dael> florian: The one problem is these are a11y only instead of being general features as well as general use
# [19:23] <jcraig> q?
# [19:23] * Zakim sees no one on the speaker queue
# [19:23] <jcraig> q+ to address the "accessibility only" comment
# [19:23] * Zakim sees jcraig on the speaker queue
# [19:23] <dael> glazou: On some mobiles you have power saving mode. My comment earlier was if the user settings on the mobile say power saving and the style sheet can override that, that's an issue.
# [19:24] <dael> glazou: It's contrary to what the user wants.
# [19:24] <dael> TabAtkins: If it's pixel level you can't override. If it isn't, aps today can respond or not. An app can do it so I think it's reasonable.
# [19:24] * dauwhe looking forward to a CSS parser that tells you your design sucks, or that your power-saving mode is a power hog
# [19:25] * glazou dauwhe AH!
# [19:25] <dael> florian: There's a dangerius aspect. You could have someone just make the screen blink because they hate animation reduction
# [19:25] <sylvaing__> dauwhe in Soviet Russia, CSS parses you
# [19:25] <dauwhe> s/dangerius/dangerous/
# [19:25] * glazou sylvaing in Soviet Russia, nobody hears you parse CSS
# [19:26] <dael> jcraig: There will always be people that use things maniputively. We've found when we added features, they were moved out of a11y only features. The powersaving could also reduce motion. They're not a11y spec. There's overlap.
# [19:26] <Bert> (Luckily, you can always turn CSS off.)
# [19:26] * glazou Bert only when JS is disabled :-p
# [19:26] <dael> jcraig: If you make them a11y specific, you can make them specific to the feature and they get used more widely.
# [19:26] * astearns we need !!important for rules you can't turn off
# [19:26] <dael> TabAtkins: I think a lot can be cast in a more general way than pure a11y. They may not be super general, but okay.
# [19:26] * Joins: florian (~Florian@public.cloak)
# [19:27] <dael> florian: I think that's cool.
# [19:27] <dael> glazou: The prop wa to review all a11y features.
# [19:27] <dael> florian: and the intent is something along what i prop earlier.
# [19:27] * sylvaing__ there is something magical about the co-creator of CSS saying 'Luckily, we can turn it off'
# [19:27] <dael> RESOLVED: review all a11y related issues to come up with a broad proposal
# [19:28] * glazou sylvaing and that’s not napoleonian
# [19:28] <dael> florian: Another topic, there was a req for scroll-position MQ and I don't think we can do that because it's layout specific.
# [19:28] <dael> florian: It's clearly interesting to do things style related, but I don't believe MQ is the right mech.
# [19:28] <dael> TabAtkins: I think the right one is attached to animation behaviour dino was talking about.
# [19:28] * dauwhe sylvaing__: you left out a word before "magical" @JonyIveParody
# [19:28] <dael> florian: Yes. I'd like to resolve to reject that.
# [19:29] <dael> TabAtkins: Even if you said selector, the same obj apply. Like a media class.
# [19:29] <dael> RESOLVED: Reject scroll-position MQ
# [19:29] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [19:29] * sylvaing__ dauwhe: :)
# [19:30] <jcraig> s/There will always be people that use things maniputively./There will always be people that use things maliciously; thankfully most people don't./
# [19:30] <dael> florian: We have a couple things about overflow-inline and over-flow block. We're trying to break the types into essential features. One type about print is that you're on a page. Inline-direction and block-direction tends to be different
# [19:30] * Joins: hiroto__ (~hiroto@public.cloak)
# [19:30] <dael> florian: A printer will page in the block direction. But there are times it will go the other way. But before that we had a question about what is it you overflow in this context.
# [19:31] <dael> florian: We concluded that what it was is the icb if you're in a scroll and the paged media if you're in paged media. There's no word for either of these. Is this the right object and, if so, what's it called?
# [19:31] * Joins: abinader (~sid21713@public.cloak)
# [19:31] <dael> TabAtkins: So naming suggestions for something more generic than icb or paged area.
# [19:31] <dael> fantasai: Wait...what?
# [19:32] <dael> TabAtkins: The thing that when you overflow causes pages to wrap. On printed it's the page area. You'll overflow to new pages.
# [19:32] <dael> fantasai: So on the first page, they're the same.
# [19:32] <dael> fantasai: You're a MQ so you don't know what page you're on.
# [19:32] <jcraig> s/We've found when we added features, they were moved out of a11y only features. The powersaving could also reduce motion. They're not a11y spec. There's overlap./We've found when we added features to the accessibility sections, they gained popularity in the mainstream user base, so over time we moved them out of the a11y-specific section (for example, bold fonts and large text). A power-saving mode could also change the reduce motion MF or the washed/dimmed MF.
# [19:32] <jcraig> They're not all accessibility-specific. There's overlap.
# [19:32] <dael> TabAtkins: This is the general strategy.
# [19:32] <dael> fantasai: I'm having a hard time because I don't have context.
# [19:33] <dael> TabAtkins: We need a name for the thing that when you're larger than it causes overflow.
# [19:33] <jcraig> s/MF or the washed/MF or the washed or dimmed MF. They're not all accessibility-specific. There's overlap./
# [19:33] <dael> Bert: Is it fragmentainer?
# [19:33] <dael> Rossen_: no. Not nec.
# [19:33] <dael> fantasai: Send me a link to the paragraph where you need this term.
# [19:33] <smfr> http://dev.w3.org/csswg/mediaqueries-4/#mf-overflow-block
# [19:33] <TabAtkins> http://dev.w3.org/csswg/mediaqueries/#mf-overflow-block
# [19:33] <dael> florian: Away from naming and back to what it is.
# [19:33] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [19:34] <dael> florian: When you overflow that thing in inline and block direction, it causes different things.
# [19:34] * Joins: plh (plehegar@public.cloak)
# [19:34] <dael> florian: If you think of a matrix printer if you overflow inline. Or a unix termal. They all have variations. The set of values that rep what can happen in inline is different then the block direction
# [19:34] <jcraig> s/I like don't adjust for this value. But I think it should be don't adjust background or something specific./I like the "don't adjust for this value" proposal, but I think it should be property level: e.g. don't remove background-image./
# [19:34] <dael> florian: If you overflow in inline you scroll or clip. There's a case for tiling too.
# [19:35] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [19:35] <dael> florian: To be able to do the tiling you need to know where the pages are physically. That only happens in inline direction. Maybe block. Inline doesn't have regular paging.
# [19:35] <dael> florian: Regular pagination can't happen in inline.
# [19:35] * Joins: jeff (jeff@public.cloak)
# [19:35] <dael> florian: Given that they're different, it brings us to having two names.
# [19:36] <jcraig> s/We have reduce motion setting, a setting to turn off transparancy. These are things we wouldn't override, but if a page can detect and adjust automatically./We have reduce motion setting, a setting to turn off transparancy, and a "differentiate without color" setting. These are things we wouldn't override mechanically in the UA, but if a page author can adjust for a preferred rendering, they should be able to detect that preference./
# [19:36] <dael> florian: If you change the block direction in your stylesheet, the meaning of the two inverts. Either you need to do a special thing where you resolve the writing mode in this MQ, or you put the same set of values on both axises
# [19:36] <dael> fantasai: Another option...if you haev a thing you can turn like a piece of paper you can turn it.
# [19:37] <dael> florian: I think you've made this arguement before, but can you expand?
# [19:37] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [19:37] * Joins: jeff_ (jeff@public.cloak)
# [19:37] <dael> fantasai: If you have a thing that's turnable, you can say the overflow block is paged etc and if the author makes a doc that changes the writing mode, you turn it so that page/screen is landscape and keep the same behaviour
# [19:38] <dael> fantasai: For writing mode when you change it you want to do it anyways. You'll want to be paging in the block direction
# [19:38] <dael> florian: a reciept printer scroll suntil you ask for a cut. You can't turn because it only prints in one way. The page can't turn.
# [19:38] <dael> fantasai: If the root element is set to be veritical and it's sent to a reciept printer, you want veritical in the short dimension.
# [19:38] <jcraig> s/It's not because this is more nuanced. It doesn't drop to bianary./Sorry, I meant "subtle" in that OS X and iOS settings "increase" contrast by more sublte amounts, while Microsoft's rendering change most colors to 100% black or 100% white./
# [19:38] <dael> florian: And once it's printed you turn it.
# [19:39] <dael> fantasai: That's the way screens behave. If you set veritical, the block scrolling goes off the screen. For paging also we will def page in the block direction for the root.
# [19:39] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [19:39] <dael> Rossen_: I think it's still worth figuring out when do you tile and not.
# [19:40] <dael> florian: Since it's a MW it's not telling the UA to do anything, it's just figuring out what it is. If it's tiling you don't lose content, if it's clipped you lose content.
# [19:40] <Bert> s/veritical/vertical/g
# [19:40] <dael> astearns: One of your options was have th same options in both. I think when dbaron brought up and issue about a table...
# [19:40] <dael> florian: I don't think it would be the same. You need to know how the pages will layout next to eachother and that's not regular pagination. It's pagination-ish, but not the same.
# [19:41] <astearns> d/dbaron/dauwhe/
# [19:41] <dael> dauwhe: I'm not conviced there isn't a req for pagination in the inline direction. We have books with massive foldouts. You have a range of content going out to the side.
# [19:42] <dael> florian: There's a few sets where it's straightforward and we should have values for those now. The types we need to handle a case like that needs two axises.
# [19:42] <dael> fantasai: WE have the concept of spreads and that needs to get into CSS.
# [19:42] * Joins: jcraig (~jcraig@public.cloak)
# [19:42] <dael> florian: I agree and this needs to respond once we figure out spreads.
# [19:42] <dael> fantasai: It might be you have to tile two pages.
# [19:42] <dael> florian: Is it tiling, is it a big page...?
# [19:42] <dael> TabAtkins: This is why we don't want to address it yet.
# [19:42] * Joins: Shige_ (~Shige@public.cloak)
# [19:43] * Quits: jeff (jeff@public.cloak) (Ping timeout: 180 seconds)
# [19:43] <dael> florian: I don't think this is incompt with the end result for spreads, but if you disagree that's fine
# [19:44] <dael> SteveZ: I'm confused by the dauwhe example. i need a clear example between pagination and tiling. pagination to me is dependant on how much fits in the block. TO me tiling is taking whatever is in the overflow direction and generating paes to hold that.
# [19:44] <dael> SteveZ: There's two ways to do that. THere's what you want for tables which is layout in a bigger space and chop it into chunks. A second way would be I don't do that for overflows and I repaginate the content in the overflow. I don't know how that would create a usable result
# [19:44] <glazou> s/paes/pages
# [19:44] <dael> dauwhe: I was thinking of a case with hundreds of digits of pi where you want to maintain it.
# [19:45] <dael> fantasai: You don't want to slice the middle of the word.
# [19:45] <dael> florian: There's where do you cut and what do you do with the bit that has been cut.
# [19:45] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [19:45] <dael> SteveZ: So it's already layed out, you're just picking out a chunk.
# [19:45] <dael> florian: So with tiling the bit you're picking out would want to appear in a specific place.
# [19:46] <dael> fantasai: For pagination you have a centered block, it should be centered on the next page.
# [19:46] <dael> florian: But that's because that's how you styled it.
# [19:46] <dael> Bert: Think of a float, it has the same width on both pages if they both have the same width
# [19:46] <dael> astearns: The distinction is pagination finds a break opportunity. In inline it could be a character boundry. That's what makes it sound paginated to me
# [19:47] <dael> fantasai: The layout of the contents creates the division. For tiling nothing changes and you just have a bigger thing.
# [19:47] <dael> florian: And you may want to be smart about where you slice.
# [19:47] <dael> fantasai: You don't want to cur tiling. You deally want to cut at a column. Tiling is we ran out of rooma nd if you tape these things together it looks right
# [19:48] <dael> SteveZ: Is this like a spread case where you need to be more specific in how you handle it. I don't think we have anything written about this.
# [19:48] * Quits: glazou_ (~glazou_@public.cloak) ("Page closed")
# [19:48] <dael> fantasai: We have things that clip and scroll int he inline direction. Tiling might be an option, but it's not impl and so we should work on how it fits into spreads.
# [19:48] * Quits: koji (~koji@public.cloak) ("Leaving...")
# [19:49] <dael> florian: So as we expand pagination specs you can then use this MQ and extend it to match the different modes. Right now inline has clip and scroll.
# [19:49] * sylvaing__ is now known as sgalineau
# [19:49] * Joins: adenilson (~anonymous@public.cloak)
# [19:49] <dael> florian: That's where I propose to start. Thank you for helping me understand the rotation. I think we need to figure out the name, but the spec can stay as-is elsewise.
# [19:49] <fantasai> s/cur tiling/cut tables/
# [19:50] <dael> dauwhe: One terminology question. Since one of theo verflow use -x, -y, do we want to have that?
# [19:50] <dael> florian: We're conflating two issues. If it's -x you're saying do the block direction. I think for this we can ignore, but for overflow-x/-y I think it's unfortunate.
# [19:50] <dael> fantasai: I think they're physical. I think we're stuck.
# [19:51] <dael> florian: Are they still used?
# [19:51] <dael> Bert: Yes. They've been used a long time.
# [19:51] * Quits: notbenjamin (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [19:51] * Joins: florian (~Florian@public.cloak)
# [19:51] <dael> florian: Other than the termonology, we want to keep the spec as-is?
# [19:51] * Quits: estellevw (~estellewyel@public.cloak) (estellevw)
# [19:51] <dael> fantasai: That seems to be where we're at.
# [19:51] * sgalineau NEXT: overflow-z
# [19:51] <dael> dauwhe: I'm fine with terminology as-is.
# [19:52] <dael> florian: Now we says overflows the initial containing block and it should add or the paged area if you have one?
# [19:52] <dael> dauwhe: We've used all the good words.
# [19:52] * Quits: alant (~alant@public.cloak) ("Page closed")
# [19:52] <dael> TabAtkins: Initial page-taining block.
# [19:52] <dael> fantasai: I'm not sure about the problem, so I can take a look.
# [19:52] * glazou inipagetainer anyone ?
# [19:52] <dael> florian: If you're in a paged thing, the initial containing block isn't the paged area.
# [19:52] <dael> fantasai: It is.
# [19:53] <dael> TabAtkins: If youre paged size changes in the document.
# [19:53] <dael> florian: Ignore me.
# [19:53] * dauwhe initial document area?
# [19:53] <dael> RESOLVED: The media features overflow-inline and overflow-block are fine as they are. No change.
# [19:53] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [19:53] <dael> florian: So we have custom media queries. Do you want that one TabAtkins?
# [19:54] * bkardell_ resolved: do nothing .. I like it
# [19:54] <dael> TabAtkins: I don't recall what we need to do except I need to finish the spec.
# [19:54] <dael> florian: WE can discuss what's called issue 4.
# [19:54] <florian> http://dev.w3.org/csswg/mediaqueries4/#script-custom-mq
# [19:54] <dael> TabAtkins: This would be easier if the spec was on the screen.
# [19:54] * Joins: alant (~alant@public.cloak)
# [19:55] * Quits: alant (~alant@public.cloak) ("Page closed")
# [19:55] <dael> TabAtkins: Ignore that some of those use underscores, we changed tat
# [19:55] <dael> TabAtkins: We already discussed custom media being aliased. If you want custom MQ that aren't aliases, I was looking at an API like this.
# [19:55] * Joins: murakami (~murakami@public.cloak)
# [19:56] <dael> TabAtkins: You have a customer media that's a map and you set the value. Current plan is it's a number or it's one or more strings that have to match the ident production.
# [19:56] * fantasai wishes custom things didn't require double hyphens
# [19:56] * fantasai thinks they look awkward
# [19:56] * fantasai -this- looks less awkward
# [19:57] <dael> TabAtkins: I don't havea good way to talk about units in here. If we pretend it has a length, you have to assume the 5 is pixels. When we have the better OM eventually we can ave it take those and all the links will be interop, but for now I think it should be int and they document what it refers to with the assumtption we'll make it better.
# [19:57] <dael> TabAtkins: This has been up for a while, but if there are comemtns that would be good.
# [19:57] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [19:57] <dael> Bert: I don't understand order they're evaluated. In this case I assume script first b/c foo isn't defined.
# [19:57] <dael> TabAtkins: foo is false and when it has a value it works.
# [19:58] * Quits: jeff_ (jeff@public.cloak) ("Leaving")
# [19:58] <dael> florian: You just have to be careful to define the diff between false and syntax error
# [19:58] <dael> Bert: So you can have a media attr on a link element, that cannot include the script?
# [19:58] <dael> TabAtkins: links can have a media and you should have that work here. Scripts always run
# [19:58] <dael> TabAtkins: MQ on elements, picture in particular, are used b preloader and that would never be usable by this.
# [19:59] <dael> TabAtkins: I'd like a solution that lets us define this in a way that's preloader friendly. That would define a custom MQ that you could use in stylesheet, but also for page where the preloader could figure out what is going on.
# [19:59] <dael> TabAtkins: Right now you have to repeat yourself over and over again. I'd rather a nice way to make those rely on a single point so there's less editing badness.
# [20:00] <dael> TabAtkins: I will want to do something with thatin the future.
# [20:00] <dael> plinss: Is the custom media to the stylesheet?
# [20:00] <dael> TabAtkins: Yes.
# [20:00] <dael> frank: What if you have MQ for bar and you haven't set it and you do later. Are we dropping it?
# [20:00] <plinss> s/media to/media scoped to/
# [20:01] <dael> TabAtkins: Unknown MQ evaluate to false. That's in the spec. It deosnt' drop the entire MQ.
# [20:01] <dael> SteveZ: Did you say this is only scripts?
# [20:01] <dael> TabAtkins: No.
# [20:01] <dael> glazou: CSS is a global object. That means CSS gets the media set by one document. That seems wrong.
# [20:02] * timeless RRSAgent, this meeting spans midnight <- if you want a single log for the two days
# [20:02] <RRSAgent> I'm logging. I don't understand 'this meeting spans midnight <- if you want a single log for the two days', timeless. Try /msg RRSAgent help
# [20:02] <dael> TabAtkins: We'v run into that before where namespace is on window not document. Maybe we put css namespacing on an object.
# [20:02] <dael> zcorpan: That CSS is on window doesn't mean it effects them all.
# [20:02] <dael> TabAtkins: All things see the window
# [20:02] <dael> dbaron: Lots of things are effected. The spec calls the consistant thing a window proxy.
# [20:03] <dael> TabAtkins: This is all confusing. If it's sufficient to say only the primary document needs to know about this and saying this kind of stuff only aplys to the document, I'm fine with that.
# [20:03] <dael> florian: And I think we're done with MQ.
# [20:03] <dael> glazou: So we can find another topic now, or go to lunch now.
# [20:03] * Quits: dino (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [20:03] * Quits: bradk (~bradk@public.cloak) ("Be back later ...")
# [20:03] <dael> [lunch break]
# [20:03] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [20:03] <dael> glazou: WE start again in an hour.
# [20:03] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [20:04] * Quits: smfr (~smfr@public.cloak) (smfr)
# [20:04] * bkardell_ resolved: lunch --- easiest decision of the day
# [20:04] * Joins: smfr (~smfr@public.cloak)
# [20:04] <dael> florian: TabAtkins and I have a few edits that don't need discussion now, but once we do we'll be ready for a new publication
# [20:04] * Quits: glazou (~glazou@public.cloak) (glazou)
# [20:04] * sgalineau wonders if he can make Zakim call into the gala dinner on Wednesday
# [20:04] * Joins: bobtung (~bobbytung@public.cloak)
# [20:04] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [20:04] * Quits: smfr (~smfr@public.cloak) (smfr)
# [20:04] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [20:04] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [20:04] * Quits: dael (~dael@public.cloak) ("Page closed")
# [20:04] * Joins: bradk (~bradk@public.cloak)
# [20:05] * Joins: zcorpan (~zcorpan@public.cloak)
# [20:05] * Quits: tantek (~tantek@public.cloak) (tantek)
# [20:05] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [20:06] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [20:07] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [20:07] * Quits: ArronEi (~ArronEi@public.cloak) (Ping timeout: 180 seconds)
# [20:07] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [20:08] * Quits: nsakai2 (~nsakai2@public.cloak) (Ping timeout: 180 seconds)
# [20:09] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [20:09] * Quits: jrossi (~jrossi@public.cloak) (Ping timeout: 180 seconds)
# [20:09] * Quits: iank_ (~iank@public.cloak) (Ping timeout: 180 seconds)
# [20:09] * Quits: Hyojin_ (~Hyojin@public.cloak) (Ping timeout: 180 seconds)
# [20:09] * Quits: KeshavP (~KeshavP@public.cloak) (Ping timeout: 180 seconds)
# [20:10] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [20:10] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [20:10] * Quits: babatakao (~babatakao@public.cloak) (Ping timeout: 180 seconds)
# [20:11] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [20:11] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [20:11] * Quits: bradk (~bradk@public.cloak) (Ping timeout: 180 seconds)
# [20:12] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [20:12] * Quits: hiroshi (~hiroshi@public.cloak) (Ping timeout: 180 seconds)
# [20:13] * Quits: hiroshi2 (~user@public.cloak) (Ping timeout: 180 seconds)
# [20:13] * Joins: estellevw (~estellewyel@public.cloak)
# [20:13] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [20:17] * leaverou is now known as leaverou_away
# [20:17] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [20:18] * Joins: myakura (~myakura@public.cloak)
# [20:23] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [20:25] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [20:27] * Joins: dauwhe (~dauwhe@public.cloak)
# [20:27] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [20:32] * Joins: chosungmann (~chosungmann@public.cloak)
# [20:35] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [20:37] * fantasai may be back closer to 1:15
# [20:37] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [20:40] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [20:41] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [20:46] * Quits: kurosawa (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [20:47] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [20:50] * Joins: lajava (~javi@public.cloak)
# [20:51] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [20:57] * Joins: notbenjamin (~textual@public.cloak)
# [20:59] * Quits: notbenjamin (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [21:01] * Joins: notbenjamin (~textual@public.cloak)
# [21:02] * Joins: smfr (~smfr@public.cloak)
# [21:02] * Joins: nvdbleek3 (~nvdbleek@public.cloak)
# [21:02] * Quits: nvdbleek (~nvdbleek@public.cloak) (Ping timeout: 180 seconds)
# [21:02] * nvdbleek3 is now known as nvdbleek
# [21:04] * Joins: myakura (~myakura@public.cloak)
# [21:05] * Joins: babatakao (~babatakao@public.cloak)
# [21:05] * Quits: hiroto__ (~hiroto@public.cloak) (Ping timeout: 180 seconds)
# [21:06] * Quits: Shige_ (~Shige@public.cloak) (Ping timeout: 180 seconds)
# [21:08] * leaverou_away is now known as leaverou
# [21:08] * Joins: smfr_ (~smfr@public.cloak)
# [21:09] * Joins: plh (plehegar@public.cloak)
# [21:09] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [21:09] * smfr_ is now known as smfr
# [21:10] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:10] * Quits: chosungmann (~chosungmann@public.cloak) ("Page closed")
# [21:11] * Joins: murakami (~murakami@public.cloak)
# [21:12] * Joins: SteveZ (~SteveZ@public.cloak)
# [21:12] * Joins: bobtung (~bobbytung@public.cloak)
# [21:12] * Joins: nsakai2 (~nsakai2@public.cloak)
# [21:13] * Joins: dauwhe (~dauwhe@public.cloak)
# [21:14] * Joins: shans__ (~shans@public.cloak)
# [21:15] * Joins: ArronEi (~ArronEi@public.cloak)
# [21:15] * Joins: dael (~dael@public.cloak)
# [21:15] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [21:17] * Joins: vollick (~vollick@public.cloak)
# [21:17] * leaverou is now known as leaverou_away
# [21:17] * Joins: iank (~iank@public.cloak)
# [21:17] * Joins: dbaron (~dbaron@public.cloak)
# [21:20] * Joins: florian (~Florian@public.cloak)
# [21:21] * Joins: KeshavP (~KeshavP@public.cloak)
# [21:22] * Joins: vollick_ (~vollick@public.cloak)
# [21:22] * Joins: tantek (~tantek@public.cloak)
# [21:22] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [21:23] * Joins: chosungmann (~chosungmann@public.cloak)
# [21:24] * Joins: andreyr (~andreyr@public.cloak)
# [21:24] * Joins: bradk (~bradk@public.cloak)
# [21:25] * Parts: chosungmann (~chosungmann@public.cloak)
# [21:25] <dael> ScribeNick: dael
# [21:25] * Joins: glazou (~glazou@public.cloak)
# [21:26] * Joins: florian (~Florian@public.cloak)
# [21:26] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [21:27] * Joins: bobtung (~bobbytung@public.cloak)
# [21:28] * leaverou_away is now known as leaverou
# [21:28] * Quits: yamamoto (~yamamoto@public.cloak) ("Page closed")
# [21:29] * Joins: dholbert (~dholbert@public.cloak)
# [21:30] <dael> plinss: Let's get started
# [21:30] * Joins: adenilson (~anonymous@public.cloak)
# [21:30] <dael> Topic: Sizing
# [21:31] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [21:31] <dael> glazou: Is fantasai around?
# [21:31] * Joins: jrossi (~jrossi@public.cloak)
# [21:31] <dael> dbaron: Can someone text her?
# [21:31] <dael> plinss: Who put this on the wiki?
# [21:31] <dael> TabAtkins: I assume fantasai
# [21:31] <gregwhitworth> http://jsfiddle.net/xzt063uv/2/
# [21:32] * Joins: hiroshi (~hiroshi@public.cloak)
# [21:32] <dael> plinss: Let's skip to inline-box?
# [21:32] * sgalineau should have gone for that second beer
# [21:32] * Joins: kurosawa (~chatzilla@public.cloak)
# [21:32] <dael> gregwhitworth: IE does layouts and we want to get interop. We want to figure out a way to do it without layout, but we often get live sites that don't render correctly. We'd like some feedback from others who don't want to change theri system.
# [21:33] * Joins: Rossen_ (~Rossen@public.cloak)
# [21:33] <dbaron> https://lists.w3.org/Archives/Member/w3c-css-wg/2006AprJun/0170.html
# [21:33] <dael> dbaron: I managed to dig up last time we discussed this issue.
# [21:33] <dael> dbaron: In the above minutes
# [21:33] <dael> dbaron: We didn't have a conclusion then.
# [21:33] * Joins: MaRakow (~MaRakow@public.cloak)
# [21:33] * Joins: hiroshi2 (~user@public.cloak)
# [21:33] <dael> dbaron: A buncho f us have made archetectual decisions that we don't do layout for this. We don't have major compat issues. It would be nice to hvae and agreement on what the rules are.
# [21:34] <dael> dbaron: Gecko code and webkit/blink code is somewhat different and I don't think coming to an agreement between those is hard and I think it would be webcompat
# [21:34] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [21:34] <dael> gregwhitworth: I agree. We have a lot of problems with what we do. I think a lot of people don't test us. We don't want to switch because people layout the same until shrink to fit.
# [21:35] <dael> dbaron: That's not ignoring the spec. It doesn't define behavior
# [21:35] <dael> gregwhitworth: At the end of the day we just want websites to work. We could say match us, but technically you're right that whenn you push down isn't defined. As an author I would expect the same layout and shrunk.
# [21:36] <dael> dbaron: There's no laying out.
# [21:36] <dael> gregwhitworth: They literally...if you look at the layouts personally I think they should be the same.
# [21:36] <dael> dbaron: Prior to 2006 or so we did it, but we stopped because it had tons of bugs and was slow. We decided webkit was surviving which doing what it was doing so that was compat for web content.
# [21:36] * Joins: hiroshi_ (~hiroshi@public.cloak)
# [21:37] <dael> gregwhitworth: Let me track down the thread. I think it was someone from Opera who said Presto is doing it differently.
# [21:37] <dael> florian: I think that was martin(?) on the list
# [21:37] <smfr> s/martin/morten
# [21:38] <dael> gregwhitworth: We don't have huge performance issues. I think most authors would expect our behaviour. What's the working group's consensus. I don't want it to stagnated because we have a few bugs.
# [21:38] * Joins: hiroshi2` (~user@public.cloak)
# [21:38] * Quits: jrossi (~jrossi@public.cloak) (Ping timeout: 180 seconds)
# [21:38] <dael> SimonSapin: What does it mean to do layouts...it depends on how much width is available, but we don't always have that information
# [21:39] <dael> dbaron: In the old days, all the layout code had a mode where you could exicute that code with a value for available width. It would than place everything as if there was no width constraint. WE would place floats along those lines.
# [21:39] <dael> Rossen_: When we run in unconstrained width we really run it unconstrained. Obv you can't resolve % because they're meaningless.
# [21:39] <dael> SimonSapin: What do you do with %s?
# [21:40] <dael> Rossen_: You can backwards resolve or resolve aainst computed shrink to fit size.
# [21:40] * sgalineau wonders if he missed someone call them 'floaters' for drinking game purposes
# [21:40] <dael> dbaron: The what do you do with x, the answers are always what are you doing when computing intrinsic widths. They just use the layout code to do that instead of sep code.
# [21:40] <dael> Rossen_: So there's pretty much no diff in the two codes.
# [21:41] <dael> gregwhitworth: It feels like again we all like our thing. I'm looking for a just deal with it.
# [21:41] * Quits: hiroshi (~hiroshi@public.cloak) (Ping timeout: 180 seconds)
# [21:41] <dael> dbaron: The algo I wrote was for the approximation stuff.
# [21:41] <dael> dbaron: I would vastly prefer not to go back down the trying to do layout path. I think IE is the only major engine doing that.
# [21:42] <dael> gregwhitworth: Putting aside interop and impl details, do you not find it odd as an author the they layout is completely different?
# [21:42] <dael> dbaron: It's no diff then if the absolute element had the same width. THe only diff is the width for the abspos element. Yes it is a little wierd but...
# [21:42] <dael> gregwhitworth: I don't know where else to take this. If everyone else is holding fast.
# [21:42] * Quits: hiroshi2 (~user@public.cloak) (Ping timeout: 180 seconds)
# [21:43] <dael> Bert: One other thing. I'd like to have for things like tables and grid layout, you do layout where the width you want is the one that minimizes the height, that gives you most compact tables as possible.
# [21:43] <dael> Bert: Maybe there should be a switch somewhere to use a different algo and then you really search for smallest way to pack the content.
# [21:43] <dael> Bert: Smallest in this case is smallest height
# [21:44] <dael> Rossen_: So that's you max content. It's shrink to fit
# [21:44] <dael> Bert: It's more complex than the basic approx like two floats could fit together. You may have to do the layout multi times. I've seen it done and you get beautiful tables. You may need a fast computer if you want it interactive.
# [21:44] * Joins: hiroshi2 (~user@public.cloak)
# [21:45] <dael> Bert: I don't know how it works with animation. I guess you turn it off. It's something to keep in mind and it may be a future way. For print especially you can get better layouts.
# [21:45] <dael> Rossen_: So dbaron you mentioned performance as an issue.
# [21:45] <dael> dbaron: A lot of the gains came from how we do invalidation. We didn't perm maintain the layout data so we would have to redo layout. I'm guessing you don't have that problem?
# [21:46] <dael> Rossen_: no.
# [21:46] <dael> Rossen_: In our case we have ways of reusing that data when we identify that it wil be the same result so you only do the nes. overrides
# [21:47] <dael> gregwhitworth: Again, I point to the ex where there's room in the container for that stuff to fit. in the testcase your constraint is the viewport. It shouldn't be pushed because technically there's room to fit.
# [21:47] * Joins: jcraig (~jcraig@public.cloak)
# [21:47] <dael> gregwhitworth: I'm leary to say match when it's a diff result.
# [21:47] * Joins: dino (~textual@public.cloak)
# [21:47] * Quits: hiroshi2` (~user@public.cloak) (Ping timeout: 180 seconds)
# [21:48] <dael> Rossen_: Given the content that's out there, does it make sense to have a higher quality of impl? So the user expectatio will match regular layout more? Or is this an edge case enough so we would go and change how we behave.
# [21:48] <dael> gregwhitworth: I'd say 50/50
# [21:48] <dael> Rossen_: I've seen bugs that argue both. The ones that suck are on the outer level of websites that control they're layout through floats. That's where we have broken layout inside shrink to fit layouts.
# [21:49] <dael> Rossen_: Hopefully with grid and flexbox they'll move away from that practise, but in the meantime we're stuff with broken behaviour
# [21:49] * hober waves at krit
# [21:49] * Joins: yamamoto (~yamamoto@public.cloak)
# [21:49] <dael> Rossen_: one q is dbaron is this an idea you guys would even entertain is to do something from approx or a diff way to do layout? If it's out of the question there's no reason to do this
# [21:50] <dael> dbaron: I think going back is pretty out of the question. I couldn't justify prob at least 1 person year of engineering time when what we have now is web compat and works.
# [21:50] <dael> Rossen_: So if this is the case, can we at least spec that?
# [21:50] <dael> dbaron: Spec the way the approx works? I can do that. At one point I think I posted to the list what we do. I'd be interested in seeing what webkit does.
# [21:50] * Quits: yamamoto (~yamamoto@public.cloak) ("Page closed")
# [21:50] <dael> smfr: We do the same as Gecko in this case.
# [21:51] <dael> dbaron: There are some differences. They're subtile, but we sometimes get bugs.
# [21:51] <dael> gregwhitworth: So can we action that or...?
# [21:51] <dael> dbaron: I can write up the Gecko behaviour.
# [21:51] <dael> gregwhitworth: Anyone willing to write up others?
# [21:51] <dael> TabAtkins: I can try and ping our people that know the details.
# [21:51] <dael> Rossen_: So where would we put that?
# [21:51] <dael> gregwhitworth: Sizing?
# [21:51] <dael> Rossen_: It could.
# [21:52] <dael> plinss: Is the current text vague or silent?
# [21:52] <dael> Rossen_: It's basically a lot of hand waving.
# [21:52] * Joins: hjlee_ (~hjlee@public.cloak)
# [21:52] <dael> Rossen_: Okay. I think we're done with that issue.
# [21:52] * Joins: shepazu (schepers@public.cloak)
# [21:52] <dael> Topic: sizing
# [21:52] * Parts: hjlee_ (~hjlee@public.cloak)
# [21:52] * Joins: glazou_ (~glazou_@public.cloak)
# [21:52] <dael> TabAtkins: fantasai you put sizing?
# [21:53] <dael> fantasai: No.
# [21:53] <dael> SimonSapin: I did.
# [21:53] * Joins: jrossi (~jrossi@public.cloak)
# [21:53] <dael> SimonSapin: In the sizing spec for the intrinsic sizes of non-replaced blocks, there are different cases depending on if the repeated width if def or not
# [21:53] * Joins: hjlee (~hjlee@public.cloak)
# [21:53] <dael> SimonSapin: If it's not definite...
# [21:53] <dael> dbaron: What does it mean for definite?
# [21:53] <dael> SimonSapin: Fixed length or a % that's ready for something definite
# [21:54] <dael> dbaron: So definite is a length or a % the resolves to length.
# [21:54] <dael> fantasai: Could be resolving in ICB, but it doesn't have to do layout.
# [21:54] <dael> florian: Inc calc?
# [21:54] <dael> fantasai: If the things being calc are definite.
# [21:55] * Joins: yamamoto (~yamamoto@public.cloak)
# [21:55] <dael> SimonSapin: When it's not def the spec says (see IRC)
# [21:55] <SimonSapin> If the computed inline-size of a block-level box is min-content, max-content, or a definite size, [...] Otherwise, if the computed inline-size of the block is fit-content, auto, or fill, its min-content inline-size contribution is its min-content inline-size plus any inline-axis margin, border, and padding.
# [21:55] <SimonSapin> http://dev.w3.org/csswg/css-sizing/#block-intrinsic
# [21:55] * Quits: kurosawa (~chatzilla@public.cloak) (Client closed connection)
# [21:56] <dael> dbaron: So you're saying it should say what to do with % size and padding.
# [21:56] <dael> SimonSapin: Yes.
# [21:56] <dael> dbaron: It should.
# [21:56] <dael> dbaron: I guess diff browsers do diff things. I believe this is a thing where Gecko does different than other browsers.
# [21:56] <dael> SimonSapin: I haven't tested.
# [21:56] <dbaron> http://dbaron.org/css/intrinsic/#mbp-adjust
# [21:57] <dael> dbaron: I wrote the above when trying to write this up
# [21:57] <dael> dbaron: I did write a def that inverted the % in padding and margin. I believe Gecko does that, but not other browsers.
# [21:57] <dael> Rossen_: We don't for sure.
# [21:57] <dael> dbaron: Geck not for width, but padding and margin
# [21:57] <dael> SimonSapin: For some reason I thought the answer was treat % as 0
# [21:58] <dael> Rossen_: That's what I do
# [21:58] <dael> fantasai: Maybe that was in grid layout.
# [21:58] <dael> Rossen_: That would make sense.
# [21:58] <dael> dbaron: The other int thing is that it does that for preferred width, but treats as 0 for min.
# [21:58] * Joins: AH_Miller (~mike@public.cloak)
# [21:58] <dael> SimonSapin: Is there a reason?
# [21:58] * Quits: AH_Miller (~mike@public.cloak) ("")
# [21:59] <dael> dbaron: Web compat. The reason for 0 as min content. The pref width is because it works better.
# [21:59] <dael> Rossen_: I'd be surprised if webkits did that. We don't
# [21:59] * Joins: hiroto_ (~hiroto@public.cloak)
# [21:59] <dael> dbaron: The compat was the min-width. I guess I'm okay with dropping inversion if that's what everyone else does.
# [21:59] <dael> fantasai: If it gives clearly better results.
# [22:00] * Joins: kurosawa (~chatzilla@public.cloak)
# [22:00] <fantasai> s/results/results, might be worth considering/
# [22:00] <dael> dbaron: I'm okay with doing 0. I think everyone else has been doing that for a while.
# [22:00] <dael> plinss: Is that specified?
# [22:00] * Joins: Cyril (~chatzilla@public.cloak)
# [22:00] <dael> dbaron: No.
# [22:00] <dael> plinss: So add it to sizing?
# [22:00] <dael> fantasai: I think 0 makes sense if it ends up being 0. If you calculate assuming 0 and then calc % against that size we have a problem.
# [22:00] <dael> dbaron: And that exists in all the other browsers.
# [22:01] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [22:01] <dael> fantasai: If we're making it 0 or intrinsic size we should make it 0 for everything.
# [22:01] <dael> gregwhitworth: That's the arguement we just made with floats.
# [22:02] <dael> dbaron: The other thing is hopefully people will be using floats for layout less over time.
# [22:02] <dael> fantasai: And intrinisic sizing goes into everything.
# [22:02] <dael> fantasai: If you special case floats, it doesn't make sense.
# [22:02] <dael> dbaron: Floats are the only concept in CSS 2.1 that req you to do layout to compute an intrinisic size.
# [22:03] <dael> dbaron: They're the only place where you need height info to determine intrinish widths. What Microsoft wants to do you need to know the height of every float to calc the intrinisic width to layout. You're doing layout of lines
# [22:03] * Joins: glenn (~gadams@public.cloak)
# [22:03] <dael> dbaron: To determine if two floats are next to each other you need to know the height of each line. It adds a lot of information to be able to calculate without a lot of value
# [22:04] <dael> fantasai: So if we're assuming 0 for intrinisic size, we should assume 0 for layout.
# [22:04] <dael> dbaron: I'd argue that becaue layout is interop
# [22:04] <dael> Rossen_: So yo're okay with dropping to 0?
# [22:04] <dael> dbaron: Yeah. I mean, everyone else is doing it.
# [22:05] <dael> fantasai: So your ideal would be the opposite of Miscrosoft? So floats are extra compex, but lets do it for all these other things because it makes sense. And Microsoft argues the opposite that we want to do this for floats, but everything else is 0.
# [22:05] * fantasai thinks we should just do what dbaron thinks is the best idea, usually
# [22:05] <dael> Rossen_: % are funky when you backwards resolve so if you have many table cells that are % in width, backwards resolving most of the time is unreasonable
# [22:06] <dael> dbaron: Tables do resolve backwards, but only for table layout, that's interop. But we're not talking about table layout right now.
# [22:06] * astearns fantasai should have an irc bot that says that every hour or so during ftf meetings
# [22:06] <dael> SimonSapin: I don't know how much of an arguement this is, but the way we layout, we can't have any results from layouts for intrinisic width. We computer them all before we start layout for the heights.
# [22:06] * Joins: song_ (~song@public.cloak)
# [22:07] <SimonSapin> s/we layout/Servo does layout/
# [22:07] * Quits: dino (~textual@public.cloak) (Ping timeout: 180 seconds)
# [22:07] * Joins: glenn_ (~gadams@public.cloak)
# [22:07] <dael> fantasai: I think Servo needs to change its architecture.
# [22:08] <dael> Rossen_: I don't think...I can prob come up with grid layout scenarios that would have the sim dependancy. Rows that are fragmenet dependant. Vertical text is another one.
# [22:08] <dael> Rossen_: I'm not sure how we got to that discussion.
# [22:08] <dael> gregwhitworth: Because the resolution is what I was trying to argue so I hijacked it.
# [22:08] <dael> plinss: I'm not sure if I'm hearing consensus.
# [22:09] * Quits: kurosawa (~chatzilla@public.cloak) (Client closed connection)
# [22:09] <dael> dbaron: one other point. The arguement for wanting to try and do this the right way and invert the %s is kind of weak b/c it's only web compat in 1/3 of the cases. WE can look at width padding and margin. For webcompt we can only do it for margin and padding.
# [22:10] <dael> fantasai: This is block layout?
# [22:10] <dael> dbaron: Yes.
# [22:10] <dael> fantasai: It may be we have to cut our losses for this and do it correctly for grid and flexbox.
# [22:10] <dael> plinss: So have a layout mode that authors can opt-into?
# [22:11] <dael> dbaron: I'd be happier about trying to do it the right way in layout modes than adding mode switches.
# [22:11] * sgalineau likes that 'doing it correctly' is 'cutting our losses'
# [22:11] <dael> fantasai: I think that's prob fine. Block layout is really about stuff in the flow. Fancy sizing isn't its fortay.
# [22:11] <fantasai> s/fortay/forte/
# [22:11] <dael> plinss: Will you get prettier answers the other way, for example like ebooks?
# [22:11] * sgalineau looks for css-fancy-sizing
# [22:11] * dauwhe fantasai just hurt block layout's feelings
# [22:12] * sgalineau box-sizing: fancy;
# [22:12] <plinss> s/fancy/fancy-pants/
# [22:12] <dael> fantasai: I def want to look into trying to figure it out for flexbox and grid.
# [22:12] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [22:12] <dael> dbaron: I'mnot sure I'm comfortable changing flexbox that much at this point.
# [22:12] <dael> fantasai: They should be consistant.
# [22:12] <dael> dbaron: The last substantitive change to flexbox had a lot of problems.
# [22:12] * sgalineau supports plinss' proposal to s/intrinsic/fancy-pants
# [22:13] <dael> fantasai: Is that flex-basis? The resolution was lets change it to this and get feedback and then it was impl.
# [22:13] <dael> fantasai: That was also syntactic, not layout issue.
# [22:13] <dael> dbaron: So are we leaning toward we want these all 0 for block and try to do the inverting for new layout modes?
# [22:13] <dael> fantasai: Makes sense.
# [22:14] <dael> Rossen_: I wouldn't change flex at this point.
# [22:14] <dael> dbaron: Then we get to argue about what's new and what's old.
# [22:14] <dael> Rossen_: They're both old for us.
# [22:14] * sgalineau can't believe we're talking about changing flex. WHAT IS THIS, GRADIENTS?
# [22:15] <dael> TabAtkins: Given the problems table layouts had when we wanted to add new functions like we can't do min/max. You objected on tables. You had to do a piece-wise linear function.
# [22:15] <dael> dbaron: We should investigate that, yes.
# [22:15] <dael> plinss: So what's the resolution?
# [22:15] <dael> fantasai: I'd like it if you said make my box as wide as it need to be to not wwrap, you get that.
# [22:15] <dael> Rossen_: IN all cases?
# [22:15] * Joins: dino (~textual@public.cloak)
# [22:16] <dael> fantasai: Ideally yes. If we can't because compat than we have a problem. I think we should honor the request to not wrap. And if the internet is dumb and we can't do it in some cases, than we can't, bbut if we can do it we should try and do it.
# [22:16] * Joins: kurosawa (~chatzilla@public.cloak)
# [22:16] * sgalineau was this all started by gregwhitworth?
# [22:16] <dael> plinss: So again...do we have a resolution, do we need to investigate more?
# [22:17] <dael> fantasai: I don't know. I think we should stick four of us in a room with a whiteboard.
# [22:17] * astearns and don't let them out until they all fit on the same line
# [22:17] <fantasai> s/whiteboard/whiteboard and the sizing spec/
# [22:17] * Quits: Rossen_ (~Rossen@public.cloak) ("Page closed")
# [22:18] <dael> Bert: What FF does looks better than what Safari does. FF currently calcs that if you want everything on one line you get everything on one line. It really looks better. I'm trying to see about others. Prince puts you on one line but makes it bigger than it needs to be.
# [22:18] <dael> Bert: So I'd rather not make it 0.
# [22:18] * Quits: kurosawa (~chatzilla@public.cloak) (Client closed connection)
# [22:18] <dael> plinss: So cage-match tonight with a whiteboard?
# [22:19] <dael> dbaron: Do we have a whiteboard?
# [22:19] <dael> plinss: We can ask.
# [22:19] <fantasai> The meeting room is non-conformat wrt CSSWG meeting room specs...
# [22:20] <dael> action TabAtkins spec their float layout for intrinisic sizes
# [22:20] * trackbot is creating a new ACTION.
# [22:20] <trackbot> Created ACTION-659 - Spec their float layout for intrinisic sizes [on Tab Atkins Jr. - due 2014-11-03].
# [22:20] <dael> action dbaron spec their float layout for intrinisic sizes
# [22:20] * trackbot is creating a new ACTION.
# [22:20] <trackbot> Created ACTION-660 - Spec their float layout for intrinisic sizes [on David Baron - due 2014-11-03].
# [22:20] * sgalineau RESOLVED: board shall be white
# [22:20] * Joins: Shige__ (~Shige@public.cloak)
# [22:21] <dael> plinss: So we'll loop back tomorrow? Folks will work this out offline?
# [22:21] <dael> rossen: Sure.
# [22:21] * fantasai was the action item supposed to have s/their/Blink's/
# [22:21] * fantasai ?
# [22:21] <dael> SimonSapin: My understanding of intrinisic sizing is that it's intrinisic and doesn't depend on the context around it.
# [22:22] * Joins: emalasky (~Adium@public.cloak)
# [22:22] <bradk> online whiteboard: https://awwapp.com
# [22:22] <dael> SimonSapin: When we have a writing mode it isn't how intrinisic sizing is supposed to work. In pariticular the intrinisic block size.
# [22:22] * sgalineau it's called intrinsic because magic was already used for all the other things
# [22:23] <dael> rossen: What we do, basically the obvious pitfall is we say it's shrink to fit, assuming youdo layout for shrink to fit, if you, let's assume you have one long lne of text. You don't want shrink-to-fit that's one long line of text.
# [22:23] <dael> rossen: I believe there's text in writing modes that spec if you have no height in the orthoganal switch you cap that to the viewport. We do nearest scrollable box of viewport.
# [22:23] <fantasai> ACTION fantasai: Put IE's nearest-scrollable-box behavior into orthogonal flows spec
# [22:23] * trackbot is creating a new ACTION.
# [22:23] * RRSAgent records action 1
# [22:23] <trackbot> Created ACTION-661 - Put ie's nearest-scrollable-box behavior into orthogonal flows spec [on Elika Etemad - due 2014-11-03].
# [22:23] * dauwhe layout-mode ( magic | fancy | none ) fixes every issue we've had today
# [22:24] <dael> rossen: We'd discovered with orthogonal flow, the cases are mostly having some kind of webpage where you scroll down and find an ex of vertical text. The idea is you want to be able to see that in your screen. You don't want to have to scroll both ways. In our impl we cap the size of the vertical orthogonal content to be the min of your nearest scrolling ancestor and your viewport.
# [22:25] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [22:25] <dael> rossen: With that in mind you can go and compute your min and max size. You need to define that. Max size can be the layout that you would produce when you cap content at the min.
# [22:25] <dael> rossen: The min of the content would be the cap size, the viewport or nearest scrolling.
# [22:25] * leaverou sgalineau you're on a roll today! Sounds like some W3C memes are in order ;)
# [22:25] <dael> rossen: That's a fairly good result in almost all proactical cases. I'm pretty sure you're looking to avoid where you have the min and max to be one line height.
# [22:26] <dael> SimonSapin: Should sizing desc all of this whenever it talks about min/max block content size.
# [22:26] * sgalineau leaverou: yes, I'd better catch up on meme editing
# [22:26] <dael> rossen: It's a split between writing modes and sizing. I think fantasai and I spoke about this, but I would expect it defined in one of the two or both specs.
# [22:26] <dael> SimonSapin: Does it make sense to talk about that for things that aren't flows.
# [22:27] <dael> fantasai: There's a couple things. If you set the keywords on the height you need some kind of result. There's also if you support writing modes it's not just the immediate orthoganal flow thing, you have to be able to compute the content size.
# [22:27] <dael> SimonSapin: Once you're inside the block direction becausem the length direction.
# [22:27] * leaverou sgalineau You have a duty to do so; The CSS WG is currently falling behind on memes :p
# [22:28] <gregwhitworth> * leaverou: build some and send them to him
# [22:28] <dael> SteveZ: It seems to me it isn't totally writing modes. In prinicipal you could have something else that changes direction like if you do rotating with layout. So it should be covered as a change in block direction.
# [22:28] <dael> SimonSapin: How is that different?
# [22:28] <dael> SteveZ: It's basically what you get with tabs on the sides.
# [22:29] <dael> fantasai: We're impl that in terms of writing modes.
# [22:29] <dael> SteveZ: There's no reaso to assume writing mode is the only want to change the block direction Or we can say it is.
# [22:29] <dael> fantasai: That's kind of what we landed on.
# [22:29] <dael> fantasai: Unless we want to do 45 degree rotations.
# [22:29] * leaverou gregwhitworth: I would, but I lack his talent in meme-ing :)
# [22:30] * sgalineau yes, gregwhitworth: don't f with the only thing i do around here
# [22:30] <dael> SteveZ: I think we should decide if it's with the orientation and in that case it goes with writing modes, but there's no harm in having a reference.
# [22:30] <dael> fantasai: Oh yeah, there isn't.
# [22:30] <gregwhitworth> sgalineau leaverou lol :)
# [22:30] <dael> SteveZ: There's other things like a sequence of linine images. Like in vertical form it lays out and we have the same issue.
# [22:31] <dael> rossen: We had a similar issue with flex with intrinisic size of images in vert flex versus horz flex. It's arguably the easiest to deal with it in writing modes and deal with jsut this weird case.
# [22:31] <dael> s/jsut/just
# [22:32] <dael> rossen: so SimonSapin was your main point to figure out where this should go or what the expected behaviour is or is there anything else we need to define?
# [22:32] <dael> SimonSapin: If this is the behaviour, it should be in the sizing spec.
# [22:32] <dael> SimonSapin: I'm worried that this would prevent some layout.
# [22:32] <dael> rossen: Well, maybe.
# [22:33] <dael> SimonSapin: Do you think we can still do parillel with this case?
# [22:33] <dael> rossen: Depends on what you would do and they type of inputs you would take.
# [22:34] <dael> rossen: From pure user, not having dependancy in orthogonal doesn't make sense. It's just goingt o producce wrong results, unfortunatly
# [22:34] <dael> plinss: Any more on this?
# [22:34] * sgalineau can't take any more
# [22:34] <dael> Topic: Grid
# [22:35] * Quits: rego (~smuxi@public.cloak) (Client closed connection)
# [22:36] <dael> TabAtkins: Before we start full grid, I've been talking to the lead maintainer of SAAS because they use paranthesis as a grouping and that's common with preprocessor. The only want to work around this is to inject some very specific language. She's requesting we revisit the syntax and either make it named or use a different grouping character.
# [22:36] <dael> bradk: What would the named function be?
# [22:36] <dael> fantasai: not-a-SAAS-function?
# [22:36] * Joins: rego (~smuxi@public.cloak)
# [22:36] <dael> TabAtkins: I don't think we...I'm not sure if we've impl the syntax or if we just did it, but we could change ours.
# [22:37] <dael> fantasai: I don't think we're shipping.
# [22:37] <bradk> that wasn't me
# [22:37] <dael> TabAtkins: If we're okay coming up with a name, we can just say that and address it on the ML?
# [22:37] <leaverou> s/SAAS/SASS/
# [22:37] <dael> rossen: I wouldn't be opposed.
# [22:37] <dael> TabAtkins: They're request is please don't ever use their paranthesis.
# [22:37] <dael> plinss: What about inside calc?
# [22:38] <fantasai> s/their/bare/
# [22:38] <dael> TabAtkins: It's already super-magic. She's talking on the property level.
# [22:38] <dael> Bert: We use them in MQ.
# [22:38] * astearns s/super-/intrinsically-/
# [22:38] <dael> TabAtkins: Different syntax pieces, it's any prop where it means something different.
# [22:38] <leaverou> shouldn't preprocessors follow CSS instead of the opposite? It's much easier for preprocessors to change their syntax than it is for CSS.
# [22:39] * Joins: bobtung (~bobbytung@public.cloak)
# [22:39] <dael> TabAtkins: Right now they use parens as a grouping and they're heavily used everywhere. They can't change their current use and they want to as much as poss that SASS is a super-set. Any CSS is correct in SASS and that would force that to change.
# [22:39] <dael> TabAtkins: And she says that calc is a crazy special case already.
# [22:39] * sgalineau must leave now. will call in again tomorrow.
# [22:39] <dael> TabAtkins: We'd be resolving to not ever use bare parenthesis.
# [22:39] <Zakim> -SGalineau
# [22:39] <dael> plinss: I'm not sure I'm okay with that.
# [22:39] * dauwhe )just reverse the parentheses(
# [22:40] <dael> TabAtkins: This preprocessor is already 5 years old.
# [22:40] <dael> leaverou: CSS has more users than pre-processors. If both options are the same w can make it easier for pre-processors, but if this is easier for authors we should do it.
# [22:40] <dael> TabAtkins: This is small, though.
# [22:40] <dael> astearns: The parens in question are grouping line names?
# [22:41] <dael> astearns: Is there any other place in CSS where we've wanted to give alternate names?
# [22:41] <dael> TabAtkins: What do you mean.
# [22:41] <TabAtkins> http://dev.w3.org/csswg/css-grid/#track-sizing
# [22:41] <dael> fantasai: One issue is you'll make the syntax more awk. Even if you pick a great name, every time you define a grid template, you'll have to repeat. It's not buying the author anything great.
# [22:42] <dael> rossen: Can they special case?
# [22:42] <dael> TabAtkins: Not without special casing this one property and any others where we create blanks.
# [22:42] <dael> rossen: They can create a lookup table
# [22:42] <dael> TabAtkins: They've avoided it until now.
# [22:42] <dael> fantasai: We have three options. 1) switch to brackets
# [22:42] <dael> fantasai: 2) swithc to curly brackets.
# [22:42] <dael> TabAtkins: I don't think we want that.
# [22:43] <dael> fantasai: That's not 2. 2 is switch to a short name.
# [22:43] <dael> fantasai: 3) is we tell SASS that the effort to put this into special case...we tell them we have to special case this.
# [22:43] <dael> fantasai: Downside of switching to name is it makes the syntax have a lot of noise and it becomes harder to read. It's not helpig the author any.
# [22:44] <dael> fantasai: Downside of telling SASS to special case is they have to put in somet ime to impl a speicla case.
# [22:44] <dael> TabAtkins: Also handing stuff in script becomes harder. In this particular case the paren in a list get translated to actual parens. It makes the model less consistant.
# [22:44] <Zakim> disconnecting the lone participant, SantaBarbara, in Team_(css)17:40Z
# [22:44] <Zakim> Team_(css)17:40Z has ended
# [22:44] <Zakim> Attendees were SGalineau, SantaBarbara
# [22:45] <dael> fantasai: The only option without a downside is switch to brackets.
# [22:45] <dael> fantasai: I'm not impressed with list.
# [22:45] * Zakim excuses himself; his presence no longer seems to be needed
# [22:45] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [22:45] <dael> ??: Brackets is pretty good.
# [22:45] * Joins: jeff (jeff@public.cloak)
# [22:45] <dael> TabAtkins: The only point of a function is to group.
# [22:45] <astearns> s/??/bkardell/
# [22:45] <glazou> s/??/bkardell
# [22:46] <dael> bkardell_: Also SASS is open sourse so anyone can submit a patch. If the WG felt strongly SASS should change they can send a request.
# [22:46] <dael> florian: It's also bad for SASS users.
# [22:46] <dael> TabAtkins: They're population is smaller, but it's not insignificant. They have lots of users.
# [22:46] <dael> TabAtkins: I'm fine with square brackets.
# [22:46] <dael> fantasai: Any other issues with them?
# [22:47] <dael> fantasai: The only option I'm not okay with is script.
# [22:47] <dael> TabAtkins: I'm down with square brakcets. And in the future when we need to group things, we'll just use suqare brackets.
# [22:48] <dael> plinss: The forward compat parsing is that you match parens and brackets. That means we can use them whereever we want. That someone else jumped over that isn't our fault.
# [22:48] * Quits: notbenjamin (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [22:48] <leaverou> I would argue that parentheses are more natural and intuitive for any kind of grouping
# [22:48] <dael> TabAtkins: And within functions it's different.
# [22:48] <bkardell_> Can we make sure the record shows that I said I don't support us changing sass before "but if we did feel strongly we could submit a pull"
# [22:48] <dael> plinss: But we might have something in selectors or something we don't see now in the future.
# [22:49] <dael> fantasai: I think plinss is obj on principal.
# [22:49] <dael> TabAtkins: I think the practical overrides principal as long as there's a reasonable answer to it.
# [22:49] <dael> dauwhe: Will brackets feel as natural?
# [22:49] <dael> TabAtkins: You don't need shift.
# [22:49] <fantasai> http://dev.w3.org/csswg/css-grid/#named-lines
# [22:49] <dael> dbaron: Is that true for non US.
# [22:49] <dael> [it's not]
# [22:49] <dbaron> s/non US/non US keyboards/
# [22:50] <dael> TabAtkins: Anyone that writes code on their keyboard can find a square bracket.
# [22:50] <dael> SteveZ: I'm not opposed but to me traditionally that means subscript.
# [22:50] <dael> SteveZ: I think it's going to be a point of mild confusion where paren would be less.
# [22:50] <dael> TabAtkins: This isn't common in programming languages.
# [22:50] <dael> many: lists
# [22:51] <dael> dauwhe: What % of CSS users are programmers?
# [22:51] * Joins: notbenjamin (~textual@public.cloak)
# [22:51] <dael> TabAtkins: Pretty low.
# [22:51] <dael> bkardell_: It's loaded. A lot of CSS do basic PHP. They're not totally withdrawn.
# [22:52] <dael> rossen: dbaron didn't you use brackets in your overflow or something?
# [22:52] <dael> dbaron: I don't know.
# [22:52] <dael> TabAtkins: It would be this (link above) with square brackets.
# [22:52] <dael> gregwhitworth: What was the arguement again?
# [22:52] <dael> TabAtkins: SASS uses parens for grouping.
# [22:52] <dael> TabAtkins: Les (?) has similar problems.
# [22:53] <gregwhitworth> s/Les/LESS
# [22:53] <dael> plinss: I'm not married to the parens and I don't mind alt syntax, but I object to us giving up parens forever.
# [22:53] <leaverou> plinss++
# [22:53] <dael> florian: We're weighing the pros and cons.
# [22:53] <dael> TabAtkins: Any arguement we make here is anywhere we use parens
# [22:53] * Quits: notbenjamin (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [22:54] <dael> SteveZ: If you establish that sq brackets are ways of identifying chunks, we should use that anywhere that we're doing chunks.
# [22:54] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [22:54] <dael> florian: And if we find another reason to use naked parens we can still do it.
# [22:54] <dael> rossen: So if you go back to them and say no, would they declare war or...?
# [22:54] <dael> TabAtkins: They'll figure something out, but it would be frustrating for them and their users.
# [22:54] <dael> bkardell_: The problem is there's a bunch of SASS out there now.
# [22:55] <dael> rossen: Existing SASS targeting grid.
# [22:55] <dael> bkardell_: That's true.
# [22:55] <leaverou> As many pointed out, it's not this particular property. If we use brackets here, we have to use them in every future property that needs grouping/chunks of any sort, for consistency
# [22:55] <dael> TabAtkins: They can't tell context immediatly. It's prob poss to make it work, but it would be weird.
# [22:55] <dael> plinss: Well they could change it.
# [22:55] <dael> TabAtkins: That would break that all valid CSS is valid SASS.
# [22:56] <dael> plinss: If that's their rule, they vilated it.
# [22:56] <dael> TabAtkins: Technically any syntax they choose violates that because we can use it.
# [22:56] * Quits: jrossi (~jrossi@public.cloak) (Ping timeout: 180 seconds)
# [22:56] <dael> plinss: I don't want to constrain ourselves because someone else picked a syntax. If they had restricted themselevs to the extension points in our syntax they'd be fine.
# [22:56] <dael> TabAtkins: Like @rule
# [22:56] <dael> plinss: And prefixes
# [22:57] * astearns we could change to --(name othername)
# [22:57] <dael> TabAtkins: But they didn't and we can't go back in time. My first answer was sucks to be you, but then she explains more and it makes sense.
# [22:57] * smfr we could just comma-separate this list
# [22:57] <dael> florian: Given that I don't find square brackets odder it's fine. In this case it's fine.
# [22:57] <dael> leaverou: It's creating a precident
# [22:58] <dael> florian: If we find later a place where naked parens is better, screw SASS but right now we have an alternative that's not any worse.
# [22:58] <leaverou> s/precident/precedent/
# [22:58] <dael> florian: If you think list you're in trouble, but this it doesn't matter square or round.
# [22:59] <dael> TabAtkins: Sizes may be keywords so you need to disambiguate.
# [22:59] <dael> fantasai: Or we might add the keyword
# [22:59] <dael> astearns: Use strings?
# [22:59] <dael> TabAtkins: It's uglier.
# [22:59] <dael> rossen: I think the arguement is beyond this. I think this is on the grounds of do we give up parens
# [23:00] <dael> florian: I don't think we have to always, but in this case they're not the only good chioce.
# [23:00] * Joins: Rossen_ (~Rossen@public.cloak)
# [23:00] <dael> Rossen_: You're saying that later in time there will be a larger chance of us going to SASS and ask them to change when they have more content because we'll have to use them.
# [23:00] <dael> TabAtkins: We're making future us deal with it.
# [23:00] <dael> leaverou: And they don't need to change until this ships
# [23:01] <dael> TabAtkins: We hope to ship in Q4
# [23:01] * Quits: emalasky (~Adium@public.cloak) (Client closed connection)
# [23:01] * Joins: emalasky1 (~Adium@public.cloak)
# [23:01] <dael> florian: Forcing SASS users to use inconsistant, we want to avoid that.
# [23:01] <dael> leaverou: But they'll special case.
# [23:01] * Joins: emalasky (~Adium@public.cloak)
# [23:01] <astearns> strings comment wasn't me
# [23:01] <dael> florian: But they'll have to remember the special case.
# [23:01] * Quits: emalasky1 (~Adium@public.cloak) (Client closed connection)
# [23:01] <zcorpan> how about grid-template-columns: first nav 150px, main 1fr, last; ? i.e. use comma, all but the last component value are custom names
# [23:01] * dauwhe we use 29,110 parenthesis in our specs.
# [23:01] * SimonSapin Rossen_, Is IE shipping the keywords-in-strings syntax of grid-template-areas?
# [23:02] <dael> bkardell_: Is there a compelling case why parens are better here? leaverou I feel like you don't like this and I want to figure out why
# [23:02] * zcorpan TabAtkins ^
# [23:02] <dael> leaverou: I'm worried about the precident.
# [23:02] <dael> TabAtkins: When SASS has asked before, I've said no. It was a little inconvenient. They've just dealt with it like when we use /. This is a different bucket and way more inconvenient.
# [23:02] <dael> bradk: Can they change their syntax
# [23:03] <dael> TabAtkins: Not at this point.
# [23:03] <dael> TabAtkins: It would just say all SASS scripts are broken.
# [23:03] <dael> bkardell_: Let me reframe. I like brackets better.
# [23:03] <dael> bradk: They make me think of attr.
# [23:03] <dael> TabAtkins: That is where we use it right now.
# [23:03] <dael> fantasai: Selectors is a completely different this.
# [23:04] <dael> TabAtkins: If we pretend I had always used sq brackets, is there an arguement to switch to parans?
# [23:04] <fantasai> s/this/syntactic space/
# [23:04] <dael> dauwhe: The corner is hard on my eyes.
# [23:04] <dael> dbaron: Would it inconvienience other preprocessors?
# [23:04] <dael> TabAtkins: Not that I'm aware of.
# [23:04] <leaverou> s/precident/precedent/
# [23:04] <fantasai> Note, it wasn't Tab's suggestion to use parens, it was mine.
# [23:05] <fantasai> :)
# [23:05] * Joins: jcraig (~jcraig@public.cloak)
# [23:05] <dbaron> (Tab said he thinks [] are fine for SASS and LESS.)
# [23:05] <dael> ??: For this specific case in grid we change to square, but it's important to let them know that this is an exception and we may use parens in the future. Since you'll have close contact, we can say we care about SASS but we are leading.
# [23:05] * smfr NB: joint meeting with webapps, publix-editing-tf, public-indie-UI at 15:10 in web apps: http://lists.w3.org/Archives/Public/public-editing-tf/2014Oct/0016.html
# [23:06] * MaRakow dbaron, I think you mean [Tab said he thinks [] are fine for SASS and LESS.]
# [23:06] <dael> TabAtkins: In this case which character doesn't affect our users
# [23:06] * fantasai thinks we should wrap this up
# [23:06] * fantasai isn't hearing anything new
# [23:06] <SimonSapin> s/??/adenilson/
# [23:06] * Quits: Cyril (~chatzilla@public.cloak) (Client closed connection)
# [23:06] * Rossen_ grid-template-columns: (╯°□°）╯︵ ┻━┻first nav (╯°□°）╯︵ ┻━┻ 150px (╯°□°）╯︵ ┻━┻main (╯°□°）╯︵ ┻━┻ 1fr (╯°□°）╯︵ ┻━┻last (╯°□°）╯︵ ┻━┻;
# [23:06] * Joins: Cyril (~chatzilla@public.cloak)
# [23:06] * dauwhe first they came for my parentheses, and I said nothing as I still had brackets.
# [23:06] <dael> plinss: I think we need to be definitive that it's a future them that has to deal with this. If we do this the installed base of parens uses will keep growing. Even if we say yes but we reserve the right, but we're creating a world where that's harder.
# [23:07] <dael> TabAtkins: We canalways say screw it SASS.
# [23:07] * astearns that still uses parens, Rossen
# [23:07] <shans__> Rossen_: the only problem with that suggestion is that the closing tables need to be reversed
# [23:07] <dael> fantasai: If the choices were between SASS fixes or we use names, I would says SASS has to fix its stuff.
# [23:07] * dbaron ⸨didn't really⸩
# [23:08] <florian> 「I like this one」
# [23:08] <iank> ╯°□°）╯︵ ┻━┻ first nav ┻━┻ ︵╯）°□°╯(
# [23:08] <dael> TabAtkins: So, square brackets. Obj?
# [23:08] <dael> plinss: I object.
# [23:08] <dael> TabAtkins: You object to future problems.
# [23:08] <dael> fantasai: I think we switch to sq brackets and tell SASS that if we have this problem again they have to fix it
# [23:09] * Joins: jcraig_ (~jcraig@public.cloak)
# [23:09] <hiroshi2> I think, to think about SASS users and scripts are important. but the time to take effects this parens would take some time. so, now we can ignore about sass. (SASS can moderate this change)
# [23:09] <dael> TabAtkins: Remember future us has never treated past us's resolutions as unchangable
# [23:09] * Quits: shans__ (~shans@public.cloak) (Client closed connection)
# [23:09] <dael> fantasai: So resolve switch grid line naming to square brackets and tell SASS that in the future they'll have to deal with it.
# [23:10] <dael> rossen: Can we do a straw poll to see if others are objecting?
# [23:10] <dael> glazou: I'd like to hear precisely.
# [23:10] <dael> plinss: Is anyone else obj to switching to suqare brakcets.
# [23:10] <dael> Rossen_: I'm with you on the basis to giving up parens yes. For a spec def that no one ships I don't care.
# [23:11] <dael> florian: You can buy into a slippery slope where it applys that.
# [23:11] <dael> plinss: No matter what we say we are.
# [23:11] <dael> TabAtkins: No we're not.
# [23:11] * Joins: shans__ (~shans@public.cloak)
# [23:11] <dael> plinss: If we're saying its a bad idea now it'll be worse later. And the amount of pain and size will get worse.
# [23:11] * Quits: smfr (~smfr@public.cloak) (smfr)
# [23:11] <dael> plinss: We're either forcing them to take pain now or force them to take a lot of pain later.
# [23:12] <dael> Rossen_: And you're saying if we use brackets here and need them again later we'll be inconsistent with ourselves.
# [23:12] * glazou is with plinss and objecting too
# [23:12] * Quits: jcraig (~jcraig@public.cloak) (Ping timeout: 180 seconds)
# [23:12] * jcraig_ is now known as jcraig
# [23:12] * ArronEi is also with plinss and objecting as well
# [23:12] <dael> fantasai: WE just did a coin toss to choose before and now SASS says we have a reasonf or you to go the other way. In the future we may need another type of grouping that's not sq brackets, then we can tell SASS they have to deal.
# [23:12] <leaverou> if in the future we have a similar discussion, there will also be the argument of consistency, i.e. "but we're already using brackets here and there"
# [23:13] <dael> fantasai: We're saying next time we have this problem they have to deal
# [23:13] <leaverou> so it essentially makes it more difficult to resolve to parens in the future
# [23:13] <dael> plinss: Do you believe SASS will make changes based on this?
# [23:13] <dael> fantasai: No.
# [23:13] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [23:13] * Quits: tantek (~tantek@public.cloak) (tantek)
# [23:13] * MaRakow expects a "deal with it" w3cmeme out of this
# [23:13] <dael> florian: As for it being worse in the future, this isn't obvious that SASS user base is growing faster than CSS.
# [23:13] <dael> plinss: SASS may go away, but another one may step in.
# [23:14] <dael> glazou: We have two arguements and no one is changing their mind. WE have at least three objections. Raise your hand if you're objecting to using square brackets.
# [23:14] <dael> TabAtkins: You're objecting to if we had picked brackets in the past.
# [23:14] * Joins: jcraig (~jcraig@public.cloak)
# [23:14] <dael> plinss: But if we had done the opposite we would be in the same place.
# [23:14] <dael> glazou: So let me see hands.
# [23:14] <dael> glazou: It's significant. It's too much.
# [23:15] * Joins: stakagi (~stakagi@public.cloak)
# [23:15] <dael> florian: We could use angle brackets, but it would inconv HTML users.
# [23:15] * Joins: jrossi (~jrossi@public.cloak)
# [23:15] <dael> dauwhe: This doesn't look like consensus.
# [23:15] <dael> TabAtkins: I really don't like it.
# [23:15] <dael> fantasai: People are objecting to changing.
# [23:15] <dael> TabAtkins: We can say in the future we can tell SASS to change.
# [23:15] <fantasai> fantasai: but not to brackets
# [23:16] <dael> plinss: We're telling SASS they made a mistake and they have to fix it now.
# [23:16] <fantasai> TabAtkins: Your preferences are path-dependent
# [23:16] <dael> glazou: We didn't choose to use the $ because it was used by preprocessors and we asked if they could change and they could not.
# [23:16] <dael> glazou: We cannot be blocked by a 3rd party
# [23:16] <dael> florian: It's about SASS users. Its inconvienet there.
# [23:17] <dael> bkardell_: If your arguement is true, we already blcoked ourselves.
# [23:17] <fantasai> could've just said script users need to use $$, just like in bash
# [23:17] <dael> bkardell_: If the arguement is we set a precident that we'll change, we already did it.
# [23:17] <fantasai> everyone else can use $
# [23:17] <dael> glazou: But we found another option
# [23:18] <adenilson> lets change from () to smiles (-: and :-)
# [23:18] <dael> bkardell_: Which we can do this again. If SASS had a WG rep they would have said they don't like parens
# [23:18] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [23:18] <dael> plinss: We're into our break. Lets go on break, meet back at 3:30ish. If we come back with changed minds we can revisit. Otherwise this is done.
# [23:18] * Quits: bradk (~bradk@public.cloak) ("Be back later ...")
# [23:19] * Joins: bradk (~bradk@public.cloak)
# [23:19] * Joins: smfr (~smfr@public.cloak)
# [23:19] * Joins: bradk_ (~bradk@public.cloak)
# [23:19] * Quits: bradk (~bradk@public.cloak) (Client closed connection)
# [23:20] * Joins: bradk__ (~bradk@public.cloak)
# [23:20] * Quits: bradk_ (~bradk@public.cloak) (Client closed connection)
# [23:21] * Joins: bradk___ (~bradk@public.cloak)
# [23:21] * Quits: bradk__ (~bradk@public.cloak) (Client closed connection)
# [23:22] * Joins: bradk____ (~bradk@public.cloak)
# [23:22] * Quits: bradk___ (~bradk@public.cloak) (Client closed connection)
# [23:23] * Joins: bradk_____ (~bradk@public.cloak)
# [23:23] * Quits: bradk____ (~bradk@public.cloak) (Client closed connection)
# [23:23] * Joins: bradk______ (~bradk@public.cloak)
# [23:23] * Quits: bradk_____ (~bradk@public.cloak) (Client closed connection)
# [23:24] * Joins: bradk_______ (~bradk@public.cloak)
# [23:24] * Quits: bradk______ (~bradk@public.cloak) (Client closed connection)
# [23:24] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [23:25] * Joins: bradk________ (~bradk@public.cloak)
# [23:25] * Quits: bradk_______ (~bradk@public.cloak) (Client closed connection)
# [23:29] * Quits: bradk________ (~bradk@public.cloak) (Client closed connection)
# [23:29] * Joins: bradk________ (~bradk@public.cloak)
# [23:31] * Quits: stakagi (~stakagi@public.cloak) ("Leaving...")
# [23:34] * Quits: lajava (~javi@public.cloak) (Client closed connection)
# [23:35] * Joins: lajava (~javi@public.cloak)
# [23:38] * Quits: jeff (jeff@public.cloak) (Ping timeout: 180 seconds)
# [23:40] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [23:42] * Joins: tantek (~tantek@public.cloak)
# [23:44] * Quits: Shige__ (~Shige@public.cloak) (Ping timeout: 180 seconds)
# [23:46] <astearns> one possible argument that brackets could be better - the names can be nested in a repeat function
# [23:46] <astearns> I find this: repeat(4, 10px [col-start] 250px [col-end])
# [23:46] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [23:46] <astearns> easier to read than this: repeat(4, 10px (col-start) 250px (col-end))
# [23:47] <shans__> astearns: me too
# [23:48] * Joins: florian (~Florian@public.cloak)
# [23:48] <bradk________> grid-template-columns: #first #nav 150px #main 1fr #last
# [23:49] * Quits: bradk________ (~bradk@public.cloak) ("Lingo: www.lingoirc.com")
# [23:49] * Joins: bradk (~bradk@public.cloak)
# [23:50] <bradk> test
# [23:52] <bradk> grid-template-columns: -id-first -id-nav 150px -id-main 1fr -id-last
# [23:52] * Joins: bobtung (~bobbytung@public.cloak)
# [23:53] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [23:53] * Joins: Shige (~Shige@public.cloak)
# [23:53] <shans__> grid-template-columns: \first nav/ 150px \main/ 1fr \last/
# [23:54] * Joins: song__ (~song@public.cloak)
# [23:54] <shans__> then you can have really happy grids:
# [23:54] * Joins: wilhelm (~wilhelm@public.cloak)
# [23:54] <shans__> grid-template-columns \m/ 150px \o/ 1fr \^/
# [23:54] <astearns> yay-notation
# [23:54] * Joins: florian (~Florian@public.cloak)
# [23:55] <dael> plinss: Other grid issues?
# [23:55] * Rossen_ grid-template-rows: 1fr minmax $min-content, 1fr$;
# [23:55] <dael> Rossen_: Did we close on the previous one?
# [23:55] <dael> gregwhitworth: It was no consensus.
# [23:55] * MaRakow Steve Holt!
# [23:55] <dael> plinss: What's next on grid?
# [23:55] <Rossen_> http://dev.w3.org/csswg/css-grid/#pagination
# [23:55] <dael> Rossen_: The one issue I wanted to cover is grid fragmentation which is something I added earlier today so I don't expect anyone to have reviewed it yet.
# [23:56] <dael> Rossen_: I can go over the proposed behaviour and explain some of the decisions.
# [23:56] * Quits: Cyril (~chatzilla@public.cloak) (Client closed connection)
# [23:56] <dael> Rossen_: So, for context, CSS grid is a layout mech that allows you to devide your area into rows and columns and define grid areas in between those and the content can influnce those by their size.
# [23:57] <dael> Rossen_: When we talk in terms of fragementation, it's not a use case where grid should be expected to work great.
# [23:57] * Joins: adenilson_ (~anonymous@public.cloak)
# [23:57] <dael> Rossen_: In other words, grid as a layout primitive in an ideal should be used in non-fragmented cases. It should be in the page, not across many pages.
# [23:57] <dael> Rossen_: With that in mind, our intent with the prop algo is we wanted to keep the areas as intact as poss.
# [23:58] * Quits: song_ (~song@public.cloak) (Ping timeout: 180 seconds)
# [23:58] <dael> Rossen_: That's why that algo is fairly simple. Any time you come across a row on a frag break, we would want to push that row to the next fragment.
# [23:58] <dael> Rossen_: The q is how you would resolve fr and auto row sizes b//c they depend on content and you might end up with reverse dependancy
# [23:59] <dael> Rossen_: The current algo resolvs grid in the first frag space, assuming it has a def width. Then we resolve all the fr and auto rows, then we would frag that layout.
# [23:59] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
# [23:59] * adenilson_ is now known as adenilson
# [23:59] <dael> Rossen_: Again, the question is what happens when a row gets to be fragmented. For ex it's the first row and it's long enough it needs to frag.
# Session Close: Tue Oct 28 00:00:00 2014

The end :)