08:03:56 <RRSAgent> RRSAgent has joined #CSS
08:03:56 <RRSAgent> logging to http://www.w3.org/2010/11/01-CSS-irc
08:04:02 <Zakim> Zakim has joined #CSS
08:04:52 <alexmog> alexmog has joined #css
08:04:54 <plinss_> rrsagent, make logs public
08:04:54 <glazou> http://wiki.csswg.org/planning/tpac-2010
08:05:32 <tabatkins> glazou: What's mos timportant?  I think we need clilley for the charter discussion.
08:05:53 <tabatkins> jdaggett: Two things I want to discuss tomorrow are Fonts and Writing Modes.
08:06:02 <tabatkins> sylvaing: We'd like to do Grid first thing tomorrow morning.
08:06:33 <tabatkins> Bert: We have a guest who wants to talk about Writing Modes, and Mike.
08:07:20 <tabatkins> glazou: Microsoft guys, wanna talk about Flexbox before Grid?
08:07:27 <tabatkins> sylvaing: Not that important, just want to talk about both.
08:07:49 <tabatkins> glazou: We can probably start this morning with css3 values.
08:08:07 <kennyluck> kennyluck has joined #CSS
08:10:26 <tabatkins> glazou: FXTF wants to take ownership of 2d transforms.  But I want the WG to talk about it too, even if only for a little bit.
08:11:02 <tabatkins> glazou: Marcus Gelling is here, so can we talk about EPUB liaison stuff later this morning?
08:11:07 <tabatkins> Marcus Gelling: Yes.
08:11:17 <tabatkins> glazou: Slow font downloading, should it be lumped with CSS3 Fonts?
08:11:32 <anne> anne has joined #css
08:11:38 <tabatkins> jdaggett: Yes, and hopefully Tues afternoon, because Slye will be here then.
08:14:48 <tabatkins> Attending: Soonbo Han, Tab Atkins, Markus Mielke, Peter Linss, Anne van Kesteren, David Singer, Bert Bos, John Daggett, David Baron, Alex Mogilevsky, Koji Ishii, Sylvain Galineau, John Jansen, Daniel Glazman, Steve Zilles
08:15:29 <kohei> kohei has joined #CSS
08:15:34 <tabatkins> glazou: So I suggest we start with 2d transforms, epub, and css2.1 testing this morning.
08:15:36 <anthony> anthony has joined #css
08:15:53 <tabatkins> glazou: We now have 4 impls on the table: gecko, webkit, opera, and ms.
08:16:08 <sbhan> sbhan has joined #css
08:16:22 <tabatkins> glazou: We need tests.  If we have interop impls - I suppose we have a fairly good level of interop - I think we can move pretty quickly to REC.
08:16:59 <tabatkins> sylvaing: We have some things that need to be resolved, like the DOM interface relying on some obsolete stuff.
08:17:07 <kohei> kohei has joined #CSS
08:17:11 <tabatkins> sylvaing: No one but Webkit implements it yet, I think.
08:17:27 <tabatkins> anne: Maybe we should drop it for now until we figure out what we want to do with the Values APIs.
08:17:35 <tabatkins> glazou: I think marking as at-risk would be better.
08:18:28 <tabatkins> dbaron: The section on Transitions has several bugs in the spec.  XXX sent feedback explaining several of them, and you can see these bugs in Webkit.
08:18:47 <tabatkins> s/XXX/bzbarsky/
08:18:52 <sylvaing> CSS3 2D Transforms transition/animation section: http://www.w3.org/TR/css3-2d-transforms/#animation
08:19:03 <tabatkins> dbaron: The other issue is transforms that affect layout.
08:19:17 <tabatkins> dbaron: I could see getting a first version to REC without that, but I'd rather fix it first.
08:19:36 <tabatkins> jdaggett: Isn't that a big issue?
08:19:42 <tabatkins> dbaron: Not necessarily.
08:19:52 <tabatkins> dbaron: Some big things, but some small things.
08:20:19 <tabatkins> sylvaing: That affects things like offsetTop, etc.
08:20:32 <tabatkins> dbaron: Right, but they kind of suck without a layout-effecting transform anyway.
08:21:33 <tabatkins> sylvaing: It would definitely lengthen the time it would take to get to CR.
08:21:53 <tabatkins> dbaron: Yeah, I think it does make sense to move it to CR first without this.
08:21:57 <anthony_work> anthony_work has joined #css
08:22:22 <tabatkins> szilles: I drafted a spec for the layout-affecting Transforms 2 or 3 years ago.  It's not bug-free, but it exists - we won't be starting from scratch.
08:22:45 <tabatkins> anne: The concern is that nobody's tried to ipmlement it yet.
08:22:55 <murakami> murakami has joined #css
08:23:40 <tabatkins> anne: I think that Transforms should redefine the boxes that already exist when transformed; the border box should get bigger, etc.
08:23:52 <tabatkins> anne: So I don't have to constantly reference Transforms when talking about boxes.
08:24:32 <tabatkins> dbaron: You've got 3 or 4 boxes now.  1) Element in its original coord space.  2) Element in the transformed coord space.  3) Rectangle containing the 1st in the 2nd coord space, 4) Rectangle containing the 2nd in the 1st coord space.
08:25:09 <tabatkins> anne: I think browsers act like the transform didn't happen for now.
08:25:27 <tabatkins> anne: Which works for me - if the border box doesn't change, and only alters for painting, that's easy.
08:25:52 <tabatkins> anne: At some point Dean asked me to draft an api that was aware of transforms, but I wasn't sure how to do it.
08:26:09 <tabatkins> sylvaing: We have 4 impls, is what we have enough for authors?  Are we missing use-cases?
08:26:22 <tabatkins> dbaron: I think we're definitely missing use-cases, but I think we're still okay to move forward.
08:27:28 <dbaron> s/bzbarsky/bzbarsky forwarded a message from Tim Terriberry/
08:27:29 <tabatkins> glazou: I'd like to talk about canonicalization of the computed value. When you query a transform, I think all browsers respond with a matrix, which is totally unuseful for authors.  Is there something we could do to ease this pain?
08:28:05 <tabatkins> anne: I think that, as a string value, having the matrix is fine and the most sane.  But I think when people start prototyping the Values API, we'll get a dedicated api for transforms.
08:28:26 <homata_> homata_ has joined #CSS
08:29:10 <tabatkins> jdaggett: Once you compose several operations, the matrix loses the state.  You can't get the compounded effects anymore.  So, glazou, what do you want?
08:29:32 <tabatkins> glazou: For example, if you have a rotation and want to rotate it a bit further, it's a huge pain.
08:29:49 <tabatkins> sylvaing: You can do that now through the matrix api, but it uses CSSValue, which we're not going to implement.
08:30:03 <timeless_mbp> timeless_mbp has joined #css
08:30:12 <tabatkins> jdaggett: Like, if you do a rotate, transform, rotate, you lose something.  What do you want to show to authors?
08:30:31 <tabatkins> glazou: The three operations, hopefully - a stack.
08:30:41 <tabatkins> dbaron: We have to store that information and pass it through anyway to do the transforms.
08:30:58 <tabatkins> s/transforms/transitions/
08:31:36 <tabatkins> glazou: I feel that as a web author, releasing this without having a way to get the scale/rotate/etc of the transform is bad.
08:32:09 <tabatkins> dbaron: Do you really need it at the computed level?  Is specified enough?  You already have it on the specified level.
08:32:46 <tabatkins> glazou: Yes, but it's a string that you have to parse, which is unacceptable.
08:32:56 <tabatkins> tabatkins: So make Anne work on the Values API faster.  ^_^
08:33:09 <tabatkins> szilles: What does SVG do?  Also, is the matrix decomposition unique?
08:33:31 <tabatkins> dbaron: There's a reference to an algorithm for a unique decomposition, but it's buggy (I raised this earlier).
08:33:50 <Ibrahima> Ibrahima has joined #css
08:34:07 <tabatkins> dbaron: I think that authors want back the order they originally specified, though, rather than some canonical transform.
08:35:11 <anne> tabatkins, the last on that is that people should start experimenting
08:35:15 <tabatkins> sylvaing: Also, SVG can do each transform from a different origin, while CSS does the whole thing from a single origin.
08:36:24 <tabatkins> Anthony (SVG): Doesn't look like SVG has a neat way of getting back the original transforms either.
08:36:37 <tabatkins> glazou: Sounds like something we can discuss in the FXTF meeting.
08:37:53 <Klaus> Klaus has joined #css
08:37:55 <tabatkins> RESOLVED: Discuss an API to parse the specified value into an author-convenient form, before pushing the spec forward.
08:38:24 <tabatkins> glazou: Next, tests.  What kind of tests do we need for Transforms, who will write them, what schedule?
08:39:10 <tabatkins> glazou: Corollary - do we have enough interop that we can remove prefixes?
08:39:49 <tabatkins> dsinger: If Transitions is going to move slower than Transforms, we should move the section on Transitioning Transforms to the Transitions spec.
08:40:31 <tabatkins> anne: Can we require that this testsuite only has reftests?
08:40:36 <tabatkins> johnjan: No, we can't require it.
08:40:38 <tabatkins> anne: Why not?
08:40:39 <Martijnc> Martijnc has joined #css
08:41:01 <tabatkins> tabatkins: Can we resolve that everything that *can* be reftests, *must* be reftests?
08:41:05 <tabatkins> johnjan: Yeah, that's acceptable.
08:41:58 <tabatkins> dbaron: We have 107 reftests for Transforms.  I'd need to ensure they're all test-suite worthy.
08:42:41 <tabatkins> glazou: We'd probably need a lead on the 2d testsuite.
08:42:54 <tabatkins> johnjan: I can do that.
08:43:41 <dbaron> (also a bunch of parsing tests)
08:44:17 <tabatkins> glazou: dbaron, can you estimate how many tests we might need for the Transforms spec?
08:44:47 <tabatkins> johnjan: My gut says a few hundred.  Right now we have far too few, at least.  I'd like to look at SVG and Moz testcases and see how we interop.
08:45:16 <anthony> SVG test suite is here: http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/test/svg/?sortby=file#dirlist
08:45:17 <fantasai> RESOLVED: Any Transforms tests that can be reftests must be reftests.
08:45:20 <anne> anne has joined #css
08:45:35 <tabatkins> dbaron: Also, a whole lot of our Transforms tests are in our Transitions tests now, because I wrote a whole lot of tests about transitioning transforms.
08:46:27 <anthony> Transforms tests specifically: coords-transformattr-01-f.svg - coords-transformattr-05-f.svg and coords-trans-01-b.svg - coords-trans-14-f.svg
08:47:09 <tabatkins> glazou: 4 impls signals that impls are very interested in this.  If we can move fast on this it would be a good signal to the w3c.
08:47:19 <tabatkins> glazou: So, maybe a CR/PR by June would be awesome.
08:49:04 <tabatkins> glazou: Are there immediate actions we can take on the spec, like removing the Transition section, mark layout as at-risk, remove the value api?
08:49:22 <tabatkins> RESOLVED: Remove the value API from 2d Transforms.
08:50:14 <tabatkins> shepazu: Once you've transformed, getting a point back is no longer in screen space, and there's some tricky transforms you need to do.
08:50:33 <tabatkins> shepazu: So people are going to get a point, expect it to be in one place, and it's not there.
08:51:07 <tabatkins> shepazu: It's a tricky solution but that can be exposed simply for authors.
08:51:19 <timeless_mbp> timeless_mbp has joined #css
08:51:35 <tabatkins> shepazu: smfr already has a very good idea of what's evolved there, and he'll add it to the 2d transforms spec.
08:52:39 <tabatkins> glazou: More agenda!
08:52:59 <tabatkins> glazou: howcome, we have some things for you.
08:53:09 <tabatkins> howcome: 15 minutes each, they're all easy.  ^_^
08:53:17 <mielke> mielke has joined #css
08:53:31 <tabatkins> glazou: today, beginning of afternoon?
08:53:34 <tabatkins> howcome: Yeah.
08:54:26 <mmielke> mmielke has joined #css
08:55:12 <tabatkins> Gylling: I'm the AC rep of the DAISY consortium, but here today for EPUB and the IPDF.
08:55:22 <dsinger> s/Marcus Gelling/Markus Gyllling/
08:55:32 <dbaron> s/Marcus Gelling/Markus Gylling/g
08:55:38 <tabatkins> gylling: This isn't really intended to be a primer for epub, so let's move quickly through that.
08:55:41 <dbaron> s/Markus Gyllling/Markus Gylling/g
08:55:59 <tabatkins> gylling: In the current revision of epub, we have adobe, apple, google, and other organizations working with us.
08:56:21 <tabatkins> gylling: What makes epub stand out in the ebook wars is that epub uses w3c standards as the highest priority.
08:56:47 <tabatkins> gylling: epub is currently undergoing a revision; version 2 has been out for several years, and the new one started this year.  We'd like to have the new one out by May 2011.
08:56:55 <tabatkins> jdaggett: What does that mean?  Final spec, or impls?
08:57:13 <tabatkins> gylling: Final spec.  The ipdf bylaws do not echo the w3c in requiring 2 independent impls.
08:57:30 <tabatkins> gylling: Of course, as we use existing web techs, generally there were already sufficient impls by the time we used something.
08:57:39 <tabatkins> gylling: But the situation is becoming somewhat more tricky now.
08:57:47 <tabatkins> gylling: bert, you sent a few questions earlier?
08:58:16 <tabatkins> Bert: Last time we talked about epub, we tried to discover which documents on the epub wiki were important; which dates, what schedule, etc should we look at?
08:58:38 <tantek> tantek has joined #css
08:59:11 <mgylling> http://code.google.com/p/epub-revision/wiki/ImplementationPipeline
08:59:27 <tabatkins> gylling: This is the current schedule.
08:59:28 <tantek> greetings from SF.
08:59:49 <tantek> sorry I couldn't be there in person!
08:59:49 <tabatkins> gylling: So we started out this summer collecting requirements.  it was an open-ended process initially.
08:59:59 <szilles> szilles has joined #css
09:00:04 <tabatkins> gylling: In our SF meeting two weeks ago, we deferred/postponed a large number of our requirements.
09:00:14 <tabatkins> gylling: So we now have a smaller set of requirements that can be reviewed.
09:00:29 <tabatkins> gylling: This is what the epub wg has set out to have done by May next year.
09:00:49 <tabatkins> gylling: There are a few outstanding items, that we'll talk about tomorrow.
09:01:02 <tabatkins> gylling: But one of th emajor things we intend to do in this revision is to increase ou support for i18n.
09:01:26 <tabatkins> gylling: Writing Modes is one of th emost critical features for us right now in epub.
09:01:34 <jypark> jypark has joined #css
09:02:14 <tabatkins> gylling: The ipdf bylaws enumerates the process to use.  Right now the ipdf doens't have an established rule that ther emust be two independent implementations of each feature.
09:02:41 <tabatkins> gylling: Inverting the question, though, would an implementation in an ebook device suffice to satisfy the w3c requirements?
09:02:57 <tabatkins> Bert: That's what I was trying to get at.  Are your results public?
09:03:21 <tabatkins> gylling: If we can submit test results based on ebook devices, there's not a bunch of problem.
09:03:55 <tabatkins> jdaggett: There's a bit of dependency problem, where there are some drafts that haven't even reached first public draft yet.  It seems like that would cause  some problems fo ryou guys.
09:03:58 <dbaron> http://dbaron.org/css/test/2010/transition-negative-determinant is a testcase showing some of the issues with animation of transforms, and http://lists.w3.org/Archives/Public/www-style/2010Oct/0440.html is the post by Tim Terriberry suggesting an approach to fix that
09:04:04 <tabatkins> fantasai: I'm trying to stabilize the specs as fast as possible.
09:04:44 <tabatkins> fantasai: If we cannot come to any conclusion on the logical directions issue, we can just not deal with it and do it later, though I'd not like to.
09:04:59 <tabatkins> jdaggett: I just don't believe we should be making any kind of promise until there is some kind of consensus in this group.
09:05:17 <tabatkins> howcome: There seems to be some kind of consensus that epub has accepted the alternate stylesheet approach.
09:05:41 <tabatkins> fantasai: Right.  I think epub is clear that Writing Modes is unclear until after TPAC.
09:06:07 <tabatkins> szilles: We shouldn't be having a discussion about what we'll do after a discussion until after the discussion.
09:06:42 <MoZ> MoZ has joined #css
09:06:47 <tabatkins> howcome: If I'm right, you're aiming for a per-document writing-mode switch, right?
09:07:08 <tabatkins> fantasai: Right, though you'll have some form of mixed content.
09:07:26 <tabatkins> fantasai: In terms of being able to switch the entire stylesheet, epub has accepted the alternate stylesheet mechanism.
09:07:55 <tabatkins> fantasai: Also, epub has their own way of handling unsupported features, so fallback isn't something we have to address *for epub*.  CSS should address that for themselves, but we don't have to worry about that as much.
09:08:15 <tabatkins> howcome: CSS now has a way to do running headers and footers.  Will epub adopt that as well?
09:08:33 <dbaron> But how we want implementations that don't support something to handle it is often fundamental to the design rather than something you tack on at the end.
09:08:53 <tabatkins> gylling: Our rendering stuff is generally going to be replaced by references to css 2.1.  We haven't discussed running headers and footers yet, but expect that we'll be able to refer to the CSS spec.
09:09:05 <tabatkins> Bert: How does your collab/discussion process work?
09:09:30 <tabatkins> Bert: If we have a question, how do we send it?
09:09:43 <tabatkins> gylling: I think the easiest is to set up a liaison.
09:09:54 <tabatkins> gylling: They would participate in our weekly telcons and our mailing list, which is public.
09:10:29 <shepazu> shepazu has joined #css
09:10:59 <tabatkins> jdaggett: The way epub is set up, different "working groups" handle different areas.  One handles i18n, another handles styling, etc.
09:11:15 <tabatkins> jdaggett: I think there's a minor dependency on CSS3 Speech?
09:11:27 <tabatkins> gylling: Right - i18n and css aren't the only thing.  We also need, frex, pagination.
09:11:48 <tabatkins> howcome: What do you mean by pagination?
09:12:04 <tabatkins> gylling: Dynamic reflow and pagination.  Also page templates.
09:12:39 <tabatkins> gylling: The feature that overshadows everything else is Writing Modes, though.
09:13:17 <tabatkins> Bert: I'd like to have some names to follow who know what's going on.
09:14:05 <tabatkins> kojiishi: I'm fine with being the liaison for egls (?), but would like someone else that can handle the other groups.
09:14:53 <tabatkins> gylling: I think the main group is 21:00utc, and all the other groups will be re-merging, so everyone should have this as well.
09:16:04 <r12a-nb> r12a-nb has joined #CSS
09:16:29 <tabatkins> MikeSmith: kennyluck has some insights into the vertical text issues as well.
09:17:43 <tabatkins> fantasai: I can attend the epub telcon - it's at a sane time in pacific timezone.
09:17:52 <Aharon> Aharon has joined #css
09:18:27 <tabatkins> gylling: So if I understand correctly, we have a liaison, we'll find out if ebook impls can serve as impls for tests.
09:18:38 <tabatkins> fantasai: ebook readers will certainly serve.
09:18:59 <tabatkins> Bert: Also a question is the test format.
09:19:16 <tabatkins> gylling: I think epub with write access could do the tests in css format and contribute the results directly.
09:20:13 <MikeSmith> MikeSmith has joined #css
09:20:16 <tabatkins> Bert: Are there resources set aside for testing purposes?
09:20:27 <tabatkins> gylling: I can't give you firm numbers, but yes, there will be resources for testing.
09:20:36 <tabatkins> Bert: Any idea how many impls you expect to exist?
09:21:07 <tabatkins> gylling: Can't say.  But in terms of rendering, there are 4 separate entities, only one of which is based on webkit.
09:21:27 <tabatkins> gylling: CSS3 Speech now.
09:21:46 <tabatkins> gylling: One of the things we're doing in epub is to enhance, for a11y reasons, speech synthesizers.
09:21:58 <tabatkins> gylling: We'd like to bring new life into the css3 speech module.
09:22:17 <tabatkins> gylling: The daisy consortium has a person we'd like to submit as a new editor.
09:22:35 <ishino> ishino has joined #css
09:23:00 <tabatkins> glazou: No problem.
09:23:09 <tabatkins> jdaggett: As long as they're a W3C member.
09:23:44 <tabatkins> fantasai: I looked over the spec, and I think claudio (?) did a good job of cleaning it up.
09:24:04 <tabatkins> fantasai: I think there's a section we should keep, another we shoudl drop, but otherwise sounds good.
09:24:16 <tabatkins> glazou: Is there already interest in implementing it?
09:24:31 <tabatkins> gylling: Yes, especially from the a11y who wants to interact with epub.
09:25:51 <tabatkins> szilles: There was a point when some phone/voice companies wanted to go with a completely different approach; I don't remember the details, but it seems that we should get whatever we're doing reviewed by the mobile community.
09:26:10 <tabatkins> gylling: The people you mentioned are currently meeting as the Speech Incubator group.  I'll be meeting with them.
09:26:17 <tabatkins> glazou: Could you report to the WG after you meet with them?
09:26:21 <tabatkins> gylling: I'll try. 
09:26:39 <JonR> JonR has joined #css
09:29:24 <plinss_> <br type='coffee' />
09:33:27 <glazou> glazou has joined #css
09:46:32 <myakura> myakura has joined #css
09:50:13 <myakura> re css3-speech, WebKit implemented 'speech' property about a month ago. http://webkit.org/b/46827
09:58:50 <glazou> glazou has joined #css
09:59:34 <mgylling> mgylling has joined #css
10:02:27 <ilkka> ilkka has joined #css
10:02:33 <mjs> mjs has joined #css
10:03:03 <tabatkins> tabatkins has joined #css
10:04:04 <fantasai> Topic: CSS2.1 Testing
10:04:08 <fantasai> round of intros
10:04:27 <tabatkin1> tabatkin1 has joined #css
10:05:20 <ilkka> my name is Ilkka Oksanen
10:05:26 <dbaron> Present: Ilkka Oksanen, Bert Bos, David Singer, Håkon Lie, Peter Linss, Markus Mielke, Tab Atkins, Soonbo Han, Steve Zilles, Daniel Glazman, John Jansen, Sylvain Galineau, Koji Ishii, Elika Etemad, Alex Mogilevsky, David Baron, John Daggett
10:05:29 <tabatkin1> tabatkin1 has left #css
10:05:52 <tabatkins> glazou: Test suite current status?
10:05:57 <tabatkins> fantasai: Published a snapshot last week.
10:06:06 <tabatkins> fantasai: I haven't done any work on it since then.
10:06:13 <tabatkins> dsinger: Because it's perfect?
10:06:22 <tabatkins> fantasai: No, I've just been working on other stuff.
10:06:24 <mjs> mjs has joined #css
10:06:34 <tabatkins> fantasai: There's still a lot of error reports that ahven't been addressed.  I'm guessing a couple weeks.
10:07:06 <tabatkins> glazou: What are the IR results? How many tests that don't pass 2 impls?
10:08:07 <tabatkins> plinss: As of RC3, 135 marked as invalid that havne't been updated yet, 908 tests that are considered required that don't have 2 passes.
10:08:32 <tabatkins> tabatkins: To be clear, a lot of those tests are rc3 and haven't been tested by several browsers yet.
10:08:49 <mmielke> mmielke has joined #css
10:09:42 <tabatkins> jdaggett: Question on what versions are allowed?
10:10:29 <tabatkins> plinss: Public availability, and results must be a month old.
10:12:49 <tabatkins> jdaggett: I have a problem with using source-code versions, because it's hard to ensure that I run the exact same version that the test results were generated for.
10:13:00 <tabatkins> fantasai: I think we should require a public *binary*, not just source.
10:13:17 <tabatkins> tabatkins: So, we only release binaries for our public channel, every 6 weeks or so.
10:13:23 <kennyluck> kennyluck has joined #CSS
10:13:33 <fantasai> s/fantasai/jdaggett/
10:13:41 <tabatkins> johnjan: So, IE9 developer previews count?
10:14:09 <jun> jun has joined #css
10:14:18 <tabatkins> jdaggett: Sure, as long as we can get historical versions that the suite was run for.
10:14:46 <tabatkins> johnjan: I'll check to see if, say, when we release preview 7, if preview 6 is still available.  if not, I'll stick with beta.
10:14:57 <tabatkins> dsinger: Are there tests that are failing because the spec is wrong?
10:15:32 <mjs> mjs has joined #css
10:15:55 <tabatkins> dbaron: There were some, yes.  I marked some of them, but others I didn't feel strongly enough about to file a bug about.
10:16:50 <tabatkins> dbaron: There were some invalids where the test was requiring something the spec doesn't actually require.  There were some that were actually testing the wrong thing.  And then there was a third category that were testing something where I believe the spec itself was wrong.
10:17:05 <tabatkins> glazou: I'd like to see all info about that in front of the group as soon as possible.
10:17:18 <tabatkins> dsinger: I'd just like a good wiki page somewhere that lists all the tests in each of those categories.
10:17:28 <tabatkins> dsinger: And then slowly see that page empty out until we're done.
10:17:52 <tabatkins> dsinger: I've gone through every mozilla failure and figured out if it was a bug in the test or in our impl, based on what the spec currently said.
10:17:56 <dethbakin> dethbakin has joined #css
10:17:57 <tabatkins> s/dsinger/dbaron/
10:19:26 <Zakim> Zakim has left #CSS
10:19:47 <tabatkins> dbaron: There were some places where the test was testing things the spec didn't require and I could have marked invalid, but I went ahead and marked it a mozilla fail because our actual behavior was so wrong.  Like Lists numbering, frex.
10:19:59 <tabatkins> fantasai: CSS3 Lists defines list numbering, but CSS2.1 doesn't.
10:20:11 <fantasai> http://wiki.csswg.org/test/css2.1/issues
10:20:23 <tabatkins> glazou: My problem is that I don't have any stable visibility on the status of the testsuite.
10:20:47 <tabatkins> jdaggett: So what are you proposing, daniel?  A specific date?
10:21:18 <tabatkins> glazou: I propose we buckle down on CSS2.1 issues again.  I think that rather than cancelling the first conf call after tpac, we have it and talk about test suite.
10:22:38 <tabatkins> johnjan: Is Nov 15th still the date for not changing the testsuite, or at least just triaging at that point?
10:22:51 <tabatkins> fantasai: That's a little early.  I'll need two weeks after this for my changes.
10:23:04 <tabatkins> johnjan: Yeah, and we'll also need to do reviews of the changes.
10:23:19 <tabatkins> johnjan: So is 2 weeks enough time?
10:23:45 <tabatkins> dbaron: What I want is, when we think we have all the changes done, I want to go through and rerun/reverify.  So that's a dependency there.
10:24:22 <Peter> Peter has joined #css
10:24:49 <tabatkins> fantasai: I think I'm about halfway through the reported issues in my tests, and have responded to each test issue email as I completed the fix.
10:25:14 <tabatkins> fantasai: But I don't know that arronei did it to all of his, and that would make it much more difficult to judge what all has been done.
10:26:03 <tabatkins> johnjan: So we can review the changes as they come in now, and on the 22nd review what's gone on and see if we're ready or we need another 2 weeks, etc.
10:26:50 <dbaron> I just went through the list of things that I thought were "too silly to file a bug" on, and one more I noticed is the test that tests that the root element's background is propagated to the canvas even when the root element is display:none.
10:26:58 <yuma_1985> yuma_1985 has joined #css
10:27:10 <tabatkins> glazou: So we'll have IRs based on the locked version by the end of year?
10:27:24 <tabatkins> johnjan: Early december, I think.
10:27:49 <Aharon> Aharon has joined #css
10:30:46 <tabatkins> plinss: [explains how results are handled in each version of the test suite harness, and how results are grandfathered over when tests don't change]
10:30:56 <joonho> joonho has joined #css
10:31:04 <tabatkins> jdaggett: Also, could you record the useragent language?  Some of the font tests are locale-specific.
10:31:16 <tabatkins> plinss: Yes, I have the useragent data, so I'll pull that data out.
10:34:04 <tabatkins> RESOLVED: Target Nov 22nd for test suite RC4 freeze.
10:34:18 <tabatkins> dbaron: Did you publish change lists from rc1-2, and rc2-3?
10:34:24 <tabatkins> fantasai: I think I did rc2-3.
10:34:36 <tabatkins> plinss: I have changed test data, so I can generate a list like that.
10:34:51 <fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0369.html
10:35:03 <fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0005.html
10:35:18 <tabatkins> johnjan: I'd like to bring up a question about a consistent place to store the impl reports - the .data files.
10:35:50 <tabatkins> johnjan: I can't find a consistent place, and I don't think attachments on the list are a good place to store them.
10:35:55 <fantasai> ACTION fantasai: update links from W3C to implementation reports and test suite releases
10:35:55 <trackbot> Created ACTION-272 - Update links from W3C to implementation reports and test suite releases [on Elika Etemad - due 2010-11-08].
10:36:01 <tabatkins> plinss: I've put them in the rc1 and rc2 folders as appropriate.
10:36:43 <tabatkins> dbaron: We have a larg enumber of IR bugs because of one issue with Ahem fonts where the tests are questionably valid.
10:37:07 <tabatkins> dbaron: The Ahem font has a lot of glyphs that are boxes - they are exactly 1em tall and wide.
10:37:19 <tabatkins> dbaron: The baseline of the font is 4/5ths from the top to the bottom of the font.
10:37:36 <tabatkins> dbaron: So all the ascent metrics are 80% of the em square, the descents are 20%.
10:38:09 <tabatkins> dbaron: So the issue is that if the ahem font is used at a size that is not a multiple of 5px, then the ascent/descent/x-height aren't a round number of pixels.
10:38:18 <tabatkins> dbaron: On Windows, our font metrics backend makes it okay.
10:38:34 <tabatkins> dbaron: We don't get good enough information anyway, so we just throw one out and subtract from the height.
10:39:02 <tabatkins> dbaron: But on Linux we get good info, so we use both the ascent and descent data, and both are rounded up.
10:39:34 <tabatkins> dbaron: So a pretty large amount of our test failures are because the Ahem font isn't a multiple of 5px.
10:39:48 <tabatkins> dbaron: I marked them as Moz bugs, but I could equally mark them as invalid, which could flip 50-80 tests.
10:40:08 <tabatkins> jdaggett: I think that in general we shouldn't be relying on rounding behavior.
10:40:54 <tabatkins> chrisl: And we don't have a canonical place to look for font data, since different font apis on different platforms return different data.
10:41:07 <tabatkins> alexmog: The spec doesn't say that fonts have to be round numbers of pixels.
10:41:37 <tabatkins> jdaggett: Yes, but the spec also doesn't specify how to round, so we can't rely on rounding.
10:43:25 <tabatkins> chrisl: Can we just ignore the fact that windows does weird things?  We have two impls that use correct platform behavior.
10:43:45 <jdaggett> waterfall test for non-integer font sizes:
10:43:46 <jdaggett> http://people.mozilla.org/~jdaggett/tests/decimalfontwaterfalls.html
10:43:58 <jdaggett> alexmog: ^
10:44:03 <tabatkins> dbaron: The rounding behavior is part of freetype, actually.  I've tried to change our rounding behavior, but it actually broke several things, like text-decorations no longer lining up exactly.
10:44:10 <MikeSmith> RRSAgent, make minutes
10:44:10 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-CSS-minutes.html MikeSmith
10:44:29 <tabatkins> s/windows/windows GDI/
10:45:25 <tabatkins> glazou: We need a way to report invalid/problematic tests.  Everyone should report invalid tests asap, and try to meet the guidelines we discussed today.
10:45:50 <tabatkins> dbaron: For the record, i went through all the mozilla failures.  There were a small number of tests I gave up on.  I havne't gotten to those yet.
10:46:09 <tabatkins> dbaron: Some were font ones, which I handed to jdaggett.
10:46:16 <tabatkins> jdaggett: I fixed the tests.
10:46:17 <dbaron> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0178.html
10:46:19 <dbaron> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0175.html
10:46:26 <tabatkins> jdaggett: But the metric ones we still need to look at.
10:48:07 <dbaron> And the other Moz failures I didn't analyze were margin-collapse-157, margin-collapse-clear-005 and margin-collapse-clear-011
10:48:25 <tabatkins> dbaron: And also some margin-collapse issues, which I skipped because it takes me too long to try and figure out what's intended there.
10:48:43 <tabatkins> chrisl: Perhaps that's a spec problem, if an implementor finds it too difficult to figure out from the spec what should happen.
10:48:50 <tabatkins> fantasai: We just rewrote that section of the spec.
10:49:01 <tabatkins> Topic: i18n
10:49:23 <tabatkins> richard ishida and aharon lenin introduce themselves
10:49:40 <tabatkins> also david clarke (sp?)
10:49:47 <johnjan> so 11/22 for Elika's changes to the Test Suite, 12/8 Conf Call for getting complete on reviewing those test changes and completing the IR submissions.
10:50:09 <tabatkins> also kennyluck
10:50:34 <tabatkins> fantasai: The point of i18n is to make everyone in the world happy with our technologies.
10:50:43 <tabatkins> fantasai: 2 major topics: bidi, and vertical text.
10:50:51 <tabatkins> fantasai: We're doing vertical text tomorrow.
10:51:03 <tabatkins> fantasai: aharon wanted to discuss bidi-related proposals for css3.
10:51:48 <tabatkins> Aharon: First thing i wanted to discuss was a couple of new proposals that I emailed to the list last night.
10:52:07 <tabatkins> Aharon: Second is to get a feeling on the acceptance level on the other bidi stuff that has been dsicussed ove rth elast year.
10:52:20 <Bert> s/lenin/lanin/
10:52:28 <tabatkins> Aharon: New stuff.  (1) A small addition to Images.
10:52:31 <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Nov/0000.html
10:52:50 <tabatkins> Aharon: I'd like an ability to flip an image based on directionality.
10:53:07 <myakura> http://www.w3.org/International/docs/html-bidi-requirements/#image-flip
10:53:29 <tabatkins> Aharon: One option is an 'rtlflip' keyword, so the image would be flipped horizontally when the direction is rtl.
10:54:08 <tabatkins> jdaggett: This isn't just bidi - vertical text may want to do rotations too.  So, this is a writing-mode thing.
10:54:33 <tabatkins> Aharon: The other way was to declare the directionality of the image, and then auto-flip as appropriate.
10:55:01 <tabatkins> Aharon: So if the image is ltr and the text is ltr, leave it alone.  If the text is rtl, then flip the image.
10:56:32 <tabatkins> szilles: One slight modification; I think this is a much better way to go as it describes the image.  I think you need to separate the idea of the image directionality from whether or not to flip it.
10:56:44 <Kai> Kai has joined #css
10:56:59 <tabatkins> szilles: Because an image might be neutral in horizontal, but not in vertical.
10:57:08 <tabatkins> szilles: Would this apply to any replaced element?
10:57:34 <tabatkins> fantasai: If this should apply to all replaced elements, this should be handed to the HTMLWG as this would be a content property.
10:59:25 <tabatkins> johnjan: One problem is backwards compat.
11:00:21 <tabatkins> fantasai: Not a problem in CSS, as you can count on the property being ignored in legacy and just add a fallback.
11:00:33 <tabatkins> szilles: So I'm hearing that we aren't intended to cover <img>?
11:00:53 <tabatkins> fantasai: For content images, in most cases I don't believe you'd generally want to flip those images.
11:01:03 <tabatkins> fantasai: The types of images you get in CSS are very often something you want to flip.
11:01:21 <tabatkins> fantasai: But images that belong in the content tend to be pictures, charts, etc. that you are much less likely to want to flip.
11:01:42 <tabatkins> fantasai: Now, if the use-case pops up and proves important, then at that point we'd push this back to the HTMLWG and ask them to fix the problem.
11:01:54 <tabatkins> szilles: Good, I just wanted to be clear on the scope.
11:04:50 <fantasai> dbaron: should look into how this interacts with Exif orientation
11:04:52 <fantasai> http://dev.w3.org/csswg/css3-images/#image-orientation
11:04:53 <tabatkins> dbaron: We had a spec somewhere relating to EXIF transformations and similar.  We might want to think about how this transformation compounds with the exif orientation.
11:05:23 <fantasai> dbaron: Didn't we have a boolean to honor the exif orientation?
11:05:39 <tabatkins> tabatkins: If honored, it should happen at a level below the rtl flipping.
11:06:21 <tabatkins> dbaron: While it's arguably correct to honor the EXIF orientation, there's probably a lot of web content that depends on EXIT not being honored.
11:06:31 <timeless_mbp> timeless_mbp has joined #css
11:06:45 <Aharon> Aharon has joined #css
11:07:32 <tabatkins> dsinger: Any image editor that doesn't set EXIF correctly is buggy.  It's not our responsibility to fix their bugs.
11:08:48 <tabatkins> tabatkins: We can't break webpages either.
11:09:05 <tabatkins> howcome: We should mandate a default behavior of not honoring, and have a property allowing honoring it.
11:09:18 <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Nov/0004.html
11:09:27 <tabatkins> dbaron: Also, theoretically attr() and Generated Content could let us handle <img>s in HTML.
11:09:45 <tabatkins> Aharon: Next topic.  You have list-style-position, which lets you put the marker inside or outside.
11:09:51 <tabatkins> Aharon: I'm only talking about the outside case.
11:10:10 <tabatkins> Aharon: Currently the bullet goes on the "start" side, based on the item's directionality.
11:10:16 <mjs> mjs has joined #css
11:10:26 <tabatkins> Aharon: Which sounds reasonable, until one realizes that one often has a list where the items are mixed directionality.
11:10:39 <tabatkins> Aharon: For example, a bibliography where some are english and some are hebrew.
11:11:17 <tabatkins> Aharon: The obvious answer is to put @dir on the <li>s directly, but that swaps bullets around inconsistently.  so you have to instead wrap a span and tag *that* with directionality, which is suboptimal.
11:11:36 <fantasai> I would suggest the syntax list-style-direction: left | right | start | match-parent, to be parallel with text-align
11:11:52 <tabatkins> Aharon: Further, the list itself creates a gutter for the bullet based on the list's direction.
11:12:07 <tabatkins> Aharon: If the bullets are mixed, then the bullets for items in the other direction are often invisible because they're off-page.
11:12:25 <tabatkins> Aharon: So my proposal is list-style-direction, which indicates the direction of the marker.
11:12:46 <tabatkins> Aharon: Four values: ltr, rtl, match-list, match-item.
11:13:23 <tabatkins> dbaron: I'm inclined to think we should instead find the right answer, and not expose this directly at all.
11:14:02 <tabatkins> Aharon: The use-case for having it match item is that in arabic, they sometimes like having markers on different sides.
11:14:59 <tabatkins> dbaron: You said that the gutter for the list is a function of the list's direction.  I think that varies between browsers.  In gecko it should match the child's direction.
11:16:04 <tabatkins> dbaron: Wait, maybe I've got that wrong.  The gutter is always generated by the list.
11:16:31 <tabatkins> dbaron: Also, in CSS Lists, there's no concept of a "list", just list items.  So you'd need match-parent, not match-list.
11:18:17 <tabatkins> dbaron: What I think is that, semantically, in the case that you have a list with differeing directionality items, the list-items themselves are all the same directionality, but the *content* has different directions.
11:18:37 <tabatkins> szilles: I'm curious why dbaron doesn't want a property there.
11:20:23 <tabatkins> dbaron: I don't think a full property is warranted to just change the behavior of a single value of anothe rproperty.
11:21:06 <tabatkins> Aharon: Maybe we can just do this as another value on list-style-position?  Currently 'outside' refers to the direction of the list-item.  Maybe a 'list' value that would be like outside but use the parent's directionality?
11:21:40 <tabatkins> aharon: When you text-align anything but start, in IE the outside marker follows the text, so they don't line up.
11:21:56 <tabatkins> aharon: Webkit doesn't make the marker move, so they still all line up.
11:23:01 <tabatkins> aharon: In my opinion, the webkit behavior is more useful.  You can use list-style-position:inside to make the marker follow the text.
11:23:55 <tabatkins> dbaron: We received a ton of feedback from authors that they don't like the bullet being separated from the text.
11:24:12 <tabatkins> dbaron: This is also tied somewhat to issues of floats and such.  When the linebox is shortened we need to specify where the bullet goes.
11:24:21 <tabatkins> dbaron: Right now we tie the bullet to the first line box.
11:24:58 <tabatkins> tabatkins: It seems conceptually consistent to make 'outside' follow the list-item's text, but make the new value 'match-parent' or whatever line them up separate from the text.
11:27:52 <fantasai> dbaron: We still need to displace bullets from floats by match-parent
11:28:58 <tabatkins> aharon: 
11:29:59 <tabatkins> aharon: Finally, I want to check on the status of the bidi things that I haven't been direclty working on, which fantasai has been keeping on top of.
11:30:15 <tabatkins> glazou: Tab, could you keep up a wiki or something for an issues list for Lists?
11:30:19 <tabatkins> tabatkins: Yeah.
11:30:20 <fantasai> tabatkins, you missed something Aharon said, can you put it in the minutes?
11:30:57 <dbaron> fantasai, that was <tabatkins> aharon: Finally, I want to check on the status of the bidi things that I haven't been direclty working on, which fantasai has been keeping on top of.
11:31:01 <fantasai> No, you missed it. He was describing the behavior of match-parent on both list markers and text alignment and how they interact
11:31:08 <fantasai> You did not catch any of that.
11:31:26 <mjs> mjs has joined #css
11:32:10 <myakura> <br type=lunch>
11:32:46 <fantasai> The entire discussion of text-align and its interaction with the list marker was not minuted.
11:32:52 <fantasai> s/marker/marker position/
11:33:23 <dbaron> Basically the idea is that with list-style-position: outside, bullets should stick to the line box (wrap for both text-align and floats), but with list-style-position: outside-parent the direction of the bullet position matches the parent, and the wrapping only accounts for floats and does not account for text-align
11:34:27 <mjs> mjs has left #css
11:34:59 <fantasai> Yes, an Aharon was discussing how that behavior handles certain use cases that are needed
11:35:19 <fantasai> Because, e.g. some lists are rendered with bullets all on one side
11:35:42 <fantasai> but an item of opposite directionality might be aligned to the opposite side
11:35:54 <fantasai> while leaving the bullet aligned with the others in the list
11:36:25 <dbaron> (and with list-style-position:outside the side for the bullet matches the item, as now)
11:49:18 <JonR> JonR has left #css
12:25:23 <jdaggett> jdaggett has joined #css
12:33:10 <plinss_> plinss_ has joined #css
12:36:37 <joonho> joonho has joined #css
12:37:01 <glazou> glazou has joined #css
12:37:51 <myakura> myakura has joined #css
12:38:56 <sylvaing> sylvaing has joined #css
12:39:23 <joonho_2010> joonho_2010 has joined #css
12:39:46 <mmielke> mmielke has joined #css
12:40:33 <szilles> szilles has joined #css
12:40:45 <dethbakin> dethbakin has joined #css
12:41:22 <anne> anne has joined #css
12:41:58 <tabatkin1> tabatkin1 has joined #css
12:42:10 <sbhan> sbhan has joined #css
12:42:33 <parkjy> parkjy has joined #css
12:43:43 <joonho_2010> joonho_2010 has joined #css
12:44:25 <fantasai> ScribeNick: fantasai
12:44:26 <Ms2ger> Ms2ger has joined #css
12:44:35 <fantasai> Topic: Accessibility
12:45:19 <fantasai> Topic: Multi-Col
12:45:45 <fantasai> howcome: I would like to confirm agreement on a few things
12:45:57 <fantasai> howcome: Implementations seem to be coming along nicely
12:46:06 <fantasai> howcome: Hopefully all of the functionality in the spec
12:46:11 <fantasai> howcome: We need some clarifications in the spec
12:46:25 <fantasai> howcome: It's all about spanning elements
12:46:33 <dbaron> dbaron has joined #css
12:46:35 <fantasai> howcome: Remember we have a multicol element here, and we lay out incolums
12:46:41 <fantasai> howcome draws on the board
12:46:49 <fantasai> howcome: The issue is overflow
12:46:59 <fantasai> howcome: There are two reasons for overflow: you could have a constrained height
12:47:13 <fantasai> howcome: or you could have forced column breaks, more breaks than you have columns
12:47:35 <fantasai> howcome: The issue is what to do if you have an element with column-span: all in one of the overflow columns
12:47:53 <fantasai> howcome: Alex proposed to do nothing, i.e. pretend column-span was not set
12:48:20 <Aharon> Aharon has joined #css
12:48:30 <Aharon> Aharon has left #css
12:49:13 <fantasai> howcome: If it's in the overflow columns due to forced breaks, though, I think it makes sense to have it break the column row and render as column-span: all, with content following it filling in columns in a row below it
12:49:26 <fantasai> dbaron: What if you have both a constrained height and forced breaks?
12:49:35 <dbaron> that wasn't me
12:50:11 <fantasai> Alex: If it's due to forced breaks, you can try to put it in the main section. And if it doesn't fit and cause overflow, then you put it in an  overflow column and ignore the spanning behavior
12:50:15 <fantasai> s/dbaron/?/
12:50:40 <mgylling> mgylling has joined #css
12:50:42 <fantasai> Alex: One special case: when you try to place a colspan and it itself doesn't fit, and creates overflow. That creates a circular dependency
12:51:06 <fantasai> Alex: I think we resolved that if it doesn't fit as a span, you ignore the span
12:51:12 <kennyluck> kennyluck has joined #CSS
12:51:33 <fantasai> howcome: So the distinction is, if it fits inside the multicol element as a span, then it does so, else the spanning behavior is ignored
12:51:58 <fantasai> dbaron: You could also ignore in all cases whether there's a constrained height
12:52:08 <fantasai> stevez: I think it should be if it fits or not
12:52:38 <dbaron> s/whether/when/
12:52:53 <fantasai> howcome: I think we should honor it in as many cases as possible, so I think we should hinge this on whether there's room or not
12:53:23 <fantasai> stevez: This might interact with the EPUB case, where they paginate in addition to doing multicol
12:54:51 <yuma_1985> yuma_1985 has joined #css
12:55:17 <homata> homata has joined #CSS
12:55:48 <Kai> Kai has joined #css
12:57:56 <fantasai> Alex: If the forced-break case is height-constrained, where does the overflow columns go?
12:58:07 <shepazu> shepazu has joined #css
12:58:30 <fantasai> Alex: Do the columns overflowing from the second row have full height, or shortened height, i.e. height after the rowspan?
12:58:46 <fantasai> dbaron: So you're saying whether colspan works at all...
12:59:34 <fantasai> howcome: is dependent on whether there is room inside the multicol element
13:00:23 <fantasai> Alex: This could create a very ugly case if you have only one line of space left at the bottom of the multicol. you would create one-line-high overflow columns off to the right
13:00:24 <johnjan> johnjan has joined #css
13:00:35 <dethbakin> dethbakin has joined #css
13:01:10 <fantasai> Alex: As the available space after the colspan approaches zero, the number of columns for content after it approaches infinity
13:02:56 <fantasai> fantasai: From an implementation perspective, I would prefer this method. 
13:03:35 <fantasai> fantasai: The main reason we simplified column-span to 1 or all instead of arbitrary numbers was to avoid a column row with columns of multiple heights
13:03:49 <fantasai> fantasai: if overflow columns were full-height columns, then we lose that simplification
13:04:16 <szilles> What Stevez was saying was that Epub wants to have pagination, expecially in the multicolumn case, because they want to avoid overflow behavior when there are mulitiple columns
13:04:26 <fantasai> fantasai: (Also, if forced-column-breaks can create overflow columns, then your full-height columns would overpaint any such overflowing columns before the column span)
13:05:04 <fantasai> [note to minutes: insert pictures]
13:06:05 <fantasai> dbaron draws some content on the board
13:06:17 <fantasai> I have a some text, then a forced break, then more content.
13:06:22 <fantasai> Then a spanning element.
13:07:06 <fantasai> tab, fantasai: Then you balance the content, which may introduce breaks in the column before the forced break or after it or both
13:08:39 <fantasai> RESOLVED: If a columnspanning element doesn't fit within the multicol element, then it doesn't span anymore
13:09:10 <fantasai> s/element/element without overflowing/
13:09:32 <fantasai> New questions:
13:09:43 <fantasai> 1. do columnspanning elements create a new block formatting context
13:09:55 <fantasai> 2. does columnspanning turn inline elements into blocks?
13:10:27 <fantasai> 3. If the answer to either of the above is yes, does that behavior apply when the columnspanning is ignored due to overflowing (as resolved above)?
13:12:15 <fantasai> 2... or does it not apply to inline elements
13:13:16 <fantasai> fantasai: I think column-span should only apply to block-level elements
13:14:00 <fantasai> Bert reads the applies-to line from the spec
13:14:39 <fantasai> RESOLVED: column-span applies to "in-flow block-level elements"
13:14:52 <fantasai> dbaron: Note in the prose that it has no effect on elements outside a multicol element
13:15:22 <dbaron> Well, really I said that maybe the in-flow aspect is the same as the doesn't-work-outside-multicol aspect, and then we got to that conclusion.
13:15:39 <freedom> freedom has joined #css
13:16:13 <dbaron> fantasai: If a column-spanning element is a BFC root, then margins don't collapse through its boundaries.
13:16:16 <tabatkin1> fantasai: I don't think that margin behavior should change based on whether a colspan is honored or not.
13:16:35 <sylvaing> CSS3 Multicolumn http://www.w3.org/TR/css3-multicol/
13:16:40 <tabatkin1> fantasai: So if it's a spanning element, it should automatically become a BFC and no longer collapse margins through its boundary.
13:17:01 <fantasai> whether or not it's triggered the overflow nonspanning case
13:17:56 <arron> arron has joined #css
13:18:43 <fantasai> fantasai: I think we might need to distinguish whether an element is spanning one column or not spanning
13:19:32 <fantasai> dbaron: I really don't want whether something is a block formatting context root depend on layout
13:19:38 <dsinger> dsinger has joined #css
13:19:40 <fantasai> dbaron: I really want to know what floats are relative to not depend on layout
13:19:59 <fantasai> tabatkin1: So they should become BFCs regardless of whether they actually span something or not
13:20:53 <fantasai> dbaron: We shouldn't have tricky behavior for an error case
13:21:39 <fantasai> Steve: So column-span: all; would mean span the current column in the overflow case
13:21:47 <fantasai> Steve: i.e. the all in that case means the one column
13:22:44 <ChrisL> ChrisL has joined #css
13:22:46 <fantasai> RESOLVED: column-spanning elements are BFC roots always
13:24:25 <fantasai> RESOLVED: Initial value of column-span is 'none'
13:25:09 <fantasai> Bert: Last issue is, do margins between spanning elements collapse?
13:26:16 <freedom> freedom has joined #css
13:26:19 <fantasai> Bert: e.g. if I have H2 followed by H3, can their margins collapse
13:26:35 <fantasai> fantasai: What about between the spanning element and the content of the columns above and below it?
13:26:55 <fantasai> Roughly, answers seem to be Yes, and No, but discussing...
13:28:18 <fantasai> Back to fantasai's issue
13:32:39 <fantasai> fantasai: If you get more columns than you have space for due to forced column breaks, then I think instead of overflowing to the right, I think the columns that don't fit should create a new column row rather than overflowing off to the side.
13:33:05 <fantasai> fantasai: This way we avoid an overflow case.
13:34:05 <fantasai> Alex: I'm concerned people would use this for some weird design cases that don't work well
13:35:48 <sylvaing> (that was szilles)
13:35:57 <fantasai> steve zilles echoes the concern
13:36:15 <Bert> (If the columns "wrap," i.e., the n+1st column starts underneath the 1st, then this becomes a way to make a grid in some cases. Effect is almost the same between 'display: inline-block' and 'break-after: always'...)
13:36:45 <fantasai> dbaron: I'm concerned that we're getting too far from what we're implementing
13:36:59 <fantasai> howcome: We have implementations of multicol, we have to resolve these issues
13:37:24 <fantasai> dbaron: We're not getting much author feedback on columns
13:37:32 <fantasai> tabatkin1: They're not useful in continuous media
13:37:56 <johnjan> s /aaron /arron
13:38:05 <glazou> glazou has joined #css
13:39:53 <fantasai> more discussion of this case
13:40:54 <fantasai> steve zilles thinks this solution causes bad layout
13:41:02 <fantasai> fantasai thinks avoiding overflow is important
13:41:05 <mgylling> mgylling has joined #css
13:42:03 <fantasai> steve: People will insert forced breaks randomly in order to get the layout they want
13:42:57 <alexmog> alexmog has joined #css
13:43:42 <tabatkin1> fantasai: [draws a multicol element overflowing, showing how block-column overflow would result in a bad overflow situation in the constrained height case]
13:44:40 <tabatkin1> fantasai: [draws another one where the multicol has an auto height and stretches to fill the content]
13:45:06 <tabatkin1> tabatkin1: Assuming overflow:visible, yeah, it looks ugly.  But you only get the good overflow if you have explicit column breaks based on where you think is "good".
13:45:38 <tabatkin1> fantasai: Right, so far.  Ideally we'll have in the future a "column-length" that can cause new column rows.
13:45:48 <arron> referring to the first drawing by fantasai, are the columns overflowing to the right or below?
13:47:20 <tabatkin1> fantasai: So if we think that column length is needed to get a sane rendering, maybe we should go ahead and just add column-length now.
13:47:45 <tabatkin1> szilles: I could live with multiple breaks overflowing to the right today.
13:49:00 <fantasai> fantasai: I'm not happy with creating overflow cases when they are not necessary
13:49:28 <fantasai> fantasai: And if we do this today, then you would have to use column-length in order to get explicit-break columns to wrap
13:49:42 <fantasai> tabatkin1: column-length is not the right trigger for wrapping overflowing explicit break columns
13:49:49 <fantasai> tabatkin1: if they're explicit breaks, they're explicit breaks
13:50:41 <fantasai> tabatkin1: If you set column-length: 40em; and your explicit breaks are at 20em, what's your column row height?
13:51:05 <fantasai> steve: Ok, I see what you're saying
13:52:22 <fantasai> Steve: Ok, I'm willing to withdraw my objection provided you add a note about this column-length property
13:52:38 <fantasai> steve: My concern is that people will start putting in explicit breaks just to get the behavior that column-length would have given
13:52:57 <fantasai> Steve: But if you at least put in the spec that this is not intended for this purpose, and how we want to proceed
13:53:44 <fantasai> Peter: Authors don't read the spec. They'll do whatever it takes to make content work the way they want it right now.
13:53:53 <fantasai> Peter: Let's just put this property in right now.
13:54:36 <fantasai> dbaron: I'm not sure this is useful
13:54:50 <fantasai> tabatkin1: This would make multicol usable for me
13:55:26 <fantasai> Peter: Fundamentally, multicol doesn't make much sense on continuous media
13:55:44 <fantasai> Peter: But let's not force people into making unusable layouts.
13:56:21 <freedom> freedom has joined #css
13:56:43 <fantasai> dbaron: I'm not sure we're addressing use cases with multicol
13:57:52 <fantasai> dbaron: And I don't think we would implement all this.
13:58:04 <fantasai> fantasai: column-length is a piece of cake
13:58:24 <fantasai> dbaron: But we don't implement column-spanning. And we can't balance columns with forced column breaks in our current design.
13:58:51 <fantasai> ?: We have a lot of demand for this, actually.
13:59:17 <fantasai> ?: We haven't switched from table layouts to CSS due to lack of multicol
14:00:44 <fantasai> howcome: So how would you decide the gap between the column rows?
14:00:50 <fantasai> fantasai: use column-gap
14:01:18 <fantasai> fantasai: can give it two values, just like border-spacing, if needed
14:01:32 <fantasai> Alex: I want separate properties
14:01:38 <fantasai> fantasai: Do you need them to cascade independently?
14:01:45 <fantasai> Alex: I just like having separate properties
14:02:00 <fantasai> fantasai: If we need separate properties, we can split them out later and make column-gap a shorthand.
14:02:34 <fantasai> Steve: In XSLFO, we replicated the multicol box
14:03:07 <Kai> Kai has joined #css
14:03:12 <fantasai> s/?/Kai/
14:04:04 <fantasai> various concerns raised to porting this idea to CSS
14:04:09 <Bert> (Chained regions, e.g., César's extensions to template layout, would solve most use cases as well. That, too, is an example of pagination inside a continuous display...)
14:05:42 <fantasai> Steve: I'm going back to my position of putting a note that this doesn't solve the following problems.
14:06:27 <fantasai> howcome: We go back to the issue of where the overflowing forced-break column goes: off to the right, or wrap under?
14:06:42 <fantasai> howcome: I'm in favor of wrapping under, quite stronger.
14:07:17 <fantasai> Alex: You need gap and rules, though.
14:09:09 <fantasai> fantasai thinks we should just use the column-gap and deal with customized gaps and rules later
14:10:10 <Kai_> Kai_ has joined #css
14:11:54 <fantasai> steve: But I don't think column-gap is good enough.
14:11:58 <Kai> q+ to say that currently control over layout is key
14:12:18 <fantasai> fantasai: I'm not saying it's good enough, I'm saying it's adequate as a default even in the future when we have all these controls
14:12:54 <fantasai> fantasai: The only other reasonable default is a zero gap. I don't see how that's better
14:13:04 <fantasai> ...
14:13:11 <fantasai> tabatkin1 doesn't want to half-ass this
14:13:13 <fantasai> ...
14:13:33 <fantasai> Kai: Web page layout is very precise right now.
14:13:45 <fantasai> Kai: Automatically wrapping columns loses precision
14:15:07 <fantasai> Kai: It's easier to control if it always overflows to the right
14:16:09 <Kai> it would be good to have this as default and have the ability to have it wrap
14:17:11 <fantasai> howcome takes a straw poll on behavior
14:17:17 <fantasai> A - overflow to the right
14:17:20 <fantasai> B - wrap under
14:17:24 <fantasai> Bert: A
14:17:25 <fantasai> Kai: A
14:17:27 <fantasai> Steve: A
14:17:29 <fantasai> Peter: B
14:17:30 <fantasai> Markus: A
14:17:33 <fantasai> Tab: A
14:17:35 <fantasai> beth: A
14:17:38 <fantasai> ?: A
14:17:41 <fantasai> ??: B
14:17:49 <fantasai> Chris: A
14:17:53 <fantasai> Daniel: A
14:17:55 <fantasai> John: A
14:17:58 <fantasai> Sylvain: A
14:18:00 <fantasai> Koji: A
14:18:00 <arron> Arron: A assuming right is actually end
14:18:06 <fantasai> fantasai: B
14:18:09 <fantasai> arron, :)
14:18:24 <fantasai> Alex: A
14:18:27 <fantasai> dbaron: A
14:18:42 <fantasai> jdaggett: A
14:18:48 <fantasai> no comment from the peanut gallery
14:18:56 <dbaron> howcome: B
14:20:06 <glazou> s/peanut gallery/other observers
14:20:56 <glazou> glazou has joined #css
14:21:40 <fantasai> Peter: I think it's unfortunate that we're choosing a behavior for multicol that doesn't work well for print
14:21:46 <fantasai> RESOLVED: overflow to the right
14:28:58 <timeless_mbp> timeless_mbp has joined #css
14:29:03 <nimbupani> nimbupani has joined #css
14:34:16 <tantek> tantek has joined #css
14:35:07 <tabatkins> tabatkins has joined #css
14:35:56 <yuma_1986> yuma_1986 has joined #css
14:37:55 <kennyluck> RRSAgent, make minutes
14:37:55 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-CSS-minutes.html kennyluck
14:39:48 <sbhan> sbhan has joined #css
14:41:57 <johnjan> johnjan has joined #css
14:44:04 <mgylling> mgylling has joined #css
14:46:27 <homata> homata has joined #CSS
14:56:54 <glazou> glazou has joined #css
14:56:55 <yuma_1986> yuma_1986 has joined #css
15:01:00 <Kai> Kai has joined #css
15:06:09 <homata> homata has joined #CSS
15:08:01 <dethbakin> dethbakin has joined #css
15:09:04 <joonho> joonho has joined #css
15:09:30 <tabatkins> http://www.xanthir.com/blog/b48Z0
15:09:48 <fantasai> tabatkins: I put up a list of all the new changes that Alex and I have agreed on for the flexbox draft
15:10:13 <fantasai> fantasai suggests putting that on the mailing list
15:10:48 <fantasai> tabatkins: Most are pretty small; syntax-level changes
15:11:00 <fantasai> tabatkins: Major one is that we're changing the prefix from box- to flex-
15:11:07 <fantasai> tabatkins: Because box is overloaded in CSS
15:11:16 <fantasai> tabatkins: The next is determining the direction
15:11:28 <dethbakin> dethbakin has joined #css
15:11:33 <fantasai> tabatkins: We used to have two properties for that
15:11:50 <fantasai> tabatkins: Don't believe they need to cascade independently, so merged them into one that has all combinations
15:12:42 <fantasai> dbaron: That probably makes sense
15:13:20 <fantasai> tabatkins: At the last F2F sorta decided that things should flex differently when they're growing from when they're shrinking
15:13:21 <mollydotcom> mollydotcom has joined #css
15:13:38 <fantasai> tabatkins: e.g. having the biggest flex, which normally becomes the biggest, become the smallest when shrinking
15:13:47 <fantasai> tabatkins: Split into flex-grow and flex-shrink
15:14:02 <fantasai> tabatkins: Also margins participate in flexing
15:14:17 <fantasai> tabatkins: 'auto' flexes as 1
15:14:36 <fantasai> tabatkins: Very common use case was splitting things to align half items on left, half on right
15:14:43 <fantasai> tabatkins: previously had to add a dummy element
15:14:46 <fantasai> tabatkins: now can do that with margins
15:14:57 <fantasai> tabatkins: Keeping box-ordinal-group, renamed to something shorter
15:15:03 <fantasai> tabatkins: Multiple lines, not super-sure about
15:15:17 <timeless_mbp> timeless_mbp has joined #css
15:15:20 <fantasai> tabatkins: Seems like a large enough topic that it should be addressed more thoroughly
15:15:21 <freedom> freedom has joined #css
15:15:30 <fantasai> Alex: There are no current implementations right now of multiple lines
15:15:38 <fantasai> tabatkins: so thinking we might push that for the next level
15:15:58 <fantasai> Alex: What was the motivation for multiple lines?
15:16:06 <fantasai> dbaron: You'd have to ask hyatt. Not sure he'd know either
15:16:23 <fantasai> Alex: We had some use cases that seemed interesting, but not sure any of them are really important.
15:16:31 <fantasai> Alex: One example of multi-line box is a dialog box with a lot of tabs
15:16:46 <fantasai> Alex: But that's not a good design to begin
15:17:06 <fantasai> with
15:17:52 <fantasai> Alex: The biggest problem with multicol is how to handle the last line
15:17:59 <fantasai> Alex: Sometimes there's only one item on the last line
15:18:07 <fantasai> Alex: I'm not sure I've seen any good design for this
15:18:22 <smfr> smfr has joined #css
15:18:29 <fantasai> Alex: So multiline is only useful in combination with max width or something like that
15:18:52 <fantasai> fantasai had a use case of a catalog, with tiles representing each item;
15:19:03 <fantasai> fantasai: But pushing multiline flexbox to a next level makes sense to me
15:19:27 <fantasai> tabatkins: The major change is alignment in the transverse direction
15:19:45 <fantasai> tabatkins: Previously handled with box-align, which would align the box to the top, bottom, or centered
15:19:51 <fantasai> tabatkins: or could stretch the box
15:20:06 <fantasai> tabatkins: I expressed some unhappiness about that design
15:20:23 <fantasai> tabatkins: I spent some time looking at it and realized you can do every case except baseline with margins
15:20:43 <fantasai> tabatkins: Current proposal is to have one keyword that makes the box shrink
15:21:11 <fantasai> tabatkins: Can align that box with margins
15:21:23 <fantasai> tabatkins: ...
15:21:42 <fantasai> dbaron: The thing that seems weird to me is if the child is itself a flexbox with the alignment in the other direction
15:21:55 <fantasai> dbaron: It's unclear whether to throw out box-align or throw out box-pack
15:22:10 <fantasai> dbaron: normally the child is in the orthogonal direction
15:22:22 <fantasai> dbaron: The control was for the alignment in the axis direction
15:22:45 <fantasai> dbaron: With your new proposal, if the child is a flexbox with an orthogonal direction
15:22:49 <fantasai> dbaron: which do you use?
15:22:58 <fantasai> dbaron: because you have two different things telling you how to align stuff
15:23:04 <fantasai> tabatkins: depends what the child wants to be
15:23:18 <freedom> freedom has joined #css
15:23:38 <fantasai> fantasai: I'm getting confused here
15:23:53 <fantasai> Alex: I think it's a good point. What we're trying to do here is require that the child layout has certain capabilities
15:24:08 <fantasai> Alex: So far there is only one precedent of requirement for nested layout, ability to declare its own baseline
15:24:17 <fantasai> Alex: We're adding requirement of declaring vertical alignment
15:24:35 <fantasai> Tab draws a big box with two small boxes inside
15:24:47 <fantasai> one on the left one on the right
15:25:03 <fantasai> right child has three boxes stacked vertically and is a flexbox
15:25:10 <fantasai> left child has squiggles aligned to the top
15:25:24 <fantasai> align: before assigned to big box
15:25:32 <fantasai> pack: end assigned to right child
15:26:03 <fantasai> Tab: Hm, I see what your'e talking about. Yes, this explicitly resolved somehow
15:26:17 <fantasai> dbaron: I think you'd want the thing on the child to beat the one on the parent
15:26:30 <ibrahima_> ibrahima_ has joined #css
15:26:45 <fantasai> fantasai: Maybe make it not apply to flexboxes
15:26:58 <fantasai> Alex: What if the left one is a table?
15:27:17 <fantasai> dbaron: I think you want these differentiations to apply to non-flexbox children
15:27:53 <fantasai> Alex: Could define this alignment to only apply to block containers
15:28:13 <fantasai> dbaron: baseline has its own problems with vertical-axis flexboxes. That's it's own problem
15:29:02 <fantasai> Alex: We're making a complicated problem just to solve baseline alignment. Not sure it's worth it.
15:29:21 <fantasai> Tab: baseline alignment is very common for e.g. tab strips
15:30:32 <fantasai> Tab: Say I have <ul> with <li>, render as a horizontal flexbox tab strip
15:30:50 <fantasai> Tab: Would want different alignments, bottom aligned, baseline aligned, centered...
15:30:54 <fantasai> Alex: .. nested elements?
15:30:59 <fantasai> Tab: How would you do that with nested elements?
15:32:33 <fantasai> fantasai: You might want to align to the top baseline or to the bottom baseline
15:32:40 <fantasai> Alex: Let's step back and talk about logistics of the spec
15:32:54 <fantasai> Alex: Let's suppose hypothetically that next implementation comes out with this new syntax
15:33:26 <fantasai> Alex: Are the existing implementations going to add another new prefixed implementation for this new spec and then on the next round it will become standard which will be in three years from now? Is that the route that we are looking at?
15:33:46 <fantasai> Alex: The alternative would be to make small changes to the spec which makes Mozilla and WebKit implementations nearly compatible with the spec
15:34:01 <fantasai> Alex: Which means next release of webkit/mozilla/ie would bring us close to CR
15:34:56 <fantasai> Tab: There are some changes that are important and we definitely want, e.g. flex-grow flex-shrink split
15:35:12 <rigo> rigo has joined #css
15:35:24 <fantasai> Alex: Question is do we consider existing implementations important in validating the spec, in which case we are trying to make less changes as long as they are equivalent
15:35:40 <fantasai> Alex: Or are we taking the position that we are changing everything freely
15:35:48 <fantasai> Alex asks dbaron
15:36:02 <fantasai> dbaron: I think in the end we're going to have to rewrite a lot of it either way. Hard to say when that's going to happen.
15:36:10 <fantasai> dbaron: But I think we should try and get this right.
15:36:43 <fantasai> Alex: I'm not as concerned with complexity of implementations. I just want this to stabilize faster. Want to know if that matters.
15:37:45 <fantasai> dbaron: What are these changes relative to?
15:37:58 <fantasai> Tab: Last official WD
15:38:56 <fantasai> Tab: Dropped idea of flex units, since couldn't figure out baseline alignment with that.
15:40:57 <fantasai> discussion of stability, etc.
15:41:29 <fantasai> Markus suggests this is parallel to multicol, fantasai says it's not nearly as advanced--hasn't gone through design review, which we are doing now
15:43:19 <fantasai> more discussion of stability and implementation release schedules and interop on old syntax etc
15:43:30 <fantasai> Alex is concerned about interop on old standard
15:43:36 <fantasai> instead of on new standard
15:44:44 <fantasai> Tab: We can try to make changes to box-align more minor.
15:44:57 <fantasai> Tab: I tried to leave it unchanged and mix in vertical-align to align contents 
15:45:09 <fantasai> Tab; But wasn't getting sane answers when I tried to map out how that works
15:46:58 <fantasai> ...
15:47:13 <fantasai> dbaron: I like the idea of using vertical-align. Want to know what the issues were.
15:47:55 <fantasai> Alex: If we resolve on everything except baseline, and can get those edits into the spec, that would be a great outcome of this meeting.
15:48:56 <fantasai> RESOLVED: Change prefix from box- to flex-
15:49:12 <freedom> freedom has joined #css
15:49:22 <fantasai> Next issue: combining box-orient and box-direction into flex-direction
15:49:37 <fantasai> Alex: I'm not too thrilled with changing that. think old is more intuitive
15:49:47 <fantasai> dbaron thinks the opposite: prefers Tab's proposal
15:49:58 <fantasai> RESOLVED: Combine box-orient and box-direction into flex-direction
15:50:27 <fantasai> RESOLVED: Split box-flex into flex-grow and flex-shrink
15:50:56 <fantasai> dbaron: I think what the spec said and what implementations did is different
15:51:23 <fantasai> fantasai: So maybe look into what current implementations do to determine default behavior of flex-shrink
15:52:15 <fantasai> Should auto margins flex as one?
15:52:20 <fantasai> fantasai: I'm strongly in favor
15:52:38 <fantasai> RESOLVED: 'auto' margins flex as 1
15:53:20 <fantasai> Tab: Drop box-flex-group? Not sure on this one
15:53:44 <fantasai> dbaron: I think splitting out flex-shrink would solve many of the use cases here
15:53:54 <fantasai> dbaron: Note we don't implement flex-group 
15:54:50 <fantasai> Alex: We haven't heard any significant use cases, and it's expensive to implement
15:54:56 <fantasai> RESOLVED: Drop box-flex-group
15:55:20 <fantasai> Drop multiple-line support?
15:55:25 <fantasai> Alex: Mark at-risk?
15:55:58 <fantasai> dbaron: We should drop before CR if we're not sure that the spec is ready
15:56:13 <fantasai> dbaron: At-risk is something that is ready to be implemented, but we're not sure that it will be implemented
15:56:38 <dbaron> I'm ok with either way.
15:56:47 <fantasai> Tab: The existing behavior is well-specified, just too simplistic to be useful
15:56:55 <fantasai> RESOLVED: Mark multiline at-risk.
15:57:57 <fantasai> RESOLVED: Rename box-ordinal-group to either flex-order or flex-index (mark as issue)
15:58:26 <fantasai> Tab: Multiple lines .. current syntax is to take values of single or multiple
15:58:44 <fantasai> Tab: Suggest to change to box-wrap: wrap | nowrap
15:59:20 <fantasai> fantasai: Makes sense to me.
16:00:34 <fantasai> Alignment in transverse direction
16:00:50 <fantasai> Alex: Would it help to solve this problem if you could independently specify background on the flexbox item from the actual child?
16:01:00 <howcome> howcome has joined #css
16:01:23 <fantasai> Tab: It's weird, but would solve my use case
16:01:30 <fantasai> fantasai cringes
16:01:49 <fantasai> dbaron: Would prefer to solve it some other way than a pseudo-element
16:02:11 <fantasai> RESOLVED: Mark entire transverse alignment as an issue until further notice.
16:02:15 <fantasai> Topic: GCPM
16:02:18 <howcome> http://dev.w3.org/csswg/css3-gcpm/#page-selection-nth
16:02:30 <fantasai> howcome: Two issues I have
16:02:52 <fantasai> howcome: One thing we cut out earlier this year was named page lists
16:03:37 <fantasai> howcome: But the requirement is still there
16:03:48 <fantasai> howcome: There's a use case for being able to style pages differently.
16:04:06 <fantasai> howcome: Named page lists approach was heavyweight; not suggesting to re-add that
16:04:49 <fantasai> howcome: Suggesting :nth page selector
16:05:49 <fantasai> howcome: Here's an example *pulls up nearest book*
16:05:49 <arron> I would prefer this to be :nth-page not just :nth
16:07:00 <hsivonen> hsivonen has joined #css
16:07:20 <fantasai> howcome: You don't want headings on the spread of a chapter heading
16:07:47 <bradk> bradk has joined #css
16:07:48 <fantasai> fantasai: How about :first, :middle, :last?
16:07:59 <fantasai> howcome: Need to access 2nd page
16:08:03 <fantasai> fantasai: what for?
16:08:25 <fantasai> howcome: both pages on the spread of the chapter heading need to be selected to e.g. drop headers
16:09:59 <fantasai> discussion of how to indicate the start and end of a named series
16:10:38 <dbaron> I think if you want @page chapter:nth(2), you need a new value for the 'page' property that makes a new chapter "restart" the sequence of chapter pages.
16:11:30 <fantasai> Tab: You could have a :spread() that takes a page name, and is true if either side of the spread has a page with that name
16:12:15 <fantasai> fantasai: But all the pages in that book are "chapter" pages. You have to somehow distinguish the start and end of a particular chapter page series
16:13:30 <fantasai> howcome explains some use case involving widows and changing page sizes
16:13:55 <fantasai> glazou: complex selectors are very hard to present in a UI
16:14:20 <fantasai> glazou: I'm not saying the feature is not needed, just presenting a warning
16:17:25 <fantasai> dbaron: You want the nth page of that name.
16:17:33 <fantasai> dbaron: But that's actually different from the nth page
16:17:59 <fantasai> dbaron: They should be separate selectors
16:17:59 <dbaron> Some of these examples are :nth-of-name(), some are :nth-page()
16:18:28 <dbaron> or maybe :nth-of-name() should be :nth-of-sequence()
16:19:01 <dbaron> ?: maybe we don't need nth... just first-in-sequence?
16:19:38 <fantasai> fantasai: Seems to me you just need to address the first page, first spread, last page, and last spread of a named series
16:20:26 <freedom> freedom has joined #css
16:20:48 <fantasai> howcome: The case I need to address an arbitrary page is to address widows and orphans
16:21:02 <fantasai> howcome: The publisher doesn't want to have a single line alone on a page
16:21:19 <fantasai> howcome: so he tweaks the size of the page before it to accommodate an extra line
16:22:19 <fantasai> Bert: TeX alters the line-height for this case
16:22:27 <fantasai> howcome: It's a spread. You want to keep the baselines even
16:22:33 <fantasai> Peter: you have this exact same problem in columns
16:22:51 <fantasai> Tab: Maybe we need more powerful orphan-widow properties
16:23:06 <mjs> mjs has joined #css
16:23:50 <fantasai> Peter: I don't like that we're targetting the page by number
16:24:04 <fantasai> Peter: You don't want to target the page with a problem.
16:24:57 <fantasai> Peter: If I edit the document: change the content, or the styling, the problem is no longer on the page I targetted.
16:25:03 <fantasai> glazou: It's a hack
16:27:05 <fantasai> Discussion returns to the 'page' property
16:27:29 <anne> anne has joined #css
16:28:01 <tabatkins> glazou: What happens if the element that triggers a page group has a page break property.  Then it's impossible to know which page is the second page he wants.
16:28:18 <tabatkins> howcome: If it's inserted before, you don't count it.
16:28:36 <tabatkins> howcome: The idea is that every chapter starts on the left of a spread.
16:29:50 <tabatkins> howcome: And you want to remove the headings on the second page of the chapter.
16:30:04 <tabatkins> glazou: No, you want to remove it on the other page of the spread that the chapter start is in.
16:30:19 <tabatkins> tabatkins: If the chapters start on the right, then you want to alter the last pag eof th eprevious chapter, instead.
16:31:27 <tabatkins> fantasai: [explains why chapter:first doesn't work, with analogy to p:first-child]
16:32:12 <tabatkins> fantasai: [explains :first-page(pagename), and :first-spread(pagename)]
16:33:10 <tabatkins> howcome: That doesn't solve the widows problem.
16:35:23 <tabatkins> plinss: It doesn't fully solve the existing problem, either.  If the chapter starts on a right page, and the left page has content, you don't necessarily want to style the left page.
16:35:54 <fantasai> :first(pagename) selects the page on which an element with page: pagename; starts
16:35:59 <tabatkins> howcome: Yeah, you don't want to select backwards.  Just select the second page, if the chapter starts on a left page.
16:36:11 <fantasai> :first-spread(pagename) selects that page and potentially the next page if they are part of the same spread
16:36:36 <fantasai> similarly for :last-page(pagename) and :last-spread(pagename)
16:37:31 <tabatkins> tabatkins: Okay, if that's the case then I don't have a problem with selecting the second page explicitly.
16:38:39 <tabatkins> glazou: I think that this offers too much power - it will be abused.
16:39:00 <fantasai> and you can combine with :left or :right for styling as needed
16:39:40 <Kai> Wondering about workflows.  As discussed now a piece of text to be printed will have to be styled after all textual changes have been made.  Any changes to the text before that might change the layout and leave the author to re-style the whole text.
16:39:59 <fantasai> Peter: Whether you have left and right pages or just right pages is a print-time decision
16:40:09 <fantasai> fantasai: not in CSS. All pages are classified as left or right
16:40:18 <fantasai> howcome: Right, suppose you're printing to PDF
16:40:49 <fantasai> Peter: If I print this document in non-duplex mode, I don't want left and right pages
16:41:39 <fantasai> Alex: could you have a media query for whether you have facing pages?
16:42:56 <fantasai> unminuted discussion
16:44:27 <fantasai> howcome: I want to suppress the headings on the pages in both page on the spread to be suppressed
16:44:54 <fantasai> peter: You want controls for spreads, not for numbered pages
16:45:24 <fantasai> Topic: Other
16:45:39 <fantasai> Bert: We can talk to XSLFO people. They've done this before
16:45:57 <fantasai> Bert: It might be more involved than just headers and footers.
16:46:25 <howcome> http://dev.w3.org/csswg/css3-gcpm/#the-hyphenate-last-line-avoid-property
16:49:00 <fantasai> Alex: Do we need a control for this property?
16:49:09 <fantasai> Alex: Couldn't we just always avoid it?
16:50:22 <fantasai> fantasai: Do we need a control for this, or can we just have the UAs be smart about it?
16:51:54 <fantasai> jdaggett: Do we need different values?
16:52:15 <fantasai> howcome: There are different policies among publishers. This is a control that's been asked for.
16:52:20 <dbaron> howcome: We can drop the 'always' value; it's not as important.
16:52:37 <fantasai> glazou: What happens if the last word is wider than the column?
16:52:52 <fantasai> howcome: It's an avoid, not a requirement
16:54:26 <fantasai> I think auto should be asking the UA to be smart and do something reasonable, not allowing anything....
16:54:53 <fantasai> Alex: spread should be on by default. Or maybe more than spread
16:55:44 <smfr> smfr has joined #css
16:56:56 <fantasai> Peter: Publishers do manual tweaking to avoid awkward breaks. Reset breaking for one particular word on one particular page
16:57:02 <fantasai> Peter: We're not going to do that in CSS
16:59:19 <fantasai> Peter describes some of the difficult aspects of pagination
16:59:47 <fantasai> Peter: But if you tweak things at that level, you only satisfy layout for that particular output instance
16:59:59 <Bert> (Another way to reduce the ugliness in the example: This is just a / simple ex- / ample to show / Antarctica.)
17:00:02 <fantasai> Peter: It doesn't apply if you change any of the output environment parameters
17:00:15 <fantasai> Peter: By flipping this switch, it'll help some of the time and hurt some of the time.
17:00:27 <Kai> isn't it exactly the ability to output on different output environments that makes this feature necessary?
17:01:46 <fantasai> Peter: I read e-documents on this thing (iphone) all the time. And I change the font size all the time.
17:01:54 <fantasai> Peter: The author isn't thinking of that
17:01:56 <mjs> mjs has joined #css
17:03:14 <fantasai> Peter: I don't want us to target the weird thing that happens on my computer. I want to target the general problem.
17:04:19 <fantasai> Meeting closed.
17:12:08 <smfr> fantasai: is there any chance of getting minutes published at the end of each day?
17:13:19 <dsinger> dsinger has joined #css
17:13:32 <fantasai> smfr: I suppose I could do it if you really really really need it
17:13:48 <fantasai> smfr: It will take me probably around 4 hours
17:14:04 <smfr> fantasai: i'm curious about some of the discussion in the morning.
17:14:09 <fantasai> RRSAgent: pointer
17:14:09 <RRSAgent> See http://www.w3.org/2010/11/01-CSS-irc#T17-14-09
17:14:14 <fantasai> The IRC logs are available
17:14:22 <fantasai> see above
17:14:23 <smfr> ah excellent, thanks!
17:14:26 <smfr> that's fine
17:14:31 <fantasai> cool
17:16:35 <mollydotcom> mollydotcom has left #css
17:18:07 <bradk_> bradk_ has joined #css
17:19:14 <TabAtkinsTPAC> TabAtkinsTPAC has joined #css
17:19:49 <bradk_> Hello
17:20:27 <TabAtkinsTPAC> brad!
17:21:48 <bradk_> Howdee. Do you know where I can find the schedule of what you'll be discussing? And raw irrc log of discussion so far?
17:22:43 <smfr> RRSAgent: pointer
17:22:43 <RRSAgent> See http://www.w3.org/2010/11/01-CSS-irc#T17-22-43
17:22:54 <smfr> bradk_: ^^ irc log
17:24:41 <bradk_> Thanks
17:25:53 <jdaggett> jdaggett has joined #css
17:27:27 <bradk_> I also could not find the link to agenda wiki in my email. I know it must be there somewhere, but I must be searching for the wrong terms.  
17:27:35 <mgylling> mgylling has joined #css
17:32:10 <mmielke> mmielke has joined #css
17:32:35 <smfr> TabAtkinsTPAC: i think a big unresolved transform issue is how they apply to inlines
17:33:23 <TabAtkinsTPAC> bradk_: the link to the agenda should be at the very beginning of the irc logs.
17:33:45 <TabAtkinsTPAC> smfr: Yes, indeed.  Should we talk about that during the FXTF meeting on Thursday, or what?
17:34:10 <smfr> TabAtkinsTPAC: i think the css-wg is more likely to have useful input
17:34:24 <TabAtkinsTPAC> Ok.  I'll push it on the agenda tomorrow.
17:34:39 <smfr> if it's later afternoon i could join
17:34:41 <TabAtkinsTPAC> The question is between transform-each-box or transform-bounding-box, right?
17:34:42 <TabAtkinsTPAC> kk
17:34:50 <smfr> options are:
17:34:57 <smfr> 1. disallow transforms on inlines
17:35:03 <smfr> 2. transform the bounding box
17:35:08 <smfr> 3. transform line boxes somehow
17:35:29 <TabAtkinsTPAC> kk
17:35:30 <smfr> 4. transform each bit like gecko does
17:35:36 <smfr> 5. maybe others
17:35:49 <TabAtkinsTPAC> Oh, right, (4) is different because of, frex, bidi mixes within a line?
17:35:53 <smfr> right
17:36:03 <smfr> i'm tempted to suggest `
17:36:05 <smfr> er, 1
17:36:24 <TabAtkinsTPAC> Yeah, that might be the best.
17:36:37 <smfr> authors can use inline-box if they have to
17:36:41 <arron> I think 1 would be best too
17:36:45 <TabAtkinsTPAC> We resolved on "just don't allow it on inline" for column spans in multicol, so it seems like we're comfortable with that.
17:36:56 <smfr> sweet
17:37:29 <TabAtkinsTPAC> smfr: Any thought on radial gradient canonical forms, while I have you here?
17:37:40 <smfr> no, i haven't studied the radial gradients spec yet
17:37:51 <smfr> saw your emails tho
17:38:01 <TabAtkinsTPAC> Did you read my email from yesterday?
17:38:20 <smfr> i saw it, then saw the second one so didn't read the first one entirely ;)
17:39:39 <smfr> TabAtkinsTPAC: i don't quite grok the start point + angle form
17:39:59 <TabAtkinsTPAC> Okay, so here's how it works.
17:39:59 <smfr> you say the end point is the start rotated around the middle, but that's not true if there's an angle
17:40:19 <TabAtkinsTPAC> Right.  What you do is, first, draw the reference line from the start point to the rotated end point.
17:40:21 <arron> arron has joined #css
17:40:32 <TabAtkinsTPAC> Then, rotate the reference line *around the center of the box* by the angle.
17:40:47 <smfr> ok, so 2 things affect the final slant
17:40:50 <smfr> the points, and the angle
17:40:53 <TabAtkinsTPAC> Then the gradient start is the "point on the reference line where a line drawn perpeendicular intersects X cornere", etc.
17:41:12 <TabAtkinsTPAC> Yes, they work together, and have good behavior for their defaults.
17:41:36 <smfr> hmm, that sounds more complicated
17:42:16 <smfr> and it doesn't address the use of the explicit start/end points which places the gradient over some sub-rect
17:42:27 <TabAtkinsTPAC> Only because the combination of both a ref-line and an angle is strictly unnecessary.  It's only specced that way so that the two cases are specific instances of a general case, and can be transitioneed together.
17:43:11 <TabAtkinsTPAC> smfr: I don't know if that's actually a use-case.  I've never had to do that.
17:43:38 <TabAtkinsTPAC> And I made myself a gradient-image generator in PHP, so I used gradients pretty freely in designs.
17:44:59 <plinss_> plinss_ has joined #css
17:45:03 <TabAtkinsTPAC> 95% of use-cases, I think, can be addressed solely with either an angle, or a box-cardinal direction.
17:45:43 <TabAtkinsTPAC> I'd be fine with just speccing both of those as separate functions, but if I can make a single function do them both without a lot of hassle, then I'd prefer to.
17:46:34 <TabAtkinsTPAC> I'd like to align whatever solution I do for linear gradients with a similar solution for radials, though.  Radials are a much harder problem.
17:46:41 <TabAtkinsTPAC> Anyway, let me post that email to the list.
17:46:45 <smfr> k
17:51:32 <TabAtkinsTPAC> k, sent.  now, off to dinner for a few hours.
17:52:10 <TabAtkinsTPAC> bradk_: Check out the email too.  I think the model I propose for linear gradients has roughly equivalent power to yours, but more continuous behavior and less abstraction.
17:53:10 <TabAtkinsTPAC> bradk_: I still don't like the mode where you pretend that the angle is relative to a unit box and then transform it.  But this one, where a bare angle is relative to a horizontal line and thus gives us the algebra-inspired behavior, still seems cool.
18:04:04 <plinss__> plinss__ has joined #css
18:04:25 <plinss__> plinss__ has joined #css
18:39:42 <nimbupani> nimbupani has joined #css
18:58:53 <arronei> arronei has joined #CSS
19:12:10 <bradk__> bradk__ has joined #css
19:15:22 <tantek> tantek has joined #css
19:18:32 <jdaggett> jdaggett has joined #css
19:25:12 <mgylling> mgylling has left #css
19:41:45 <nimbupani> nimbupani has joined #css
20:22:42 <bradk_> bradk_ has joined #css
20:46:33 <Peter`> Peter` has joined #css
20:51:03 <bradk_> Tab, I see it the other way around, where the keyword just turns off the bit that prevents the angle from stretching as the box stretches. 
22:31:04 <arronei> arronei has joined #CSS
23:07:06 <plinss_> plinss_ has joined #css