IRC log of css on 2011-03-08

Timestamps are in UTC.

00:00:29 [Bert]

JJ: Just say "HTML specifications"

00:01:08 [Bert]

DG: Cannot reference HTML5 as it is not a REc.

00:01:21 [arno1]

arno1 has joined #css

00:01:48 [Bert]

RESOLVED: "and future versions" added to to section 3.1 for issue 255.

00:02:10 [Bert]

Topic: issue 256

00:02:20 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-256

00:03:02 [Bert]

DG: Just add "in HTML"

00:03:17 [Bert]

TC: *any version* of HTML.

00:04:28 [Bert]

PL: How about XForms?

00:04:39 [Bert]

... Leave it as is.

00:04:55 [Bert]

RESOLVED: No change for issue 256.

00:05:00 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-257

00:05:05 [Bert]

Topic: Issue 257

00:05:59 [Bert]

PL: I think we do want boxes to have properties.

00:06:03 [Bert]

DB: I agree.

00:06:07 [Bert]

PL: So no chnage?

00:06:17 [Bert]

RESOLVED: no change for issue 257

00:06:33 [Bert]

Topic: Issue 259

00:06:35 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-259

00:07:43 [Bert]

DG: Indeed the 'inherit' keyword is never the computed value.

00:08:35 [Bert]

HL: In css3-values, 'inherit' is not the specified value.

00:08:46 [Bert]

DB: We might have changed that already.

00:09:24 [Bert]

DG: If 'inherit' is not returned as the specified value, that breaks editors.

00:09:47 [Bert]

EE: Have to distinguish from what the CSSOM says.

00:10:29 [Bert]

HL: There is a "cascaded value" also, that is what editors need.

00:11:14 [Bert]

... The text in CSS 2.1 is consistent with css3-values.

00:11:47 [Bert]

PL: So no change?

00:11:54 [Bert]

JJ: And do something in level 3?

00:12:05 [Bert]

TA: Better not have level 3 contradict level 2.

00:12:57 [Bert]

HL/JJ: Bahevior isn't different, there is just different terms: cascaded values.

00:13:54 [Bert]

EE: Inconsistency between 3 and 2 is the missing term cascaded value.

00:14:02 [Bert]

... Could add a note about that.

00:14:28 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-260

00:14:46 [Bert]

ACTION elika: write a proposed text for issue 259

00:14:46 [trackbot]

Created ACTION-310 - Write a proposed text for issue 259 [on Elika Etemad - due 2011-03-15].

00:15:04 [Bert]

Topic: issue 260

00:16:29 [Bert]

EE: We added that note to clarify something else. Opinions differ on what is more or less confusing. So no change.

00:16:53 [Bert]

RESOLVED: no change for issue 260

00:17:07 [Bert]

Topic: Issue 261

00:17:34 [Bert]

DG: Nobody ever complained. Seems not worth a chnage.

00:18:02 [Bert]

PL: Is this already in Selectors spec?

00:18:19 [Bert]

DG: No, that has the same prose as 2.1.

00:18:26 [arno]

arno has joined #css

00:19:14 [Bert]

PL: No chnage needed. Selectors is a clearer, that's good enough.

00:19:23 [Bert]

RESOLVED: No change issue 261

00:20:50 [Bert]

[Discussion about issues list and numbers, duplicates]

00:21:37 [Bert]

JJ: Issue 262 seems duplicate of 261 and 260.

00:22:00 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-262

00:22:25 [Bert]

Topic: Issue 262

00:22:35 [Bert]

PL: Propose no change for issue 262.

00:23:01 [Bert]

RESOLVED: No change issue 262

00:25:43 [homata]

homata has joined #CSS

00:26:41 [Bert]

[Discussion about what is best way to deal with minor editorial issues. At this point, just rejecting it is best, no risk of errors.]

00:26:56 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-263

00:27:13 [Bert]

Topic: Issue 263

00:27:52 [Bert]

SZ: Maybe we can make a boilerplate text for all these editorial rejected issues.

00:28:09 [Bert]

... For when we reply to the submitter of the issue.

00:29:13 [Bert]

PL: Seems same case again: Edit is nice to have, but not needed now.

00:29:22 [Bert]

RESOLVED: no change for issue 263

00:29:29 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-264

00:29:36 [Bert]

Topic: Issue 264

00:30:11 [Bert]

DB: We discussed zero-height floats already today.

00:31:00 [Bert]

JJ: Did the earlier discussion affect this issue?

00:31:20 [Bert]

DB: No. The note in the issue is wrong.

00:32:44 [Bert]

RESOLVED: accept change proposed in the issue e-mail for issue 264.

00:32:56 [Bert]

Topic: Issue 265

00:33:14 [Bert]

RESOLVED: No change issue 265

00:33:22 [Bert]

Topic: Issue 266

00:34:06 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-266

00:35:15 [Bert]

EE: I think we should make the suggested edits, they fix what we missied in the previous round for issue 120.

00:35:26 [Bert]

JJ: And the ones you were not sure about?

00:35:44 [Bert]

... Issue 3 in the linked e-mail.

00:36:31 [Bert]

[it's about whether table-caption is block-level]

00:36:47 [Bert]

AE: Doesn't seem to hurt anything to make it block-level.

00:38:45 [Bert]

EE: If we don't fix it, we'll have to do it in errata anyway.

00:39:20 [Bert]

[Discussion about how 'overflow' might apply if flex box is added to CSS]

00:39:57 [Bert]

JJ: So take all of them, except issue 6.

00:40:26 [Bert]

s/all of/none of/

00:41:53 [Bert]

EE: What does Bert think?

00:41:58 [Bert]

BB: I don't know yet.

00:42:40 [Bert]

RESOLVED: Accept issue 6, defer the others to the errata.

00:43:00 [Bert]

[Above is for issue 266]

00:43:08 [Bert]

Topic: Issue 267

00:43:10 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-267

00:43:34 [Bert]

DB: It marches impls that I tested.

00:43:45 [Bert]

s/marches/matches/

00:44:16 [Bert]

s/It/The proposed edit/

00:44:45 [sgalineau]

sgalineau has joined #css

00:44:48 [dbaron]

test is http://dbaron.org/css/test/2011/css21-issue-267

00:45:00 [dbaron]

(question is which is on top)

00:45:26 [dbaron]

actually, it doesn't test the issue

00:45:35 [Bert]

DB: I think it is editorial.

00:45:57 [dbaron]

actually, hold on

00:49:12 [bradk]

268 and 269 should be http://lists.w3.org/Archives/Public/www-style/2011Jan/0087.html right?

00:49:21 [Bert]

DB: Two browsers do one thing, two do the other.

00:49:46 [Bert]

... The proposal matches Opera nd Webkit.

00:49:52 [Bert]

s/nd/and/

00:50:20 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-268

00:50:22 [Bert]

RESOLVED: Accept propsoed edit for issue 267.

00:50:32 [Bert]

Topic: Issue 268

00:52:02 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-203

00:52:15 [johnjan]

http://lists.w3.org/Archives/Public/www-style/2010Sep/0665.html

00:52:15 [Bert]

Topic: Issue 203 (again)

00:52:42 [Bert]

JJ: Anton Prowse disagrees with our resolution.

00:54:17 [Bert]

-> http://lists.w3.org/Archives/Public/www-style/2010Sep/0665.html Anton's message

00:58:50 [Bert]

DB: The reason for the hypothetical top border is so as not to move the element unnecessarily.

00:59:05 [Bert]

AE: Test cases are all interoperable.

00:59:57 [Bert]

... See margin-collapse-05

01:01:14 [Bert]

EE: Difficult to keep track of which clearance issues are the same issue.

01:01:52 [Arron]

s/margin-collapse-05/margin-collapse-clear-005

01:02:17 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-268

01:03:46 [fantasai]

http://lists.w3.org/Archives/Public/www-style/2011Jan/0644.html

01:03:50 [fantasai]

resolved in that meeting

01:04:32 [Bert]

RESOLVED: 203 was already discussed and we allowed two behaviors. (See issues list)

01:04:48 [dbaron]

s/move the element/move the element up/

01:04:52 [Bert]

Topic: Issue 268

01:05:09 [dbaron]

(I'm having trouble working out a testcase for why the hypothetical border edge is useful, though.)

01:05:30 [Bert]

EE: I thibnk the spec is correct.

01:06:19 [alexmog]

alexmog has joined #css

01:06:43 [dbaron]

Though actually, maybe I'm misremembering the purpose.

01:06:51 [dbaron]

Maybe it's to prevent contradictions.

01:07:22 [Bert]

s/thibnk/think/

01:07:22 [tantek]

tantek has joined #css

01:08:45 [Bert]

[People trying to find out what the issue is]

01:09:20 [Bert]

AE: Quite a few test cases for this.

01:11:06 [johnjan]

actual issue: http://lists.w3.org/Archives/Public/www-style/2011Jan/0085.html

01:12:12 [Bert]

[Mumble mumble]

01:12:36 [Bert]

RESOLVED: No change for issue 268

01:13:54 [Bert]

[DB and EE discuss some case]

01:15:05 [Bert]

EE: All impls seem to agree on what the first formatted line is.

01:15:11 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-269

01:15:15 [Bert]

Topic: Issue 169

01:15:21 [Bert]

s/169/269/

01:16:44 [arno]

arno has joined #css

01:17:06 [Bert]

EE: propose to change to edges of line box, instead of block.

01:17:53 [Bert]

RESOLVED: Use line box edges instea dof block edges in issue 269

01:18:03 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-270

01:18:04 [Bert]

Topic: Issue 270

01:18:59 [Bert]

EE: I can propose a text.

01:19:30 [Bert]

DB: I might have some issues. I started implementing this.

01:19:50 [arno1]

arno1 has joined #css

01:20:02 [Bert]

RESOLVED: No change for issue 270. Do something in level 3.

01:20:09 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-271

01:20:12 [Bert]

Topic: Issue 271

01:22:08 [Bert]

AE: I think the colon in the spec was intended to mean "e.g."

01:22:52 [Bert]

[Discussion about what issues to discuss. Skip all editorial?]

01:22:55 [fantasai]

http://lists.w3.org/Archives/Public/www-style/2010Dec/0312.html

01:23:02 [fantasai]

Anton's list of substantive issues ^

01:24:25 [dbaron]

DB: Turn the email into a wiki page so we can start dealing with it

01:25:10 [fantasai]

http://wiki.csswg.org/spec/css2.1/anton-lc-2010

01:25:57 [Bert]

PL: What can we discuss now?

01:26:33 [Bert]

... How dow we go through Anton's list?

01:26:44 [Bert]

AE: I have made comments on many of the issues.

01:27:36 [Bert]

... Most of them I found need no change.

01:28:26 [johnjan]

so Arron and Elika will get Anton's email into actionable issues

01:28:30 [Bert]

Topic: Test failures

01:28:34 [johnjan]

discuss on wednesday.

01:29:35 [Bert]

PL: Background-fixed 4 and 5 were expecting a fix in Gecko.

01:29:48 [Bert]

DB: Give me 5 seconds...

01:30:51 [Bert]

SF: Last week we suggested to leave it undefined.

01:31:30 [Bert]

PL: I agree with undefined. Unless we have a proposal for a spec chnage.

01:31:40 [Bert]

DB: Gecko might take a month to fix.

01:32:26 [Bert]

EE: bg-pos may apply to image with no intrinsic size.

01:33:00 [Bert]

AE: Is it not already undefined?

01:33:15 [Bert]

DB: Might want to make it explicit, and say there is another spec that defines it.

01:33:56 [fantasai]

The background position of background images with an intrinsic ratio and no intrinsic size is undefined in CSS2.1, see CSS3 Backgrounds and Borders.

01:34:34 [Bert]

RESOLVED: Change bg-pos of images as fantasai just wrote.

01:34:58 [Bert]

DB: So the test still needs fixing?

01:35:19 [Bert]

Topic: test bidi-breaking-2

01:36:02 [dbaron]

EE: should be a may

01:37:15 [dbaron]

http://test.csswg.org/suites/css2.1/latest/xhtml1/block-in-inline-relpos-002.xht

01:37:38 [Bert]

Topic: block-in-inline-relpos-002

01:38:53 [Bert]

PL: What do we do with this one?

01:40:00 [Bert]

[DB trying to find out why various browsers fail.]

01:40:27 [fantasai]

arronei: http://test.csswg.org/source/contributors/fantasai/submitted/css2.1/bidi-breaking-002.xht

01:40:41 [Bert]

DB: Related to what we discussed earlier, about relative pos. affecting nested block elements.

01:41:21 [Bert]

... Four browsers that all do different things.

01:41:32 [myakura]

myakura has joined #css

01:42:55 [Bert]

[DB and PL notice that two versions on diff. platforms of Opera do different things, too.]

01:43:01 [fantasai]

bidi-breaking-002 should work now; removed the HTML <br> bit of the test (since that's up in the air anyway)

01:44:06 [Bert]

[People looking over other people's shoulders to see what various browsers do on different platforms...]

01:44:47 [Bert]

DB: Somebody should take an action to figure out what to do. And not me.

01:44:53 [Bert]

AE: I can do it.

01:45:41 [Bert]

ACTION Arron: propose a solution for block-in-inline-relpos-002

01:45:41 [trackbot]

Created ACTION-311 - Propose a solution for block-in-inline-relpos-002 [on Arron Eicholz - due 2011-03-15].

01:49:51 [howcome]

content-computed-value-001

01:50:33 [Bert]

Topic: content-computed-value-001

01:50:41 [Bert]

RESOLVED: Remove the test

01:51:30 [stearns]

stearns has left #css

01:52:42 [Bert]

Topic: replaced-intrinsic-ration-001

01:52:44 [smfr]

we're going through the blocking tests on http://wiki.csswg.org/test/css2.1/blocking

01:52:48 [Bert]

s/ration/ratio/

01:53:09 [dbaron]

DB: Close to a patch for Gecko, just need to fix a few more existing tests.

01:54:18 [Bert]

PL: It seems to be testing multiple things.

01:54:23 [Bert]

EE: [something]

01:54:39 [Bert]

PL: Are you going to define behavior?

01:54:49 [Bert]

EE: I might want to fix this.

01:55:16 [Bert]

... I will propose text.

01:55:49 [Bert]

... For the spec.

01:56:15 [Bert]

HL: Is this an SVG issue?

01:57:36 [fantasai]

EE: Yes, affects all SVG that doesn't have a fixed size (i.e. scalable SVG)

01:57:47 [Bert]

RESOLVED: Change the spec in some way.

01:57:50 [fantasai]

EE: Proposal is to make sizing of replaced elements with intrinsic ratio but no size undefined.

02:00:28 [Bert]

RESOLVED: ... and put the current rule in level 3 instead.

02:00:42 [Bert]

BB: It was put in on request from SVG wasn't it?

02:01:00 [Bert]

Topic: uri-016

02:01:51 [johnjan]

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/uri-016.htm

02:01:53 [fantasai]

no, it was put in a long time ago because it was it wasn't defined

02:02:00 [fantasai]

the test is failing because UAs misinterpreted SVG

02:03:39 [kennyluck]

kennyluck has joined #CSS

02:03:59 [Bert]

PL: We don't have the exit criteria from other CSS modules in the CSS 2.1 spec,

02:04:21 [Bert]

... Difference is about experimental builds.

02:04:33 [Bert]

... Didn't we resolve to fix that already?

02:05:13 [fantasai]

http://wiki.csswg.org/spec/css2.1#issue-272

02:05:45 [Bert]

RESOLVED: Update CSS 2.1 exit criteria to the current (CSS3 standard) exit criteria, minus the 30-day implementation requirement.

02:07:11 [Bert]

[End of meeting for today]

02:10:39 [Bert]

rrsagent, draft minutes

02:10:39 [RRSAgent]

I have made the request to generate http://www.w3.org/2011/03/08-css-minutes.html Bert

02:10:49 [Bert]

rrsagent, make logs public

02:13:16 [Bert]

Hmm, forgot to tell rrsagent that the meeting spanned midnight. :-(

02:55:06 [miketaylr]

miketaylr has joined #css

03:22:29 [bradk]

bradk has joined #css

03:34:49 [bradk]

bradk has joined #css

03:54:37 [Xaxio]

Xaxio has joined #css

04:55:56 [tantek]

tantek has joined #css

05:00:23 [fantasai2]

fantasai2 has joined #css

05:04:50 [homata]

homata has joined #CSS

06:01:15 [dsinger]

dsinger has joined #css

06:07:12 [jdaggett]

jdaggett has joined #css

06:19:52 [Arron]

Arron has joined #css

06:21:21 [sylvaing]

sylvaing has joined #css

06:39:18 [plinss_]

plinss_ has joined #css

06:41:39 [anne]

anne has joined #css

06:44:59 [dbaron]

dbaron has joined #css

06:48:39 [arno]

arno has joined #css

07:04:24 [homata__]

homata__ has joined #CSS

07:04:27 [TabAtkins_]

TabAtkins_ has joined #css

07:20:16 [arno1]

arno1 has joined #css

07:33:07 [plinss_]

plinss_ has joined #css

07:38:06 [Martijnc]

Martijnc has joined #css

07:58:39 [homata]

homata has joined #CSS

08:07:55 [plinss_]

plinss_ has joined #css

08:38:23 [homata__]

homata__ has joined #CSS

09:45:55 [plinss_]

plinss_ has joined #css

09:46:07 [Ms2ger]

Ms2ger has joined #css

09:52:22 [lhnz]

lhnz has joined #css

10:27:50 [plinss_]

plinss_ has joined #css

10:47:45 [homata]

homata has joined #CSS

10:47:50 [plinss_]

plinss_ has joined #css

11:03:15 [arronei]

arronei has joined #CSS

11:20:43 [Martijnc]

Martijnc has joined #css

16:55:23 [RRSAgent]

RRSAgent has joined #css

16:55:23 [RRSAgent]

logging to http://www.w3.org/2011/03/08-css-irc

16:55:31 [plinss_]

invite zakim, #css

16:56:19 [Zakim]

Zakim has joined #css

16:57:56 [stearns]

stearns has joined #css

17:00:45 [sylvaing]

sylvaing has joined #css

17:02:07 [TabAtkins_]

TabAtkins_ has joined #css

17:02:33 [glazou]

glazou has joined #css

17:02:55 [mihara]

mihara has joined #css

17:03:08 [shan]

shan has joined #css

17:03:13 [johnjan]

johnjan has joined #css

17:03:29 [fantasai]

ScribeNick: fantasai

17:03:54 [Arron]

Arron has joined #css

17:03:58 [fantasai]

Topic: Agenda

17:04:28 [fantasai]

Steve: Request toput tokyo workshop dates today

17:04:37 [fantasai]

?: multicol today

17:04:54 [Arron]

Arron has joined #css

17:05:24 [fantasai]

glazou: module template tomorrow

17:05:39 [dbaron]

dbaron has joined #css

17:05:43 [fantasai]

glazou: pull tokyo dates and multicol for today, keep rest for tomorrow

17:05:53 [fantasai]

glazou: Start with Adobe's proposal

17:06:02 [fantasai]

Topic: Adobe's Template Proposal

17:06:22 [plinss_]

s/Template/Regions/

17:06:51 [howcome]

howcome has joined #css

17:07:22 [smfr]

smfr has joined #css

17:07:30 [fantasai]

Arno: I'd like tot talk to you a little bit about things we work on we're calling CSS "Regions"

17:07:45 [fantasai]

arno: Would like your feedback on whether it's interesting, going in an interesting direction, etc.

17:07:58 [bradk]

bradk has joined #css

17:08:04 [fantasai]

arno: It started by us talking to our customers, especially print customers using InDesign t do fancy layouts

17:08:11 [fantasai]

arno: e.g. Conde Nast

17:08:24 [fantasai]

arno: They want to bring the experience ppl have on paper into digital media

17:08:34 [Kazutaka]

Kazutaka has joined #CSS

17:08:40 [fantasai]

arno: We started experimenting, and some of those magazines are already available on the iPad

17:08:51 [fantasai]

arno: We very quickly ran into some limitations

17:09:01 [fantasai]

arno: e.g. Wired has very complex layouts

17:09:09 [fantasai]

arno: We tried using various technologies to represent those layouts

17:09:29 [fantasai]

arno: But in this version we had to use images to represent each page

17:09:47 [fantasai]

arno: It's a lot of work, since the designers have to do layouts twice once for layout and portrait

17:09:56 [fantasai]

arno: With different device aspect ratios, it's even more work

17:10:01 [fantasai]

arno: Not a good solution

17:10:21 [fantasai]

arno: Not the case for everyone -- some customers have very simple layouts, close to templates, can use HTML to represent their ocntent

17:10:27 [fantasai]

arno: which has lots of benefits

17:10:41 [fantasai]

arno: We want to find the way to bridge the gap between HTML layouts you can do today, and what you can do on paper

17:10:52 [fantasai]

arno: You have very sophisticated layout of text, interaction of graphics and text

17:11:08 [fantasai]

arno shows pages with text flowing around contoured images, fitted to shaped regions

17:11:28 [fantasai]

arno: We want to be able to find ways to represent these sophisticated layouts in HTML and CSS

17:11:38 [fantasai]

arno: We studied these and came up with a proposal tha we think solves the problems.

17:11:54 [fantasai]

arno: We wanted to make sure what we were thinking about was implementable

17:12:09 [fantasai]

arno: So we started investigating implementing it

17:12:29 [fantasai]

arno: BTw, another use case is of course printing, which would benefit from sophisticated layouts

17:12:35 [fantasai]

arno: We started experimenting with WebKit

17:12:47 [fantasai]

arno: I'm going to show you some screenshots of some things, and then also live demos

17:12:56 [fantasai]

arno: Starting with very simple and basic things, it's columns

17:13:02 [fantasai]

arno shows a 3-col layout

17:13:10 [fantasai]

arno: You can do this with multicol

17:13:22 [fantasai]

arno: You have some fairly simple markup -- three divs and a heading

17:13:34 [fantasai]

divs are labeled region1 through 3

17:14:21 [fantasai]

prior to that there's another div called article-content, which includes a heading and then the flow content (paragraphs)

17:14:43 [fantasai]

the regions are styled to be boxes floating side by side

17:15:03 [fantasai]

article-content is assigned a flow-thread: main;

17:15:28 [fantasai]

the region3 divs are assigned display: region; region-thread: main;

17:16:03 [fantasai]

howcome: Those region elements are only there to give the layout

17:16:18 [fantasai]

Simon: What happens to the content of the region elements?

17:16:25 [mollydotcom]

mollydotcom has joined #css

17:16:46 [fantasai]

jdaggett: It would be better to not put the layout structure as markup in the document.

17:17:01 [fantasai]

arno: Next example, we add an image sitting on top of the two first columns

17:17:21 [fantasai]

arno: You adjust the two columns to shorten them, and then place the image

17:17:37 [fantasai]

glazou: You cannot make content flow from one region to another, right?

17:17:43 [fantasai]

arno: correct

17:18:02 [fantasai]

jdaggett: I'm wondering if you looked at some of the other proposals..

17:18:29 [fantasai]

plinss: This is not the interesting case. This is a very basic case.

17:18:33 [TabAtkins_]

TabAtkins_ has joined #css

17:18:43 [fantasai]

jdaggett: But I think this is added semantics on top of one of the other layout approaches

17:19:03 [fantasai]

arno: One of the things you can do is to specify the order in which content flows

17:19:28 [fantasai]

arno: you do this by specifying region-index: <integer> on the region elements

17:19:43 [fantasai]

arno: Since the divs are just divs, you can also do more sophisticated things like applying transforms.

17:19:55 [fantasai]

arno: Another thing we've been talking about are exclusions

17:20:05 [fantasai]

arno: Which is saying "I want the text to avoid these areas"

17:20:14 [fantasai]

arno: So you can have images that encroach on the text

17:21:04 [fantasai]

arno: Our proposal is to use an exclusion-shape property that takes coordinates which you apply to an element, and then assign exclusions: "#idofelement" to the flow content

17:21:17 [dbaron]

...could also use alpha area of image

17:21:27 [fantasai]

jdaggett: SVG path or mask would make more sense

17:21:38 [fantasai]

http://www.w3.org/blog/CSS/2007/07/03/rotations_and_non_rectangular_floats

17:22:13 [dbaron]

fantasai: There was a proposal from Bert for doing this by adding a single keyword to float.

17:22:47 [dbaron]

arno: also want to specify geometric shapes even if there's no image

17:22:51 [fantasai]

arno: You also want to do this for e.g. a circular pull-quote

17:23:27 [Bert]

(For the old, 1996(!) idea for flow around non-rectangular images: see 'contour' in https://www.w3.org/Style/Group/css3-src/css3-box/Overview.html#the-float-property)

17:23:34 [Bert]

(For an idea for non-rectangular/connected regions: https://www.w3.org/Style/Group/css3-src/css3-layout/Overview.html#chaining-slots-the-chains-property)

17:24:42 [dbaron]

[discussion of margin around the alpha shape]

17:24:50 [Bert]

(The "margin" around non-rect images in the contour idea is given by areas that are almost transparent, say 99%)

17:24:58 [howcome]

http://www.w3.org/TR/WD-layout

17:25:06 [fantasai]

arno: we just started with the coordinates since that was simple to implement and could do everything

17:25:34 [fantasai]

discussion of float intrusions that break a line in half

17:26:14 [fantasai]

plinss: We have a convention, starting with clip property, of using functional notation with shape e.g. rect(...)

17:26:20 [fantasai]

plinss: That would let you have different shapes

17:26:24 [fantasai]

plinss: more easily

17:26:44 [fantasai]

plinss: The other thing is you have a property linking from one to the other

17:26:55 [fantasai]

plinss: to define the exclusion

17:27:17 [fantasai]

plinss: What is the coordinates relative to?

17:27:44 [fantasai]

alex: What defines the tightwrap, content wnats to tightwrap, or shape wants everything to wrap around it?

17:27:57 [fantasai]

alex: In CSS1, it was float requesting wrapping

17:28:42 [fantasai]

alex: So you could have a boolean, wrap around stuff, or don't wrap around stuff.

17:29:42 [fantasai]

alex: if you want to control, e.g. this bfc doesn't avoid floats, or this non-bfc avoids floats

17:29:48 [fantasai]

discussion of bfcs

17:30:01 [fantasai]

Steve: Think of the part that intrudes as being part of the bfc

17:30:37 [fantasai]

dbaron: Well, if we have a BFC due to scrolling, you don't want any floating content intruding into that content and forcing relayout on scroll

17:30:39 [hyatt]

hyatt has joined #css

17:31:01 [fantasai]

alex: But that's a special case. overflow: hidden; it's totally reasonable to wrap around

17:31:19 [fantasai]

arno show s an example of columned text flowing around the coyote

17:31:34 [fantasai]

arno shows a page layout that uses this as a component

17:32:29 [fantasai]

arno pulls up a live demon

17:32:53 [fantasai]

arno: Here's the example with columns that have been transformed to be crooked

17:33:09 [fantasai]

arno edits the contenteditable content: the content flows from one column to the other

17:33:32 [fantasai]

plinss: What about property inheritance?

17:33:51 [fantasai]

plinss: Does content flowing into a region inherit from the region or its element tree parent?

17:34:28 [fantasai]

Steve: There is a desire to allow inheritance from regions (in its equivalent model)

17:34:41 [fantasai]

Steve: We have a special function, like inherit-from-region, that does that

17:34:53 [fantasai]

Steve: What's there doesn't quite match CSS's model

17:35:00 [fantasai]

plinss: I looked at that and couldn't figure out how it works

17:35:57 [fantasai]

Steve: This would be similar to the way ::first-line works

17:36:22 [fantasai]

fantasai: If you're doing inheritable properties, you'll probably want selectors too. So you can change not just the color of the text overall, but e.g. links inside the region

17:36:33 [fantasai]

fantasai: If you go down this route, people will want to go in that direction

17:37:00 [fantasai]

...

17:37:08 [fantasai]

howcome: Have you shipped content with this?

17:37:12 [fantasai]

arno: No, just experimental

17:38:02 [fantasai]

howcome asks about resizing and reflow

17:38:25 [fantasai]

howcome: With multicol, you'd add a third column as the page gets wider

17:38:50 [fantasai]

howcome: what would you do here? is it tied only to two columns?

17:39:13 [fantasai]

Steve: This is with fixed regions, each explicitly specified.

17:39:25 [fantasai]

Steve: It needs to be adapted to work with multicol, flexbox, grid layout, etc.

17:39:30 [fantasai]

Steve: The key concept is the threads

17:39:37 [fantasai]

Steve: and the concept of exclusions

17:39:39 [mollydotcom]

mollydotcom has left #css

17:40:05 [fantasai]

jdaggett: So what you're saying is not the syntax that's important, but those two concepts that are important.

17:40:20 [fantasai]

Steve: Yes. There's still some work to do to make this fit into CSS well

17:40:51 [fantasai]

plinss: Another issue is that you're using 'display' to make something a region. You should use something else, so that we can control display of the regions

17:41:24 [dbaron]

maybe the 'content' property would work?

17:41:48 [dbaron]

e.g., content: flow(main), or content: flow(main, 2) to give indices

17:41:59 [fantasai]

plinss: In most cases, you want to use the other layout systems you have, and just have content flow differently through it

17:42:18 [fantasai]

Phil: What happens if you run out of content?

17:42:29 [fantasai]

(or too much)

17:42:36 [fantasai]

arno: It's a good question.

17:43:33 [fantasai]

fantasai: The other thing is that the regions shouldn't be empty elements in the document, they should be separate. SO you odn't have to build the layout into the document content

17:44:01 [fantasai]

Bert: César and I worked on some of this flow threading with his studies on the Template module

17:44:14 [hyatt]

extend the slot concept from css3 template layout to allow for the specification of positioned slots

17:44:30 [fantasai]

Bert: One thing that became clear was that you need a baseline grid, so that the lines are consistently placed

17:45:02 [dbaron]

...so that if you have two regions above each other (with different horizontal positions), you don't have a gap due to having half a line at the bottom of the first

17:45:21 [stearns]

need a baseline grid for content today (even if it's not all part of the same flow)

17:45:29 [fantasai]

Bert: Other comment, when you were moving the image in the demo, you have some cases where the content shows up in holes in the image. In howcome's proposal, the content always had to be on the outside

17:45:48 [fantasai]

Bert: So you wouldn't split the content into two columns

17:48:02 [fantasai]

glazou: You want to be able to flow text inside, e.g. a bowl

17:48:07 [fantasai]

fantasai: You're talking about two different things.

17:48:56 [fantasai]

glazou clarifies by drawing a picture

17:49:06 [fantasai]

11|222|33

17:49:13 [jdaggett]

jdaggett has joined #css

17:49:17 [fantasai]

44\555/66

17:49:33 [fantasai]

77---88

17:49:49 [fantasai]

arno's example doesn't actually allow a line to be split by the float

17:50:10 [fantasai]

but it does allow the image to define the contour on both the left and right side of the line, if it's bowl-shaped

17:50:21 [Bert]

(Example XXII in https://www.w3.org/Style/Group/css3-src/css3-layout/Overview.html#chaining-slots-the-chains-property defines a reading order over partly side-by-side regions)

17:50:23 [fantasai]

glazou's example intrudes into the text splitting the line into multiple pieces

17:50:46 [fantasai]

howcome: So what happens today if you have too much content for the regions?

17:50:49 [fantasai]

arno: It will not display

17:51:05 [fantasai]

smfr: What if you put overflow: scroll on the last region?

17:51:31 [fantasai]

Tab: Could think of this as a kind of overflow mode

17:51:44 [hyatt]

css3 template layout defines a grid of anonymous slots. you could imagine also allowing it to define anonymous positioned slots (that other content could then flow around/avoid)

17:51:46 [fantasai]

Tab: Would clarify what overflow: scroll means on the first region -- nothing

17:53:00 [dbaron]

peterl: (responding to hyatt's first comment) I'd actually like to see the other way - this replacing template's slot concept.

17:53:07 [TabAtkins_]

>

17:53:19 [hyatt]

div { positioned-slots: sidebar, masthead, body; } ::slot(sidebar) { position: absolute; left:100px; top:100px; box-shape: <some path>; }

17:53:54 [fantasai]

howcome: We need to make sure this wokrs in a reusable way for longer articles, for printing

17:54:04 [hyatt]

css3 template layout supports per-page templates too

17:54:06 [fantasai]

Bert talks about his attempt to extend slots concept in template-layout

17:54:11 [dbaron]

peterl: I'd like to be able to define regions in an @page rule.

17:55:05 [Bert]

(Extend in the sense of automatic repeating the same layout template if there is more room, without need for media queries.)

17:55:41 [alexmog]

alexmog has joined #css

17:56:00 [hyatt]

i would try to separate out all the concepts here. there is (1) content flowing across linked regions, (2) the ability to define an irregular external shape that content flows around, (3) the ability do specify an irregular shape that content inside fits to, and (4) the definition of placed regions themselves that content can flow around

17:56:22 [fantasai]

glazou: Do you want to standardize this in CSSWG?

17:56:46 [fantasai]

arno: If you're interested in this, yes.

17:57:09 [fantasai]

jdaggett: Before we get to the stage of these guys spending time putting together a proposal

17:57:38 [fantasai]

jdaggett: I think it would make more sense for your group to start by reviewing the modules we already have, and see what you would need to /change/ to make them work for you

17:57:52 [fantasai]

jdaggett: The cases you're trying to solve are valid, but the syntax you're doing is grotty

17:58:00 [shonda]

shonda has joined #css

17:58:08 [fantasai]

smfr: I agree, we should avoid adding another module and try to work this into e.g. Template Layout

17:58:44 [stearns]

linked regions might make sense in Template, but would exclusions?

17:59:18 [fantasai]

howcome: We can't keep adding more and more advanced layout systems. We should try to merge them

17:59:48 [tantek]

tantek has joined #css

17:59:55 [fantasai]

Steve: There are several key concepts here. One is the threading concept, which would fit well in many of our layout specs

17:59:57 [hyatt]

the concept of content flowing around a positioned shape and/or of irregular shapes is just new properties for positioned or floating elements (depending on what approach you decide to take)

18:00:24 [fantasai]

Steve: The other key piece is the exclusion piece, which is separate but also important

18:00:26 [hyatt]

the concept of flow across containers should IMO be limited to anonymous models (multicol, template layout)

18:01:06 [fantasai]

dbaron: We could use 'content' property to assign content to a flow, e.g. with a flow() function

18:01:10 [hyatt]

i think just using positioned elements as the way to flow around content instead of floats, and then use positioned element z-index rules to say whether you avoid or not might work fine

18:01:18 [fantasai]

Steve: That's a pull model, this is a push model.

18:01:19 [hyatt]

e.g,. establish a stacking context, then your internal stuff doesn't propagate out

18:01:23 [hyatt]

auto z-inxex it does, etc.

18:01:31 [fantasai]

Steve: The third approach is to define a mapping between the twol.

18:01:42 [fantasai]

Steve: Those are 3 different ways of looking at the problem.

18:01:48 [fantasai]

Steve: Layout and grid are using a push model.

18:01:53 [fantasai]

Steve: I agree you could use a pull model as well

18:02:02 [fantasai]

Bert: There's a pull model in the cross-references in GCPM

18:02:19 [fantasai]

q+

18:02:49 [fantasai]

Bert explains hyatt's comment above

18:03:15 [fantasai]

Bert: wrt #3, I was wondering if that should be extended to also make the text exactly fit a certain shape by e.g. making it smaller or larger

18:05:21 [fantasai]

Steve: That was in the proposal, too, arno just didn't mention it

18:05:32 [fantasai]

Tab likes hyatt's comments

18:05:45 [fantasai]

and strongly agrees with using anonymous boxes instead of real elements to define the regions

18:06:36 [fantasai]

Steve: Classic example of pushing content into an external region that only shows up when needed is footnotes.

18:06:48 [fantasai]

Tab: You can tell the region to only exist if it has content inside of it.

18:07:13 [fantasai]

glazou: Another way of specifying exclusions, used many years ago, is like background image

18:07:32 [fantasai]

glazou: You position the image and it defines an exclusion

18:07:58 [fantasai]

Tab says something that I didn't quite follow....

18:08:03 [hyatt]

@page { positioned-slots: header, sidebar, body(col1, col2) ::slot(col1) { ... } ::slot(col2) { ... } } You could imagine the "chains" linking being done without a property, e.g., in the specification of the template itself... see body(col1, col2) example

18:08:27 [fantasai]

...

18:08:48 [fantasai]

Steve: In a gridlike or template-like layout you'd like to position to cell boundaries in that model, which doesn't quite fit into the bgpos model.

18:09:24 [fantasai]

glazou: Desktop publishing software can do that. What is the best option in terms of you for CSS to be able to translate those layouts into CSS layouts and vice versa?

18:09:56 [fantasai]

glazou: If we run into that, people are going to base layouts in CSS, so it needs to be compatible with desktop software

18:10:04 [fantasai]

Steve: FYI, glazou writs an editor

18:10:11 [fantasai]

glazou: Need to allow round-tripping

18:10:29 [fantasai]

arno: For us the key thing is to have the expressiveness. We are willing to take the cost on the tooling side.

18:10:40 [fantasai]

arno: round-tripping is a good point to bring up, though

18:10:57 [TabAtkins_]

Tab: The only problem with defining exclusions purely on the content element is that it may then be difficult to position content that should sit in those exclusions (like a callout) in an appropriate manner. But Positioned Layout, which I'll work on later this year, should be able to solve this - you can abspos an element relative to the content element, and specify the exclusion and callout using nearly identical rules as a bg-position and as top/right

18:11:38 [fantasai]

arno: want for an author to be able to us the tools, but more importantly the concepts they are used to

18:12:24 [glazou]

all applause Arno's pres and demo

18:12:52 [arno]

arno has joined #css

18:30:57 [arno1]

arno1 has joined #css

18:31:54 [mihara]

mihara has joined #css

18:33:14 [fantasai]

alex: What we have here in this version of the spec, it tries to roll into it all the feedback we've had so far

18:33:18 [fantasai]

if somalex: If something is thatere, doesn't necessarily mean we have the final overall picture

18:33:27 [fantasai]

alex: We're trying to be inclusive here, we wanted to produce a version of how it might work with the feedback

18:33:31 [smfr]

which spec? can we have a link?

18:33:47 [fantasai]

alex: We're getting to the shape where we can think about how it integrates with other specs, e.g. merge with Template Layout

18:33:57 [fantasai]

alexmog: If there something we didn't get here, doesn't make sense to have there, let's discuss

18:34:30 [fantasai]

Markus: Our main goal was to address the feedback from the last F2F, align with Template Layout, figure out integration

18:34:37 [fantasai]

Markus: Also think more about print layout and lines

18:35:26 [arno1]

Thanks everyone for the great feedback!

18:36:14 [smfr]

http://dev.w3.org/csswg/css3-grid-align/

18:36:17 [fantasai]

Phil: Hi, my name is Phil and I'm from Microsoft, and I'm one of th editors on the CSS Grid specification

18:36:41 [fantasai]

Phil: Recap of feedback was to think in lines, not just thinking in rows and columns

18:36:58 [fantasai]

Phil: also think about naming lines to simplify maintenance so you don't have to renumber when you change things

18:37:05 [fantasai]

Phil: We also thought about naming regions of space.

18:37:20 [fantasai]

Phil: Template Layout does this, so we looked into incorporating that idea

18:37:37 [fantasai]

Phil: Also thought about ::slot() pseudo and putting multiple elements into a slot

18:37:51 [fantasai]

Phil: ... a default slot

18:38:03 [fantasai]

Phil: I'll start by just walking through this and summarizing.

18:38:19 [fantasai]

Phil: Grid is not a table. Can do things tables can't do, e.g. hav cells overlap

18:38:41 [fantasai]

Phil: It's similar positioning in that regard; can be considered an alternate grid system for positioning

18:39:37 [fantasai]

Phil: We think people will use grid to do page layouts, form layouts, etc.

18:39:47 [fantasai]

Phil: We want layouts to be able to adapt to available space

18:39:54 [fantasai]

Phil: So we have some concepts

18:40:01 [fantasai]

Phil: auto sizing to the size of the content

18:40:05 [fantasai]

Phil: min/max functions

18:40:16 [fantasai]

Phil: fractional units, allocating remaining space

18:40:34 [fantasai]

Phil: You declare a grid by setting its display to grid

18:40:42 [fantasai]

Phil shows Example 1

18:41:11 [fantasai]

Phil: Declare a grid with "display: grid", set grid columns and rows

18:41:32 [fantasai]

position to grid

18:41:48 [fantasai]

Phil moves to next section

18:42:12 [fantasai]

Phil shows template layout in grid

18:42:39 [fantasai]

Phil: assign into template regions with 'grid-cell' property

18:42:45 [fantasai]

Phil: We're not using the position property here

18:42:59 [fantasai]

Phil shows slider control example

18:43:32 [fantasai]

Phil: In this example we're using an alternative syntax that names the grid lines

18:43:57 [fantasai]

Phil: To name a grid line, you just specify a string before the measurement

18:44:54 [fantasai]

Phil: You can assign starting and ending lines to an element to position it in the grid

18:45:03 [fantasai]

Phil: There are tracks, lines, and cells in the grid model

18:45:13 [fantasai]

Phil: Tracks are the columns and rows of the grids

18:45:46 [fantasai]

Phil: grid-columns: 150px 1fr; creates two columns, a 150px column and a remaining space column

18:45:54 [fantasai]

Phil: This gives us 3 lines

18:46:49 [fantasai]

Phil: In old spec you would define cells implicitly by giving a span property, and then could align content within that cell (which could span multiple row-col intersections)

18:46:57 [fantasai]

Phil: in new spec you can define those cells explicitly

18:47:28 [fantasai]

...

18:47:32 [fantasai]

Phil: grid-cell speudo

18:47:50 [fantasai]

Phil: In template module you would define of the grid-cell with the template string

18:48:00 [bradk]

bradk has joined #css

18:48:06 [fantasai]

Phil: Here you can create a grid-cell [somehow]

18:48:53 [fantasai]

Phil: by using the grid-cell pseudo element, and giving it positions

18:49:10 [fantasai]

Phil: e.g. #grid::grid-cell("cell") { grid-column: .. ; grid-row: ...; }

18:50:03 [fantasai]

Phil: This creates a named cell, that you can then assign into just like you can assing into template-created named cells

18:50:58 [fantasai]

dbaron: maybe split this example using markup instead of a comment, it's not clear they are two different approaches to the same thing

18:51:38 [fantasai]

Steve: So you wanted to create a cell on the grid-line strucutre using pseudo-element

18:52:01 [fantasai]

sylvaing: That's similar to what hyatt proposed earlier, with the ::slot() syntax creating a flow target

18:52:49 [fantasai]

Brad: Can you assign other properties to a grid cell?

18:52:55 [fantasai]

Phil: Some, but mostly positioning stuff

18:53:28 [fantasai]

Tab: If you have a slot created by the template property, can you reposition it using grid-rows and grid-columns?

18:53:34 [fantasai]

Tab: I would prefer "no" :)

18:54:19 [fantasai]

Tab: I would not want a designer to be confused about their slot moving around because a later definition moved it

18:54:52 [fantasai]

plinss: I would prefer the cells to be defined where the template is defined.

18:55:01 [fantasai]

Markus: You could do that too

18:55:35 [fantasai]

plinss: I would prefer to have the template declaration to also include a list of defined cells

18:56:06 [fantasai]

plinss: You could then use ::grid-cell() to style the slot

18:56:37 [fantasai]

Phil: That starts making the template declaration really long and complicated.

18:56:44 [fantasai]

Phil: I like breaking it up into bite-sized chunks

18:57:39 [fantasai]

plinss: As a designer, I'd think of the template as a single thing. Don't like breaking it out like this.

18:58:17 [dbaron]

plinss: I don't like the template ASCII art thing.

18:58:45 [fantasai]

fantasai: You could use an @rule to put all the pieces together and give it a name @template mylayout { .... }

18:59:20 [fantasai]

various people object and declare their love for the ASCII art thing

18:59:34 [smfr]

can't hear a word plinss is saying

18:59:36 [fantasai]

plinss: I think it's very 80s and very constrained and very silly

18:59:55 [fantasai]

Markus: I was exactly in your camp when I first looked at it. We want to make it cleaner, more industrial strength, etc.

19:00:06 [fantasai]

Markus: But then we started to try building something a little more complex with it

19:00:15 [bradk]

: #grid::grid-cell("cell-start" "cell-end", "cell-start" "cell-end") { grid-cell-name: "cell" }

19:00:33 [fantasai]

Markus: But as you start to have more complex grid structures, the ASCII art structure very easily and clearly represents those layouts

19:00:54 [fantasai]

Markus: The problem is that it's not industrial strength. You run out of characters

19:01:00 [fantasai]

howcome: Can we get some from the Chinese? :)

19:01:19 [fantasai]

Markus: You have the power of both.

19:01:41 [dbaron]

Phil: grid cells is a superset of template since you can do overlapping cells

19:02:14 [dbaron]

plinss: What happens if the "d"s in a template don't form rectangles?

19:02:22 [fantasai]

Tab: You can't do that

19:02:29 [fantasai]

Tab: They have to be rectangles

19:02:39 [fantasai]

plinss: I have to draw rectangles in ASCII art?

19:02:47 [fantasai]

glazou: It's ugly

19:03:03 [fantasai]

Tab: As someone who edits CSS in a plaintext editor, I love this.

19:03:13 [fantasai]

glazou: My goal is to make CSS editable without a text editor.

19:03:25 [fantasai]

glazou: Without knowing about CSS.

19:03:40 [fantasai]

Tab: It is really easy to create a UI for the ASCII art.

19:03:53 [fantasai]

Markus: We are open to either way.

19:04:38 [fantasai]

Steve: I agree with what Markus just said, which is that the argument is a red herring, provided that there is a clear relationship among each method of specifying the grid

19:05:15 [Bert]

(The "ASCII art" was inspired by proprietary WYSIWYG template editors used by two mobile companies; although their output was HTML tables, not CSS.)

19:05:37 [fantasai]

Steve: and that you cand round-trip between the two

19:06:09 [fantasai]

fantasai: well, ascii art is a subset of the functionality of the other method, so you can't round-trip but there is a clear mapping between the two

19:06:29 [Bert]

(Cesar has a WYSIWYG editor for templates themselves, made by a student.)

19:06:30 [fantasai]

Steve: yes

19:06:38 [fantasai]

Steve: that satisfies my requirements

19:07:09 [fantasai]

Steve: talks about assinging multiple inlines into a single slot

19:07:14 [fantasai]

Phil: I wasn't too clear on that point

19:07:36 [fantasai]

Phil: If I were to float: left something I positioned into slot A, and positioned something else into slot A, would it flow around the float?

19:07:41 [fantasai]

Bert: That was the intention, yes

19:08:04 [fantasai]

something about overlapping

19:08:11 [fantasai]

Tab: You could create multiple slots in the same place

19:08:39 [fantasai]

Alex: Not sure you want to mix unrelated content from various pieces of the dom into a single flow

19:09:10 [fantasai]

Bert: run-in has a similar problem, taking an element out of here and putting it there where it has to be reflowed

19:09:22 [fantasai]

Steve: You're just creating a shadow element that's the combination of all the things you're flowing into the slot

19:09:35 [fantasai]

Steve: and then you flow that

19:09:39 [fantasai]

Alex: Yes, it's possible, but it becomes more complicated

19:09:48 [fantasai]

Alex: If you really need it we could do it

19:09:56 [fantasai]

Steve: The example from the spec is footnotes

19:10:08 [fantasai]

Phil: Ok, let's note that and move on.

19:10:24 [fantasai]

Phil: You declare a grid using the display property -- could be inline or block

19:10:34 [fantasai]

Phil: We have a definition of grid items

19:10:48 [fantasai]

Phil: You can put inline-blocks, block-level elements, various other items

19:10:57 [fantasai]

Phil: These are wrapped in an anonymous block

19:11:31 [fantasai]

Tab: We have more precise terminology for this stuff

19:11:39 [fantasai]

(probably should look at 9.2 etc.)

19:12:04 [fantasai]

Phil: You can name lines, or not name lines. They have an implicit name which is a number

19:12:34 [fantasai]

Steve: Do you use direction and writing mode to determine these?

19:12:36 [fantasai]

Phil: Yes

19:12:38 [stearns]

stearns has joined #css

19:13:05 [fantasai]

Phil: I can put names by putting strings before the grid measurements.

19:13:17 [fantasai]

Phil: I can put multiple names before a measurement, that gives it aliases

19:13:29 [fantasai]

Phil: depending on your naming convention, this might be convenient

19:13:36 [fantasai]

Phil: You specify a start and end line

19:13:55 [dbaron]

Phil: There are also start and end lines predefined, which are keywords rather than strings.

19:14:54 [fantasai]

glazou: I don't like that. A lot of authors are going to use the terms start and end

19:15:17 [fantasai]

Phil: Not a syntactic conflict. There might be mental conflict. I've heard that several times...

19:15:43 [dbaron]

fantasai: Can you count the numbers from the end rather than from the beginning.

19:15:55 [dbaron]

Steve: e.g., if you allow negatives to count from end, 1 to -1 would be start to end

19:16:29 [fantasai]

Phil: We also introduced syntax we borrowed from grid spec for repeating rows or columns

19:16:33 [fantasai]

patterns

19:16:45 [fantasai]

Phil: You might want, e.g. a content space and a gutter, content space, gutter.

19:17:12 [fantasai]

Phil: We have a concept of repeating patterns for that

19:17:23 [fantasai]

Phil: You can name the pattern, that applies to the first line in the pattern

19:17:31 [fantasai]

Phil: This is useful for noting the start of the repeating run.

19:17:42 [fantasai]

Phil: grid-columns: 10px ("content" 250px 10px)[4];

19:18:04 [fantasai]

Steve: If i have this repeating pattern, and I shrink the window size, is there a way to drop columns?

19:18:31 [fantasai]

Phil: Not in this spec. Although we have a concept of automatic columns and rows.

19:18:49 [fantasai]

Alex: With grid positioning, repeat meant repeat this combination until you run out of space.

19:18:54 [fantasai]

Phil: That's something you could add.

19:19:11 [fantasai]

Steve: There's an interesting interaction between fractional space and that concept

19:19:21 [fantasai]

Alex: Yeah, you can't combine them.

19:19:33 [fantasai]

Alex: I think we resolved them to zero or something.

19:19:44 [fantasai]

Tab: You could have repeating pattern, and fractional space on either side.

19:19:49 [fantasai]

Tab: I think that's the only case it would make sense.

19:20:05 [fantasai]

Alex: You could repeat fractions, but you'd wnat to resolve those first before repeating them.

19:20:33 [fantasai]

Steve: You want an integral number of columns, use flex space algo to adjust columns or gaps as specified

19:21:26 [hober]

repeat("content" 250px 10px, 4)

19:21:39 [fantasai]

fantasai: Syntax comment -- we're trying to avoid using additional punctuation for something specific, in case we want to do something generic with it later. So I would suggest to use a functional notation.

19:21:50 [fantasai]

Phil: We have some different sizing functions for tracks

19:21:57 [fantasai]

Phil: Lenghts, percentages resolved against grid element size

19:22:17 [fantasai]

Phil: Fractional values, which are resolved against the remaining space proportional to the number (relative to total of fractional values)

19:22:23 [fantasai]

Phil: max-content, min-content keywords

19:22:29 [fantasai]

Phil: fit-content

19:22:39 [fantasai]

Phil: minmax defines a size range

19:22:48 [fantasai]

Phil: auto keyword is equivalent to fit-content

19:23:14 [fantasai]

Phil: Any questions on these?

19:23:27 [fantasai]

Simon: Did you consider a comma-separated syntax?

19:23:49 [fantasai]

Phil: We played with various syntaxes, but tried to avoid adding unnecessary characters

19:24:37 [fantasai]

dbaron: If you have commas, you have lines and you have things for the spaces in between them. You have to then figure out where the commas would go.

19:24:53 [fantasai]

Steve: good point

19:25:19 [fantasai]

fantasai: You could use line breaks, since it's space-separated, which let's you break wherever you think make sense.

19:25:27 [fantasai]

simon was concerned about readability with multiple names

19:25:57 [fantasai]

Steve asks about flex vs fractional notation

19:26:20 [fantasai]

Alex: Aiming to get flex and grid to have same sizing capabilities

19:26:50 [fantasai]

Steve: My impression was that it's easier to use flex.

19:27:06 [fantasai]

Steve: To get an equivalent mapping, it takes several nested minmax functions

19:27:29 [fantasai]

Steve: A 5-tuple as a set of constraints is simple

19:27:34 [fantasai]

Tab: Let's talk about that

19:27:36 [fantasai]

[later]

19:28:10 [fantasai]

Phil: Just a note on how values are computed.

19:28:32 [fantasai]

Phil: You might have the same name appear multiple times in the grid value ...

19:29:19 [fantasai]

Phil: auto grid column and row generation in case you refer to a gridline that doesn't exist

19:29:53 [fantasai]

Phil talks about used value serialization

19:30:05 [fantasai]

CSSOM results

19:30:52 [fantasai]

glazou: Computed Value is extremely painful to parse

19:30:58 [fantasai]

Simon: What's the alternative?

19:31:28 [fantasai]

glazou: parsing the repeat notation is problematic

19:31:40 [fantasai]

Simon: Thinking about gradients, how could that have been better?

19:31:49 [fantasai]

glazou: For gradients need a better CSSOM

19:32:04 [fantasai]

glazou: Think about users of getComputedStyle, expand everything

19:33:12 [fantasai]

Phil: We wanted to be able to re-assign the value back into the OM and get the same result

19:33:31 [fantasai]

Phil explains a complicated example

19:33:49 [fantasai]

dbaron: I think it's important that it be round-trippable

19:34:15 [fantasai]

dbaron: I think expanding it beyond what it was is causing it to be non-round-trippable.

19:34:47 [fantasai]

dbaron: If you read in the grid , and there's an element that auto-generates lines, and you write back, and then you read in and remove the element, you wind up wit lots of extra grid lines that weren't there before

19:35:23 [fantasai]

Phil: The grid-column and grid-row properites are used for positioning children of the grid

19:35:38 [fantasai]

Phil shows the syntax propdfe tables

19:35:50 [fantasai]

Phil: If you don't specify ? you get an implicit end column

19:35:55 [fantasai]

s/column/line/

19:36:09 [fantasai]

Phil: We said that items are placed in a cell.

19:36:15 [Bert]

s/propdfe/propdef/

19:36:22 [fantasai]

Phil: That doesn't necessarily mean the element stretches to fill the cell

19:36:31 [Bert]

rrsagent, pointer?

19:36:31 [RRSAgent]

See http://www.w3.org/2011/03/08-css-irc#T19-36-31

19:36:33 [fantasai]

Phil: The cell is just a containing block

19:36:42 [fantasai]

Phil: There's also the concept of explicitly defining the grid cells, which we covered before

19:36:58 [fantasai]

Phil: with that name you can place more than one item into a cell

19:37:27 [fantasai]

Steve: What do you mean by placing more than one item into a cell?

19:37:41 [fantasai]

Phil: The default behavior is for these items to stack

19:38:04 [fantasai]

one after the flow

19:38:45 [fantasai]

Phil: whereas positioning them makes them overlap

19:38:50 [fantasai]

Steve: That seems a little subtle

19:39:07 [fantasai]

Phil: There's a property to control this, grid-cell-stacking

19:39:21 [fantasai]

Phil: You can have things stack in rows or columns directions, or layer them

19:40:13 [fantasai]

Phil: Perhaps the initial value here should be layer for ocnsistency

19:40:16 [fantasai]

Steve: That would be better

19:40:21 [fantasai]

Simon: ...

19:40:44 [fantasai]

Phil: We intend that they are block-level or inline-block elements.

19:40:52 [fantasai]

Phil: if they are valid grid items

19:41:10 [fantasai]

Phil: There is also special sizing behavior, where the alignment properties for when you put an element into a grid-cell include stretch, start, end and center

19:41:17 [fantasai]

Phil: There's a row alignment and a column alignment

19:41:57 [fantasai]

Phil: If you take a block-level element and assign it a grid-column-align property other than stretch, then it will align to one of the edges of its grid-cell and size itself shrink-to-fit

19:42:11 [fantasai]

Phil: relationship between that and stacking items in a grid cell

19:42:15 [fantasai]

Phil: default is to stretch

19:42:25 [fantasai]

Phil: so it stretches to occupy the whole cell

19:42:36 [fantasai]

Phil: But if you're stacking, the elements will size shrink-to-fit so you can put one on top of the other

19:42:53 [Bert]

rrsagent, this meeting spans midnight

19:43:20 [fantasai]

Phil explains something more about sizing, several people look confused

19:43:43 [stearns]

stearns has joined #css

19:44:12 [fantasai]

Phil talks too fast

19:44:32 [fantasai]

Steve: Sounds sort of like each of these cells is a flexbox in what you're doing, with the flex direction being either rows or columns

19:44:48 [fantasai]

Phil: No flex, but yes similar

19:45:27 [fantasai]

Steve: Each item that's stacked is being handled as if it were a flex item whose size is based on its content. I.e. it beocmes a BFC, there's no margin collapsing, etc.

19:45:47 [fantasai]

Phil scans through sections of the draft defining the various properites

19:46:41 [dbaron]

fantasai: What if grid-row specifies and a start and an end line, and grid-row-span also specifies a span? Could have a cascading problem too.

19:46:51 [dbaron]

Phil: We should make it clear that an ending line has priority over a span.

19:46:53 [fantasai]

Phil: We left in grid-row-span, grid-column-span, because we liked that ability more

19:47:13 [fantasai]

Phil: There's a concept of implicit columns or rows

19:47:23 [fantasai]

Phil: You create auto tracks as needed

19:47:39 [fantasai]

Phil: There's a property to control what size track gets created, so that they're not always auto-sized

19:48:04 [fantasai]

Phil: Lastly, concept of automatically placing items in the gird.

19:48:29 [fantasai]

Phil: There's a concept of grid-flow, which creates more rows (or columns) as needed.

19:48:40 [fantasai]

Phil: Would take awhile to explain, take a look at the draft

19:48:52 [fantasai]

Steve: this is for indefinite numer of coluns?

19:49:19 [fantasai]

Phil: Yeah. I have a form with lots of fields, as an author just want to define a grid for your fields

19:49:31 [fantasai]

Phil: I create three columns, and then tell the forms to find an auto row

19:50:22 [fantasai]

Phil: Here are the grid alignment properites, discusses writing mode interactions, etc.

19:51:28 [fantasai]

Phil: Drawing order of grid items is not changed; got some feedback on using z-index, haven't incorporated yet

19:51:46 [fantasai]

Phil: Concern is wanting to drop things behind other things, but not behind the grid element background

19:51:55 [fantasai]

Phil talks about stacking contexts

19:53:12 [fantasai]

Phil: Need an easy send-to-back functionality

19:53:26 [fantasai]

dbaron: A full stacking context would do that

19:53:50 [fantasai]

Phil: Not sure we really want to prevent z-ordering behind the grid element just because we want easy send-to-back

19:54:08 [fantasai]

dbaron: You don't have to do that by default, but the author could specify it themselves

19:54:19 [fantasai]

dbaron: That makes the send-to-back scenario work

19:56:02 [fantasai]

Phil: Stacking contexts are complicated, I'm concerned about making authors understand them and z-index in order to make this work.

19:56:38 [fantasai]

Alex explains something about making all form controls relpos just to get z-index working

19:57:10 [fantasai]

fantasai: What is the relationship of this to existing grid module?

19:57:23 [fantasai]

Alex: Positioning is really interesting in concept of page layouts, and we have some ideas on how to integrate them

19:58:02 [fantasai]

Alex: I have some ideas on how to integrat them

19:58:19 [fantasai]

fantasai: It seems this module folds in a lot of that functionality, so you could publish this as an update to that module.

19:59:29 [fantasai]

Alex: Grid positioning deals with other content, no necessarily your immediate children

19:59:55 [fantasai]

Alex: One thing that needs to be defined is element sizing, and how do you define a positioning container ... where grid is applicable

20:00:46 [fantasai]

Alex: Once we figures out where grid position is applicable, who is the grid positioning container, and how is the grid defined on that, we can easily merge these specs together

20:01:03 [fantasai]

Alex: So that everything here contributes to grid definition.

20:01:18 [fantasai]

Markus: We still need a lot of the concepts from that spec to integrate.

20:01:41 [fantasai]

Alex: I think the main ue case for grid positioning is page floats

20:02:00 [fantasai]

Alex: I don't think page floats is quite as ready

20:03:59 [fantasai]

fantasai: Ok, I understand why they are separate and I agree that makes sense.

20:04:04 [fantasai]

<br type="lunch">

20:31:32 [Zakim]

Zakim has left #css

20:31:53 [Kazutaka]

Kazutaka has joined #CSS

20:34:38 [stearns]

stearns has joined #css

20:41:42 [stearns]

stearns has left #css

20:41:51 [stearns]

stearns has joined #css

21:02:37 [Arron]

Arron has joined #css

21:02:59 [mmielke]

mmielke has joined #css

21:03:50 [Zakim]

Zakim has joined #css

21:05:12 [smfr]

smfr has joined #css

21:07:02 [TabAtkins_]

TabAtkins_ has joined #css

21:07:21 [fantasai]

</br>

21:07:54 [fantasai]

Markus: Wanted to follow up on discussion from before-lunch meeting

21:08:09 [fantasai]

Markus: Would like to advance grid layout spec from editor's draft to WD

21:08:49 [fantasai]

jdaggett: For FPWD, there are special requirements

21:08:49 [glazou]

glazou has joined #css

21:09:10 [glazou]

test

21:09:45 [fantasai]

fantasai: From what Alex was saying, I think it makes sense for the modules to be separate

21:09:49 [fantasai]

[howcome asked if we can merge them]

21:09:59 [fantasai]

fantasai: And publish this as grid-layout

21:10:01 [Jay]

Jay has joined #CSS

21:10:15 [fantasai]

jdaggett: What are the requirements?

21:10:45 [fantasai]

glazou: Has to be in the charter

21:11:22 [fantasai]

fantasai: It is, since it's closely related to existing css3-grid

21:11:32 [fantasai]

fantasai: need permission from plh to publish FPWD, but nothing else

21:12:02 [fantasai]

RESOLVED: Publish as css-grid, i.e. CSS Grid Layout [Level 1]

21:12:18 [fantasai]

ACTION Bert make publication

21:12:18 [trackbot]

Created ACTION-312 - Make publication [on Bert Bos - due 2011-03-15].

21:12:48 [fantasai]

s/css-grid/css-grid-layout/

21:13:25 [karl]

karl has joined #CSS

21:13:45 [fantasai]

note: level 1 is not part of title, just clarifying that no other level is

21:14:04 [fantasai]

plinss: Skipping line grid, since it's marked as "if time allowed"

21:14:20 [fantasai]

plinss: Flexbox?

21:14:23 [fantasai]

Tab: ???

21:14:30 [fantasai]

Alex: Wouldn't you like to present the changes in your latest draft?

21:14:32 [fantasai]

Tab: I could?

21:14:44 [shonda]

shonda has joined #css

21:14:54 [fantasai]

Tab goes up to present

21:14:58 [plinss_]

s/Skipping line/Deferring line/

21:15:39 [arno1]

Moved "Line Grid" to end of agenda for today on wiki

21:15:43 [fantasai]

Tab gives overview of flexbox

21:15:45 [smfr]

http://dev.w3.org/csswg/css3-flexbox/

21:16:04 [fantasai]

Tab: Current editor's draft of flexbox is much closer to my draft, and to suggestions we've made so far

21:16:10 [fantasai]

Tab loads page with lots of red

21:16:34 [fantasai]

Tab: Using term flexbox consistently, instead of box which is too generic

21:16:44 [fantasai]

Tab: Flex-direction says which directions the boxes flow in

21:17:11 [fantasai]

Tab: Have physical and logical directions

21:17:29 [fantasai]

Alex: If we had a multiline flexbox, how would we extend flex direction for it?

21:17:39 [fantasai]

ISSUE ^

21:17:47 [fantasai]

Alex: One approach would be to use existing writing mode

21:17:53 [fantasai]

Alex: There is no logical equivalent of those

21:18:04 [fantasai]

Alex: Maybe do come up with eight logical abbreviation directions

21:18:18 [bradk_]

bradk_ has joined #css

21:19:40 [fantasai]

fantasai: How about combining keywords with spaces, e.g. tb lr

21:19:52 [fantasai]

Tab: flex-order lets you reorder items

21:20:28 [bradk_]

bradk_ has joined #css

21:20:28 [fantasai]

Tab: Flexible lengths is where it really changes.

21:20:42 [fantasai]

Tab: Old draft used a flex property that took an integer, and then keywords for alignment

21:20:59 [fantasai]

Tab: I'm going with a different approach here,

21:21:16 [fantasai]

Tab: Got feedback from daniel and web authors that "width" being an input in to the flex algo and not really the width was confusing

21:21:38 [fantasai]

Tab: Using now a flex() function, which takes 3 args, first one is positive flex, second is negative flex --

21:22:03 [fantasai]

Tab: Established at F2F that negative and positive flex should be distinguished, otherwise you get unintuitive results, ie. largest thing becoming smallest

21:22:15 [fantasai]

Tab: Third arg is the starting width.

21:23:00 [fantasai]

Tab: auto gives previous behavior; it's always additive flex, but by default this arg is zero so you get absolute flex if you don't specify

21:23:14 [dbaron]

Phil: Is there plan to have something not flex-prefixed for any type of layout not based on source order?

21:23:21 [sylvaing]

sylvaing has joined #css

21:23:27 [dbaron]

(regarding flex-order)

21:23:51 [fantasai]

Phil asks about having the reordering be a more generic concept, since it's useful in many layout models not just for flexboxy

21:23:54 [fantasai]

s/y//

21:24:11 [fantasai]

Tab: Ok, could have that be a generic mechanism for rewriting source order

21:24:25 [fantasai]

Steve: ...

21:24:50 [fantasai]

Phil: Template layout had an area that used source order for flowing items, might want to reorder in that as well

21:25:12 [fantasai]

dbaron: Do people have positive experiences using an integer-ordering property like this?

21:25:44 [fantasai]

dbaron: or does this get unweildy with more content?

21:25:53 [fantasai]

Tantek: numbering BASIC worked so well!

21:26:11 [fantasai]

Steve: Might want to reorder columns

21:26:19 [fantasai]

Steve: in that case maybe using names

21:26:37 [fantasai]

Tab: Elika brought up case of tabbed layouts, where active tab is always in front

21:26:49 [fantasai]

Tab: I'm certain like many of our advanced tools it can be abused

21:26:57 [fantasai]

Tab: Like we shouldn't be sorting lists with this

21:27:05 [fantasai]

Tab: But I'm not sure how else to get the functionality we need here

21:27:38 [fantasai]

dbaron: Wrt usefulness of order, Gecko has implemented box-ordinal-group for around a decade now.

21:27:51 [fantasai]

dbaron: But it's used so rarely that we're still getting very fundamental bugs filex on it

21:28:11 [fantasai]

Tab returns to flex()

21:28:25 [fantasai]

Tab: The old flex property and box-align properties are replaced with flex() notation

21:28:47 [fantasai]

Tab: Then we have the flex-pack property, which determines the distribution of content within the flex direction

21:29:20 [fantasai]

Tab: It works similar to text-align

21:30:01 [fantasai]

Tab: justify evenly spaces out the flexboxes, aligning them flush

21:30:32 [fantasai]

fantasai: I would suggest to look at ruby-align property, esp distribute (which seems like a better name here) and distribute-space

21:30:39 [fantasai]

Tab: flex-align property..

21:30:59 [fantasai]

Tab: Normally use flex to do alignment, but couldn't figure out how to do baseline alignment

21:31:18 [fantasai]

Tab: Not totally clear on the use cases, so still haven't fully specc'ed it out.

21:31:35 [fantasai]

Tab: auto just means normal flex distribution, baseline means currently-undefined magic

21:31:48 [fantasai]

Tab: That's pretty much it, rest is algorithms

21:32:41 [fantasai]

Tab: We've established that for flex, we want positive flexibility, negative flexibility, and a starting width. These are all important pieces of information we need to flex correctly.

21:33:04 [fantasai]

Tab: The original approach of having two different properties that have to be thought of together to get a single effect was confusing

21:33:13 [fantasai]

Tab: And with negative flex we needed yet another one

21:33:30 [fantasai]

[Markus asked why there's flex() instead of 'flex']

21:34:08 [fantasai]

Alex: My concern is that it makes absolute flex easier but relative flex harder

21:34:50 [fantasai]

Alex: The main working mode of the whole spec becomes absolute flex, which is not the previous system

21:35:05 [fantasai]

Alex: I expected default starting width to be auto

21:35:34 [fantasai]

Alex: Have padding initial be zero, width initial be auto

21:36:43 [fantasai]

Markus: ...

21:37:10 [fantasai]

Tab: Talking to authors playing with old spec, they're confused.

21:37:25 [fantasai]

Tab: Having flex: 1; on multiple elements result in different sizes confuses them

21:38:05 [fantasai]

Alex: If you're working on top-level page layout, absolute flex is more useful

21:38:21 [fantasai]

Alex: If you're laying out form controls, then additive flex is more useful.

21:38:34 [dbaron]

s/form controls/form controls or menus/

21:38:36 [fantasai]

Tab: I have to make one shorter syntax than the other

21:38:48 [fantasai]

Alex: Let's look at other options

21:39:31 [fantasai]

Tab talks about terminology for width and height algos

21:39:45 [fantasai]

Markus: Is your motivation that this would replace existing flexbox spec?

21:39:48 [fantasai]

Tab: Yes, replace

21:40:00 [fantasai]

Markus: Despite existing implementations?

21:40:09 [fantasai]

Tab: Yes. I think this is sufficiently better that it should replace.

21:40:21 [fantasai]

Tab: Working with chrome devs, they are enthusiastic about replacing it

21:40:41 [fantasai]

Alex: Is Mozilla going to move to the new syntax?

21:40:50 [fantasai]

dbaron: We'd definitely like to have a standard version of flexbox.

21:41:06 [fantasai]

dbaron: It's hard to tell how quickly it would happen/

21:41:19 [fantasai]

Alex: would it make a difference if it stayed closer to the old syntax?

21:41:27 [fantasai]

dbaron: I think the syntax is less of a big deal than the concepts

21:41:42 [fantasai]

dbaron: A lot of the stuff we use flexbox for now is stuff we want additive flex for now.

21:41:56 [fantasai]

dbaron: potentially harder to convert existing content

21:42:03 [fantasai]

Tab: I don't buy the conversion argument

21:42:08 [fantasai]

dbaron: But it seems like a lot of typing

21:42:32 [dbaron]

people might not know what flex(1, 0, auto) means

21:42:33 [fantasai]

dbaron: And I don't think people will know what flex(1,0,auto) means

21:42:39 [dbaron]

(which they'll be using a lot)

21:43:11 [fantasai]

Markus: Shouldn't we standardize the current spec now?

21:43:19 [fantasai]

Markus: And make this the next level?

21:43:37 [fantasai]

Tab: You can't really do that. They're not compatible, not without some really hacky stuff

21:43:56 [fantasai]

Tab: Also my experience talking with authors is that the current spec is really confusing

21:44:10 [fantasai]

Markus: Yeah, it's not that great, but we have implementations

21:44:43 [fantasai]

Tab: I'm not in favor of standardizing something that's bad.

21:45:04 [fantasai]

dbaron: I think you're getting different feedback because the web authors you're talking with are trying flexbox for something it wasn't designed for

21:45:11 [glazou]

standardization is always bad because it is always a compromise

21:46:19 [Bert]

i/Arno: I'd like tot/-> http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0011/CSS_Regions.pdf CSS Regions draft

21:46:42 [fantasai]

fantasai: So, my position is [minute here later]

21:47:05 [fantasai]

Tab: If it's a question of which (additive vs absolute) is easier, I'm not concerned about that question

21:47:21 [fantasai]

Tab: What's important to me is breaking with the previous syntax.

21:47:29 [fantasai]

Markus: We have implementations coming, and it's used.

21:47:32 [fantasai]

Tab: But not on the Web

21:47:39 [fantasai]

Tab: And our implementation at least is very buggy

21:47:50 [fantasai]

Tab: It's a minority prefixed thing.

21:48:07 [fantasai]

glazou: Current implementations are too weak and too buggy for use

21:48:18 [fantasai]

Tantek: That's the point of prefixes -- they allow us to experiment.

21:49:37 [fantasai]

fantasai rants, but doens't have time to type it

21:50:11 [fantasai]

dbaron: I don't think negative flex is the hardes thing here, it's adding flex to margins and padding

21:50:22 [fantasai]

fantasai: But thats needed if you want to apply this to HTML, because in XUL you have to use <spacer> elements

21:50:27 [dbaron]

dbaron: ...and as a value to existing properties

21:50:41 [fantasai]

Steve: ...

21:50:51 [fantasai]

Steve: This in my mind has the level of flexibility that you need

21:51:01 [fantasai]

Steve: It's also a lot easier to explain to people than the other one

21:52:06 [fantasai]

Steve: It would work perfectly well within the grid layout model

21:52:21 [fantasai]

Steve: I think Tab's choice of using the zero-width thing is more appropriate there

21:53:00 [fantasai]

Tab: For the most common case, of starting flex from the auto width and using single flex, you can just use 'auto'

21:53:06 [fantasai]

Tab: That's equal to flex(1,0,auto)

21:53:41 [fantasai]

Tab: We can still talk about how to make them easy, but there are ways to make both common cases easy

21:53:54 [fantasai]

dbaron: Shouldn't the width value come first?

21:54:29 [dbaron]

Tab: I had it that way at first; seemed reasonable; Alex convinced me to change.

21:55:43 [fantasai]

Tab: I had that first, and it makes it easier to do relative flex, but it doesn't work so well for absolute flex

21:55:51 [fantasai]

Tab: And Alex suggested swapping the order

21:56:10 [fantasai]

fantasai asks about making flex() detec whether it's aboslute or relative based on whether it's a length or an integer

21:56:34 [fantasai]

Steve: ...

21:57:01 [fantasai]

Steve: The flex unit is confusing if grow and shrink are given in one set of units, and differnt in another

21:57:15 [fantasai]

Tab^: I had flex units be additive and flex() be absolute before

21:57:28 [fantasai]

...

21:57:46 [fantasai]

Tab: The idea of what's the best way to present this concept to authors is omething we should talk about

21:58:00 [fantasai]

Steve: Btw I'm not disputng the 5-tuples

21:58:09 [fantasai]

Steve: Just discussing synta

21:58:38 [fantasai]

Tab: I think this is the best option, though I'm open to other options.

21:58:49 [fantasai]

Tab: Main question is whether we go forward with this or revert to the old draft.

21:59:06 [fantasai]

Alex: We want draft to become stable and move forward

21:59:14 [fantasai]

Alex: I don't see a way to get there without having a new draft

21:59:23 [fantasai]

plinss asked for objections to moving forward with this draft

21:59:50 [fantasai]

RESOLVED: Publish updated draft of css3-flexbox

22:00:08 [fantasai]

Topic: MultiCol

22:00:47 [fantasai]

howcome: Multicol is in CR. We have a couple of issues, but close to getting a new version

22:00:53 [fantasai]

howcome: Would like to publish another CR

22:01:03 [fantasai]

howcome: Big issue was pseudo-algorithm

22:01:44 [fantasai]

howcome: In previous versions the pseudo-algorithm tried to reduce the number of columns

22:02:05 [fantasai]

howcome: Seems to be consensus on not doing that, and relying on authors setting column-width to give the columns a minimum width

22:02:34 [fantasai]

howcome: here's what I suggest to edit the pseudo-algorithm

22:03:01 [fantasai]

fantasai: Can we get comments in the pseudo-algorithm?

22:03:04 [fantasai]

howcome: maybe

22:03:37 [fantasai]

howcome: I think my proposal is correct, put a max fuction to make sure width doesn't go negative

22:04:01 [fantasai]

howcome: The prose says that if both 'column-width' and 'column-count' have non-auto values, the integer value describes the maximum number of columns

22:04:09 [fantasai]

howcome: fantasai noted this in the minutes

22:04:20 [fantasai]

howcome: But this prose is not included in the pseudo-algorithm

22:04:36 [fantasai]

Sylvain: Fix the pseudo-algorithm

22:07:03 [fantasai]

Discussion of use cases for column-count

22:08:14 [brennannovak]

brennannovak has joined #css

22:08:15 [fantasai]

howcome: btw, my proposal for fixing this should use min() instead of max() ...

22:08:41 [brennannovak]

brennannovak has left #css

22:11:06 [fantasai]

fantasai makes an argument that the combination of column-width and column-count is the most useful way of specifying column-count, and this behavior is not provided by any of the alternative proposals

22:11:19 [fantasai]

wheres the behavior of the alternative proposals can be gotten in other ways

22:11:32 [fantasai]

Simon: Should we rename it to column-min-width?

22:11:52 [fantasai]

howcome: we'd have to go back to last call

22:12:29 [fantasai]

no strong opinions in favor of renaming

22:12:35 [fantasai]

howcome: Can we update the CR?

22:13:50 [fantasai]

plinss wants to be more verbose and have it column-min-width

22:13:59 [fantasai]

fantasai disagrees

22:14:09 [fantasai]

Brad: If there's only one thing to set the widht, it should just be width

22:14:21 [fantasai]

RESOLVED: Publish updated WD of css3-multicol

22:14:29 [fantasai]

RESOLVED: Publish updated CR of css3-multicol

22:14:37 [fantasai]

dbaron: test suite?

22:14:53 [dsinger]

dsinger has joined #css

22:15:15 [fantasai]

howcome: I'm working on the test suite

22:15:49 [fantasai]

dbaron: we have 22 reftests for columns

22:16:18 [fantasai]

fantasai: bunch more in pagination

22:16:35 [fantasai]

dbaron: we'd need to go back and check that the tests match the current spec

22:16:44 [fantasai]

johnjan: I have some ideas

22:16:51 [fantasai]

howcome: how do we go forward with the tests

22:17:00 [fantasai]

johnjan: We should take what we learned about CSS2.1 and apply to CSS3

22:17:13 [fantasai]

johnjan: I think first we should map every test to the part of the spec's testing

22:18:01 [RRSAgent]

I have made the request to generate http://www.w3.org/2011/03/08-css-minutes.html Bert

22:18:29 [fantasai]

dbaron, fantasai: We have links to section headings laready

22:18:43 [fantasai]

fantasai: css3 specs have more fine-grained subsections than CSS2.1

22:19:20 [fantasai]

johnjan, fantasai: ideally would do per-paragraph anchors

22:19:48 [fantasai]

fantasai: but hard to have stable anchors

22:20:24 [Bert]

i/I'd like tot talk/-> http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0011/CSS_Regions.pdf CSS Regions draft

22:20:27 [RRSAgent]

I have made the request to generate http://www.w3.org/2011/03/08-css-minutes.html Bert

22:20:46 [dbaron]

http://test.csswg.org/suites/css2.1/20110111/xhtml1/toc.xht

22:20:48 [fantasai]

johnjan talks about testing

22:20:54 [fantasai]

keeping track of which sections are tested, not tested,

22:21:01 [fantasai]

how many tests are for each section

22:21:35 [fantasai]

johnjan: we're not interested in implementation testing, but in implementability testing

22:21:46 [fantasai]

dbaron: We need a test suite to enter PR, but that shouldn't be the only purpose of the test suite.

22:21:55 [fantasai]

dbaron: I think we should be developing the test suite for interop

22:22:34 [fantasai]

dbaron: We want the test suite to solve real problems for authors, not just get us to PR

22:22:44 [fantasai]

dbaron: Authors have problems when impls don't do the same thing

22:23:36 [fantasai]

dbaron: And we want to test things that will have bugs that bother them

22:23:48 [dbaron]

It's not about proving interop... it's about improving interop.

22:23:49 [fantasai]

johnjan: proving compliance and interop are two different

22:23:50 [Bert]

i|I'd like tot talk|-> http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0011/CSS_Regions.pdf CSS Regions draft

22:23:54 [RRSAgent]

I have made the request to generate http://www.w3.org/2011/03/08-css-minutes.html Bert

22:24:33 [fantasai]

dbaron: It's not about proving interop, it's about IMproving it

22:24:39 [fantasai]

...

22:25:01 [fantasai]

johnjan: There's no motivation for making test suites other than going to CR

22:25:19 [alexmog]

what if test ID used a section URL plus the text of the paragraph? then mapping can use simple search to map. when paragraph moves it is still mapped to. when the pargarph changes the tests have to be updated anyway...

22:25:19 [fantasai]

sylvaing: You could say that you need an implementation report to drop your prefixes

22:25:48 [fantasai]

sylvaing: Today, we allow dropping prefixes as soon as we go to CR.

22:26:11 [fantasai]

sylvaing: If we require tests, that gets us tests and it makes sure that impls dropping prefixes implemented it correctly

22:26:28 [fantasai]

johnjan: I think testing has to drive the process more

22:27:52 [fantasai]

fantasai: public-css-testsuite and the svn repo are available to all css modules, not just 2.1

22:29:10 [fantasai]

fantasai and arronei review the review process

22:29:42 [fantasai]

http://wiki.csswg.org/test

22:29:52 [fantasai]

Tab: There should be an excuse to why it's not a reftest

22:30:42 [fantasai]

dbaron: Did we adopt the scripted reftest conventions?

22:30:54 [fantasai]

fantasai: Not yet, we'd have to do so

22:31:26 [fantasai]

dbaron explains reftest-wait

22:32:39 [fantasai]

howcome: do we need scripted tests?

22:32:47 [fantasai]

dbaron: Yes, changing pagination points

22:32:54 [fantasai]

johnjan: resizing the window

22:33:11 [fantasai]

howcome: Safari?

22:33:18 [fantasai]

Simon: We have 50-60 tests in our test suite

22:33:33 [fantasai]

Simon: But they're not really suitable for test suite tests in their current incarnation

22:34:19 [fantasai]

howcome: What about multi-col in vertical text?

22:34:22 [fantasai]

Alex: It should just work :)

22:35:51 [fantasai]

johnjan: what about prefixes?

22:36:02 [fantasai]

Arron: No prefixes in the test suites

22:36:17 [fantasai]

johnjan: So we can't test until we drop prefixes

22:36:31 [fantasai]

dbaron: Could add prefixes with regexp

22:37:56 [homata__]

homata__ has joined #CSS

22:38:22 [fantasai]

fantasai: Current build system has concept of output formats, would be easy to build regexp into that

22:38:27 [mollydotcom]

mollydotcom has joined #css

22:38:36 [fantasai]

Arron: Another issue is tracking issues on the testcases

22:38:47 [fantasai]

Arron: Using the mailing list is really really unweildy

22:39:09 [fantasai]

Arron: Can we use bugzilla?

22:40:36 [fantasai]

johnjan: The mailing list is really going to be hard to manage

22:40:52 [fantasai]

dbaron: Bugzilla is too heavyweight

22:40:58 [fantasai]

plinss: we have a design for a system, just need to build it

22:41:11 [fantasai]

johnjan: We need something now

22:41:28 [fantasai]

Arron: May not be perfect solution, but Bugzilla gives us something for now

22:42:31 [fantasai]

fantasai: So I think we should adopt Bugzilla, one bug report per test unless you have a really good reason not to.

22:43:29 [fantasai]

howcome: So we put tests in contributors directory, and if I review and approve them I move them to the approved/ directory

22:43:33 [fantasai]

fantasai, arron: right

22:43:49 [fantasai]

RESOLVED: Use Bugzilla for test suite bugs, one bug report per test unless there's a good reason not to

22:45:53 [fantasai]

<br>

22:48:59 [mollydotcom]

hey folks - I'm much on the mend now - wondering if I should come in? Or rest and wait 'til tomorrow?

22:50:13 [mollydotcom]

(ps it's not contagious ;))

22:55:53 [mollydotcom]

That's very sweet, Sylvain. I think I will stay and rest here as there's not much time left of the day. Better to be feeling more myself tomorrow

23:03:57 [fantasai]

Topic: Tokyo Workshop

23:04:11 [plinss_]

http://wiki.csswg.org/planning/tokyo-workshop-2011

23:04:14 [howcome]

howcome has joined #css

23:04:16 [fantasai]

howcome: http://wiki.csswg.org/spec/css-multicol

23:05:19 [fantasai]

Koji: There is a group in Japan supported by Japanese government trying to host forum or workshop

23:05:27 [fantasai]

Koji: I'm the liaison to the CSSWG

23:06:06 [fantasai]

My name is Jay [?]

23:06:23 [fantasai]

Jay: I am going to make a presentation for the upcoming Tokyo workshop

23:06:28 [kojiishi]

Jay Kishigami

23:07:12 [fantasai]

http://wiki.csswg.org/planning/tokyo-workshop-2011

23:07:26 [fantasai]

Jay: This is a good opportunity to discuss with Japanese publishers and other users of vertical writing.

23:07:41 [fantasai]

Jay: But it's not only in Japan, but also in other countries.

23:07:51 [fantasai]

Jay: Old Korean was written in vertically

23:07:57 [fantasai]

Jay: And also Chinese write in vertical

23:08:08 [fantasai]

Jay: Chinese, Japanese, and Mongolian all currently write in vertical

23:08:12 [kojiishi]

Newspapers in Korea were in vertical up until 1996 or so

23:08:30 [fantasai]

Jay: Maybe this community discuss the real requirements

23:08:54 [fantasai]

Jay: Publishers and software vendors are very interested in ths workshop

23:09:12 [fantasai]

Jay: Maybe some presentation from Asian layout implementers and device vendors

23:09:16 [kojiishi]

You can find Korean newspaper archives by date at http://dna.naver.com

23:09:17 [fantasai]

Jay: authors

23:09:30 [fantasai]

Jay: I just wanted to confirm dates for workshop

23:09:37 [fantasai]

Jay: Before or after

23:09:51 [fantasai]

Jay: I heard that fantasai cannot attend before, but others are better before

23:10:16 [fantasai]

Jay: before is also good if items come up for WG discussion, can be discussed at F2F after

23:10:23 [fantasai]

Jay: Is there any objections or comments on the date?

23:10:26 [bradk]

bradk has joined #css

23:10:37 [fantasai]

glazou: How many days do you plan to have the workshop?

23:10:45 [fantasai]

Koji: I don't think we have finalized this yet

23:10:54 [fantasai]

glazou: I think one day is probably enough

23:11:07 [fantasai]

glazou: Since we are meeting W-F for CSSWG F2F

23:11:48 [fantasai]

glazou: So Tuesday is best especially for people travelling from far away

23:12:52 [fantasai]

Bert: How many people should come to the workshop?

23:13:11 [fantasai]

Koji: It depends if you want a small group, then we can have such a meeting, or if you want to have a bigger meeting we can do that.

23:13:14 [fantasai]

glazou: We can have both.

23:13:19 [fantasai]

glazou: Most of the WG will be present.

23:13:31 [hober]

hober has joined #css

23:13:38 [fantasai]

glazou: We can have panels with questions where WG interact with audience, split into tables for lunch

23:13:57 [fantasai]

glazou: The only problem in smaller groups is your last line, the language

23:14:12 [fantasai]

Jay: Atm we have two solutions for the language.

23:14:19 [fantasai]

Jay: one is to have basic language be English

23:14:36 [fantasai]

Jay: But for some people they're not comfortable to speak English

23:14:45 [fantasai]

Jay: So we can have simultaneous language

23:14:58 [fantasai]

glazou: Japanese is probably best for main language, but we need English :)

23:15:17 [fantasai]

Jay: So proposal is May 31st Tuesday from 9 or 10am through the evening, with lunch session

23:15:25 [fantasai]

Jay: We can have tables with discussions at the tables

23:15:37 [fantasai]

glazou: That's doable if we have one person per table able to translate between English and japanese

23:15:41 [fantasai]

glazou: That's the only trouble we have

23:16:05 [fantasai]

Peter: One other thought about the dates is that we could push our meeting back by a day or shorten it by a day

23:16:14 [fantasai]

jdaggett: I think we definitely shouldn't shorten our meeting

23:17:12 [fantasai]

plinss: We could also push back our meeting by a day, T-S

23:18:35 [fantasai]

fantasai and Steve can't make Tuesday

23:18:47 [fantasai]

?: Tab, can you host on Saturday?

23:19:02 [fantasai]

Tab: difficult, since Google employees won't be there

23:19:14 [fantasai]

jdaggett: We could host on Saturday

23:19:29 [Bert]

(So how big will the ftf be, again 25, or less?)

23:21:27 [TabAtkins_]

TabAtkins_:

23:21:33 [TabAtkins_]

ScribeNick: TabAtkins_

23:21:55 [TabAtkins_]

jdaggett: I'm concerned that if it's only publishing/gov people, we (CSS) aren't really capturing the main audience for this, which is people designing for the web.

23:22:16 [TabAtkins_]

jdaggett: It's good to consider the use-cases the publishers have, but that tends to be a relaitvely limited set of uses compared to everyone designing webpages.

23:22:39 [TabAtkins_]

Jay: The participants here may be from the publishing area, but will include the web designers.

23:22:40 [mollydotcom]

i'd like to jump in on that too

23:22:43 [mollydotcom]

if I may?

23:23:02 [TabAtkins_]

Jay: Maybe the signage designers would be able to offer useful feedback as well

23:23:10 [mollydotcom]

John's concerns are very real, and of course this is an ongoing issue

23:23:31 [TabAtkins_]

jdaggett: We're designing CSS here, and the focus is on designing CSS, not necessarily on how Japanese test works.

23:23:39 [mollydotcom]

as the person who acts as developer liaisons, we have to engage designers more

23:24:10 [mollydotcom]

but Japanese text is part of that too - designers designing Japanese sites need the technology

23:24:19 [TabAtkins_]

Jay: The goal of this workshop is understanding how to handle vertical text.

23:24:28 [TabAtkins_]

[reading Molly's comments]

23:24:46 [mollydotcom]

I'm just repeating my old mantra: Engage designers somehow

23:24:57 [TabAtkins_]

jdaggett: It would be useful to have a workshop on CSS and how Japanese fits into that context, rather than how publishing works in Japan.

23:25:00 [mollydotcom]

It's very difficult, not our fault, but it's necessary

23:25:44 [TabAtkins_]

Koji: I think we tried to make the participant list take into account input from the WG, including you.

23:25:46 [mollydotcom]

+1 That's the point, is it not? John. At least as I see it

23:26:05 [TabAtkins_]

jdaggett: I think it seems that this is trying to be everything to everyone, and it needs some clear themes. What are the problems we're trying to discuss.

23:26:18 [TabAtkins_]

jdaggett: My concern is that people are just going to get up and talk about things that they think are important.

23:26:41 [TabAtkins_]

Markus: So you want to frame it as "How can we help", action items that the WG can take away to work on.

23:26:57 [TabAtkins_]

jdaggett: Right; we need to think about it in terms of CSS and the web, not just about the difficulties of publishing.

23:27:42 [TabAtkins_]

plinss_: I think CSS is becoming more and more important in publishing.

23:27:55 [TabAtkins_]

jdaggett: Right, but we need to ensure that it's both about the web and publishing.

23:28:09 [fantasai]

Markus: If you explain what is the delta between what you see on the Web and what you would want to see

23:28:11 [TabAtkins_]

Markus: I think it's easiest to phrase things as a delta between what currently exists and what is lacking that is needed.

23:28:28 [mollydotcom]

I agree - but any focus on publishing and not the Web pisses off a lot of developers and designers. Who is using CSS more today?

23:28:36 [TabAtkins_]

Jay: We want to intentionally produce just such a productive and tangible result from the discussions.

23:28:42 [fantasai]

Markus: Every time you have a speaker, elicit a summary so we can walk away with an understanding of what we need to work on.

23:29:08 [TabAtkins_]

Jay: Though, perhaps the older publishing people won't fully grasp what is "CSS".

23:29:16 [TabAtkins_]

Jay: So some interpretation may be required.

23:29:43 [myakura]

myakura has joined #css

23:29:45 [mollydotcom]

it sounds unfocused to me

23:29:47 [fantasai]

Steve: Are you looking at this as a meeting as a way for CSSWG to present what we're doing and get comments and questions back,

23:29:49 [mollydotcom]

what is the end goal?

23:30:00 [mollydotcom]

in one sentence

23:30:02 [fantasai]

Steve: Or are we sitting through presentations where japanese people explain what they need?

23:30:31 [fantasai]

Steve: I don't have a particular preference, but from the CSS viewpoint it seems to make more sene for us to present what we are doing, since that's what we are expert in

23:30:42 [fantasai]

Steve: But it would also be relevant to hear what other people think we /should/ be doing

23:31:01 [hyatt]

"what they need" is already described really well by the amazing http://www.w3.org/TR/jlreq/ document

23:31:30 [fantasai]

Koji: Is there anyone who can give an overview of what's going on in CSSWG?

23:31:31 [mollydotcom]

How about focus sessions on each then? "Hear from the CSS WG" and "Hear from the attendees" which could be very compelling if well described

23:31:42 [fantasai]

fantasai: you? :)

23:31:56 [fantasai]

tab reads out comments from IRC

23:33:50 [Bert]

fantasai: Could hve two days, one in Japanese, one with the WG in English

23:33:58 [Zakim]

Zakim has left #css

23:34:06 [glazou]

hyatt: yes that document is amazing

23:34:21 [hyatt]

glazou: that's really what we've been using in webkit to guide our implementation

23:34:27 [fantasai]

fantasai: Japanese can use the first day to interact with and learn from each other, and organize what they want to present to us, ask us, request from us

23:34:33 [glazou]

hyatt: how suprising :-)

23:35:57 [fantasai]

Koji: Could have first day Japanese learning, second day presenting to WG

23:36:21 [fantasai]

Jay: So could have second day be workshop, with English support, first day be preparation for/by/in Japanese

23:36:52 [fantasai]

Jay reads out name of government org that will be co-organizing with W3C

23:37:21 [fantasai]

glazou: When do you think the organizing committee is going to release a schedule for the day?

23:37:42 [fantasai]

Jay: Need to coordinate with Japanese government and W3C

23:37:55 [fantasai]

Koji: SVGWG is also interested in participating in this forum

23:38:19 [fantasai]

Steve: They have their F2F the next week

23:38:39 [fantasai]

Steve: I think Chris favored having the workshop beforehand as well

23:39:09 [fantasai]

Steve: He also talked about having a joint SVG-CSS meeting

23:39:51 [fantasai]

Koji: Should be able to get back to everyone within 2-3 weeks

23:40:04 [fantasai]

Steve: Asap, so people can get airline tickets

23:41:16 [fantasai]

RESOLVED: Tokyo workshop tentatively scheduled 31st and 1st, 31st as Japanese-only, 1st also in English with CSSWG; CSSWG F2F moved to Thursday-Saturday June 2-4

23:41:48 [fantasai]

Topic: CSS3 Line Grid

23:41:55 [fantasai]

plinss: anything to discuss here?

23:42:20 [fantasai]

John: I don't think we should be discussing things where we don't have anything written down. I think that should be a prereq for discussing at an F2F

23:42:29 [fantasai]

jdaggett: I'm a little confused why we're talking about this as a separate spec

23:42:35 [fantasai]

jdaggett: This was in a previous CSS3 Text draft

23:42:49 [fantasai]

jdaggett: I think it's peculiar to be creating modules here

23:43:20 [philcupp]

philcupp has joined #css

23:43:30 [fantasai]

fantasai recaps history of CSS3 Text

23:43:46 [fantasai]

jdaggett: Given everything we have on our plate here, I think it's a little premature to work on a spec here

23:43:59 [fantasai]

jdaggett: Were there implementers on the CSSWG who wanted to implement this?

23:44:05 [fantasai]

Koji: Apple

23:44:26 [fantasai]

fantasai: We need 2 implementers to take on a module

23:44:38 [arno]

arno has joined #css

23:44:45 [fantasai]

Koji: CSS3 Text was born 12-13 yrs ago as International Text Layout spec from stuff at Microsoft

23:44:52 [szilles]

szilles has joined #css

23:45:07 [fantasai]

Koji: The Japanese portion of that spec was mostly written by me, brought from MS Word features

23:45:19 [fantasai]

Koji: Line grid one of the features Word implemented in 97 and tried to bring into IE

23:45:29 [fantasai]

Koji: Nobody has been showing much interest since IE

23:45:41 [fantasai]

Koji: Not sure what happend after, but it was decided to split up

23:45:55 [fantasai]

jdaggett: What needs to happen first is Apple need to say they're interested in this

23:46:04 [fantasai]

jdaggett: And then we can assess whether this is something we want to take on

23:46:11 [fantasai]

jdaggett: We have a very full charter

23:46:22 [fantasai]

jdaggett: Seems like something that should be starting after we finish CSS3 Text and CSS3 Writing Modes

23:46:26 [fantasai]

jdaggett: Talking about it now seems premature

23:46:46 [fantasai]

Alex: We started that set of specs in IE6 time to reflect what we had in IE and what we wanted to have in IE

23:47:21 [fantasai]

Alex: line-grid itself is largely driven by Japanese publishing but it is also line alignment that typography, in particular multicol, that is used in desktop publishing

23:47:27 [fantasai]

Alex: We are glad that somebody else is interested

23:47:34 [fantasai]

Alex: We had a hard time last 12 years in promoting this

23:47:49 [fantasai]

Alex: We should create a spec that a new implementer like us can agree on

23:48:00 [fantasai]

Alex: Not sure what we do if Apple goes to implement line grid without a spec

23:48:34 [fantasai]

jdaggett: If both Apple and Microsoft are interested, then we should have them write down what they're interested in implementing

23:48:47 [fantasai]

jdaggett: Let's have a written proposal that describes what they're interested in

23:49:25 [fantasai]

Simon: for the record, we weren't aware of this, so we need to talk with hyatt and find out more

23:49:33 [fantasai]

Koji: ...

23:49:37 [fantasai]

jdaggett: So we can talk about it then

23:49:46 [fantasai]

Alex: What do you propose for start making changes to the spec

23:49:59 [fantasai]

jdaggett: first, I think we should have a written proposal of what we want to take on,

23:50:15 [fantasai]

jdaggett: second, group reviews this and decides whether this is something we want to take on

23:50:32 [fantasai]

jdaggett: It's largely a matterof editor's time, but also discussions at F2F and telecons, so impacts groups time

23:50:40 [Bert]

s/Koji: .../Koji: I prioritice writing mode and text higher, but expect to get to line grid in a few months./

23:50:48 [fantasai]

Koji: It's not a new spec, it already exists in 2003 CR

23:51:05 [fantasai]

jdaggett: So point to the spec sections

23:51:22 [fantasai]

http://www.w3.org/TR/2003/CR-css3-text-20030514/#document-grid

23:51:34 [fantasai]

jdaggett: Do you want all of this?

23:52:34 [fantasai]

jdaggett: What is the exact set of features from that spec that you are talking about?

23:52:55 [fantasai]

Koji: My approach was to write an editor's draft and ask people for review

23:53:32 [fantasai]

jdaggett: Usually people write a rough draft of what they want

23:53:54 [fantasai]

Steve: I think there are two points going around here.

23:54:12 [fantasai]

Steve: One is, we get regularly beat up from W3CM about having too many irons in the fire and not finishing anything

23:54:26 [fantasai]

Steve: We did a priority review at the last charter, and concluded this was not at all a priority

23:54:37 [fantasai]

Steve: Since then priorities have changed, especially due to EPUB

23:54:45 [fantasai]

Steve: So one issue is what are we giving up to work on this

23:55:00 [fantasai]

Steve: Second is, if we are going to work on this, is how to go about doing it.

23:55:15 [fantasai]

Steve: Adobe and Microsoft both put proposals on the table to discuss

23:55:30 [fantasai]

Arron: You mean a proposal other than the current spec?

23:55:38 [fantasai]

Steve: Could just be updated copy of old spec

23:56:27 [fantasai]

jdaggett: I also think along with the proposal, an indication of what set of features implementers are interested in implementing from that proposal, is also important.

23:56:37 [fantasai]

jdaggett: My concern is that you and Elika are editors of the CSS3 Text spec

23:56:45 [fantasai]

jdaggett: And I don't see that as being stable, there's a lot of work remaining there.

23:57:03 [fantasai]

jdaggett: My concern is that we shouldn't be talking about priorities until we get through whatever has to happen for that

23:57:49 [fantasai]

Koji: So when the time arrives I should copy from 2003 CR and put on my own site?

23:58:07 [fantasai]

jdaggett: Just put it on dev.w3.org

23:58:18 [fantasai]

fantasai: I think that was all he was asking for.

23:58:33 [fantasai]

Bert: Putting it in the charter is a separate matter, but dev.w3.org is available.

23:58:59 [fantasai]

Topic: Compositing

23:59:11 [fantasai]

plinss: SVGWG has published Last Call of their Compositing spec.

23:59:24 [fantasai]

s/has/will/

23:59:27 [fantasai]

s/ed//

23:59:36 [fantasai]

plinss: They plan to set a 4-week LC period, until april 7

23:59:45 [fantasai]

plinss: They are asking us if that's sufficient time

23:59:47 [plinss_]

http://dev.w3.org/SVG/modules/compositing/master/

00:00:51 [fantasai]

plinss: Ok, nobody seems to be asking for more time.

00:01:10 [fantasai]

plinss: That's most of what we preplanned out for today. Also have the elephant in the room of CSS2.1 issues

00:01:21 [fantasai]

plinss: Daniel and I suggest tackling those

00:05:05 [myakura]

myakura has joined #css

00:19:58 [fantasai]

Topic: CSS2.1

00:20:07 [fantasai]

plinss: Plan for rest of day is to work on CSS2.1 issues.

00:20:27 [fantasai]

plinss: If people want to leave, feel free to leave. We are not working on anything else today.

00:20:28 [Kazutaka]

Kazutaka has joined #CSS

00:20:45 [fantasai]

plinss: One quick thing to discuss, over lunch we talked about keeping the editorial issues we don't want to deal with now

00:21:02 [fantasai]

plinss: but that we think are valid

00:21:24 [fantasai]

plinss: Several options are making a CSS2.1.1 or CSS2.1

00:21:31 [fantasai]

plinss: or slip them in between PR and REC

00:22:03 [fantasai]

plinss: Advantage is that we can tell people that we accept their issue just not right now and it will show up in a future revision

00:22:15 [fantasai]

Arron: My concern with the last one is that we accidentally introduce a substantive change.

00:22:24 [fantasai]

plinss: Other thoughts?

00:23:07 [mollydotcom]

this is to ensure that we can shelf 2.1 or does it still remain in limbo

00:23:13 [sgalineau]

sgalineau has joined #css

00:23:21 [johnjan]

johnjan has joined #css

00:23:34 [fantasai]

dbaron: So, it's somewhat dangerous from an editing perspective to branch if you're going to make substantial changes to both halves of a branch

00:23:45 [dbaron]

...and then want to merge them

00:24:02 [fantasai]

fantasai: I don't think the merge is going to be that difficult, because CSS2.1 has short lines and we aren't making that many changes at this point.

00:25:21 [fantasai]

plinss: So what are we going to do?

00:25:47 [fantasai]

fantasai: I don't care, as long as I have some place to put the edits so I never have to look at these emails again.

00:25:56 [mollydotcom]

hahaha

00:27:03 [plinss_]

http://wiki.csswg.org/spec/css2.1/anton-lc-2010

00:27:09 [fantasai]

dbaron: Should consider which branch is going to get served off the server, if you're going to branch

00:27:27 [mollydotcom]

it's been suggested from the design community to add an intermediary css2.1.1 or somesuch. I don't know if that helps or hurts us, but that's the general sentiment

00:28:09 [markus]

markus has joined #css

00:28:11 [fantasai]

plinss: I'm looking for resolution to accept the recommendations on the wiki page where Arron and fantasai analyzed Anton's comments.

00:29:04 [fantasai]

arron: Stuff we didn't have a no-change conclusion on has been filed in the wiki

00:29:09 [fantasai]

as issues

00:29:38 [mollydotcom]

mollydotcom has left #css

00:31:45 [johnjan]

looks like IRC may not be working.

00:32:44 [fantasai]

fantasai reviews the wiki doc

00:33:00 [johnjan]

ah... it is working. it's just very very quiet there.

00:38:43 [glazou]

johnjan: you're at the airport ?

00:38:55 [johnjan]

yeah

00:39:01 [glazou]

san jose ?

00:39:05 [johnjan]

yes

00:39:14 [glazou]

have a good trip !

00:39:25 [johnjan]

having a beer while the CSSWG discusses 2.1!

00:39:33 [glazou]

tss tss :-)

00:43:19 [fantasai]

CL3 could add a more explicit reference to other section, but there's a link already

00:50:24 [dbaron]

http://dbaron.org/css/test/2011/css21-issue-280 is a testcase for issue 280

00:54:06 [fantasai]

fantasai: I basically have three levels of suggestion: 1. Change now 2. Change in errata 3. Editorial for some undetermined future revision. (and of course 0. No change)

00:55:11 [TabAtkins_]

plinss_: First open issue is 179.

00:55:15 [TabAtkins_]

dbaron: Has an action to Bert.

00:55:20 [TabAtkins_]

dbaron: So what do we need to do?

00:55:27 [TabAtkins_]

plinss_: Do we need to make this change?

00:55:35 [TabAtkins_]

fantasai: Yes, it's currently wrong. It's an example, but it's wrong.

00:56:05 [TabAtkins_]

RESOLVED: Accept the edit for 179.

00:56:10 [TabAtkins_]

plinss_: Issue 225

00:57:39 [TabAtkins_]

dbaron: I don't understand "the top of the parent box" in this proposal.

00:58:05 [TabAtkins_]

dbaron: In the text he's quoting, the conditions for top and bottom are different, and I think they need to be.

00:58:11 [TabAtkins_]

arronei: I think the current text is fine, personally.

00:59:06 [TabAtkins_]

dbaron: This proposal looks like a substantive change.

00:59:09 [stearns_]

stearns_ has joined #css

01:00:56 [TabAtkins_]

dbaron: I don't understand why this is saying "top of the parent box" instead of using the same language for top and bottom in each list item.

01:01:00 [TabAtkins_]

dbaron: What's the parent box?

01:01:07 [TabAtkins_]

arronei: It should be the top border edge of ???

01:01:18 [TabAtkins_]

dbaron: If it has a previous sibling, the top of the parent isn't what you want.

01:01:51 [TabAtkins_]

dbaron: And a lot of this section is dealing with situations where the first child may be outside of the element's own height, because margins are collapsing through that first child.

01:03:20 [TabAtkins_]

dbaron: Anton is correct that the current spec is wrong.

01:04:18 [TabAtkins_]

dbaron: It was written at a time when we assumed there was no in-flow content that would inhibit margin collapsing ??? [maybe never mind, the text may be right]

01:05:20 [TabAtkins_]

dbaron: Never mind, I don't see anything that needs changing here. Certainly don't see what's wrong with the second sentence.

01:05:57 [TabAtkins_]

plinss_: So, do we think the spec is fine?

01:06:01 [TabAtkins_]

dbaron: Yeah, I think so.

01:06:09 [TabAtkins_]

RESOLVED: No change for issue 225.

01:06:38 [TabAtkins_]

plinss_: Issue 226

01:06:47 [TabAtkins_]

fantasai: I need to write text.

01:07:00 [TabAtkins_]

plinss_: Do we agree that this is a necessary change?

01:07:02 [TabAtkins_]

fantasai: Don't remember.

01:07:05 [johnjan]

http://wiki.csswg.org/spec/css2.1#issue-226

01:07:10 [TabAtkins_]

arronei: let's look at it and see.

01:09:27 [Jay]

Jay has joined #CSS

01:10:00 [TabAtkins_]

RESOLVED: 226 is editorial, deferred to CSS3. No change to CSS2.

01:10:03 [TabAtkins_]

plinss_: 229.

01:10:12 [TabAtkins_]

dbaron: This is a case where no impls match the spec, I think.

01:11:17 [fantasai]

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22border%3A%20solid%20magenta%22%3E%0A%20%20%3Cdiv%20style%3D%27float%3A%20left%3B%20border%3A%20solid%20green%3B%20%27%3EA%3C%2Fdiv%3E%20aaaa%0A%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22border%3A%20solid%20blue%3B%20margin%3A%20-2em%22%3E%0A%20%20%3Civ%20style%3D%22float%3A%20left%3B%20border%3A%20solid%20yellow%3B%20%22%3EB%3C%2Fdiv%3E%20bbbbbbb%0A%3C%2Fdiv%3E

01:11:54 [fantasai]

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22border%3A%20solid%20magenta%22%3E%0A%20%20%3Cdiv%20style%3D%27float%3A%20left%3B%20border%3A%20solid%20green%3B%20%27%3EA%3C%2Fdiv%3E%20aaaa%0A%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22border%3A%20solid%20blue%3B%20margin%3A%20-2em%22%3E%0A%20%20%3Civ%20style%3D%22float%3A%20left%3B%20border%3A%20solid%20yellow%3B%20%22%3EB%3C%2Fdiv%3E%20bbbbbbb%0A%3C%2Fdiv%3E

01:13:32 [TabAtkins_]

fantasai: The "aaa"s don't move to make room for the "bbbb".

01:13:47 [johnjan]

if the tests are right, looks like everyone is interop, but no one is compliant.

01:13:49 [TabAtkins_]

dbaron: If there's a float between two blocks, does the placeholder get wrapped?

01:14:29 [TabAtkins_]

fantasai: No, placeholders only get created for tables.

01:14:37 [TabAtkins_]

dbaron: But I thought we needed it for containing block?

01:14:57 [TabAtkins_]

dbaron: The reason the spec is wrong is the wording we used to work around the fact that the float's placeholder isn't in a block.

01:15:33 [fantasai]

fantasai: ????

01:16:09 [TabAtkins_]

dbaron: There is some wording about "the float can't be below the bottom of the previous block"

01:16:44 [TabAtkins_]

dbaron: Either the person who wrote that assumed that the previous block is clearly the lowest block, or they assumed that you should also check all the previous blocks, but no implementor picked up on that.

01:17:05 [TabAtkins_]

dbaron: In some ways the spec is maybe better, but we have no implementations of that, because nobody ever pointed out this issue before #229.

01:17:40 [TabAtkins_]

Bert: I wrote those rules 15 years ago, and I definitely didn't want floats to move up when their containing block moved up.

01:17:56 [TabAtkins_]

Bert: The intention was definitely to check for the lowest thing of *everything* that came before.

01:18:13 [TabAtkins_]

Bert: I imagined keeping a running track of what is currently the lowest element.

01:18:28 [TabAtkins_]

fantasai: I think most impls do that, but also move it up if you have a negative margin.

01:18:44 [TabAtkins_]

dbaron: We do the same thing for floats, we just don't do it for blocks. We track the to pof the last float.

01:20:39 [TabAtkins_]

dbaron: In rule 4, we already have this condition...

01:20:52 [TabAtkins_]

dbaron: It helps, because we already have the hypothetical that we need.

01:22:04 [TabAtkins_]

dbaron: [something about rule 5, strike the "block or"]

01:22:16 [TabAtkins_]

dbaron: And then in rule 6, you'd only count the linebox containing the float, and not lineboxes earlier than that one.

01:23:30 [TabAtkins_]

dbaron: [something about negative margins]

01:24:06 [TabAtkins_]

[unminuted discussion]

01:24:17 [TabAtkins_]

plinss_: I think at this point we should lean toward undefined.

01:24:25 [TabAtkins_]

fantasai: We can't undefine the whole floats section!

01:24:47 [TabAtkins_]

fantasai: And fixing this is probably about as much effort as carefully undefining just the behavior we're talking about.

01:25:59 [TabAtkins_]

arronei: I'm up for a note. We have no testcases.

01:27:04 [TabAtkins_]

fantasai: What are you going to do? Report that we resolved this by noting that the spec is in error?

01:27:49 [TabAtkins_]

plinss_: I like David's suggestion - the spec is correct. In the future we'll create a testcase to identify impl issues, and address them at that time (possibly with spec issues).

01:28:50 [TabAtkins_]

plinss_: If we can do this by simply saying the interaction with negative margins is undefined, that's fine too.

01:28:57 [TabAtkins_]

dbaron: I think that is making too much undefined.

01:31:10 [TabAtkins_]

dbaron: We deifnitely want to limit it to negative vertical marings in the containing block prior to that float.

01:31:23 [dbaron]

s/marings/margins/

01:31:53 [TabAtkins_]

plinss_: Objections?

01:31:58 [fantasai]

If, within the BFC, there is a negative margin such that it moves the float up from the position it would be at were the negative margin(s) set to zero,

01:32:01 [TabAtkins_]

arronei: I'm concerned there may be more interactions, but I'm okay.

01:32:10 [fantasai]

the position of the float is undefined

01:32:48 [johnjan]

agree with fantasai's proposal.

01:32:59 [johnjan]

that seems to describe interop behavior.

01:33:15 [fantasai]

If, within the BFC, there is a negative margin such that the floats position is above the position it would be at were all such negative margins set to zero, the position of hte float is undefined.

01:33:23 [TabAtkins_]

RESOLVED: Accept fantasai's edits for issue 229.

01:33:58 [TabAtkins_]

plinss_: Issue 239.

01:34:19 [johnjan]

http://lists.w3.org/Archives/Public/www-style/2010Oct/0750.html

01:35:12 [fantasai]

add "in-flow vertical" to margin above

01:35:18 [dbaron]

was 239 the right number? Issue is currently marked closed.

01:35:23 [dbaron]

johnjan, ^

01:36:28 [TabAtkins_]

plinss_: Issue 242.

01:36:29 [dbaron]

re-resolved to accept proposal for 241 in case we didn't accept it already

01:37:17 [johnjan]

checking my list

01:38:09 [johnjan]

239 is the correct issue. I didn't think we closed on Body propogating to HTML based on Alex's comments.

01:38:30 [johnjan]

if we did, then my mistake.

01:38:33 [Kazutaka0]

Kazutaka0 has joined #CSS

01:43:12 [TabAtkins_]

RESOLVED: Defer 273 to future version, editorial.

01:43:16 [TabAtkins_]

plinss_: issue 274.

01:43:31 [TabAtkins_]

fantasai: 274 is related to the earlier one we discussed.

01:44:00 [TabAtkins_]

plinss_: Did we undefine this one implicitly?

01:44:02 [TabAtkins_]

fantasai: No.

01:44:46 [TabAtkins_]

dbaron: [something about lineboxes next to floats]

01:46:45 [TabAtkins_]

dbaron: Lineboxes are not shortened by a float that occurs after them.

01:46:59 [dbaron]

which we could note can only occur under the undefined behavior we just added

01:47:10 [TabAtkins_]

RESOLVED: Accept dbaron's edit for 274.

01:47:14 [TabAtkins_]

plinss_: Issue 274.

01:47:21 [TabAtkins_]

plinss_: Issue 275

01:48:08 [TabAtkins_]

dbaron: This is saying that if you're in a 500px wide block, and you have a 490px wide float, and you're trying to place a word next to that float, which is more than 10px wide.

01:48:28 [TabAtkins_]

dbaron: It doesn't fit, so you push that linebox down until it's past the float, or there aren't any floats next to you and you just have an overflow.

01:48:53 [fantasai]

Bert: But do you move the line box, or do you move the word?

01:49:02 [fantasai]

Bert: and have empty line boxes all the way down?

01:49:19 [TabAtkins_]

dbaron: i remember discussing this in a meeting when tantek was on macIE.

01:49:40 [TabAtkins_]

dbaron: I think this was an intentional decision (to allow the gap to be a non-integral multiple of line-height)

01:49:57 [TabAtkins_]

dbaron: So the issue is that 9.4.2 says that lineboxes are stacked with no vertical separation.

01:50:09 [TabAtkins_]

dbaron: I'll say that 9.5 overrides 9.4.2 and we can just live with it.

01:50:23 [TabAtkins_]

dbaron: Or we can say in 9.4.2 "except as described in 9.5".

01:51:04 [TabAtkins_]

Bert: Kind of ugly, because it can mess up the vertical rhythm.

01:51:19 [TabAtkins_]

TabAtkins_: Many things can do that; we shouldn't worry about that until we have a spec that can solve it properly.

01:51:36 [TabAtkins_]

plinss_: So what's the resolution? Fix, or leave spec as it is?

01:52:53 [TabAtkins_]

plinss_: There are many places where one piece of prose overrides another. Let's just leave it.

01:52:57 [johnjan]

leave as is.

01:53:14 [johnjan]

note that 9.5 overrides 9.4.2

01:53:22 [johnjan]

on the list

01:53:50 [TabAtkins_]

RESOLVED: No change for issue 275.

01:55:21 [dbaron]

Bert: "(except as specified elsewhere)"

01:55:36 [dbaron]

RESOLVED: accept Bert's proposal for 275.

01:56:08 [TabAtkins_]

plinss_: Issue 276

01:56:44 [TabAtkins_]

dbaron: I'm okay with the proposal.

01:56:55 [TabAtkins_]

fantasai: It's in CSS Selectors, though it's not better defined there.

01:57:07 [johnjan]

that's OK, selectors has time to get it right.

01:57:14 [TabAtkins_]

fantasai: I think we should add a note that the precise behavior is undefined, and may be defined in a future version.

01:57:19 [dbaron]

johnjan, not really, since it's ahead of 2.1...

01:57:41 [johnjan]

good point...

01:57:56 [TabAtkins_]

RESOLVED: Note that :first-letter, :first-line are undefined, to resolve issue 276.

01:58:42 [TabAtkins_]

plinss_: Issue 277.

01:58:58 [TabAtkins_]

arronei: This is a terminology issue. We should get it right, but it's editorial.

01:59:07 [TabAtkins_]

dbaron: Though it affects DOM APIs...

01:59:33 [dbaron]

I was just correcting "may confuse conversations" to "may or may have confused conversations or DOM APIs"

01:59:39 [dbaron]

since CSSOM misuses declaration

02:04:50 [bradk]

A rule set (also called "rule") consists of a selector followed by a set of rules (also called "declaration blocks").

02:04:52 [TabAtkins_]

RESOLVED: Defer issue 276 for errata.

02:05:10 [johnjan]

277, right?

02:05:36 [tantek]

tantek has joined #css

02:05:54 [plinss_]

s/276/277/

02:05:55 [plinss_]

right

02:06:31 [TabAtkins_]

plinss_: Issue 278.

02:06:45 [TabAtkins_]

dbaron: This is saying we should exlicitly say "margin box" to be clearer? Seems good.

02:06:49 [dbaron]

RESOLVED: accept proposal for 278

02:06:50 [TabAtkins_]

RESOLVED: Accept edit for 278.

02:06:58 [TabAtkins_]

plinss_: Issue 279.

02:08:06 [johnjan]

http://lists.w3.org/Archives/Public/www-style/2010Sep/0130.html

02:09:51 [TabAtkins_]

RESOLVED: Accept edit for 279.

02:09:54 [TabAtkins_]

plinss_: Issue 280.

02:10:06 [TabAtkins_]

dbaron: I believe 280 is an error in the spec, where the impls got it right and the spec is wrong.

02:10:11 [dbaron]

http://dbaron.org/css/test/2011/css21-issue-280

02:10:59 [TabAtkins_]

dbaron: The question is whether fuschia starts within or below the purple box.

02:11:03 [TabAtkins_]

fantasai: We have full interop.

02:11:08 [TabAtkins_]

dbaron: ...which disagrees with the spec.

02:11:20 [TabAtkins_]

dbaron: I think the problem is that the spec can be taken more literally than intended.

02:11:38 [TabAtkins_]

dbaron: The spec says that [omg rule 3].

02:11:59 [TabAtkins_]

dbaron: But this neglects the possibility that the right-floating box may be at the same vertical postion as the left float, but be entirely to its left.

02:12:08 [TabAtkins_]

dbaron: Which is this testcase.

02:13:17 [TabAtkins_]

dbaron: The change is to make the spec say "when they overlap in vertical position".

02:13:25 [TabAtkins_]

dbaron: But the spec literally says something wider.

02:13:31 [fantasai]

s/wider/to the right/

02:14:24 [fantasai]

dbaron: so the implementations implemented what Bert meant to say, and Anton has noticed that this is not what was actually said

02:14:30 [TabAtkins_]

dbaron: "next to it" works.

02:14:45 [dbaron]

Bert proposed "next to it"

02:15:04 [TabAtkins_]

RESOLVED: Change "to the right of it" into "next to it".

02:15:09 [TabAtkins_]

glazou: Issue 281.

02:15:41 [johnjan]

no change necessary for 2.1 here.... errata

02:16:00 [TabAtkins_]

fantasai: I think we should fix this. It's just wrong.

02:16:25 [TabAtkins_]

dbaron: You could change it to "not a position derived from the line-height".

02:16:37 [dbaron]

maybe change "not the 'line-height'" to "not a position derived from the 'line-height'"

02:17:00 [dbaron]

fantasai: or just replace the clause with "and has nothing to do with the 'line-height'"

02:18:07 [TabAtkins_]

RESOLVED: Accept fantasai's edit for 281.

02:18:12 [johnjan]

I can buy that

02:19:09 [fantasai]

Meeting closed.

02:19:17 [Bert]

Still not on the plane, johnjan?

02:20:49 [RRSAgent]

I have made the request to generate http://www.w3.org/2011/03/08-css-minutes.html Bert

02:21:01 [Bert]

Meeting: CSS ftf day 2

02:21:13 [Bert]

Chair: Peter/Daniel

02:21:34 [RRSAgent]

I have made the request to generate http://www.w3.org/2011/03/08-css-minutes.html Bert

02:24:51 [dsinger]

dsinger has joined #css

02:33:52 [jdaggett]

jdaggett has joined #css

04:13:40 [glazou]

glazou has joined #css

04:19:10 [TabAtkins_]

TabAtkins_ has joined #css

04:35:01 [plinss_]

plinss_ has joined #css

04:46:46 [Arron]

Arron has joined #css

04:53:59 [plinss_]

plinss_ has joined #css

05:03:53 [mmielke]

mmielke has joined #css

05:28:31 [plinss_]

plinss_ has joined #css

05:57:31 [plinss_]

plinss_ has joined #css

06:20:57 [plinss_]

plinss_ has joined #css

06:55:11 [kennyluck]

kennyluck has joined #CSS

07:17:21 [plinss_]

plinss_ has joined #css

07:37:13 [philcupp]

philcupp has joined #css

07:38:28 [Xaxio]

Xaxio has joined #css

08:19:39 [TabAtkins_]

TabAtkins_ has joined #css

08:38:24 [shepazu]

shepazu has joined #css

08:50:46 [TabAtkins_]

TabAtkins_ has joined #css

08:53:26 [plinss_]

plinss_ has joined #css

08:58:17 [Ms2ger]

Ms2ger has joined #css

09:09:59 [homata]

homata has joined #CSS

11:12:03 [arronei]

arronei has joined #CSS

11:50:55 [myakura]

myakura has joined #css

11:57:35 [anne]

anne has joined #css

13:26:08 [jdaggett]

jdaggett has joined #css

14:24:09 [philcupp]

philcupp has joined #css

15:13:59 [plinss_]

plinss_ has joined #css

15:26:48 [plinss_]

plinss_ has joined #css

15:48:55 [plinss_]

plinss_ has joined #css

16:06:08 [Martijnc]

Martijnc has joined #css

16:11:42 [dsinger_]

dsinger_ has joined #css

16:45:35 [dbaron]

dbaron has joined #css

16:50:46 [dsinger]

dsinger has joined #css

16:54:50 [Arron]

Arron has joined #css

16:55:51 [stearns]

stearns has joined #css

16:57:09 [stearns]

Does the F2F pre-empt the weekly conference call, or should I hop on the phone?

16:58:25 [plinss_]

plinss_ has joined #css

17:01:42 [shonda]

shonda has joined #css

17:01:47 [jdaggett]

jdaggett has joined #css

17:02:43 [dbaron]

dbaron has joined #css

17:02:51 [anne]

stearns, dsinger, it pre-empts

17:02:52 [glazou]

glazou has joined #css

17:03:35 [shan]

shan has joined #css

17:06:00 [cslye]

cslye has joined #css

17:06:49 [dbaron]

RRSAgent, make logs public

17:06:56 [RRSAgent]

I see no action items