/irc-logs / w3c / #css / 2012-10-28 / end

Options:

# Session Start: Sun Oct 28 00:00:01 2012
# Session Ident: #css
# [00:01] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 20 seconds)
# [00:08] * Quits: Kid (~Kid@public.cloak) ("Leaving...")
# [00:10] * Joins: Kid (~Kid@public.cloak)
# [00:17] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 20 seconds)
# [00:54] * Joins: dbaron (~dbaron@public.cloak)
# [00:59] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 20 seconds)
# [02:16] * Joins: cabanier (~cabanier@public.cloak)
# [03:33] * Joins: SimonSapin (~simon@public.cloak)
# [03:57] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 20 seconds)
# [04:20] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 20 seconds)
# [04:43] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [04:43] * Joins: cabanier (~cabanier@public.cloak)
# [05:07] * Joins: glenn (~gadams@public.cloak)
# [05:14] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 20 seconds)
# [06:12] * Quits: Kid (~Kid@public.cloak) ("Leaving...")
# [06:41] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 20 seconds)
# [06:53] * Joins: darktears_ (~darktears@public.cloak)
# [06:53] * Quits: {Darktears} (~darktears@public.cloak) (Ping timeout: 20 seconds)
# [07:24] * Joins: SimonSapin (~simon@public.cloak)
# [07:41] * Joins: dbaron (~dbaron@public.cloak)
# [07:48] * Quits: SamB_MacG5 (~SamB_MacG5@public.cloak) (Ping timeout: 20 seconds)
# [07:50] * Joins: SamB_MacG5 (~SamB_MacG5@public.cloak)
# [08:03] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 20 seconds)
# [08:34] * leaverou is now known as leaverou_away
# [08:40] * Joins: cabanier (~cabanier@public.cloak)
# [08:41] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 20 seconds)
# [09:09] * Joins: stearns (~anonymous@public.cloak)
# [09:14] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [09:15] * Joins: dbaron (~dbaron@public.cloak)
# [09:34] * leaverou_away is now known as leaverou
# [09:36] * Joins: florian (~florian@public.cloak)
# [09:37] * Joins: SimonSapin (~simon@public.cloak)
# [09:37] * Joins: antonp (~Thunderbird@public.cloak)
# [09:39] * Joins: Rossen (~Rossen@public.cloak)
# [09:44] * Joins: Koji (~koji@public.cloak)
# [09:44] * Joins: RRSAgent (rrsagent@public.irc.w3.org)
# [09:44] <RRSAgent> logging to http://www.w3.org/2012/10/28-css-irc
# [09:44] * Joins: TabAtkins_ (~TabAtkins@public.irc.w3.org)
# [09:44] * Joins: Zakim (zakim@public.irc.w3.org)
# [09:44] <TabAtkins_> ScribeNick: TabAtkins_
# [09:44] <plinss> rrsagent, make logs public
# [09:44] <RRSAgent> I have made the request, plinss
# [09:44] * Joins: glazou (~glazou@public.cloak)
# [09:44] * Joins: lstorset (~lastorset@public.cloak)
# [09:44] <TabAtkins_> Topic: Agenda
# [09:45] * Joins: jet (~jet@public.cloak)
# [09:45] <dbaron> http://wiki.csswg.org/planning/tpac-2012#agenda
# [09:45] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:48] <TabAtkins_> [discussion over what to discuss, given our attendance today]
# [09:49] * Joins: kazutaka (~yamamoto_kazutaka@public.cloak)
# [09:49] <TabAtkins_> Topic: Style attribute
# [09:50] <TabAtkins_> glazou: This doc should be a rec already.
# [09:50] <TabAtkins_> fantasai: There are still test failures.
# [09:50] <TabAtkins_> glazou: Right, but it's so simple, and so core. What can we do to fix this?
# [09:50] <TabAtkins_> dbaron: What do we fail? xml:base ordering?
# [09:50] <TabAtkins_> hober: WebKit fails some of the parsing tests related to braces.
# [09:50] <hober> http://test.csswg.org/shepherd/testcase/style-attr-braces-001/spec/CSS-STYLE-ATTR/owner/fantasai/
# [09:50] <fantasai> http://test.csswg.org/suites/css-style-attr/nightly-unstable/html4/toc.htm
# [09:51] <plinss> current results: http://test.csswg.org/harness/results/CSS-STYLE-ATTR_DEV/
# [09:51] <TabAtkins_> florian: None of those sound difficult to solve, just priorities, right?
# [09:51] <TabAtkins_> dbaron: Ours is a bit harder - we'd have to change the timing of how we parse attributes.
# [09:51] <TabAtkins_> dbaron: We *should* technically be doing it, but xml:base is pretty irrelevant, frankly.
# [09:52] <TabAtkins_> fantasai: I think we should fix the parsing issues, and then deal with xml:base somehow else - remove it as a normative part of the spec, and state that it's basically an implementation failure that's unrelated to the spec.
# [09:52] <TabAtkins_> dbaron: Could Trident pass this test suite?
# [09:53] <fantasai> http://test.csswg.org/harness/test/CSS-STYLE-ATTR_DEV/style-attr-cascade-006/
# [09:55] <TabAtkins_> TabAtkins_: As far as I can tell, Trident fails the first parsing test.
# [09:56] <TabAtkins_> florian: Okay, so it looks like we could probably just get people to fix the parsing attrs, then resolve xml:base to be non-normative?
# [09:56] <TabAtkins_> fantasai: Re: xml:base, the spec basically just defers to XML/HTML (the host language).
# [09:56] <TabAtkins_> fantasai: So you can make a good argument that this isn't a CSS issue, but rather an XML one.
# [09:57] <TabAtkins_> florian: So move the test to another spec?
# [09:57] <TabAtkins_> fantasai: Yeah.
# [09:57] <TabAtkins_> TabAtkins_: This should maybe be something to bring up in HTML, since if FF isn't passing xml:base tests in CSS, it's probably nonconformant to some part of HTML's XML parser in general.
# [09:58] <TabAtkins_> glazou: Okay, so let's get this done asap. This seems like another Rec at low cost for us.
# [09:58] <TabAtkins_> Topic: Writing Modes
# [09:58] <TabAtkins_> fantasai: Status is that Tab and I removed Appendix D (moved to Sizing spec) and fixed a lot fo errors in the orthogonal flow section.
# [09:58] <TabAtkins_> fantasai: Open issues are that UTR-50 is way out of date.
# [09:58] <TabAtkins_> fantasai: Second is the naming of directions.
# [09:59] <TabAtkins_> fantasai: Third is that jdaggett needs to figure out what issues he wants to file and we need to deal with them.
# [09:59] <TabAtkins_> fantasai: Fourth is taht there are a bunch of values in text-combine that aren't implemented, so we'll probably drop them to move to last call.
# [09:59] <TabAtkins_> Koji: For UTR-50, ??? and I had a conf call last week, and we're making progress toward an updated data file.
# [09:59] <TabAtkins_> Koji: There will be a UTC meeting next week and I'll be there, so the hope is that the updated draft with data will be published next week.
# [10:00] <TabAtkins_> fantasai: So we should publish an updated WD in conjunction with that, then request LC after everyone's had time to review it.
# [10:00] <TabAtkins_> florian: And that updated draft is considered good enough for our use?
# [10:00] <TabAtkins_> Koji: It's still a "proposed draft", which is similar to our WDs.
# [10:00] <TabAtkins_> fantasai: But it's not going to be horribly wrong, like our current data.
# [10:00] <TabAtkins_> Koji: The process is that the UTC releases the proposed draft, then there's a review period.
# [10:01] <TabAtkins_> Koji: If the review gives only small changes, they're made and it goes right to "Rec".
# [10:01] <TabAtkins_> Koji: If there's too much changes, there may be another proposed draft, and another review period.
# [10:02] <TabAtkins_> fantasai: For our purposes, any update that incorporates the fixes we need will be good enough. Any additional issues are their issues, not ours.
# [10:02] <Rossen> (re: http://test.csswg.org/harness/test/CSS-STYLE-ATTR) Trident 6, ie10 is passing it but we fail in Trident 5, ie9
# [10:03] <TabAtkins_> TabAtkins_: We can talk about the naming issues tomorrow, when Glenn is here.
# [10:03] <TabAtkins_> fantasai: the i18n group had an opinion too.
# [10:03] <TabAtkins_> Koji: What happened to the joint meeting with them?
# [10:03] <TabAtkins_> plinss: No reply from them.
# [10:03] * Joins: SteveZ (~chatzilla@public.cloak)
# [10:04] <TabAtkins_> fantasai: I think if we don't get a solid resolution on it this week it's okay - we can publish with it marked as an issue.
# [10:04] <TabAtkins_> fantasai: So we should still publish next week.
# [10:05] <dbaron> Koji: I would like the terminology issue split from writing modes.
# [10:05] <dbaron> fantasai: We can't write the spec without the terminology.
# [10:05] <TabAtkins_> fantasai: So maybe we can publish next week?
# [10:05] <TabAtkins_> florian: What about the text-combine issues?
# [10:05] <plinss> http://dev.w3.org/csswg/css3-writing-modes/
# [10:06] <TabAtkins_> fantasai: I'm okay to leave them in there for now. But we can bring them up.
# [10:06] <TabAtkins_> Koji: If you publish next week, I'm slightly concerned the UTR-50 data may not be available yet.
# [10:07] <TabAtkins_> fantasai: Okay. If necessary, we can delay for another week for their data. But we can't wait, like, another 3 months for them to publish. We've already been held up since June, when they decided the relevant things.
# [10:07] <TabAtkins_> Koji: For text-combine, you said you're going to leave it as an issue?
# [10:07] <TabAtkins_> fantasai: I'm okay with leaving it as an issue, or to just drop everything but "none" and "all" for now, since that's what's implemented.
# [10:08] <TabAtkins_> fantasai: So we'd drop text-combine-mode, and drop all values of text-combine-horizontal except "none" and "all". By "drop", I mean defer until level 4.
# [10:08] <TabAtkins_> florian: Dropping them just means you need more markup to do some things, but nothing is made impossible by their lack.
# [10:08] <TabAtkins_> fantasai: Right. And it's better to ahve that than to hold up the rest of the draft.
# [10:09] <TabAtkins_> florian: And the other property?
# [10:09] <TabAtkins_> fantasai: Leave it as "auto" for now. It just means the UA does whatever it thinks is smart.
# [10:09] <TabAtkins_> florian: Was there an issue with leaving the "no-compress" option in?
# [10:10] <TabAtkins_> Koji: There are a couple of unresolved issues with it.
# [10:10] <TabAtkins_> florian: Okay. Well, if no one implements it anyway, I guess we can push it to next level.
# [10:10] <TabAtkins_> glazou: Writing Mode is normatively linked from epub. You're the laiason for them. How will this affect epub3?
# [10:11] <TabAtkins_> fantasai: Not at all. epub3 profiled these properties - they only include the "none" and "all" values.
# [10:11] <TabAtkins_> glazou: Okay.
# [10:12] <TabAtkins_> RESOLVED: Defer to level 4 the 'text-combine-mode' property, and all values for 'text-combine-horizontal' except "none" and "all".
# [10:14] <TabAtkins_> RESOLVED: Publish a new WD of Writing Modes when UTC releases a new UTR-50 report, or Nov 15, whichever comes first.
# [10:16] <TabAtkins_> Topic: Text
# [10:16] <TabAtkins_> fantasai: Text and Text Decoration have been split.
# [10:16] <TabAtkins_> fantasai: text-justify needed more examples - this hasnt' been done yet.
# [10:16] <TabAtkins_> fantasai: Text Decoration is ready for FPWD, though.
# [10:16] <TabAtkins_> fantasai: I know of no open issues against Text.
# [10:16] <TabAtkins_> dbaron: how close is this to LC?
# [10:17] <TabAtkins_> fantasai: I think we can resolve to publish FPWD of Text Decor and WD of Text, then ask for LC of Text at the next telcon, after people have time to review.
# [10:17] <TabAtkins_> fantasai: Plan is that Koji and I will finish all the outstanding edits in the next week or two; things we've already decided, just need to write the text.
# [10:18] <TabAtkins_> fantasai: And with that publication, request everyone to review the draft and tell us how much time they need for LC.
# [10:18] <TabAtkins_> fantasai: Then the WG can request LC for both drafts.
# [10:18] * leaverou is there a link to the text decoration ED?
# [10:19] <leaverou> http://dev.w3.org/csswg/css-text-decor-3/
# [10:19] <TabAtkins_> fantasai: So if you ahve an issue, file it.
# [10:19] <TabAtkins_> fantasai: Otherwise, does anyone have an objection to publish FP/WD for both next week?
# [10:20] <TabAtkins_> RESOLVED: Publish Text Decor as FPWD and Text as WD for next week.
# [10:21] <TabAtkins_> florian: Side question - naming question? When do we do the naming switchover?
# [10:22] <TabAtkins_> plinss: We should verify with W3C about the TR naming, and do the whole switch at the same time as we publish these next drafts.
# [10:22] <TabAtkins_> Bert: You need a good reason to do a rename on TR.
# [10:22] <TabAtkins_> TabAtkins_: (Not really a rename - the old links will just redirect to the new locations.)
# [10:22] * sylvaing_away is now known as sylvaing
# [10:22] * Quits: Koji (~koji@public.cloak) (Ping timeout: 20 seconds)
# [10:23] <TabAtkins_> florian: The current naming convention is pretty inconsistent. We've now decided on a real convention, and we'd like to apply it across all of them, with redirects so content isn't lost.
# [10:23] <TabAtkins_> Bert: We had a rule already, but the names are just us. The names on /TR don't have a system. But putting in lots of redirects and such is expensive.
# [10:23] <TabAtkins_> TabAtkins_: Redirects are super cheap and easy, actually.
# [10:24] <TabAtkins_> Bert: But why did we want to do this?
# [10:24] <TabAtkins_> florian: The current naming patterns confuse people about "CSS3" and "CSS4", and are inconsistent with unleveled things. The new system keeps everything consistent.
# [10:24] <TabAtkins_> plinss: We also want to ahve shortnames that are unlevelled that redirect to the latest level of each module.
# [10:25] <TabAtkins_> Bert: We have that for CSS1 and CSS2. We can make one for CSS3 as well.
# [10:25] <TabAtkins_> plinss: We don't want a "CSS3" link. We want "/TR/css-writing-modes/" which redirects to "/TR/css-writing-modes-3/", etc.
# [10:25] <TabAtkins_> leaverou: If there's a Rec in level 3 and a WD in level 4, when does the unlevelled link switch over?
# [10:26] <TabAtkins_> fantasai: We switch when it reaches "Snapshot-level" stability.
# [10:26] <TabAtkins_> Bert: Well, I'm not going to ask. I don't think we should do this.
# [10:26] <TabAtkins_> plinss: We're not asking you to ask, we're asking you *who* to ask.
# [10:26] <TabAtkins_> Bert: Our webmaster.
# [10:26] <TabAtkins_> fantasai: I'll take an action item for it.
# [10:27] <TabAtkins_> ACTION fantasai to bug the W3C webmaster about setting up redirects for the Great CSSWG Renaming (immediately before LC, natch)
# [10:27] * trackbot noticed an ACTION. Trying to create it.
# [10:27] <trackbot> Created ACTION-512 - Bug the W3C webmaster about setting up redirects for the Great CSSWG Renaming (immediately before LC, natch) [on Elika Etemad - due 2012-11-04].
# [10:28] <TabAtkins_> plinss: There was an issue in the wiki about text decoration.
# [10:28] <TabAtkins_> fantasai: That was about the underline position thing, which we fixed a week or two ago.
# [10:28] <TabAtkins_> plinss: So no open issues?
# [10:28] <TabAtkins_> fantasai: None that i know of.
# [10:29] <TabAtkins_> Topic: Prioritization List
# [10:29] <TabAtkins_> glazou: Starting tomorrow we'll have intrustions from observers and other WGs, etc.
# [10:29] <TabAtkins_> glazou: probably better to do this while we have a quiet environment.
# [10:30] * sylvaing can't wait for the 'intruders' to peruse the IRC log
# [10:30] <TabAtkins_> glazou: Here's the aggregrated data from our survey.
# [10:30] <TabAtkins_> glazou: Not public yet, but I'll post it later today to www-style.
# [10:31] * Joins: krit (~krit@public.cloak)
# [10:31] <TabAtkins_> szilles: If you tried other formulas, what was the variance?
# [10:31] <TabAtkins_> glazou: Almost no effect on the top items, mostly just in the middle.
# [10:32] <TabAtkins_> florian: Picking up on a comment from dbaron earlier, there were a lot of specs that are *nearly* finished, and so high-priority to finish, but that I'm not really interested in personally. So I found it hard to rate things sometimes.
# [10:32] * krit do we have an agenda?
# [10:32] <TabAtkins_> glazou: Same as me - I had several sepcs that I thought were highly strategic for the WG, but that I don't personally care about.
# [10:32] * fantasai not really. no fxtf stuff today, though
# [10:33] <TabAtkins_> szilles: So that suggests that we might temporarily boost the priority of specs that are nearly out the door, just to finish them off. If that's accepted, I'm fine with this.
# [10:33] * krit fantasai thanks!
# [10:34] <TabAtkins_> glazou: There are a few poitns I'd like to draw from this.
# [10:34] <TabAtkins_> glazou: Whatever formula I used, TTA were always at the top.
# [10:34] <TabAtkins_> glazou: The layout modules are always in the top ten.
# [10:34] <dbaron> s/at the top/in the top 4/
# [10:34] <dbaron> s/layout modules/layout module (flexbox, multicol, regions, grid)/
# [10:34] <dbaron> s/layout module/layout modules/
# [10:34] <TabAtkins_> glazou: There's not a single level 4 in the top ones.
# [10:35] <fantasai> glazou: highest one ranges 17-30
# [10:35] <dbaron> 58 specs in list; 18 responses to survey
# [10:35] <TabAtkins_> glazou: 59 specs for a single group, even with all the people in this room, I think is far too much.
# [10:35] <TabAtkins_> glazou: We have the workforce to work on 12-15 specs. 59 is just crazy.
# [10:36] <TabAtkins_> glazou: I'm not saying we have to trash anything. I'm just saying we should put some of them into a fridge to keep them fresh, and resurrect them when we're ready only.
# [10:36] <TabAtkins_> glazou: Some of the level 4 specs are here when the level 3 still doesn't have a test suite.
# [10:37] <fantasai> TabAtkins_: Though mostly, this was because we deferred things from L3, so had to put them somewhere -- therefore started a level 4 draft
# [10:37] <TabAtkins_> glazou: I agree, but we ahve to care a bit more about the signals to the outside world.
# [10:37] <TabAtkins_> florian: I think it's not too important to publish a FPWD of things that we're not seriously pursuing yet.
# [10:37] * sylvaing would like to attend one f2f where we do not start a new draft
# [10:38] * sylvaing ...or three
# [10:38] <TabAtkins_> glazou: Even EDs are visible. We have a wiki for this kind of thing.
# [10:38] <dbaron> fantasai: wiki not a great place for spec test that's already been written but deferred
# [10:38] <TabAtkins_> szilles: No matter what we do, the public will be confused. We can mitigate this, though.
# [10:38] <TabAtkins_> szilles: I think it would be useful to have something on the public page that bullet-points what levels things are.
# [10:39] <TabAtkins_> szilles: I think trying to make our working process painful isn't the answer.
# [10:39] <TabAtkins_> florian: We have a disclaimer for things that are obsolete and very wrong.
# [10:39] * Quits: SamB_MacG5 (~SamB_MacG5@public.cloak) (Ping timeout: 20 seconds)
# [10:39] <TabAtkins_> florian: We can have one for the really immature drafts too.
# [10:40] <TabAtkins_> dbaron: We can make the title/h1 say "Material deferred from CSS-foo level 3 for future use".
# [10:40] <TabAtkins_> TabAtkins: Sounds good to me.
# [10:40] * Quits: krit (~krit@public.cloak) (Ping timeout: 20 seconds)
# [10:40] * Joins: krit (~krit@public.cloak)
# [10:40] <TabAtkins_> glazou: I remind you that I heard at TTWF that things on dev.w3.org are better than /TR.
# [10:41] * Joins: SamB_MacG5 (~SamB_MacG5@public.cloak)
# [10:41] * Joins: Koji (~koji@public.cloak)
# [10:41] <TabAtkins_> glazou: So I don't want things looking better when they're experimental versus real specs.
# [10:41] <fantasai> fantasai suggests using the GeoCities stylesheet
# [10:41] <TabAtkins_> glazou: Continuing, the bottom of the table doesn't change very much.
# [10:42] <TabAtkins_> glazou: Some of these I didn't include in the original email, so their numbers aren't reliable.
# [10:42] <TabAtkins_> TabAtkins_: Could you mark the rows specially for those that weren't in the original email?
# [10:43] <TabAtkins_> dbaron: Also, can we have a column that's just a straight sum of responses? Most of them have 18, some have 17, but some have next to none.
# [10:43] * Quits: SamB_MacG5 (~SamB_MacG5@public.cloak) (Ping timeout: 20 seconds)
# [10:43] <TabAtkins_> glazou: Speech is strongly at the bottom, even though it's a CR.
# [10:44] <TabAtkins_> chris: If you have a spec with one strong editor and it's also the prime implementor, that's what you expect.
# [10:44] <TabAtkins_> glazou: So what do we do about it?
# [10:44] * Joins: SamB_MacG5 (~SamB_MacG5@public.cloak)
# [10:44] <TabAtkins_> fantasai: I think we leave it in CR and let the people who are interested in it write tests and such.
# [10:44] <TabAtkins_> fantasai: Speech is quite different from the rest of the specs, different canvas and such.
# [10:45] * sylvaing +1 to fantasai
# [10:45] <TabAtkins_> glazou: I want to avoid 8 years of CR.
# [10:45] <TabAtkins_> dbaron: The 8 years of CR was an issue because we had a spec we all actually cared about. It's not a problem for Speech.
# [10:46] <TabAtkins_> szilles: I think it's the role of the chairs to discuss with the champion what their plans are for the spec. I agree that simply leaving it isn't the responsible thing to do.
# [10:46] <TabAtkins_> szilles: I mean, if we can't find a second implementor, but still believe it's implementable, we could change our CR exit criteria.
# [10:47] <TabAtkins_> chris: One thing we could do is talk to the WAI people and say "hey, we have this spec which could probably help you", and see if they have any implementor interest, and say that if we don't get any movement in two years or so we can move it back to Note, and see what happens.
# [10:47] <TabAtkins_> fantasai: I think it's a good thing to have a normative definition of what we think Speech should be done.
# [10:47] <TabAtkins_> fantasai: We currently have a Rec (CSS 2.0) that is definitely *not* what we want to do.
# [10:48] <TabAtkins_> fantasai: I think it's great to pursue the people who are interested and see if they're willing to help get it to CR, but I don't think we should be afraid to leave it at CR as the right way to implement for people that care.
# [10:49] <TabAtkins_> szilles: Two impls are definitely preferred, but one is technically sufficient for a standard.
# [10:49] <TabAtkins_> florian: So I think we should support a low-prio spec like that as long as they don't eat too much time.
# [10:50] <TabAtkins_> TabAtkins_: Agree, and Speech hasn't needed much input for a while anyway.
# [10:50] <TabAtkins_> glazou: Back to the list, the takeaway is that the top and bottom don't change much regardless of your ranking formula, but the middle does.
# [10:50] <TabAtkins_> glazou: So there are definitely some specs that are *clearly* something the WG should work on.
# [10:51] <TabAtkins_> glazou: So TTA is clearly the highest priority of all.
# [10:51] <TabAtkins_> glazou: So whoever you are, help TTA get out as a Rec asap.
# [10:51] <TabAtkins_> glazou: Flexbox is the 2nd or third spec in the list no matter what we do. Strong interest from all vendors.
# [10:52] <TabAtkins_> TabAtkins_: On that, I should have a test suite written by the end of the year.
# [10:52] * sylvaing suggests we do not rename specs in the top tier of the list :)
# [10:52] * Joins: glenn (~gadams@public.cloak)
# [10:53] <fantasai> discussion of tests for flexbox
# [10:53] <fantasai> glazou: top 10 here, almost whatever I do, is the same
# [10:53] <fantasai> glazou: nearly all members agree on these 10
# [10:53] <fantasai> glazou: I think we should focus our time, energy, conf calls, on these ones if we can
# [10:54] <fantasai> glazou: to solve technical issues, discuss them, make them move, etc.
# [10:54] <fantasai> glazou: asap
# [10:54] <TabAtkins_> dbaron: One question about the responses.
# [10:54] <TabAtkins_> dbaron: Were these all one response per member company?
# [10:54] <TabAtkins_> glazou: Yes.
# [10:54] <TabAtkins_> leaverou: I think me and Bert both answered.
# [10:55] <fantasai> leaverou: because you asked me to reply on behalf of the authoring community
# [10:55] <fantasai> glazou: yes, tha'ts fine. W3c is a bit special in this regardl. You're more similar to an invited expert in this regard
# [10:55] <TabAtkins_> glazou: A few personal surprises.
# [10:55] <TabAtkins_> glazou: I was surprised to see Device Adaptation lower than I thought.
# [10:55] <TabAtkins_> glazou: I was surprised to see 9 very strong interest for Regions.
# [10:56] <TabAtkins_> glazou: I was also a little puzzled to see more interest for Transforms than for Trans/Anim.
# [10:57] <SimonSapin> that was me (and public)
# [10:57] <TabAtkins_> glazou: So I'd like us to use the top of this table to focus our effort in the coming months. Not 100%, but high prio.
# [10:57] * sylvaing would be interested to see browser vendor responses vs. everyone else
# [10:57] * sylvaing (everone else including browser vendors i.e. browser makers compared to all)
# [10:57] <TabAtkins_> chris: typically the conf call agenda is just whatever has been talked about this week. Will this change to have the top-prio things showing up, even with just a progress report request?
# [10:58] <TabAtkins_> glazou: I think it might change a little bit, but not much.
# [10:58] <TabAtkins_> glazou: But like, if we have a request for 20 minutes for OM Values or something, not much chance, unless we just have a slow week.
# [10:59] <TabAtkins_> chris: Maybe a monthly roundup of all the major specs?
# [11:00] <TabAtkins_> dbaron: If we spend conf time on regular "simple updates", I think it's a waste of conf call time, and will stop attending conf calls. I've done it in the past when we'd done something like this.
# [11:00] <TabAtkins_> stearns: One thing that coudl take up conf time if the survey hasn't gotten any updates in six months or something.
# [11:00] * lstorset FYI TabAtkins_, Opera's Flexbox test suite is submitted at http://test.csswg.org/shepherd/search/testcase/spec/CSS3-FLEXBOX/owner/oyvind/load/t135/
# [11:00] <TabAtkins_> dbaron: We could have something on the agenda that points to a wiki page and requests updates, for example.
# [11:01] <TabAtkins_> dbaron: Even brainstorming is sometimes okay. But it's the repeated "no updates this week" for 15 minutes each week.
# [11:01] <TabAtkins_> stearns: I was more thinking of public shaming to induce people to work on it.
# [11:01] <TabAtkins_> dbaron: Nont a good use of conf call time. Do it in email.
# [11:01] <TabAtkins_> hober: Or Twitter.
# [11:02] <TabAtkins_> fantasai: On the topic of the top 3 specs, what *is* the hold up?
# [11:02] * sylvaing I shame people for renaming stuff. It only resulted in more renaming...
# [11:02] <TabAtkins_> arronei: I know one of the specs has a bunch of open issues.
# [11:03] * TabAtkins_ sylvain, when will you be here?
# [11:03] <sylvaing> Animations/Transitions have 30 open issues each (vs. 60-80 a year ago). Need to work through them.
# [11:03] <sylvaing> hopefully 2pm-ish today
# [11:05] <TabAtkins_> We were going to discuss adding me as a co-editor, so dbaron wanted you here to help.
# [11:05] * hober sylvaing: i'd prefer we do tta stuff either tomorrow or tuesday, when dean is here
# [11:06] * krit hober tta?
# [11:06] * hober transforms, transitions, and animations.
# [11:07] * krit didn't we want to wait for smfr for transforms?
# [11:07] * hober yup
# [11:07] * sylvaing that sounds fine to me; I'd like to dean tobe there as well
# [11:08] * sylvaing open css3-animations issues https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=Animations&resolution=---&list_id=1151
# [11:09] * sylvaing tracking progress by spec section here https://docs.google.com/spreadsheet/ccc?key=0Akz3Ts2PEQF2dFVua2toVjBtam9rd3h4LXJSTVdCV2c#gid=0
# [11:09] * krit sylvaing :(
# [11:09] * sylvaing krit, this is 1/3 of what we had at the last TPAC
# [11:09] * sylvaing never mind all the things we resolved on www-style
# [11:10] * krit sylvaing and still not in the spec? :)
# [11:10] * sylvaing things still not in the spec are all in bugzilla afaik
# [11:10] * sylvaing if you know otherwise, do ping me
# [11:11] * krit of course I would, but don't
# [11:11] * sylvaing i started the bugzilla tracking by going 3 years back and logging all the issues that were not edited
# [11:11] * sylvaing I believe I'm up to date but I could be wrong, though not by much
# [11:12] * krit lot of work, I know :/
# [11:13] * krit Can we have a rough agenda for the next days? I helps to focus on discussions
# [11:15] * sylvaing i think it's coming. weird day today I think because a lot of people are still on their way and haven't arrived.
# [11:16] * hober lots of people who were at ttwf are playing hooky today or at least this morning
# [11:17] * krit hides him self
# [11:17] * sylvaing hober, I don't think those organizing it are goofing off. it ended with a dinner last night so after wrapping up and packing they'll be traveling today.
# [11:18] * sylvaing other folks are flying in today (like @t I think)
# [11:22] * Ms2ger tries to remember how long it's been since the WG decided that TTA was absolutely top priority and would go to CR within weeks
# [11:22] * krit Ms2ger it will got to CR within weeks
# [11:23] * Ms2ger has heard this before...
# [11:23] * krit Ms2ger just some more weeks then most expected
# [11:23] <Ms2ger> If you had 60 issues a year ago, and 30 now...
# [11:23] <Ms2ger> Doesn't that mean you'll have them fixed in about a year?
# [11:23] * hober Ms2ger: I believe you're referring to the Paris F2F (late jan / early feb 2012 iirc)
# [11:24] * krit Ms2ger but we unprefixed. So can't be that bad, right?
# [11:24] * sylvaing there were 79 for animations. and no, i don't think it should take a year.
# [11:24] <Ms2ger> I would hope it doesn't take a year
# [11:24] <Ms2ger> But I'm not sure if I should believe it won't be
# [11:25] <Ms2ger> And let's be clear, the unprefixing happened *despite* the WG
# [11:25] <sylvaing> no, the WG approved it
# [11:25] <Ms2ger> Yes
# [11:26] <Ms2ger> The WG approved *after* browser vendors said they would unprefix regardless of what the WG would decide
# [11:26] <sylvaing> no, not what happened
# [11:26] <sylvaing> one vendor unprefixed in a beta build; chairs asked group what they wanted to do. group agreed to unprefix.
# [11:27] * krit wasn't it more -webkit- all the things?
# [11:27] * sylvaing yes, i think we're mixing threads here
# [11:28] * sylvaing or crossing the streams, ghostbusters-style
# [11:31] * Joins: arronei (~arronei@public.cloak)
# [11:31] <Ms2ger> Anyway, I'm glad to hear that actual work is going to be done on TTA, this time
# [11:32] <sylvaing> this time? actual work has been happening across all three specs.
# [11:32] <sylvaing> but all three had fallen so far behind impls that it hurts, yes
# [11:33] <fantasai> ScribeNick: fantasai
# [11:33] <fantasai> Topic: CSS3 Conditional
# [11:34] <fantasai> TabAtkins_: dbaron and I just need to figure out exact edits. But that's the only issue.
# [11:34] <fantasai> TabAtkins_: Talked about it in a telecon already
# [11:34] <fantasai> fantasai: Should do that this week, publish LC next week.
# [11:34] <fantasai> fantasai: So get edits done so we can resolve on Tuesday?
# [11:35] <fantasai> TabAtkins_: yep
# [11:35] <fantasai> florian: I raised an issue wrt grammar of @media and media queries
# [11:36] <fantasai> fantasai: Florian and I discussed this and, I told htat the best option would be for media queries to define the media_query_list production
# [11:36] <fantasai> fantasai: and css3-condition to reference it, and define the @media rule productions
# [11:36] <fantasai> fantasai: And I think that should solve that integration problem
# [11:37] <fantasai> dbaron and Florian discuss what needs to be edited for this to happen
# [11:37] <fantasai> Florian will update MQ4
# [11:37] <fantasai> to not define @media rule itself
# [11:38] <fantasai> Topic: CSS3 Sizing
# [11:38] <TabAtkins_> ScribeNick: TabAtkins_
# [11:38] <TabAtkins_> fantasai: The Sizing spec hasn't had *much* changes, but we added rules for the intrinsic size of multicol elements.
# [11:39] * Joins: kawabata (~kawabata@public.cloak)
# [11:39] <fantasai> TabAtkins_: The definitions there were derived by working through a case of multi-col inside a flexbox
# [11:39] <fantasai> TabAtkins_: http://dev.w3.org/csswg/css3-sizing/
# [11:40] <stearns> http://dev.w3.org/csswg/css3-sizing/#multicol-intrinsic
# [11:40] <fantasai> TabAtkins_: This has to handle four cases independently
# [11:40] <fantasai> TabAtkins_: A multicol with only column count, only column width, or with both
# [11:40] <fantasai> TabAtkins_: They size a little differently dpeending on how it works
# [11:40] <fantasai> TabAtkins_: As far as we can tell, this is the correct definition for handling in flexbox, so probably correct definition in general
# [11:41] <fantasai> TabAtkins_: We're wanting to take out parts of multi-col sizing rules in css3-multicol, defer to this
# [11:41] <fantasai> SteveZ: Is howcome ok with this?
# [11:42] <TabAtkins_> Bert: Why do you need to split out the calculationf or different types of boxes?
# [11:42] <TabAtkins_> Bert: multicol is just another type of block.
# [11:42] <TabAtkins_> fantasai: In a multicol element, if you want to make it as narrow as possible, but it says it's two columns, you need to be *double* the longest word.
# [11:43] <fantasai> bert: You just find the narrowest width that doesn't overflow
# [11:43] <fantasai> TabAtkins_: We want it to not require full layout
# [11:43] <TabAtkins_> Bert: That doesn't help with Grid or Tables.
# [11:43] <TabAtkins_> fantasai: I think Bert is saying the same thing as us, but from a different angle.
# [11:44] <TabAtkins_> fantasai: He's explaining the terms in general, but we're just laying down the algorithms for actually determining that.
# [11:44] <TabAtkins_> fantasai: The goal is to result in the width that satisfies your definition.
# [11:45] <TabAtkins_> TabAtkins_: Then that wouldn't be much of a spec. ^_^
# [11:45] <TabAtkins_> antonp: Is that needed in this spec? It seems that this should just be the general definitions.
# [11:45] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 20 seconds)
# [11:45] <TabAtkins_> dbaron: There are some cases that are genuinely ambiguous, so they do need definition.
# [11:46] <fantasai> dbaron: particularly wrt floats
# [11:46] <TabAtkins_> Bert: There are some cases, like legacy tables, whhich are just weird.
# [11:46] <antonp> i was thinking more about this spec being useful for where different layout aspects combine/conflict. But other specs should hanbdle the basics
# [11:46] <antonp> for themselves
# [11:46] <TabAtkins_> Bert: What I'd like for Grid is a new layout algorithm that gives you better tables.
# [11:47] <TabAtkins_> Bert: But all you need to say is the general definition.
# [11:47] * glazou noticed commits to css4-background and css3-hierarchies *5 minutes ago, you geeks ;-)
# [11:48] <fantasai> TabAtkins_: We want algorithms so that we have exact results
# [11:48] * Quits: Koji (~koji@public.cloak) (Ping timeout: 20 seconds)
# [11:48] <fantasai> Bert: There are better algorithms and faster algorithms, different algorithms
# [11:48] <fantasai> TabAtkins_: ... There's not a really obvious answer in some cases; haven't thought it through a ton. If we'd had a deifnition laid out against it, implementations can converge faster
# [11:49] <fantasai> Rossen: From implementation perspective, need to figure it out for each layout type differently
# [11:49] <fantasai> Rossen: Having it all summarized in one spot, is helpful
# [11:49] <TabAtkins_> s/.../For example, browsers give different widths to a floated multicol element, even though theoretically there's a single correct answer for it./
# [11:50] <fantasai> Rossen: Nice if each individual layout model has a section defining intrinsic sizes for that model
# [11:50] <fantasai> Bert: don't think it's needed
# [11:50] * Joins: ChrisL (clilley@public.cloak)
# [11:50] <fantasai> Rossen: Implementations need it, need clear definitions
# [11:50] <fantasai> Bert: Only algorithm that will give you the optimal answer will be trying all possible layouts
# [11:51] <fantasai> TabAtkins: We just need a definition that gives the correct answer
# [11:51] <fantasai> dbaron: Trying all layouts is not an answre. There are layouts that always overflow
# [11:51] <fantasai> Bert: it's not no overflow, it's minimizing overflow
# [11:51] * sylvaing "TRY ALL THE LAYOUTS" - Old performance proverb
# [11:51] <fantasai> TabAtkins: Trying all layouts is not a real answer.
# [11:51] <fantasai> dbaron: Brings up question of whether it's np-complete
# [11:52] * glazou thinks sylvaing is not sick enough to stop trolling ;-)
# [11:52] <fantasai> Rossen: Shrink-to-fit with shapes :)
# [11:52] <fantasai> Florian: An important question is there a single layout, or multiple layouts that solve the constraints
# [11:52] <fantasai> dbaron discusses a W-shaped graphed
# [11:53] * ChrisL changes topic to 'Computer Science chatroom'
# [11:53] <fantasai> Florian: when there are multiple equal minimums, do we wantt o pick one normatively, or say any one is fine?
# [11:53] <fantasai> TabAtkins: We want everyone to agree on the same answer
# [11:53] <fantasai> Florian: Then pick an answer, and explain consequences
# [11:53] * Zakim excuses himself; his presence no longer seems to be needed
# [11:53] * Parts: Zakim (zakim@public.irc.w3.org) (Zakim)
# [11:53] * sylvaing glazou, IRC log indicates staying in bed was the right move, sick or not :)
# [11:53] * sylvaing even Zakim is giving up
# [11:53] <fantasai> ....
# [11:53] * glazou sylvaing eheh
# [11:53] <fantasai> TabAtkins: Say that here's an aglorithm, you can optimize it however you want
# [11:54] <fantasai> TabAtkins: Algorithms are never normative except for their answers
# [11:54] <fantasai> Florian: I think the most interesting part of working through the algorithms is saying which out of multiple answers is the right one
# [11:54] <fantasai> glazou intervenes
# [11:54] * ChrisL ding ding round two
# [11:54] <fantasai> glazou: I'm not sure this is a very productive discussion
# [11:55] <fantasai> jet proposes discussing the travelling salesman problem instead
# [11:55] <fantasai> TabAtkins: Mostly we pulled from other specs, and just cleaned up definitions and put terminology other specs can hook into
# [11:56] <fantasai> TabAtkins: New thing is mainly multi-col
# [11:56] <fantasai> TabAtkins: If dbaron has a good eifntion for tables, we can put it in
# [11:56] <fantasai> TabAtkins: otherwise we'll leave it to the next timesomeone reimplements table layout
# [11:56] <fantasai> SteveZ: Can we resolve the goal we're trying to get to is an interoperable deifnitio of sizing?
# [11:56] * krit sylvaing: you too, Brutus? You too?
# [11:57] * sylvaing it appears the Cite Internationale has Bert's Cafe Contemporain. I think this is where you can order all the layouts
# [11:57] <TabAtkins_> fantasai: There is still the issue that Bert was discussing,w here you can have slightly better/worse results based on how much effor tyou're willing to put in.
# [11:57] <TabAtkins_> fantasai: For example, a multicol element with fixed height and all-spanners, and you want this to take up max-content size...
# [11:58] <TabAtkins_> fantasai: Figuring that out is iterative convergence, or you can do an estimation algorithm that is 3-pass and gets you close.
# [11:58] <TabAtkins_> fantasai: The different answers should be very close, but probably not exactly the same.
# [11:59] <TabAtkins_> szilles: What I was trying to get at with the resolution is that my observation is that users would prefer interoperable over better.
# [11:59] <TabAtkins_> Bert: Depends on how bad.
# [11:59] * Joins: Zakim (zakim@public.irc.w3.org)
# [11:59] * dbaron Zakim, remind us in 6 hours to go home
# [11:59] * Zakim ok, dbaron
# [12:00] <TabAtkins_> arronei: Tables are bad, but interoperable. People tweak until it looks right, and then can depend it to still be "right" for other browsers. Not a great situation, but worse than slightly better and not interoperable.
# [12:00] <TabAtkins_> plinss: There are cases like in print where you want things as pretty as possible, regardless of time, but that's not default.
# [12:01] <TabAtkins_> [talk about trading off constraints in printing]
# [12:01] * fantasai changes topic to 'CSSWG discussion'
# [12:03] * Ms2ger would think that people need consistency even more in printing
# [12:03] <TabAtkins_> fantasai: I think we can say that this spec is the minimum definition. If people can do better, that's fine, but having a minimum definition makes it less likely that people don't accidentally miss the effects of various constraints.
# [12:04] <fantasai> fantasai: esp when applied to complex layout models
# [12:04] <TabAtkins_> dbaron: The thing about this kind of pixel-perfect interop is that authors don't use tech quite the way we intend it.
# [12:05] <TabAtkins_> dbaron: The results when something is off may seem reasonable when the tech is used exactly as intended, but the reality is that it's used in lots of ways we didn't think of.
# [12:05] <TabAtkins_> dbaron: "Off" in odd situations can mean that the page completely overlaps, or overflows off the screen, or does something else that makes it unreadable. That's a problem today.
# [12:06] * fantasai would like to point out that pixel perfection is not achievable here, due to variation in things like fonts, font sizes, viewport sizes, line-breaking algorithms, hyphenation, etc.
# [12:06] <TabAtkins_> ChrisL: The user doesn't care if, given infinite computing power, you could find a situation that slightly doesn't overflow.
# [12:06] <dbaron> yeah, pixel-perfect wasn't really what I meant
# [12:07] <dbaron> more about getting the same layout concept
# [12:07] <TabAtkins_> fantasai: Let's not pretend that we're going to pixel perfection - line breaking is still undefined, after all.
# [12:08] <TabAtkins_> Rossen: In section 3.1 where you're defining keywords, there is a note for how you resolve double dependencies duringmeasuring in the case of percentages. I'd like to see that become normative instead of a note.
# [12:08] <fantasai> fantasai: The goal of this spec is to define a minimum level of interop, and to make sure the consequences of complex layout models are handled properly when sizing at intrinsic sizes
# [12:08] <fantasai> fantasai: We would like review that the spe chere is sane and achieves this goal.
# [12:09] <TabAtkins_> Rossen: All browsers resolve percentages to auto when they're computed against an intrinsic width.
# [12:09] <TabAtkins_> dbaron: FF does that for width, but not padding/margins.
# [12:09] <TabAtkins_> dbaron: We resolve the constrains backwards.
# [12:10] <dbaron> <div id="computemyintrinsicwidth"><div style="width:100px;margin-left:10%"></div></div>
# [12:10] <dbaron> Gecko makes the intrinsic width 111.11111px.
# [12:10] <TabAtkins_> Rossen: I don't want to go into too much details. There are testcases which will break this pretty quickly.
# [12:10] <TabAtkins_> dbaron: Tables also do this inversion.
# [12:11] <TabAtkins_> Rossen: This is just one of the things in intrinsic sizing that is often overlooked.
# [12:11] <TabAtkins_> Rossen: So this spec should define it.
# [12:11] <TabAtkins_> TabAtkins_: Yeah, we can try to promote that note into something normative.
# [12:11] <TabAtkins_> Bert: I have a note about the organization of this spec.
# [12:11] <TabAtkins_> Bert: It defines the width/height properties.
# [12:12] <TabAtkins_> Bert: But there are keywords also defined in Box Layout. Where should things be defined?
# [12:13] <TabAtkins_> fantasai: The old keywords are in 2.1. Intrinsic sizing defines the new keywords. I think Box will take both specs and combine them, superseding.
# [12:13] <TabAtkins_> fantasai: In the meantime, the Sizing spec is working "as 2.1, plus this stuff we're defining".
# [12:14] <TabAtkins_> florian: When Box is ready, it'll take over from both.
# [12:14] <TabAtkins_> szilles: It's no worse than 2.1, where bits are defined in other specs.
# [12:15] <TabAtkins_> TabAtkins_: Eventually, Box can normatively say that it supercedes 2.1 and Sizing for the definition of width/height.
# [12:15] <TabAtkins_> fantasai: And if necessary, we can rescind Sizing if necessary.
# [12:15] <TabAtkins_> leif: Is this why multicol sizing was here rather than Multicol?
# [12:15] <TabAtkins_> TabAtkins_: yes.
# [12:16] * Joins: kawabata (~kawabata@public.cloak)
# [12:16] * Quits: TabAtkins_ (~TabAtkins@public.irc.w3.org) ("Page closed")
# [12:16] * Joins: TabAtkins_ (~TabAtkins@public.irc.w3.org)
# [12:17] <TabAtkins_> Topic: CSS Collision
# [12:17] <TabAtkins_> florian: There's a link to the spec at the bottom of the wiki.
# [12:17] <stearns> http://lists.w3.org/Archives/Public/www-archive/2012Oct/att-0120/Overview.html
# [12:17] <TabAtkins_> florian: At the last f2f, we discussed a possible CSS property that would help deal with colliding thigns.
# [12:17] <TabAtkins_> florian: I've had limited time, but I've started a spec.
# [12:18] <TabAtkins_> florian: Basic idea is that you have a property 'collision' that can take "overlap" or "avoid". If two elements have "avoid", and they collide the one later in document order moves out of the way. The spec defines what "collide" means, and how they move.
# [12:18] <TabAtkins_> florian: So please review and give me feedback or ideas for things not yet defined.
# [12:18] <TabAtkins_> florian: This is not yet ready for FPWD. I'm not sure if it's ready for ED on dev.
# [12:19] * fantasai defers to dbaron on this
# [12:19] <TabAtkins_> TabAtkins_: I'm fine with ED. You can add the "not-yet-ready" notice that I've put on a few specs this morning.
# [12:20] <TabAtkins_> TabAtkins_: My opinion is that I simply cant' find anything that's not on dev.w3.org.
# [12:20] <TabAtkins_> szilles: Agree with Tab. I've got some specs there as well that are similarly not-yet-ready.
# [12:20] * TabAtkins_ BIG RED NOTICE: http://dev.w3.org/csswg/css3-hierarchies/
# [12:21] <TabAtkins_> dbaron: I'm not too excited about this draft, but with a big warning, I'm okay.
# [12:21] <TabAtkins_> florian: So with a big warning, we're okay with publishing an ED?
# [12:22] <TabAtkins_> Rossen: I think I'm interested in co-editting as well.
# [12:22] * glazou CSS WG welcomes W3C CEO in the meeting room...
# [12:22] * sylvaing I don't see any big red notice on Tab's link
# [12:22] * fantasai you need to enable CSS
# [12:22] * TabAtkins_ sylvaing, use a better browser.
# [12:22] * sylvaing make your notice work in all browsers
# [12:22] * sylvaing or better, test your stuff in more than WebKit
# [12:23] * TabAtkins_ it's HTML5 compliant!
# [12:23] * hober better yet, implement <details>
# [12:23] <TabAtkins_> szilles: Is this intended to cover floats?
# [12:23] <TabAtkins_> florian: yes, but perhaps by reference.
# [12:24] <glazou> <br type="lunch"/>
# [12:24] * TabAtkins_ sylvain,what browser *are* you using?
# [12:24] <TabAtkins_> it definitely shows up in IE.
# [12:24] <TabAtkins_> It's not *closable* like in real browsers, though...
# [12:24] * fantasai also tested opera and FF
# [12:25] * fantasai verifies that it is obnoxious in both
# [12:26] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 20 seconds)
# [12:26] * sylvaing Tab, take a wild guess
# [12:26] * Quits: lstorset (~lastorset@public.cloak) (Ping timeout: 20 seconds)
# [12:27] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [12:29] * Quits: SteveZ (~chatzilla@public.cloak) (Ping timeout: 20 seconds)
# [12:53] * Quits: TabAtkins_ (~TabAtkins@public.irc.w3.org) (Ping timeout: 20 seconds)
# [13:20] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 20 seconds)
# [13:48] * Quits: glazou (~glazou@public.cloak) (Ping timeout: 20 seconds)
# [14:22] * Joins: glazou (~glazou@public.cloak)
# [14:22] * Joins: glenn (~gadams@public.cloak)
# [14:25] * Joins: SteveZ (~chatzilla@public.cloak)
# [14:27] <ChrisL> scribenick: chrisl
# [14:28] * Joins: TabAtkins_ (~TabAtkins@public.irc.w3.org)
# [14:28] <ChrisL> Topic: Exclusions and shapes
# [14:28] <dbaron> Topic: Exclusions Open Issues
# [14:28] * Joins: arronei (~arronei@public.cloak)
# [14:29] <stearns> http://dev.w3.org/csswg/css3-exclusions/
# [14:29] * Joins: Rossen (~Rossen@public.cloak)
# [14:30] <ChrisL> Rossen: we have several issues, first is 15085
# [14:30] <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15085
# [14:30] <stearns> http://dev.w3.org/csswg/css3-exclusions/#wrap-through-property
# [14:30] <ChrisL> Rossen: do we need it? we think yes
# [14:31] <ChrisL> ... helful for implementations using exclusions, easy and natural way to prevent them affecting content
# [14:31] <ChrisL> ... magazine-like effects, see examples on wiki
# [14:31] <ChrisL> .. want to close the issue
# [14:31] <stearns> http://wiki.csswg.org/ideas/css3-exclusions-print-use-cases
# [14:32] <ChrisL> stearns: near the end there is an example with overlays of exclusions, some affect content and not others for layered effects. needs wrap-through
# [14:33] <ChrisL> Rossen: also exclusions overlapping other exclusions. Collision avoid/allow is different, this allows collision but does not affect the content
# [14:33] <ChrisL> ... can maybe move this into the new property
# [14:33] <ChrisL> florian: how does this differ
# [14:34] <ChrisL> Rossen: allows collision but content is not affected. Different, and needed. Want to resolve issue as 'yes we need the property'
# [14:34] <ChrisL> (no objections)
# [14:35] <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16437
# [14:35] <stearns> http://dev.w3.org/csswg/css3-exclusions/#wrap-flow-property
# [14:35] <ChrisL> resolved: bug 15085 closed, keep the wrap-through propoerty
# [14:36] <ChrisL> Rossen: this was already resolved but relates to top and bottom definition
# [14:36] <ChrisL> TabAtkins: its clearly not right
# [14:36] <ChrisL> .. at very least add before and after
# [14:36] <ChrisL> Rossen: ok
# [14:37] * sylvaing is now known as sylvaing_away
# [14:37] <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15087
# [14:37] <ChrisL> Rossen: Interaction of floats and exclusions
# [14:37] <stearns> http://dev.w3.org/csswg/css3-exclusions/#floats-and-exclusions
# [14:37] <ChrisL> ... section on exclusions and floats, 3.6 covers this
# [14:38] <ChrisL> Rossen: discussed at previous f2f and mailing list, no feedback. Can leave open, while people review the proposed solution
# [14:39] <ChrisL> stearns: Or we could close it, and re-ope if more specific issues arise
# [14:39] <ChrisL> Rossen: changed a year ago
# [14:39] <ChrisL> glazou: close it
# [14:40] <ChrisL> resolved: bug 15087 closed, it is explained in the spec section 3.6
# [14:40] <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15089
# [14:41] <ChrisL> stearns: shrink-to-fit circle with shape, not conent outside a shape
# [14:42] <ChrisL> Rossen: came up in Santa Clara, Bert or Howcome raised it, exploring shrink to fit inside a circle
# [14:42] <ChrisL> stearns: it was fantasai
# [14:42] * sylvaing_away is now known as sylvaing
# [14:42] <ChrisL> Rossen: have come up with *a* solution, not one that gives us exact content fitting in arbitrary shapes
# [14:43] <ChrisL> ... still do shrink to fit, apply min max sizing to original content box per 2.1
# [14:43] <ChrisL> ... then we apply the shape and resolve shape percentages against that box
# [14:43] <ChrisL> ... not perfect, circle will give overflow
# [14:43] <ChrisL> ... better than no shrink to fit at all
# [14:44] <ChrisL> Rossen; more elaborate solution which approximates tightly fitting content in arbitrary shapes is difficult to compute
# [14:44] <ChrisL> ... especially when the shapes are different inside and outside. its np-complete.
# [14:44] * ChrisL just try all the shapes
# [14:45] <ChrisL> Rossen: so do shrink to fit on box, [....]
# [14:45] <ChrisL> Rossen: author is asking for auto layout, and result is not optimal
# [14:46] <ChrisL> ChrisL: would like to see an example where it gives a resonable result
# [14:46] <ChrisL> szilles: would prefer to see underflow rather than overflow, can grow the box for the second iteration
# [14:47] <ChrisL> florian: so repeat and increase
# [14:47] <ChrisL> szilles: increase enough
# [14:47] <ChrisL> dbaron: sometimes increasing width increases height too eg images
# [14:48] <ChrisL> stearns: could evaluate percentage you get when applying the shape, as a first approximation
# [14:49] <ChrisL> Rossen: opposite is when there is a shape that extends out of the content box, will get underflow by default. Do you squeeze it?
# [14:49] <ChrisL> szilles: no
# [14:49] <ChrisL> Rossen: can look into adding one extra resize
# [14:49] <ChrisL> Rossen: any additional reservations
# [14:50] <ChrisL> Bert: some module has the 'change the fontsize' property
# [14:50] <ChrisL> aaron: text-size-adjust
# [14:50] <ChrisL> Bert: was discussed in context of justifying last line of a para, its the same problem
# [14:50] <ChrisL> Rossen: in those cases ppl will not rely on shrink to fit
# [14:51] <ChrisL> Rossen: if both are dependent on resizing we need to cut the dependency. its ok with only one extra lyout
# [14:51] <ChrisL> s/lyo/layo
# [14:51] <ChrisL> Bert: how does author express this?
# [14:52] <ChrisL> arronei; text-size-adjust
# [14:52] <ChrisL> Rossen: its not just text, it can be images
# [14:52] <ChrisL> stearns: needs additional steps for content fitting
# [14:52] <ChrisL> szilles: also for tab;les and line grid
# [14:53] * Joins: lstorset (~lastorset@public.cloak)
# [14:53] <ChrisL> ... keeping the lines aligned inside tables
# [14:53] <ChrisL> ... so don't change the line heights
# [14:54] <ChrisL> stearns: assume we will get to content fitting in a later spec
# [14:54] <ChrisL> Bert: maybe it was removed
# [14:54] <ChrisL> Rossen: ok so keep it open and add the solution we just agreed on, resolve it later
# [14:55] <ChrisL> arronei: original issue is resolved
# [14:55] <ChrisL> stearns: want the algo resolved and in the spec
# [14:55] <ChrisL> ChrisL: so keeping it open while spec text is proposed?
# [14:55] <ChrisL> Rossen: yes
# [14:55] * Quits: jet (~jet@public.cloak) (Ping timeout: 20 seconds)
# [14:56] <ChrisL> florian: could compare relative percentage coverage of box and shape to get estimate for second iteration
# [14:56] <ChrisL> Rossen: yes but putting triangles inside squares, its harder
# [14:57] <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15083
# [14:57] <ChrisL> Concerns over Error accumulation vs. performance
# [14:57] <ChrisL> Rossen: processing model was not in th spec when this was raised. Spec was updated Dec 2011
# [14:58] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [14:58] <ChrisL> Rossen: believe issue is currently resolved. Exclusions positioned out of flow require the extra layout pass
# [14:58] <ChrisL> ... in terms of performance, that is the best we can do
# [14:59] <ChrisL> ... there are cases where the position does not depend on the content so onlyone pass, as described in the spec
# [14:59] <ChrisL> Rossen: issue opena long time, spec updated to adress it a long time ago, wanrt to close it
# [15:00] * fantasai defers to dbaron on this one too :)
# [15:00] <ChrisL> resolved: bug 15083 closed as processing model is now described
# [15:00] <ChrisL> Rossen: if there are more specific issues, then raise them
# [15:01] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 20 seconds)
# [15:01] * sylvaing we can just try all the processing models!
# [15:01] <ChrisL> Bert: two passes is the minimum?
# [15:01] * Quits: krit (~krit@public.cloak) (Ping timeout: 20 seconds)
# [15:01] <ChrisL> Rossen: no its the maximum
# [15:02] <ChrisL> stearns: we need specific cases cited where two passes does not work
# [15:02] <ChrisL> ... if those cases are important enough to address
# [15:03] <ChrisL> florian: could add a 'take as long as you want' option, off by default
# [15:03] <ChrisL> Bert: not clear what the second pass is
# [15:03] <ChrisL> Rossen: its specified in the spec
# [15:04] * fantasai notes that column-balancing is multi-pass until it stabilizes
# [15:04] <ChrisL> Rossen: THAT IS A DIFFFERNT PART OF THE SPEC. THESE ARE SEPARATE PROBLEMS
# [15:04] * ChrisL OOPS CAPS SORRY
# [15:04] * Joins: krit (~krit@public.cloak)
# [15:05] <ChrisL> Rossen: error accumulation is the issue here, as exclusons accumulate it becomes significant
# [15:05] * Joins: antonp (~Thunderbird@public.cloak)
# [15:06] <ChrisL> ... so we favoured a more performant approach with a single pass that computes all the positions, then position all the exclusions, and then you are done
# [15:06] <ChrisL> ... if exclusions have prefefined positions you dont need the first pass which is the case here
# [15:06] * Quits: stearns (~anonymous@public.cloak) (Ping timeout: 20 seconds)
# [15:07] <ChrisL> florian: shrink to fit first and position later does not give extra iterations unless content of exclusion is generated using regions
# [15:08] <ChrisL> ... then the position and size of the exclusion change the content of the exclusion
# [15:08] * ChrisL head explodes
# [15:08] <ChrisL> Rossen: this is nothing new
# [15:08] <ChrisL> florian: multicol has same issue
# [15:08] * Joins: stearns (~anonymous@public.cloak)
# [15:09] <ChrisL> Rossen: done with issies, just brainstorming stuff
# [15:09] * fantasai agrees with Bert
# [15:09] <ChrisL> Bert: worried we close the door on future improvements
# [15:09] <ChrisL> Rossen: no, we closed the door on 'there is no processing model defined'. It favours a performant model
# [15:10] <ChrisL> ... we can add other models later, but we tried and did not come up with one
# [15:10] <ChrisL> stearns: Bert wants to ensure improvements are not disallowed. We can add text to the spc to clarify that.
# [15:11] <ChrisL> florian: how do you rest between a refinement and a random non-conforming change
# [15:11] <ChrisL> Bert: needs a lot of effort for shapes
# [15:11] <ChrisL> szilles: already have a bunch of properties to control that
# [15:11] <ChrisL> Bert: its not line by line
# [15:12] <ChrisL> SteveZ: can't define as 'always seek optimum', its a default algorithm
# [15:13] <ChrisL> florian: if we say 'must do at least as good as this' we need a measure of goodness
# [15:13] <ChrisL> stearns: place where content is laid out and shape should match. so it is reducing drift
# [15:14] <ChrisL> SteveZ: optimal is no underflow and no overflow
# [15:14] <ChrisL> TabAtkins: lets wait until a better algorithm is proposed and tested
# [15:14] <ChrisL> Bert: no single objective. Different products can have different objectives
# [15:15] <ChrisL> ... can use Tex algorithm, different weighting factors. people choose the best product for their needs
# [15:15] <ChrisL> ... like differing opinions on line breaking. same for balancing multicolumns
# [15:16] <ChrisL> florian: if there is a single possible way to define best, its ok. But if now, we can't say 'at least as good as' because it can't be tested or measured
# [15:17] <ChrisL> SteveZ: lets see what we get with the current algorithms, we need experience
# [15:17] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 20 seconds)
# [15:17] <ChrisL> Topic: Line module
# [15:18] <stearns> http://dev.w3.org/csswg/css3-linebox/
# [15:18] <ChrisL> SteveZ: http://dev.w3.org/csswg/css3-linebox/#inline1
# [15:19] <ChrisL> SteveZ: in bad need of a complete restructuringto make it understandable
# [15:19] <fantasai> +1 to that
# [15:19] <ChrisL> .. want to make it have a processing model, fefinitions, then details
# [15:19] <fantasai> s/fefinitions/definition/s
# [15:20] <ChrisL> ... some parts are not related to the line - text height and line-box-contain. mainly concerned with size of the content area that text takes up
# [15:20] <ChrisL> ... em-box or max ascender/descender. for background
# [15:21] <ChrisL> dbaron: is this about line height
# [15:21] <ChrisL> ... text does not have backgrounds. inline boxes do
# [15:21] <ChrisL> SteveZ: everyone is using ascender/descender so the black background actually covers the white text
# [15:22] <ChrisL> ... moz, ie safari and chrome all use asc=desc
# [15:22] <ChrisL> s/=/+
# [15:22] <ChrisL> dbaron: spec requires that
# [15:22] <ChrisL> SteveZ: not, it requires either that or em-box. So there is less need for the property as everyone uses the same in practice
# [15:23] <ChrisL> ... text-height is the easy one
# [15:23] * Joins: dbaron (~dbaron@public.cloak)
# [15:23] <ChrisL> SteveZ: will say explicitly that asc+desc is picked
# [15:24] <ChrisL> Bert: think you are saying the one people implemented is the one I don't like
# [15:24] <ChrisL> ... backgrounds will differ if multiple fonts used on one line
# [15:24] <ChrisL> (several) yes
# [15:25] <ChrisL> SteveZ: we don't need it for version 3, can put it back in if I am wrong. will copy the note from 2.1 but give the default that is used in practice
# [15:25] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 20 seconds)
# [15:25] <ChrisL> bert: I agree
# [15:25] <ChrisL> ... but would rather the default was 1em
# [15:26] <ChrisL> SteveZ: went in neutral but all the implementations oicked one of the two allowable ways
# [15:26] <ChrisL> florian: a default that is different from what everyone implements is no use
# [15:26] * Joins: JohnJansen (~JohnJansen@public.irc.w3.org)
# [15:27] <ChrisL> SteveZ: vendors are not clamouring for a new property. want to focus on what it implemented now and get it done
# [15:28] <ChrisL> SteveZ: so, line-box-contain
# [15:28] <ChrisL> http://dev.w3.org/csswg/css3-linebox/#LineStacking
# [15:28] <ChrisL> SteveZ: non-replaced and replaced elements work differently, these were suboptimal cjhoices so this property lets you specifiy different things in the computation
# [15:29] <ChrisL> ... eg use font size rather than line-height
# [15:29] <ChrisL> dbaron: its the ascender=descender size
# [15:29] <ChrisL> s/=/+
# [15:29] <ChrisL> SteveZ: did not see a resolution
# [15:30] <ChrisL> dbaron: hyatt did this in webkit with a prefix
# [15:30] <ChrisL> ... it was my proposal as an alternative to line stacking strategy
# [15:30] <ChrisL> ... browsers all need this internally to handle quirks mode rendering
# [15:32] <ChrisL> SteveZ: so looking for confirmation that this needs to remain in the level 3 standard
# [15:32] <ChrisL> dbaron: was never super keen on it as i didlike mode selector properties
# [15:32] <ChrisL> ... but don't see an alternative here
# [15:33] <ChrisL> fantasai: coould apply to inline level elements
# [15:33] <ChrisL> dbaron: applies to both inlines and blocks
# [15:34] <Ms2ger> s/didlike/dislike/
# [15:34] <ChrisL> SteveZ: will liik in line stacking stategy for reusable bits but it may be we are already committed
# [15:35] <fantasai> dbaron^: Deifnitely applies to blocks. Question is whether it applies to both inlines and blocks
# [15:35] <ChrisL> SteveZ: we have the general problem, related to line grid
# [15:35] <ChrisL> bert: doesn't line grid solve all the problems?
# [15:35] <fantasai> dbaron^: Have gone back and forth on this. Not a problem from implementation perspective, just from "what controls do we want to provde" perspective
# [15:36] * Quits: florian (~florian@public.cloak) (Ping timeout: 20 seconds)
# [15:36] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 20 seconds)
# [15:36] <ChrisL> SteveZ: for ruby its assumed the line spacing is enough that the ruby will fit
# [15:36] <ChrisL> TabAtkins; (editorial comment)
# [15:36] <ChrisL> (various) dude this text is mostly from like 2001
# [15:37] * Joins: SimonSapin (~simon@public.cloak)
# [15:37] * Joins: florian (~florian@public.cloak)
# [15:37] <ChrisL> koji: found a webkit bug on this
# [15:37] <hober> https://bugs.webkit.org/show_bug.cgi?id=56388
# [15:37] <ChrisL> (scribe missed bug number)
# [15:37] * Joins: Koji (~koji@public.cloak)
# [15:38] <Koji> webkit bug for line-box-contain: https://bugs.webkit.org/show_bug.cgi?id=56388
# [15:38] <ChrisL> TabAtkins, : in sizing, new keyword repudiate-floats needs a better name
# [15:38] * sylvaing theme of the day could be 'size matters'
# [15:39] <ChrisL> (everyone) stupid name!
# [15:39] <ChrisL> break
# [15:39] <dbaron> fill-inside-floats
# [15:39] <antonp> squish
# [15:39] <ChrisL> (many longer and multi hyphenated names proposed, all of which suck)
# [15:40] <dbaron> except, actually, what you often want is:
# [15:40] <dbaron> min(fill-available, max(min-content, fill-inside-floats))
# [15:40] <dbaron> I think
# [15:40] * fantasai sylvain, should I put that in the title of the minutes? :)
# [15:40] <ChrisL> Topic: CSS3 Page
# [15:40] <ChrisL> (break abandoned)
# [15:41] <ChrisL> zakim, who is speaking?
# [15:41] <Zakim> sorry, ChrisL, I don't know what conference this is
# [15:41] <TabAtkins_> dbaron, that's exactly the definition in the spec. ^_^
# [15:41] <ChrisL> spec has an algo with adaprive optimisation
# [15:41] * sylvaing fantasai, i tried to set the IRC topic to that but I'll take the minutes
# [15:41] * dbaron SimonSapin is speaking
# [15:41] * leaverou is now known as leaverou_away
# [15:41] * fantasai changes topic to 'CSSWG discussion: size matters'
# [15:42] <ChrisL> SimonSapin: this is not what people do, its too hard to implement
# [15:42] * leaverou_away is now known as leaverou
# [15:42] <ChrisL> fantasai: margin box sizing rules in paged media spec
# [15:42] <ChrisL> s/spec has/SimonSapin: spec has/
# [15:43] <ChrisL> fantasai: algorithm is quadratic
# [15:43] <ChrisL> dbaron: in what?
# [15:43] <dbaron> s/in what/quadratic in what/
# [15:43] <ChrisL> SimonSapin: need to minimise square values of margin
# [15:44] <ChrisL> TabAtkins: we can minimuise linear measures but not squares so we iterate and hope to converge
# [15:44] <ChrisL> SimonSapin: spec does not say which values to pick
# [15:45] <ChrisL> fantasai: sp spec the text, put it in and then we can publish a WD as the other pendin gedits are done
# [15:45] <ChrisL> s/in ged/ing ed
# [15:45] <ChrisL> SimonSapin: second issue is initial containing block
# [15:45] <stearns> http://lists.w3.org/Archives/Public/www-style/2012Oct/0769.html
# [15:46] <ChrisL> ... apprantly, in pages we have a different idea of what it should be, eg based on first page even if other pages are different sizes so we need multiple values for this
# [15:46] <ChrisL> ... in general ICB with pages is fuzzy
# [15:47] <ChrisL> fantasai: one for normal flow and another for abspos
# [15:47] <ChrisL> ... we have an open issue on that
# [15:47] <ChrisL> stearns: decision for pages would apply to regions as well?
# [15:48] <ChrisL> antonp: ICB has been elevated to a status it does not deserve
# [15:48] * lstorset We need an ICBModule :)
# [15:48] <ChrisL> ... need to be open to a related but different concept
# [15:49] <ChrisL> TabAtkins: would this go in page?
# [15:49] <ChrisL> fantasai: paged media includes all of fragmentation, but poorly. Needs to be removed
# [15:50] <ChrisL> ChrisL: fragmentation sucks as a name btw
# [15:50] <ChrisL> (general disagreement)
# [15:51] <ChrisL> (real break this time)
# [15:51] <TabAtkins_> <br duration=900s>
# [15:55] * sylvaing with a name like that I will never ever take a fragmentainer seriously
# [15:58] * Quits: hober (~ted@public.irc.w3.org) (Client closed connection)
# [15:58] * Joins: hober (~ted@public.cloak)
# [16:16] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 20 seconds)
# [16:18] <antonp> ScribeNick: antonp
# [16:18] * Joins: arronei (~arronei@public.cloak)
# [16:18] <antonp> TOPIC: css3-box
# [16:18] <fantasai> ScribeNick: fantasai
# [16:19] <fantasai> Bert asks what the topics are
# [16:19] <fantasai> glazou reads from some list
# [16:20] * Ms2ger wonders if the time allocations for this f2f were made according to the priorities glazou asked for
# [16:20] <plinss> s/some list/the agenda/
# [16:20] * fantasai thinks it's completely random
# [16:20] * ChrisL @Ms2Ger kinda, yes
# [16:20] <fantasai> Bert: Question about direction to go in for centering
# [16:20] <glazou> Ms2ger: no ; it would not have been fair to do so before releasing the list first
# [16:20] <fantasai> Bert: We have in flexbox centering with auto margins, and ustification
# [16:21] * sylvaing We keep using this word, 'priorities'. I do not think it means what we think it does
# [16:21] <fantasai> Bert: But what do we do for things in normal flow?
# [16:21] <fantasai> Bert: How do we push Box to the bottom of a flow, for example?
# [16:21] <Ms2ger> glazou, I see; why not release the list first, then? :)
# [16:21] <fantasai> Florian: Wasn't there something in theAlignment module?
# [16:21] <glazou> sylvaing: want to bikeshed about that too ? ;-)
# [16:21] <glazou> Ms2ger: ask MSFT who answered late
# [16:22] <fantasai> Bert: One option is to extend properties in alignment module to apply to normal flow
# [16:22] * Ms2ger shakes his fist at Microsoft :)
# [16:22] <fantasai> Bert: Some text about that in the draft, leftover from before
# [16:22] <sylvaing> i'm pretty sure i answered quite some time before this meeting's agenda was set....
# [16:22] <fantasai> Bert: Another way would be to use auto margins, but not with auto margins keyword
# [16:22] <fantasai> Bert: my preference tis to use a keyword on the margins
# [16:22] <fantasai> Bert: But also other prposal to use alignm properties
# [16:22] <fantasai> Bert: I'm not quite sure how that works in the vertical direction
# [16:23] <fantasai> florian: There's a property called justify-self
# [16:23] <sylvaing> ...but I did question what the survey was really for. Now I remember why :)
# [16:23] <fantasai> Bert: That would work for horizontal direction, but how do I push tsomething down in vertical direction?
# [16:23] <fantasai> TabAtkins_: [...]
# [16:23] * sylvaing more seriously, we're missing a number of key people today so that's why animations and such are tomorrow
# [16:24] <fantasai> fantasai: Currently, the alignment module allows a box in nrmal flow to push its contents to the top or bottom, or to center it. Or even to justify it; if we want we can allow that
# [16:24] <fantasai> fantasai: There's no way to push a box down by itself
# [16:24] * plinss and some items are also scheduled for people to call in or attend other meetings
# [16:24] <fantasai> TabAtkins_: Can do that in flexbox with auto margins, though. I think that's what Bert is suggesting
# [16:24] <fantasai> Bert: yes
# [16:25] <fantasai> Bert: For example, I want to have a slide where I want the heading at the top, but the paragraphs centered in the middle
# [16:25] <fantasai> Bert: If I had an auto margin above/ below, coudl do that
# [16:25] <fantasai> Bert: Could do that in Flexbox, but this is just some normal text
# [16:25] <fantasai> Bert: Could maybe put a div around the paragraphs and centered that, but have to change the markup
# [16:26] <fantasai> Bert: also, want to center itbelow the heading, not across the whole side
# [16:26] <fantasai> Bert: Some examples I showed on slide...
# [16:26] <fantasai> Bert: Magazine where all columns have one paragraph aligned at the bottom
# [16:26] <fantasai> Bert: last paragraph is an address or summariy, that's always aligned at the bottom
# [16:26] <fantasai> antonp: In that sense very similar to flex layout
# [16:26] <fantasai> antonp: to do with spacing rather than to do with alignment
# [16:27] <fantasai> antonp: you could want both things, paragraph in the middle andparagraph in the bottom. Wouldn't solve the problem properly
# [16:27] <fantasai> antonp: Would want to combine several things
# [16:27] <fantasai> antonp: ... this is kindof how flexbox works
# [16:27] <fantasai> antonp: I suppose doing it on margin does make to me some sense
# [16:27] <fantasai> an but authors don't understand auto margins at all
# [16:27] <fantasai> antonp: it's very unexpected
# [16:27] <fantasai> Bert: Well, we have one similar case. Leaders work in horizontal direction
# [16:27] <fantasai> Bert: if you use two leaders, will center thing
# [16:28] <fantasai> Bert: Andrew Fedoniouk has %% unit that does similar things
# [16:28] <fantasai> Bert: Don't know what is most intuitive
# [16:28] <fantasai> Bert: Want it to be intuitive, but also powerful
# [16:28] <fantasai> Bert: leaders already compromised, e.g. can't align on a decimal point
# [16:29] <fantasai> Bert: I would want true centering in horizontal centering. if can do them the same way, could be elegant
# [16:29] <fantasai> Florian: What's missing from align-self: center true?
# [16:29] <fantasai> Bert: If it's defined to work for flow, that's good
# [16:29] <fantasai> fantasia: Not defined to work in Flexobx, but alignment module defines it for block flow
# [16:29] <fantasai> s/fantasia/fantasai/
# [16:30] <fantasai> s/Flexobx/Flexbox/
# [16:30] <fantasai> Florian: If we assume the alignment spec does what it says it does, the thing that's missing is magic margins
# [16:30] * Quits: krit (~krit@public.cloak) (Ping timeout: 20 seconds)
# [16:30] <fantasai> Florian: If we have these two things, do we solve the problems you're talking about?
# [16:30] <fantasai> Bert: Those are all the cases I've come across
# [16:30] <fantasai> SteveZ: One thing missing I don't want to tackle right now...
# [16:30] <fantasai> SteveZ: baseline alignment
# [16:30] <fantasai> SteveZ: If I push these pargraphs to the end, would want the last baseline to align across each of the paragraphs in the columns
# [16:31] <fantasai> SteveZ: there may be different sizes
# [16:31] <fantasai> St Line grid would do some of that, but not all of it
# [16:31] <fantasai> SteveZ: Inline blocks align on their last line.
# [16:31] <fantasai> SteveZ: Table cells align on their first line Ste
# [16:31] <fantasai> vhardy: probably would like some mechanims to say which line is used for alignment
# [16:31] <fantasai> s/vhardy/SteveZ/
# [16:31] <fantasai> SteveZ: ... eventually also want to talk about how to align initial caps, too
# [16:32] <fantasai> SteveZ: it's not always the baseline of the Nth letter, sometimes the top....
# [16:32] <fantasai> SteveZ: I think there's an opportunity in the long term for expanding basline alignment in that direction, but don't want to tackle it now
# [16:32] <fantasai> Florian: Are the things you're wanting to do eventually compatible with what we're doing now?
# [16:32] <fantasai> SteveZ: If you use springs-based approach, then baseline alignment would be an additional constraint to solve there
# [16:33] <fantasai> SteveZ: epends on how you solve things. But as long as it is a distribute-remaining-space kind of alignment, just need to specify order of relaxing overconstraints is
# [16:33] <fantasai> Bert: I guess that means wonce we have a line grid, we can't always increase margins; might sometimes decrease margin in order to align on the line grid
# [16:34] <fantasai> SteveZ: With line grids will very quickly get overconsrainted situations
# [16:34] <fantasai> Bert: Cases I've seen were pretty simple. Whole pages had same font size + line height
# [16:34] <fantasai> SteveZ: But you can easily see where the central paragraph would be in a larger font
# [16:34] <Ms2ger> s/wonce/once/
# [16:34] <fantasai> Bert: So, inline direction try a property, and maybe find a keyword for margins in vertical
# [16:35] <fantasai> antonp: it's been brought up on the list by Andrew the idea of spring units. But never gained any traction. But interesting idea.
# [16:35] <fantasai> antonp: Would be interested if anyone has any immediate "interesting, but doens't work ..."
# [16:35] <fantasai> antonp: reactions
# [16:35] <fantasai> TabAtkins_: Spring units are similar to flex, but don't normalize to fill all the free space unles sthey're overflowing
# [16:35] <fantasai> TabAtkins_: They will shrink but not grow to fill free space
# [16:36] <fantasai> TabAtkins_: means you can transition from zero to nonzero smoothly, which you can't do with flexbox
# [16:36] <fantasai> TabAtkins_: It's kindof not great. Investigated spring units while working on flexbox, but nobody that excited about it
# [16:36] <fantasai> SteveZ: Could you do it by adding a property interpreting flex units differently?
# [16:36] <fantasai> TabAtkins_: maybe. Would affet flex units less than one
# [16:37] <fantasai> fantasai: i would hesitate to add a mode-switching property, maybe a keyword on flex property
# [16:37] <fantasai> SteveZ: wouldn't want another unit
# [16:37] <fantasai> fantasai: could use the fr units, not using them atm :)
# [16:37] <fantasai> TabAtkins_: I don't like the name of the spec.
# [16:38] <fantasai> TabAtkins_: This is a block & inline layout spec
# [16:38] <fantasai> TabAtkins_: box is too generic
# [16:38] <fantasai> antonp: In my mind it's really two specs, but can't convince Bert :)
# [16:38] <fantasai> Rossen: Call it flow layout
# [16:38] <fantasai> Bert: Also talks aobutborders/padding/margin
# [16:39] * stearns hears chair snorting
# [16:39] <fantasai> antonp: It's got a lot of generic box-related stuff
# [16:39] * glazou plinss says "call it XSL"
# [16:39] <fantasai> TabAtkins_: I'd like to use box as name of a box-generation spec for generating the box tree
# [16:39] <SimonSapin> renaming yay!
# [16:39] * fantasai call it XBox, because anything with X is goingt o be really popular. Oh wait, that's already taken
# [16:40] <fantasai> sylvaing: Change the name at Lst Call. For sure.
# [16:41] <fantasai> [discussion of what to discuss; we wen through agenda already]
# [16:41] <stearns> http://lists.w3.org/Archives/Public/www-style/2012Sep/0304.html
# [16:41] <fantasai> Topic: css3-break
# [16:41] <fantasai> Alan: Have some issues
# [16:41] <fantasai> Alan: First issue is about zero-height fragmentainers
# [16:42] <fantasai> AlaIn Regions spec you can have a fragmenation context, content flows thorugh them
# [16:42] <fantasai> Alan: If you have a fragmentainer that has no area
# [16:42] <fantasai> Alan: Or too small to fit anything useful
# [16:42] <fantasai> Alan: Les than the next bit of monolithic content that can't be sliced
# [16:42] <fantasai> Alan: I'd lie to ignore that fragmentainer
# [16:42] <fantasai> Rossen: But then you're in an infinite loop
# [16:42] * glazou 's next proposed spec to thi group will be CSS Selectizors
# [16:43] <fantasai> dbaron: Might want different behavior depending on whether there's a taller fragmentainer later
# [16:43] <fantasai> dbaron: Similar problem if you have a line box taller than the page, but every page is the same height
# [16:43] <fantasai> dbaron: Need to force something on every page, to make progress
# [16:43] <fantasai> dbaron: Makes sense when you know that the next page has the same problem
# [16:43] <SimonSapin> I’ve had actual infinite loops like this in implementation
# [16:43] <fantasai> dbaron: But might to allow some heuristics
# [16:44] <fantasai> dbaron: If we have a 10-in item and 50 landscape pages, followed by portrait page, do you push to the landscape page and pritn 50 blank pages?
# [16:44] * hober plinss: we would need a pseudo to select the "this page intentionally left blank" box for styling it...
# [16:44] <fantasai> Alan: ... slicing deciion
# [16:44] * plinss agreed
# [16:44] <fantasai> Alan: If you decide not to slice, for whatever reason, would likeit not to consume e.g. any margin of stuff going into next fragmentatiner
# [16:45] <fantasai> fantasai: I remember Melinda raising this issue; can't remember thd iscussion that went with it
# [16:45] <leaverou> s/fragmentatiner/fragmentainer
# [16:45] <fantasai> Rossen: Really the behavior you're asking for is, your question is not whether or not we fragment monolithic elements that happen to be at the beginning of the fragment, but whether we have the ability to skip ahead, what dbaron was talking about
# [16:46] <fantasai> Rossen: This is not about fragmentation, but abou higher-level layout that deals with that
# [16:46] <fantasai> Alan: Think it's a fragmentation issue
# [16:46] <fantasai> fantasai thinks it belongs in the same spec anyway
# [16:46] * Joins: krit (~krit@public.cloak)
# [16:46] <fantasai> SteveZ: There's two questions: does the whole of the item fit here or not?
# [16:47] <fantasai> SteveZ: If not, what fits, and do you put it there.
# [16:47] <fantasai> Alan: The thing that does not fit, and at that point you have a decisioN: fit part of it or not
# [16:47] <fantasai> Alan: If you decide not to slice, want us to really stick with that decision not to slice and have it not consume any margin for the element that you decided not to slice, to ignore that fragmentatiner and be positioned in the next one
# [16:48] <fantasai> SteveZ: Tht goes to dbaron's comment: you need to know that somewhere in the future there will be a next fragmentatiner
# [16:48] <fantasai> Rossen: Then there's issue of always slicing, and still not making any progress: zero-height fragmentatiner
# [16:48] <fantasai> Rossen: Making zero-height slices means never making any progress
# [16:49] <fantasai> Rossen: Question of, if I'm fragmenting, need to consume something.
# [16:49] * hober http://en.wikipedia.org/wiki/Intentionally_blank_page
# [16:49] <fantasai> Rossen: currently odn't have anythign in spec that calls out exactly that.
# [16:49] <fantasai> Rossen: If on the next fragment you didn't make any progress [...]
# [16:49] <fantasai> Rossen: If you fragment and didn't make any progress, can assume current piece of content has been consumed. Then always assuming some kind of progress.
# [16:49] <fantasai> Rossen: Suppose you have a line, one character
# [16:50] <fantasai> Rossen: Zero-height fragemntainer.
# [16:50] <fantasai> Rossen: you have to make progres in the content.
# [16:51] <fantasai> Rossen: So if you consume zero height, make zero progress on your monolithic element, you need to assume that this element is consumed
# [16:51] <fantasai> Rossen: If you r fragments are the same
# [16:51] <fantasai> Alan: If there is no other fragmentainer in the fragmentation context that can retain the monoloithic element, need to bail
# [16:52] <fantasai> Florian: What if you have a seris of zero-height fragmentainers followed by a positive-height fragmentainer
# [16:52] <fantasai> Florian: Then you lose a bunch of content.
# [16:52] <fantasai> Florian talks about auto-height regions
# [16:52] <fantasai> Florian: with your algorithm things will disappear
# [16:53] * sylvaing as much as I like the idea of overflowing our alloted meeting time discussing fragments, i'm not sure this is going somewhere....
# [16:53] <fantasai> fantasai: An alternative to deal with this is to assume that each page makes at least X amount of progress, e.g. X=1px
# [16:54] <fantasai> Alan: In region chain case, if the rest of your region-chain is zero-height regions, then would prefer the last region to overflow
# [16:54] <fantasai> SteveZ: I'm very concerned about not showing the content
# [16:54] <fantasai> Florian: If you can eventually show something, probably should shjow it
# [16:54] <fantasai> Rossen: What you're saying makes sense for regions, but not pagination
# [16:55] <fantasai> Alan: I don't know that we'll make any progres on this today. Could we address this at least in part in the css3-break module? I can build on that in regions if we want regions be different
# [16:55] <fantasai> Florian: I don't think there's a conceptual differenc,e just more common for pages to be the same size and less likely to be zero-height
# [16:56] <fantasai> ..
# [16:56] <fantasai> Rossen: Same thing goes for multi-col, too
# [16:56] <fantasai> Rossen: If your columns are zero height, you know they will all be zero-height
# [16:57] <fantasai> ....
# [16:57] <fantasai> Rossen: There needs to be a notion that the fragmentainer knows if there are any fragments ahead that are able to consume content
# [16:58] <fantasai> fantasai: I think we need some concrete proposals here
# [16:58] <fantasai> [...]
# [16:59] <fantasai> SteveZ: One constraint is you're trying to make progress
# [16:59] <fantasai> SteveZ: Other is you want to fill the area
# [16:59] <fantasai> Florian: Third is you want to show the content
# [16:59] <fantasai> SteveZ: Decide order of decision-making from that
# [16:59] <fantasai> Bert: Another different case; if you have an infinite number of regsions, e.g. pages
# [16:59] <fantasai> Bert: If you have finite number of regions, might be different.
# [16:59] <fantasai> antonp: need to know whether ithere is a last region or not
# [17:00] <fantasai> ...
# [17:00] <fantasai> SteveZ: Need to know which order you relax constraints
# [17:01] <fantasai> fantasai: I agree it's an issue, but not going to make any progress without concrete proposals
# [17:01] * Quits: krit (~krit@public.cloak) (Ping timeout: 20 seconds)
# [17:01] * Joins: krit (~krit@public.cloak)
# [17:02] <fantasai> ...
# [17:02] <fantasai> alan like's steves approach
# [17:02] <fantasai> Bert: Boxes outside printable area, sometimes meant to be invisible, someteims contain something important. difficult decision whether it's just meant for bleeding, or an error case. We don't say what you do, just warn about that case.
# [17:03] <fantasai> ACTION Alan: propose handling for making progress in fragmentation
# [17:03] * trackbot noticed an ACTION. Trying to create it.
# [17:03] * RRSAgent records action 1
# [17:03] <trackbot> Created ACTION-513 - Propose handling for making progress in fragmentation [on Alan Stearns - due 2012-11-04].
# [17:03] <hober> http://xmlgraphics.apache.org/fop/fo.html#fo-blank-pages
# [17:03] <fantasai> plinss: Need a pseudo-selector for blank pages
# [17:04] <fantasai> fantasia: There's a proposal there in GCPM. Could pull it into css3-page
# [17:04] <SimonSapin> I actually implemented GCPM’s @page :blank … should I prefix it?
# [17:04] <fantasai> RESOLVED: Pull :blank into css3-page
# [17:05] <fantasai> Florian: I think the ansewr is, don't ask and don't prefix.
# [17:05] <stearns> http://lists.w3.org/Archives/Public/www-style/2012Oct/0428.html
# [17:05] <fantasai> Alan: Othe rbreak issue I had was, say you have a 2-column multicol element
# [17:06] <fantasai> Alan: And each column has a fragment
# [17:06] <fantasai> Alan: each fragment has a relpos element init
# [17:06] <fantasai> Alan: There's no spec that says where to position those relposed elements
# [17:06] <fantasai> fantasai: My position is you fragment, and then relpos is taken a sa graphical transformation of that
# [17:06] <fantasai> Alan: Would like that define
# [17:06] <fantasai> TabAtkins_: Other option is to relpos it first, then fragment it
# [17:07] * Quits: SteveZ (~chatzilla@public.cloak) (Ping timeout: 20 seconds)
# [17:08] <fantasai> SteveZ: relpos isn't really that useful for printing
# [17:08] <fantasai> plinss: There's also paged modes in browsers, too
# [17:08] <fantasai> fantasai: I stick by my original ansewr, treat it like transform
# [17:08] * Joins: jarek (~jarek@public.cloak)
# [17:08] <fantasai> Florian: Does anyone implement the other behavior?
# [17:08] <fantasai> Alan: webkit
# [17:09] <fantasai> TabAtkins_: Overall our fragmenting behavior is really shitty.
# [17:09] <fantasai> dbaron: Idea of relpos is you do it after layout
# [17:09] <fantasai> dbaron: This would break that
# [17:10] <fantasai> fantasai: fragmenting affects layout -- it changes the effective height of an element
# [17:10] <fantasai> TabAtkins_: ... you're right
# [17:10] <fantasai> RESOLVED: relpos after fragmentation
# [17:10] * Joins: glenn (~gadams@public.cloak)
# [17:11] <fantasai> TabAtkins_: On that topic... abspos, is that currently undefined?
# [17:11] <fantasai> [for regions]
# [17:11] <fantasai> Alan: It's defined, but defined badly
# [17:11] <fantasai> Alan: If you have abspos elements in the named flow, that don't have a parent that is relposed in the named flow, we use the box for the initial region. So everything piles up
# [17:12] <fantasai> fantasai: That's how it works for abspos currently
# [17:12] <fantasai> fantasai: The initial containing block is either the first page or the viewport before scrolling
# [17:12] <fantasai> fantasai: that gives your coordinate space
# [17:12] <fantasai> fantasai: you have something that flows below the bottom edge of that
# [17:12] <fantasai> fantasai: then it will paginate
# [17:13] <fantasai> antonp: I don't think that's defined
# [17:13] <fantasai> antonp: Do you have a parallel canvas that gets sliced across, for positioned elements
# [17:14] <fantasai> fantasai: In terms of 2.1, you have to have abspos elements fragemtn across pages because there are lots of websites out there that put everything in the page inside an bsolutely-positioned element
# [17:14] <SimonSapin> (Actually, I lied about WeasyPrint not being a browser … http://i.imgur.com/dSgNx.png )
# [17:14] <fantasai> fantasai: So if you can't fragment an abspos, then you can't print them
# [17:14] <fantasai> antonp: Asking not whether the element fragments, but whether the offset from the top fragments
# [17:14] <fantasai> fantasai: yes
# [17:15] <fantasai> antonp: need to define that more clearly
# [17:15] <fantasai> Florian: isn't that different from relpos?
# [17:16] <fantasai> fantasai: Yes, relpos is after fragementing, abspos before it
# [17:18] <fantasai> [discussion of relpos and whether something relposed down would show up on the next page]
# [17:19] <fantasai> plinss: If you have a spread, then relpos something to the side should show up on ther hafl of spread
# [17:19] <fantasai> plinss: visual arrangement of pages should be in pairs if double-sided
# [17:19] <fantasai> SteveZ: Need a concept of spreads. [...]
# [17:20] * fantasai is starting to feel sick...
# [17:20] <fantasai> plinss: Abspos canvas that slices... want to make sure we're not just literally slicing
# [17:20] * Joins: jarek__ (~jarek@public.cloak)
# [17:20] * Quits: jarek__ (~jarek@public.cloak) (jarek__)
# [17:20] * Joins: jarek__ (~jarek@public.cloak)
# [17:21] * Quits: jarek (~jarek@public.cloak) (Ping timeout: 20 seconds)
# [17:21] <fantasai> plinss: that we're fragmenting
# [17:21] * hober Who's dog is named Ab, and why do we care about his paws so much?
# [17:21] <fantasai> fantasai: No, you fragment it
# [17:21] <fantasai> fantasai: But this is very difficult for bottom-positioned abspos, because you have to fragment backwards.
# [17:22] <fantasai> antonp: It's not obvious to me... I agree with what we're deciding, but it needs to be defined
# [17:22] <fantasai> ?: What's the result on relpos?
# [17:22] <fantasai> fantasai: Open question is how do pages relate to each other in space
# [17:23] <fantasai> some discussion of bleeding
# [17:24] <fantasai> plinss: When you're pritning bleeds, e.g. I have a black box that's background of my page, I want it to print to edge fo paper. not going to print that 10inch, will print to near the edge of the page.
# [17:24] <fantasai> plinss: say only allow overflow, but only this much
# [17:24] <fantasai> plinss: Change sbounding area of where overflow becomes hidden
# [17:25] <fantasai> plinss: need some way to control that
# [17:25] <fantasai> ISSUE: define relation of pages in space, and how this interrelates with bleed
# [17:25] * trackbot noticed an ISSUE. Trying to create it.
# [17:25] <trackbot> Created ISSUE-283 - Define relation of pages in space, and how this interrelates with bleed ; please complete additional details at http://www.w3.org/Style/CSS/Tracker/issues/283/edit .
# [17:26] <fantasai> Florian: Any new thing on dbaron's overflow regions spec?
# [17:26] <fantasai> dbaron: Not really, though someone else said we should discuss it
# [17:27] <fantasai> dbaron: I don't have anything to say
# [17:27] <fantasai> Tp[oc" Pverf;pw regopms
# [17:27] <fantasai> Tab We tjoml we [refer s;ogjt;u tje pver;fpw regopms a[[rpacj tp tje exact sumtax tjat regopms os isomg rogjt mpw. becaise ot
# [17:27] <Ms2ger> fantasai, er...
# [17:28] <TabAtkins_> ms2ger, fantasai had a stroke.
# [17:28] * plinss scribe-transform: gibberish
# [17:28] * fantasai no, just off-by-one error
# [17:28] * sylvaing cthulhu fhtagn
# [17:28] <fantasai> Topic: Overflow Regions
# [17:29] <Bert> (Re relation in space: GCPM has 'overflow-style: paged-x' to say that pages are side by side instead of above each other, but that isn't powerful enough to say there are two-page spreads that are one above the other.)
# [17:29] <dbaron> just transform all the right hand qwerty keys one to the left
# [17:29] * sylvaing we are taking renaming to a whole new level
# [17:29] <fantasai> TabAtkins: We prefer the dbaron's overflow regions proposla to the syntax to the regions proposal, because it satisfies all the use cases we care about
# [17:29] * glazou changes topic to '#css We tjoml we [refer s;ogjt;u tje pver;fpw regopms a[[rpacj tp tje exact sumtax tjat regopms os isomg rogjt mpw. becaise ot'
# [17:30] <leaverou> s/proposla/proposal
# [17:30] <fantasai> Alan: It doesn't satisfy first example in the regiosn pec
# [17:30] <fantasai> TabAtkins: No, it's totally fine
# [17:30] <leaverou> s/regiosn/regions
# [17:30] <fantasai> Florian: Does it satisfy use case of parallel languages?
# [17:30] <fantasai> Florian; There's markup somewhere using page templates
# [17:30] <fantasai> Alan: Wnat to go back to 1st example
# [17:31] <fantasai> Alan: You have an element with overlfow; fragments
# [17:31] <fantasai> Alan: Andyou can style the various boxes that get generatied
# [17:31] <leaverou> s/overlfow/overflow
# [17:31] <fantasai> Alan: It generates lots of sibling
# [17:31] <fantasai> Alan: How do you position some of them not others?
# [17:31] <fantasai> TabAtkins pulls up the example
# [17:32] <fantasai> TabAtkins: You'd use a grid
# [17:32] <fantasai> Florian: You could also do it with multicol
# [17:33] <fantasai> TabAtkins: I think that would be awful
# [17:33] * glazou shall we declare 28 october the TALK_LIKE_ELIKA day for next years ?
# [17:33] <fantasai> SteveZ: What about page templates? Also use regiosn for page templates
# [17:34] * leaverou glazou: totally!
# [17:34] <fantasai> TabAtkins: The page template generates a bunch of pseudo-elements, attached to grid that template defines, define a region-chain
# [17:34] <fantasai> TabAtkins: You'd have to recast the semantics a bit, that the page template consumes overflow boxes
# [17:34] <fantasai> SteveZ, Alan: Interleaving example
# [17:34] <fantasai> Alan: Position of each, alternating threads,
# [17:35] <fantasai> TabAtkins: I Don't think that's problematic...
# [17:35] <fantasai> TabAtkins: I'm thinking that the interaction of grid ...
# [17:35] * Quits: Koji (~koji@public.cloak) (Ping timeout: 20 seconds)
# [17:35] <fantasai> TabAtkins: That grid can be appropriately powerful to handle this
# [17:35] <Bert> (Example of interleaving: 'p:even {flow: a} p:odd {flow: b}')
# [17:35] <fantasai> florian: To backtrack, you like dbaron's proposal because it solves all or many of regions use cases. Therefore, what?
# [17:36] <fantasai> TabAtkins: I believe dbaron's proposal is easier to understand an dimplement, and would prioritize it over Regions
# [17:36] <fantasai> TabAtkins: We believe that Regions is going ot keep our fuzzers busy for a long time
# [17:36] <fantasai> TabAtkins: This is just a more complicated version of multicol
# [17:36] <fantasai> TabAtkins: If we can simplify the implementation as much as possible, while maintaining as much power as possible, is beter b/c reduce number of crashers
# [17:37] <fantasai> TabAtkins: The technical weakness is that you can't start from multiple elements into single flow, then split across elements
# [17:37] <fantasai> TabAtkins: Regions give you many to many. dbaron's proposal gives you one to many, therefore simpler
# [17:37] <fantasai> fantasai: its also restricts you to all boxes beingsiblings
# [17:37] <fantasai> Alan: For use cases we're considering, too much of a limitation
# [17:37] <fantasai> Alan: Sibling boxes aren't sufficient as faras we can tell
# [17:37] <fantasai> TabAtkins: Let's go into more detail later.
# [17:38] <fantasai> TabAtkins: I think as-written, or with minor additions,c an handle it with our layout specs
# [17:38] <fantasai> SteveZ: will it be easier for users?
# [17:38] <fantasai> SteveZ: You have to go back and make selectors with dbaron's model
# [17:38] <fantasai> SteveZ: with regions, can use page templates
# [17:38] <fantasai> SteveZ: have graphical model of what's happening to pieces
# [17:39] <fantasai> Tabatkins: I'd like to go over exactly how page templates work. Think it's similar to dbaron's model as well
# [17:39] <fantasai> SteveZ: It's simple, hard part is decideing which page template you use next
# [17:39] <fantasai> SteveZ: may have multiple components that are threads flowing through
# [17:39] <fantasai> Alan: Nice thing abou Regions and my page templates proposal
# [17:39] <fantasai> Alan: Can ay that these boxes have this flow-from value
# [17:39] <fantasai> Alan: With overflow proposal would have to have particular page-targeting mechanism
# [17:39] <florian> q+
# [17:39] * Zakim sees florian on the speaker queue
# [17:40] <fantasai> TabAtkins: I think I disagree because I believe tha tit should be possible to rework page templates a little bit so that they essentially consume overflow blocks, rather than directly consuming content out of a flow
# [17:40] <fantasai> TabAtkins: Should hopefully give you same results with similar semantics
# [17:40] <fantasai> Alan: There you're taking a page and targetting an overflow box
# [17:40] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 60 seconds)
# [17:40] <fantasai> TabAtkins: Idea is, take grid. You can have two boxes that are region overflowing.
# [17:41] <fantasai> TabAtkins: Page templtes would be able to work similarly, just have to invert relationship from go-to relationship to take-from
# [17:41] <fantasai> TabAtkins: Still grid positioning, with niceities of that layout, but with inverted relationship of how you target elements to grid cells
# [17:42] <fantasai> Florian: I generally agree with most of what Tab said
# [17:42] <fantasai> Florian: Essentially can , or can easily extend, into doing regions
# [17:42] <fantasai> Florian: Don't think we have to check that right now
# [17:42] <Bert> q+ to say the pb with pull-from is that regions, unlike elts, don't have an order, so you don't know which to fill first.
# [17:42] * Zakim sees florian, Bert on the speaker queue
# [17:42] <fantasai> Florian: We should just pursue as it is, and [...]
# [17:42] * sylvaing got lost at the 4th-level if in Florian's sentence
# [17:43] <fantasai> Florian: Then when we run into cases where use cases aren't handled yet, decide whether extend it or use regions.
# [17:43] * Quits: jarek__ (~jarek@public.cloak) (Ping timeout: 20 seconds)
# [17:43] <fantasai> Florian: what we have right now they work together just fine
# [17:43] <Bert> q- florian
# [17:43] * Zakim sees Bert on the speaker queue
# [17:44] <fantasai> TabAtkins: My goal is to see if we can do enough without regions, to do that first. And then only do regions if it's necessary, later
# [17:44] <fantasai> Alan: My concern is taking those sibling boxes, and extending them to all use cases identified for regions, that you'd get osmething as complicated as the colum-styling situation you liked
# [17:44] <fantasai> SteveZ: i would like the user model should also be easy and simple, not just the implementer model
# [17:44] <fantasai> TabAtkins: I think it should be as easy to use, yes
# [17:44] <fantasai> Bert: Wrt push-> pull
# [17:45] <fantasai> Bert: Regions are not in a tree. They don't have an order. Don't know if pulling from two regions, which pulls first.
# [17:45] <dbaron> (earlier:)
# [17:45] <dbaron> dbaron: Florian, what did you mean by ???
# [17:45] <dbaron> Alan: In Hamburg, I introduced the idea of using overflow:fragments as a way to handle the overflow for the last box of a region.
# [17:45] <fantasai> Bert: Just a warning, if you go that way, you may need extra properties.
# [17:45] <fantasai> TabAtkins: That problem exists right now.
# [17:46] <fantasai> ...
# [17:46] * Joins: koji (~koji@public.cloak)
# [17:46] * antonp thinks that when Bert says regions he means page template "cells"
# [17:46] <fantasai> TabAtkins: I think we're talking about different hings now.
# [17:46] * fantasai has so many tpos to fix now..
# [17:46] <fantasai> >_<
# [17:46] * Joins: ChrisL (clilley@public.cloak)
# [17:46] <fantasai> Bert: ... pseudo-elements ...
# [17:47] <fantasai> TabAtkins: Need to establish an ordering then, because if individual pseudo-elements flow from a particular flow, need to establish an ordering. Need to establish an ordering no matter what.
# [17:47] <fantasai> TabAtkins: Regardless of flow-from or flow-to
# [17:47] <fantasai> SteveZ: need ordering for both content and containers
# [17:47] <fantasai> Bert: content has ordering already
# [17:47] <fantasai> Alan: While you said your main concern was fuzzing hte named flows...
# [17:48] <fantasai> Alan: It's something that's going with insertion points of hsadow dom as well
# [17:48] <fantasai> Alan: The street has found named flows useful for things we didn't intend
# [17:48] <fantasai> Alan: People think it's very interesting to use it as general content rdirection
# [17:48] <fantasai> Alan: Using media queries, using named flows to reorder things
# [17:49] <fantasai> Alan: e.g. Chris Coyier uses responsive layout with ads on the right or bottom
# [17:49] <fantasai> Alan: Use named flows to intersperse ads in moblbile layout
# [17:49] <fantasai> TabAtkins: It works with dbaron's as well. Can show you how you would mark it out
# [17:49] <fantasai> Alan: Florian wasn't able to, so would be interested why ou think you can
# [17:49] <fantasai> Rossen: Since the overflow module relies entirely on speduo-elements, will you have eventing and programmability built into that?
# [17:49] * ChrisL div.advert {display: none}
# [17:49] <fantasai> Rossen: Regions give you that for free
# [17:50] <fantasai> Tab If you put a bunch of dummy eleents in you markup
# [17:50] <fantasai> sylvaing: shadow dom
# [17:50] <fantasai> TabAtkins: On that note, actually a lot of us in Webkit do believe that pseudo-elements are the same concept of shadow dom and ivnvestigating how to unify them
# [17:50] * hober in the future, we can use https://gist.github.com/3969117 to fix right hand off-by-one scribing errors.
# [17:50] <fantasai> Florian: I think it's a good chance that we can do everything we want
# [17:51] <fantasai> Florian: That said, what difference does it make right now?
# [17:51] * sylvaing there are no problems that can't be solved by having two parallel shadow DOMs!
# [17:51] <fantasai> TabAtkins: We have a regions Webkit implementation... because implementations are showing up now, we will lock into regions model
# [17:51] <fantasai> Florian: So just don't ship it
# [17:51] <fantasai> TabAtkins: ^: Where simpler model would be sufficient
# [17:52] <fantasai> Florian: What action or resolution are we aiming for?
# [17:52] <fantasai> Tab I need to discuss use cases more with Alan.
# [17:52] <fantasai> TabAtkins: If we canestablish to our satisfaction that use cases are solved, then idscuss as a grou pwhether to switch as a group
# [17:52] <fantasai> SteveZ: Why is the overflow model simpler?
# [17:52] <fantasai> TabAtkins; one, you have lost flow-into an moultiple things. Always origins from same element
# [17:53] * Joins: jet (~jet@public.cloak)
# [17:53] <fantasai> TabAtkins; i haven't heard anything yet hwere that is actually needed
# [17:53] <fantasai> TabAtkins: Secondarily, because you're only flowing into a particular type of thing, not every element/speduo-element potentially, because implementations do a lot of weird things for pseudo-elements, [.... [
# [17:54] <fantasai> TabAktins: Generating sinle set of sibling boxes, make a lot of simplifying assujptions that avoid a lot of crasher boxes
# [17:54] <sylvaing> s/implementations/WebKit
# [17:54] <fantasai> TabAtkins: e.g. WebKit right now is rationalizeing pseudo-elements so that we could add more in the future. Before were handled at layout time, made things really messed up
# [17:55] <fantasai> TabAtkins: Scattering the flow around the dom can result in very weird stufff
# [17:55] <fantasai> Alan: Would be happy to say you can't make before/after pseudos into regions
# [17:55] <stearns> and have some future pseudo-element made for that purpose
# [17:56] <fantasai> fantasai: Having worked on Mozilla's layout engine, I think I agree with Tab that it would be a lot simpler.
# [17:56] * Quits: krit (~krit@public.cloak) (Ping timeout: 20 seconds)
# [17:56] <fantasai> fantasai: And we have all kinds of crashers that result from fragmenting things.
# [17:56] * Joins: krit (~krit@public.cloak)
# [17:56] <fantasai> Rossen: wrt flow-from/flow-into
# [17:56] <fantasai> Rossen: Saying something you lose with dbaron's proposal? Do you need to?
# [17:57] <fantasai> Rossen: What is reason why you cannot ... flow is a general concept which is orthogonal to regions
# [17:57] <fantasai> TabAtkins: Technically ability to flow multiple elements into a single flow is separable from this
# [17:57] <fantasai> TabAtkins: Since separte, coudl potentially still have that it
# [17:57] <fantasai> Rossen: Named flows and regions are two separate concepts
# [17:57] <fantasai> TabAtkins: Right, and baron's proposal properly deals just with regions
# [17:58] <fantasai> Florian: I agree with you that dbaron'sproposal is significantly simpler, and agree it wil cover a very substantial subset, not sure aobut all. But let's not close any doors right now.
# [17:58] <fantasai> TabAtkins: Agree
# [17:58] <fantasai> Rossen: Want to again minute concern wrt programmability and pseudo-element
# [17:58] <fantasai> sylvaing: and shadow dom work
# [17:58] * Quits: krit (~krit@public.cloak) (Ping timeout: 20 seconds)
# [17:58] <fantasai> Rossen: Good to slve the layout problem, but don't overlook other side
# [17:58] <fantasai> sylvaing: Don't want to create another shadow dom
# [17:59] <fantasai> TabAtkins: no, let's just create the same shadow dom :)
# [17:59] <fantasai> TabAtkins: We've been thinking about implementing all our pseudo-elements, as a built-in always-on-top shadow tree
# [17:59] * Zakim dbaron, you asked to be reminded at this time to go home
# [17:59] <fantasai> TabAtkins: could implement pseudos as a shadow tree, and you get benefits of shadow dom for free
# [17:59] <fantasai> TabAtkins: might make eventability and whatever ossible
# [17:59] <fantasai> glazou: we're out of time.
# [17:59] * Quits: stearns (~anonymous@public.cloak) (stearns)
# [17:59] <fantasai> Meeting closed.
# [18:00] * Quits: Rossen (~Rossen@public.cloak) ("")
# [18:00] * leaverou is now known as leaverou_away
# [18:00] * Quits: florian (~florian@public.cloak) (Ping timeout: 20 seconds)
# [18:00] <fantasai> glazou: Thanks very much to members who made this meeting possible: Adobe, Microsoft, Opera
# [18:00] <fantasai> glazou: Bert and Alexandra
# [18:00] <fantasai> (and Google, if they get around to paying for something ?)
# [18:01] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [18:01] * Quits: glazou (~glazou@public.cloak) (glazou)
# [18:01] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [18:02] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 20 seconds)
# [18:02] * Quits: kazutaka (~yamamoto_kazutaka@public.cloak) ("CHOCOA")
# [18:02] * Quits: koji (~koji@public.cloak) ("Leaving...")
# [18:03] * Quits: TabAtkins_ (~TabAtkins@public.irc.w3.org) (Ping timeout: 20 seconds)
# [18:04] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [18:04] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 60 seconds)
# [18:05] * Joins: Kid (~Kid@public.cloak)
# [18:06] * Quits: jet (~jet@public.cloak) (jet)
# [18:06] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [18:08] * sylvaing is now known as sylvaing_away
# [18:10] * Joins: krit (~krit@public.cloak)
# [18:10] * Joins: krit1 (~krit@public.cloak)
# [18:10] * Quits: krit (~krit@public.cloak) (Client closed connection)
# [18:14] * leaverou_away is now known as leaverou
# [18:14] * Quits: JohnJansen (~JohnJansen@public.irc.w3.org) (Ping timeout: 20 seconds)
# [18:15] * leaverou is now known as leaverou_away
# [18:17] * sylvaing_away is now known as sylvaing
# [18:38] * Joins: cabanier (~cabanier@public.cloak)
# [18:39] * Quits: lstorset (~lastorset@public.cloak) (Ping timeout: 20 seconds)
# [18:56] * Quits: krit1 (~krit@public.cloak) ("Leaving.")
# [19:01] * Joins: stearns (~anonymous@public.cloak)
# [19:01] * Quits: stearns (~anonymous@public.cloak) (stearns)
# [19:02] * Joins: SimonSapin (~simon@public.cloak)
# [19:08] * Joins: shepazu (schepers@public.cloak)
# [19:11] * Quits: Kid (~Kid@public.cloak) ("Leaving...")
# [19:18] * Joins: SteveZ (~chatzilla@public.cloak)
# [20:14] * sylvaing is now known as sylvaing_away
# [20:20] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 20 seconds)
# [21:02] * Joins: drublic (~drublic@public.cloak)
# [21:13] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 60 seconds)
# [22:06] * Disconnected
# [22:08] * Attempting to rejoin channel #css
# [22:08] * Rejoined channel #css
# [22:08] * Topic is '#css We tjoml we [refer s;ogjt;u tje pver;fpw regopms a[[rpacj tp tje exact sumtax tjat regopms os isomg rogjt mpw. becaise ot'
# [22:08] * Set by glazou on Sun Oct 28 17:26:36
# [22:09] * leaverou_away is now known as leaverou
# [22:19] * Joins: Kid (~Kid@public.cloak)
# [22:41] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [22:49] * Zakim excuses himself; his presence no longer seems to be needed
# [22:49] * Parts: Zakim (zakim@public.irc.w3.org) (Zakim)
# [22:50] * Joins: lstorset (~lastorset@public.cloak)
# [22:56] * Quits: lstorset (~lastorset@public.cloak) (Ping timeout: 20 seconds)
# [23:22] * Joins: cabanier (~cabanier@public.cloak)
# [23:26] * leaverou is now known as leaverou_away
# [23:29] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 20 seconds)
# [23:31] * leaverou_away is now known as leaverou
# [23:31] * Joins: cabanier (~cabanier@public.cloak)
# [23:39] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 20 seconds)
# [23:41] * Joins: cabanier (~cabanier@public.cloak)
# [23:49] * Disconnected
# [23:50] * Attempting to rejoin channel #css
# [23:50] * Rejoined channel #css
# [23:50] * Topic is '#css We tjoml we [refer s;ogjt;u tje pver;fpw regopms a[[rpacj tp tje exact sumtax tjat regopms os isomg rogjt mpw. becaise ot'
# [23:50] * Set by glazou on Sun Oct 28 17:26:36
# [23:55] * leaverou is now known as leaverou_away
# [23:57] * leaverou_away is now known as leaverou
# [23:59] * Quits: Kid (~Kid@public.cloak) ("Leaving...")
# [23:59] * Joins: krit (~krit@public.cloak)
# Session Close: Mon Oct 29 00:00:00 2012

The end :)