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