W3C home > Mailing lists > Public > www-style@w3.org > March 2011

[CSSWG] Minutes and Resolutions F2F Mountain View March 2011 Day 2: Layout specs, Tokyo Workshop, CSS2.1

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 13 Mar 2011 13:18:27 -0700
Message-ID: <4D7D2693.5010209@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

Summary:

   - Reviewed Adobe's CSS Regions proposal for threaded regions and exclusions
       http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0011/CSS_Regions.pdf
     Many interesting ideas were presented and many good comments and suggestions
     made.

   - Reviewed Microsoft's CSS Grid Layout proposal, which incorporates most
     feedback from the last F2F.
   - RESOLVED: Publish Microsoft's proposal as css-grid-layout, i.e. CSS Grid
     Layout
   - Reviewed Tab's changes to Flexbox draft
   - RESOLVED: Publish updated draft of css3-flexbox
   - RESOLVED: Publish updated CR of css3-multicol
   - Discussed various issues with managing the test suites, particularly
     expanding to handle CSS3, especially CSS3 Multi-Column Layout.
   - RESOLVED: Use Bugzilla (instead of mailing list) for test suite bugs:
               one bug report per test unless there's a good reason not to.
   - 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.
   - Discussed line grid spec; Koji to write editor's draft after CSS3 Text
     and CSS3 Writing Modes winds down.
   - SVGWG will publish LCWD of their Compositing spec very soon.
   - RESOLVED: For CSS2.1 Issue 179, accept edit.
               http://wiki.csswg.org/spec/css2.1#issue-179
   - RESOLVED: For CSS2.1 Issue 225, no change.
               http://wiki.csswg.org/spec/css2.1#issue-225
   - RESOLVED: For CSS2.1 Issue 226, editorial deferred to CSS3.
               http://wiki.csswg.org/spec/css2.1#issue-226
   - RESOLVED: For CSS2.1 Issue 229, make situation undefined.
               http://wiki.csswg.org/spec/css2.1#issue-229
   - RESOLVED: For CSS2.1 Issue 273, editorial deferred to future version.
               http://wiki.csswg.org/spec/css2.1#issue-273
   - RESOLVED: For CSS2.1 Issue 274, accept dbaron's proposal.
               http://wiki.csswg.org/spec/css2.1#issue-274
   - RESOLVED: For CSS2.1 Issue 275, accept Bert's proposal.
               http://wiki.csswg.org/spec/css2.1#issue-275
   - RESOLVED: For CSS2.1 Issue 276, note that precise behavior of
               :first-letter, :first-line is not defined, may be defined
               in a future spec.
               http://wiki.csswg.org/spec/css2.1#issue-276
   - RESOLVED: For CSS2.1 Issue 277, deferred to errata.
               http://wiki.csswg.org/spec/css2.1#issue-277
   - RESOLVED: For CSS2.1 Issue 278, say "margin box of float"
               http://wiki.csswg.org/spec/css2.1#issue-278
   - RESOLVED: For CSS2.1 Issue 279, accept edit.
               http://wiki.csswg.org/spec/css2.1#issue-279
   - RESOLVED: For CSS2.1 Issue 280, change "to the right of it" to "next to it".
               http://wiki.csswg.org/spec/css2.1#issue-280
   - RESOLVED: For CSS2.1 Issue 281, accept fantasai's proposal.
               http://wiki.csswg.org/spec/css2.1#issue-281

====== Full minutes below ======

<RRSAgent> logging to http://www.w3.org/2011/03/08-css-irc
http://krijnhoetmer.nl/irc-logs/css/20110308
http://krijnhoetmer.nl/irc-logs/css/20110309

Scribe: fantasai

Agenda
------

   Steve: Request toput tokyo workshop dates today
   howcome: multicol today
   glazou: module template tomorrow
   glazou: pull tokyo dates and multicol for today, keep rest for tomorrow
   glazou: Start with Adobe's proposal

Adobe's Regions Proposal
------------------------

   CSS Regions draft
   -> http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0011/CSS_Regions.pdf
   Arno: I'd like to talk to you a little bit about things we work on
         we're calling CSS "Regions"
   arno: Would like your feedback on whether it's interesting, going in
         an interesting direction, etc.
   arno: It started by us talking to our customers, especially print
         customers using InDesign to do fancy layouts
   arno: e.g. Conde Nast
   arno: They want to bring the experience ppl have on paper into digital media
   arno: We started experimenting, and some of those magazines are already
         available on the iPad
   arno: We very quickly ran into some limitations
   arno:  e.g. Wired has very complex layouts
   arno: We tried using various technologies to represent those layouts
   arno: But in this version we had to use images to represent each page
   arno: It's a lot of work, since the designers have to do layouts twice once
         for layout and portrait
   arno: With different device aspect ratios, it's even more work
   arno: Not a good solution
   arno: Not the case for everyone -- some customers have very simple layouts,
         close to templates, can use HTML to represent their ocntent
   arno: which has lots of benefits
   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
   arno: You have very sophisticated layout of text, interaction of graphics
         and text
   arno shows pages with text flowing around contoured images, fitted to
        shaped regions
   arno: We want to be able to find ways to represent these sophisticated
         layouts in HTML and CSS
   arno: We studied these and came up with a proposal tha we think solves
         the problems.
   arno: We wanted to make sure what we were thinking about was implementable
   arno: So we started investigating implementing it
   arno: Btw, another use case is of course printing, which would benefit
         from sophisticated layouts
   arno: We started experimenting with WebKit
   arno: I'm going to show you some screenshots of some things, and then
         also live demos

   arno: Starting with very simple and basic things, it's columns
   arno shows a 3-col layout
   arno: You can do this with multicol
   arno: You have some fairly simple markup -- three divs and a heading
   The <div>s are labeled region1 through region3.
   Prior to that there's another div called article-content, which includes
     a heading and then the flow content (paragraphs).
   The regions are styled to be boxes floating side by side.
   article-content is assigned a "flow-thread: main;"
   The region3 divs are assigned "display: region; region-thread: main;"
   howcome: Those region elements are only there to give the layout
   Simon: What happens to the content of the region elements?
   jdaggett: It would be better to not put the layout structure as markup
             in the document.
   arno: Next example, we add an image sitting on top of the two first columns
   arno: You adjust the two columns to shorten them, and then place the image
   glazou: You cannot make content flow from one region to another, right?
   arno: correct
   * fantasai is confused about that, wasn't that the point?
   jdaggett: I'm wondering if you looked at some of the other proposals..
   plinss: This is not the interesting case. This is a very basic case.
   * Ms2ger is concerned about the number of layout specs
   jdaggett: But I think this is added semantics on top of one of the other
             layout approaches
   arno: One of the things you can do is to specify the order in which
         content flows
   arno: you do this by specifying region-index: <integer> on the region
         elements
   arno: Since the divs are just divs, you can also do more sophisticated
         things like applying transforms.

   arno: Another thing we've been talking about are exclusions
   arno: Which is saying "I want the text to avoid these areas"
   arno: So you can have images that encroach on the text
   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
   <dbaron> ...could also use alpha area of image
   jdaggett: SVG path or mask would make more sense
   fantasai: There was a proposal from Bert for doing this by adding a
             single keyword to float.
   <fantasai> http://www.w3.org/blog/CSS/2007/07/03/rotations_and_non_rectangular_floats
   arno: also want to specify geometric shapes even if there's no image
   arno: You also want to do this for e.g. a circular pull-quote
   <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)
   <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)
   <dbaron> [discussion of margin around the alpha shape]
   <Bert> (The "margin" around non-rect images in the contour idea is given
           by areas that are almost transparent, say 99%)
   <howcome> http://www.w3.org/TR/WD-layout

   arno: we just started with the coordinates since that was simple to
         implement and could do everything
   discussion of float intrusions that break a line in half
   plinss: We have a convention, starting with clip property, of using
           functional notation with shape e.g. rect(...)
   plinss: That would let you have different shapes
   plinss: more easily
   plinss: The other thing is you have a property linking from one to the other
   plinss: to define the exclusion
   plinss: What is the coordinates relative to?
   alex: What defines the tightwrap, content wants to tightwrap, or shape
         wants everything to wrap around it?
   alex: In CSS1, it was float requesting wrapping
   alex: So you could have a boolean, wrap around stuff, or don't wrap
         around stuff.
   alex: if you want to control, e.g. this bfc doesn't avoid floats, or
         this non-bfc avoids floats
   discussion of bfcs
   Steve: Think of the part that intrudes as being part of the bfc
   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
   alex: But that's a special case. overflow: hidden; it's totally reasonable
         to wrap around
   arno show s an example of columned text flowing around the coyote
   arno shows a page layout that uses this as a component

   arno pulls up a live demo
   arno: Here's the example with columns that have been transformed to be
         crooked
   arno edits the contenteditable content: the content flows from one column
        to the other
   plinss: What about property inheritance?
   plinss: Does content flowing into a region inherit from the region or
           its element tree parent?
   Steve: There is a desire to allow inheritance from regions (in its
          equivalent model)
   Steve: We have a special function, like inherit-from-region, that does that
   Steve: What's there doesn't quite match CSS's model
   plinss: I looked at that and couldn't figure out how it works
   Steve: This would be similar to the way ::first-line works
   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
   fantasai: If you go down this route, people will want to go in that direction
   ...

   howcome: Have you shipped content with this?
   arno: No, just experimental
   howcome asks about resizing and reflow
   howcome: With multicol, you'd add a third column as the page gets wider
   howcome: what would you do here? is it tied only to two columns?
   Steve: This is with fixed regions, each explicitly specified.
   Steve: It needs to be adapted to work with multicol, flexbox, grid layout,
          etc.
   Steve: The key concept is the threads
   Steve: and the concept of exclusions
   jdaggett: So what you're saying is not the syntax that's important, but
             those two concepts that are important.
   Steve: Yes. There's still some work to do to make this fit into CSS well
   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
   <dbaron> maybe the 'content' property would work?
   <dbaron> e.g., content: flow(main), or content: flow(main, 2) to give
           indices
   plinss: In most cases, you want to use the other layout systems you have,
           and just have content flow differently through it
   Phil: What happens if you run out of content?
   <fantasai> or too much
   arno: It's a good question.
   fantasai: The other thing is that the regions shouldn't be empty elements
             in the document, they should be separate. So you don't have to
             build the layout into the document content
   Bert: CÚsar and I worked on some of this flow threading with his studies
         on the Template module
   Bert: One thing that became clear was that you need a baseline grid, so
         that the lines are consistently placed
   <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
   <stearns> need a baseline grid for content today (even if it's not all
             part of the same flow)
   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
   Bert: So you wouldn't split the content into two columns
   glazou: You want to be able to flow text inside, e.g. a bowl
   fantasai: You're talking about two different things.
   glazou clarifies by drawing a picture of a bowl intruding into text
   11|222|33
   44\555/66
   777---888
   arno's example doesn't actually allow a line to be split by the float
     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
   glazou's example intrudes into the text splitting the line into multiple
     pieces
   <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)
   * fantasai thinks Bert should put that on dev.w3.org
   * Ms2ger agrees with fantasai

   <hyatt> extend the slot concept from css3 template layout to allow for the
           specification of positioned slots
   <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)

   howcome: So what happens today if you have too much content for the regions?
   arno: It will not display
   smfr: What if you put overflow: scroll on the last region?
   Tab: Could think of this as a kind of overflow mode
   Tab: Would clarify what overflow: scroll means on the first region -- nothing
   * fantasai reads hyatts comments aloud
   peterl: (responding to hyatt's first comment) I'd actually like to see the
           other way - this replacing template's slot concept.
   <hyatt> div { positioned-slots: sidebar, masthead, body; }
           ::slot(sidebar) { position: absolute; left:100px; top:100px;
                             box-shape: <some path>; }
   howcome: We need to make sure this wokrs in a reusable way for longer
            articles, for printing
   <hyatt> css3 template layout supports per-page templates too
   peterl: I'd like to be able to define regions in an @page rule.
   Bert talks about his attempt to extend slots concept in template-layout
   <Bert> (Extend in the sense of automatic repeating the same layout
          template if there is more room, without need for media queries.)
   <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

   glazou: Do you want to standardize this in CSSWG?
   arno: If you're interested in this, yes.
   jdaggett: Before we get to the stage of these guys spending time putting
             together a proposal
   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
   jdaggett: The cases you're trying to solve are valid, but the syntax
             you're doing it with is grotty
   smfr: I agree, we should avoid adding another module and try to work this
         into e.g. Template Layout
   <stearns> linked regions might make sense in Template, but would exclusions?
   * fantasai thinks we need a Floats module
   howcome: We can't keep adding more and more advanced layout systems.
            We should try to merge them

   Steve: There are several key concepts here. One is the threading concept,
          which would fit well in many of our layout specs
   Steve: The other key piece is the exclusion piece, which is separate but
           also important
   dbaron: We could use 'content' property to assign content to a flow,
           e.g. with a flow() function
   Steve: That's a pull model, this is a push model.
   Steve: The third approach is to define a mapping between the twol.
   Steve: Those are 3 different ways of looking at the problem.
   Steve: Layout and grid are using a push model.
   Steve: I agree you could use a pull model as well
   Bert: There's a pull model in the cross-references in GCPM

   <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)
   <hyatt> the concept of flow across containers should IMO be limited to
           anonymous models (multicol, template layout)
   <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
   <hyatt> e.g,. establish a stacking context, then your internal stuff doesn't propagate out
   <hyatt> auto z-inxex it does, etc.

   Bert points to hyatt's comment above
   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
   Steve: That was in the proposal, too, arno just didn't mention it
   Steve: Classic example of pushing content into an external region that only
          shows up when needed is footnotes.
   Tab likes hyatt's comments and strongly agrees with using anonymous boxes
       instead of real elements to define the regions
   Tab: You can tell the region to only exist if it has content inside of it.

   <hyatt> @page { positioned-slots: header, sidebar, body(col1, col2)
             ::slot(col1) { ... }
             ::slot(col2) { ... }
           }
   <hyatt> 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

   glazou: Another way of specifying exclusions, used many years ago, is like
           background image
   glazou: You position the image and it defines an exclusion
   Tab says something that I didn't quite follow....
   ...
   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.
   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?
   glazou: If we run into that, people are going to base layouts in CSS, so it
           needs to be compatible with desktop software
   Steve: FYI, glazou writes an editor
   glazou: Need to allow round-tripping
   arno: For us the key thing is to have the expressiveness. We are willing to
         take the cost on the tooling side.
   arno: round-tripping is a good point to bring up, though
   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
   arno: want for an author to be able to us the tools, but more importantly
         the concepts they are used to

   <glazou> all applause Arno's pres and demo
   <arno1> Thanks everyone for the great feedback!

Grid Layout Proposal
--------------------

   <smfr> http://dev.w3.org/csswg/css3-grid-align/
   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
   alex: Doesn't necessarily mean we have the final overall picture
   alex: We're trying to be inclusive here, we wanted to produce a version of
         how it might work with the feedback
   alex: We're getting to the shape where we can think about how it integrates
         with other specs, e.g. merge with Template Layout
   alex: If there something we didn't get here, doesn't make sense to have
         there, let's discuss
   Markus: Our main goal was to address the feedback from the last F2F, align
           with Template Layout, figure out integration
   Markus: Also think more about print layout and lines

   Phil: Hi, my name is Phil and I'm from Microsoft, and I'm one of the editors
         on the CSS Grid specification
   Phil: Recap of feedback was to think in lines, not just thinking in rows
         and columns
   Phil: also think about naming lines to simplify maintenance so you don't
         have to renumber when you change things
   Phil: We also thought about naming regions of space.
   Phil: Template Layout does this, so we looked into incorporating that idea
   Phil: Also thought about ::slot() pseudo and putting multiple elements into
         a slot
   Phil: [...] a default slot
   Phil: I'll start by just walking through this and summarizing.

   Phil: Grid is not a table. Can do things tables can't do, e.g. hav cells
         overlap
   Phil: It's similar positioning in that regard; can be considered an alternate
         grid system for positioning
   Phil: We think people will use grid to do page layouts, form layouts, etc.
   Phil: We want layouts to be able to adapt to available space
   Phil: So we have some concepts
   Phil: auto sizing to the size of the content
   Phil: min/max functions
   Phil: fractional units, allocating remaining space
   Phil: You declare a grid by setting its display to grid

   Phil shows Example 1
   Phil: Declare a grid with "display: grid", set grid columns and rows,
         position to grid
   Phil moves to next section
   Phil shows template layout in grid
   Phil: assign into template regions with 'grid-cell' property
   Phil: We're not using the position property here
   Phil shows slider control example
   Phil: In this example we're using an alternative syntax that names the grid
         lines

   Phil: To name a grid line, you just specify a string before the measurement
   Phil: You can assign starting and ending lines to an element to position it
         in the grid
   Phil: There are tracks, lines, and cells in the grid model
   Phil: Tracks are the columns and rows of the grids
   Phil: grid-columns: 150px 1fr; creates two columns, a 150px column and a
         remaining space column
   Phil: This gives us 3 lines
   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)
   Phil: in new spec you can define those cells explicitly
   ...
   Phil: grid-cell pseudo
   Phil: In template module you would define of the grid-cell with the
         template string
   Phil: Here you can create a grid-cell
   Phil: by using the grid-cell pseudo element, and giving it positions
   Phil: e.g. #grid::grid-cell("cell") { grid-column: .. ; grid-row: ...; }
   Phil: This creates a named cell, that you can then assign into just like
         you can assing into template-created named cells
   dbaron: maybe split this example using markup instead of a comment, it's
           not clear they are two different approaches to the same thing
   Steve: So you wanted to create a cell on the grid-line structure using
          pseudo-element
   sylvaing: That's similar to what hyatt proposed earlier, with the
             ::slot() syntax creating a flow target
   Brad: Can you assign other properties to a grid cell?
   Phil: Some, but mostly positioning stuff
   Tab: If you have a slot created by the template property, can you
        reposition it using grid-rows and grid-columns?
   Tab: I would prefer "no" :)
   Tab: I would not want a designer to be confused about their slot moving
        around because a later definition moved it
   plinss: I would prefer the cells to be defined where the template is defined.
   Markus: You could do that too
   plinss: I would prefer to have the template declaration to also include a
           list of defined cells
   plinss: You could then use ::grid-cell() to style the slot
   Phil: That starts making the template declaration really long and
         complicated.
   Phil: I like breaking it up into bite-sized chunks
   plinss: As a designer, I'd think of the template as a single thing. Don't
           like breaking it out like this.
   fantasai: You could use an @rule to put all the pieces together and give
             it a name @template mylayout { .... }

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

   plinss: I don't like the template ASCII art thing.
   various people object and declare their love for the ASCII art thing
   plinss: I think it's very 80s and very constrained and very silly
   Markus: I was exactly in your camp when I first looked at it. We want to
           make it cleaner, more industrial strength, etc.
   Markus: But then we started to try building something a little more
          complex with it
   Markus: But as you start to have more complex grid structures, the ASCII
           art structure very easily and clearly represents those layouts
   Markus: The problem is that it's not industrial strength. You run out of
           characters
   howcome: Can we get some from the Chinese? :)
   Markus: You have the power of both.
   Phil: grid cells is a superset of template since you can do overlapping cells
   * hober never wants to see slots named U+1F4A9 in ascii art
   plinss:  What happens if the "d"s in a template don't form rectangles?
   Tab: You can't do that
   Tab: They have to be rectangles
   plinss: I have to draw rectangles in ASCII art?
   glazou: It's ugly
   Tab: As someone who edits CSS in a plaintext editor, I love this.
   glazou: My goal is to make CSS editable without a text editor.
   glazou: Without knowing about CSS.
   Tab: It is really easy to create a UI for the ASCII art.
   Markus: We are open to either way.
   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
   Steve: and that you cand round-trip between the two
   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
   Steve: yes
   Steve: that satisfies my requirements
   <Bert> (The "ASCII art" was inspired by proprietary WYSIWYG template
          editors used by two mobile companies; although their output
          was HTML tables, not CSS.)
   <Bert> (Cesar has a WYSIWYG editor for templates themselves, made by a student.)

   Steve: talks about assinging multiple inlines into a single slot
   Phil: I wasn't too clear on that point
   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?
   Bert: That was the intention, yes
   something about overlapping
   Tab: You could create multiple slots in the same place
   Alex: Not sure you want to mix unrelated content from various pieces of
         the dom into a single flow
   Bert: run-in has a similar problem, taking an element out of here and
         putting it there where it has to be reflowed
   fantasai: run-in has other problems...
   Steve: You're just creating a shadow element that's the combination of
          all the things you're flowing into the slot
   Steve: and then you flow that
   Alex: Yes, it's possible, but it becomes more complicated
   Alex: If you really need it we could do it
   Steve: The example from the spec is footnotes
   Phil: Ok, let's note that and move on.

   Phil: You declare a grid using the display property -- could be inline
         or block
   Phil: We have a definition of grid items
   Phil: You can put inline-blocks, block-level elements, various other items
   Phil: These are wrapped in an anonymous block
   Tab: We have more precise terminology for this stuff
   <fantasai> (probably should look at 9.2 etc.)
   Phil: You can name lines, or not name lines. They have an implicit name
         which is a number
   Steve: Do you use direction and writing mode to determine these?
   Phil: Yes

   Phil: I can put names by putting strings before the grid measurements.
   Phil: I can put multiple names before a measurement, that gives it aliases
   Phil: depending on your naming convention, this might be convenient
   Phil: You specify a start and end line
   Phil: There are also start and end lines predefined, which are keywords
         rather than strings.
   glazou: I don't like that. A lot of authors are going to use the terms
           start and end
   Phil: Not a syntactic conflict. There might be mental conflict. I've
         heard that several times...
   fantasai: Can you count the numbers from the end rather than from the
             beginning?
   Steve: e.g., if you allow negatives to count from end, 1 to -1 would be
          start to end

   Phil: We also introduced syntax we borrowed from grid spec for repeating
         rows or columns patterns
   Phil: You might want, e.g. a content space and a gutter, content space,
         gutter.
   Phil: We have a concept of repeating patterns for that
   Phil: You can name the pattern, that applies to the first line in the pattern
   Phil: This is useful for noting the start of the repeating run.
   Phil: grid-columns: 10px ("content" 250px 10px)[4];
   Steve: If I have this repeating pattern, and I shrink the window size,
          is there a way to drop columns?
   Phil: Not in this spec. Although we have a concept of automatic columns
         and rows.
   Alex: With grid positioning, repeat meant repeat this combination until
         you run out of space.
   Phil: That's something you could add.
   Steve: There's an interesting interaction between fractional space and
          that concept
   Alex: Yeah, you can't combine them.
   Alex: I think we resolved them to zero or something.
   Tab: You could have repeating pattern, and fractional space on either side.
   Tab: I think that's the only case it would make sense.
   Alex: You could repeat fractions, but you'd wnat to resolve those first
         before repeating them.
   Steve: You want an integral number of columns, use flex space algo to
          adjust columns or gaps as specified
   <hober> repeat("content" 250px 10px, 4)
   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, e.g. repeat(). Also more clear what
             it's doing.

   Phil: We have some different sizing functions for tracks
   Phil: Lengths, percentages resolved against grid element size
   Phil: Fractional values, which are resolved against the remaining space
         proportional to the number (relative to total of fractional values)
   Phil: max-content, min-content keywords
   Phil: fit-content
   Phil: minmax() defines a size range
   Phil: auto keyword is equivalent to fit-content
   Phil: Any questions on these?
   Simon: Did you consider a comma-separated syntax?
   Phil: We played with various syntaxes, but tried to avoid adding
         unnecessary characters
   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.
   Steve: good point
   simon is concerned about readability with multiple names
   fantasai: You could use line breaks, since it's space-separated,
             which let's you break wherever you (the author) think makes sense.

   Steve asks about flex vs fractional notation
   Alex: Aiming to get flex and grid to have same sizing capabilities
   Steve: My impression was that it's easier to use flex.
   Steve: To get an equivalent mapping, it takes several nested minmax()
          functions
   Steve: A 5-tuple as a set of constraints is simple
   Tab: Let's talk about that [later]
   Phil: Just a note on how values are computed.
   Phil: You might have the same name appear multiple times in the grid value ...
   * scribe isn't getting this

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

   Phil talks about used value serialization
   CSSOM results
   glazou: Computed Value is extremely painful to parse
   Simon: What's the alternative?
   glazou: parsing the repeat notation is problematic
   Simon: Thinking about gradients, how could that have been better?
   glazou: For gradients need a better CSSOM
   glazou: Think about users of getComputedStyle, expand everything
   Phil: We wanted to be able to re-assign the value back into the OM and
         get the same result
   Phil explains a complicated example
   dbaron: I think it's important that it be round-trippable
   dbaron: I think expanding it beyond what it was is causing it to be
           non-round-trippable.
   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

   Phil: The grid-column and grid-row properites are used for positioning
         children of the grid
   Phil shows the syntax propdef tables
   Phil: If you don't specify ? you get an implicit end line
   Phil: We said that items are placed in a cell.
   Phil: That doesn't necessarily mean the element stretches to fill the cell
   Phil: The cell is just a containing block
   Phil: There's also the concept of explicitly defining the grid cells,
         which we covered before
   Phil: with that name you can place more than one item into a cell
   Steve: What do you mean by placing more than one item into a cell?

   Phil: The default behavior is for these items to stack, one after
         the other in a flow
   Phil: whereas positioning them makes them overlap
   Steve: That seems a little subtle
   Phil: There's a property to control this, grid-cell-stacking
   Phil: You can have things stack in rows or columns directions, or layer them
   Phil: Perhaps the initial value here should be layer for ocnsistency
   Steve: That would be better
   Simon: [...]
   Phil: We intend that they are block-level or inline-block elements.
   Phil: if they are valid grid items
   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
   Phil: There's a row alignment and a column alignment
   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
   Phil: relationship between that and stacking items in a grid cell
   Phil: default is to stretch
   Phil: so it stretches to occupy the whole cell
   Phil: But if you're stacking, the elements will size shrink-to-fit so you
         can put one on top of the other
   Phil explains something more about sizing, several people look confused
   Phil talks too fast to minute.

   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
   Phil: No flex, but yes similar
   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.
   Phil scans through sections of the draft defining the various properites
   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.
   Phil: We should make it clear that an ending line has priority over a span.
   Phil: We left in grid-row-span, grid-column-span, because we liked that
         ability more

   Phil: There's a concept of implicit columns or rows
   Phil: You create auto tracks as needed
   Phil: There's a property to control what size track gets created, so that
         they're not always auto-sized

   Phil: Lastly, concept of automatically placing items in the gird.
   Phil: There's a concept of grid-flow, which creates more rows (or columns)
         as needed.
   Phil: Would take awhile to explain, take a look at the draft
   Steve: this is for indefinite numer of coluns?
   Phil: Yeah. I have a form with lots of fields, as an author just want to
         define a grid for your fields
   Phil: I create three columns, and then tell the forms to find an auto row
   Phil: Here are the grid alignment properites, discusses writing mode
         interactions, etc.

   Phil: Drawing order of grid items is not changed; got some feedback on
         using z-index, haven't incorporated yet
   Phil: Concern is wanting to drop things behind other things, but not
         behind the grid element background
   Phil talks about stacking contexts
   Phil: Need an easy send-to-back functionality
   dbaron: A full stacking context would do that
   Phil: Not sure we really want to prevent z-ordering behind the grid
         element just because we want easy send-to-back
   dbaron: You don't have to do that by default, but the author could
           specify it themselves
   dbaron: That makes the send-to-back scenario work
   Phil: Stacking contexts are complicated, I'm concerned about making
         authors understand them and z-index in order to make this work.
   Alex explains something about making all form controls relpos just
        to get z-index working

   fantasai: What is the relationship of this to existing grid module?
   Alex: Positioning is really interesting in concept of page layouts,
         and we have some ideas on how to integrate them
   fantasai: It seems this module folds in a lot of that functionality,
             so you could publish this as an update to that module.
   Alex: Grid positioning deals with other content, not necessarily your
         immediate children
   Alex: One thing that needs to be defined is element sizing, and how
         do you define a positioning container ... where grid is applicable
   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
   Alex: So that everything here contributes to grid definition.
   Markus: We still need a lot of the concepts from that spec to integrate.
   Alex: I think the main use case for grid positioning is page floats
   Alex: I don't think page floats is quite as ready
   fantasai: Ok, I understand why they are separate and I agree that makes sense.
   * fantasai suggests css3-grid-layout :)

   <br type="lunch">
   * Ms2ger suggests css3-kitchen-sink-layout :)
   * fantasai thinks that's an accurate description :P
   </br>

   Markus: Wanted to follow up on discussion from before-lunch meeting
   Markus: Would like to advance grid layout spec from editor's draft to WD
   jdaggett: For FPWD, there are special requirements
   howcome asks if we can merge grid layout and grid positioning
   fantasai: From what Alex was saying, I think it makes sense for the modules
             to be separate
   fantasai: And publish this as grid-layout

   jdaggett: What are the requirements?
   glazou: Has to be in the charter
   fantasai: It is, since it's closely related to existing css3-grid
   fantasai: need permission from plh to publish FPWD, but nothing else
   RESOLVED: Publish as css-grid-layout, i.e. CSS Grid Layout
   ACTION Bert make publication
   <trackbot> Created ACTION-312
   fantasai: (It would be a Level 1 of this module, so not using Level 3 in
              title.)

Flexbox
-------

   plinss: Deferring line grid, since it's marked as "if time allowed"
   plinss: Flexbox?
   Tab: ???
   Alex: Wouldn't you like to present the changes in your latest draft?
   Tab: I could?
   Tab goes up to present
   Tab gives overview of flexbox
   <smfr> http://dev.w3.org/csswg/css3-flexbox/
   Tab: Current editor's draft of flexbox is much closer to my draft,
        and to suggestions we've made so far
   Tab loads page with lots of red

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

   Tab: Flex-direction says which directions the boxes flow in
   Tab: Have physical and logical directions
   Alex: If we had a multiline flexbox, how would we extend flex direction
         for it?
   ISSUE ^
   Alex: One approach would be to use existing writing mode
   Alex: There is no logical equivalent of those
   Alex: Maybe do come up with eight logical abbreviation directions
   fantasai: How about combining keywords with spaces, e.g. tb lr ?
   Tab: flex-order lets you reorder items

   Tab: Flexible lengths is where it really changes.
   Tab: Old draft used a flex property that took an integer, and then
        keywords for alignment
   Tab: I'm going with a different approach here,
   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
   Tab: Using now a flex() function, which takes 3 args, first one is
        positive flex, second is negative flex --
   Tab: Established at F2F that negative and positive flex should be
        distinguished, otherwise you get unintuitive results, ie. largest
        thing becoming smallest
   Tab: Third arg is the starting width.
   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

   Tab: flex-order allows you to reorder items
   Phil asks about having the reordering be a more generic concept, since
        it's useful in many layout models not just for flexbox
   Tab: Ok, could have that be a generic mechanism for rewriting source order
   Steve: ...
   Phil: Template layout had an area that used source order for flowing
         items, might want to reorder in that as well
   dbaron: Do people have positive experiences using an integer-ordering
           property like this?
   dbaron: or does this get unweildy with more content?
   Tantek: numbering BASIC worked so well!
   Steve: Might want to reorder columns
   Steve: in that case maybe using names
   Tab: fantasai brought up case of tabbed layouts, where active tab is always
        in front
   Tab: I'm certain like many of our advanced tools it can be abused
   Tab: Like we shouldn't be sorting lists with this
   Tab: But I'm not sure how else to get the functionality we need here
   dbaron: Wrt usefulness of order, Gecko has implemented box-ordinal-group
           for around a decade now.
   dbaron: But it's used so rarely that we're still getting very fundamental
           bugs filed on it

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

   Tab: Then we have the flex-pack property, which determines the
        distribution of content within the flex direction
   Tab: It works similar to text-align
   Tab: justify evenly spaces out the flexboxes, aligning them flush
   fantasai: I would suggest to look at ruby-align property, esp distribute
             (which seems like a better name here) and distribute-space
   Tab: flex-align property..
   Tab: Normally use flex to do alignment, but couldn't figure out how to
        do baseline alignment
   Tab: Not totally clear on the use cases, so still haven't fully specc'ed
        it out.
   Tab: auto just means normal flex distribution, baseline means
        currently-undefined magic
   Tab: That's pretty much it, rest is algorithms
   * fantasai notes that flex-align could get a generic name and solve some
     other important problems like vertical alignment of boxes

   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.
   Markus asks why there's flex() instead of 'flex'
   Tab: The original approach of having two different properties that have
        to be thought of together to get a single effect was confusing
   Tab: And with negative flex we needed yet another one
   Alex: My concern is that it makes absolute flex easier but relative flex
         harder
   Alex: The main working mode of the whole spec becomes absolute flex,
         which is not the previous system
   Alex: I expected default starting width to be auto
   Alex: Have padding initial be zero, width initial be auto
   Markus: ...
   Tab: Talking to authors playing with old spec, they're confused.
   Tab: Having flex: 1; on multiple elements result in different sizes
        confuses them
   Alex: If you're working on top-level page layout, absolute flex is more
         useful
   Alex: If you're laying out form controls or menus, then additive flex
         is more useful.
   Tab: I have to make one shorter syntax than the other
   Alex: Let's look at other options

   Tab talks about terminology for width and height algos
   Markus: Is your motivation that this would replace existing flexbox spec?
   Tab: Yes, replace
   Markus: Despite existing implementations?
   Tab: Yes. I think this is sufficiently better that it should replace.
   Tab: Working with chrome devs, they are enthusiastic about replacing it
   Alex: Is Mozilla going to move to the new syntax?
   dbaron: We'd definitely like to have a standard version of flexbox.
   dbaron: It's hard to tell how quickly it would happen.
   Alex: would it make a difference if it stayed closer to the old syntax?
   dbaron: I think the syntax is less of a big deal than the concepts
   dbaron: A lot of the stuff we use flexbox for now is stuff we want
           additive flex for now.
   dbaron: potentially harder to convert existing content
   Tab: I don't buy the conversion argument
   dbaron: But it seems like a lot of typing
   <dbaron> people might not know what flex(1, 0, auto) means
   dbaron: And I don't think people will know what flex(1,0,auto) means
   <dbaron> (which they'll be using a lot)
   Markus: Shouldn't we standardize the current spec now?
   Markus: And make this the next level?
   Tab: You can't really do that. They're not compatible, not without some
        really hacky stuff
   Tab: Also my experience talking with authors is that the current spec
        is really confusing
   Markus: Yeah, it's not that great, but we have implementations
   Tab: I'm not in favor of standardizing something that's bad.
   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
   <glazou> standardization is always bad because it is always a compromise
   fantasai: So, my position is that the changes Tab have made make this
             spec much better, and we should go in this direction. With
             regards to implementation, I don't think changing syntax is a
             significant cost: the hard part is the layout code. Which has
             to change to handle negative flex and other concepts we're all
             agreed are important to have.

   Tab: If it's a question of which (additive vs absolute) is easier, I'm
        not concerned about that question
   Tab: What's important to me is breaking with the previous syntax.
   Markus: We have implementations coming, and it's used.
   Tab: But not on the Web
   Tab: And our implementation at least is very buggy.
   Tab: It's a minority prefixed thing.
   glazou: Current implementations are too weak and too buggy for use
   Tantek: That's the point of prefixes -- they allow us to experiment.
   fantasai expounds on this topic, but doesn't have time to type it.
   dbaron: I don't think negative flex is the hardest thing here, it's
           adding flex to margins and padding
   dbaron: ...and as a value to existing properties
   fantasai: But thats needed if you want to apply this to HTML, because
             in XUL you have to use <spacer> elements, and we don't want
             to add those in HTML documents.

   Steve: ...
   Steve: This in my mind has the level of flexibility that you need
   Steve: It's also a lot easier to explain to people than the other one
   Steve: It would work perfectly well within the grid layout model
   Steve: I think Tab's choice of using the zero-width thing is more
          appropriate there
   Tab: For the most common case, of starting flex from the auto width
        and using single flex, you can just use 'auto'
   Tab: That's equal to flex(1,0,auto)
   Tab: We can still talk about how to make them easy, but there are ways
        to make both common cases easy
   dbaron: Shouldn't the width value come first?
   Tab: I had that first, and it makes it easier to do relative flex, but
        it doesn't work so well for absolute flex
   Tab: Alex suggested swapping the order

   fantasai asks about making flex() detect whether it's aboslute or
            relative based on whether it's a length or an integer
   Steve: ...
   Tab: I had flex units be additive and flex() be absolute before
   Steve: The flex unit is confusing if grow and shrink are given in one
          set of units, and different in another
   ...
   Tab: The idea of what's the best way to present this concept to authors
        is something we should talk about
   Steve: Btw I'm not disputng the 5-tuples
   Steve: Just discussing syntax
   Tab: I think this is the best option, though I'm open to other options.
   Tab: Main question is whether we go forward with this or revert to the
        old draft.
   Alex: We want draft to become stable and move forward
   Alex: I don't see a way to get there without having a new draft
   plinss asked for objections to moving forward with this draft
   RESOLVED: Publish updated draft of css3-flexbox

CSS MultiCol
------------

   howcome: Multicol is in CR. We have a couple of issues, but close to
            getting a new version
   howcome: Would like to publish another CR
   howcome: Big issue was pseudo-algorithm
   howcome: In previous versions the pseudo-algorithm tried to reduce the
            number of columns
   howcome: Seems to be consensus on not doing that, and relying on authors
            setting column-width to give the columns a minimum width
   howcome: here's what I suggest to edit the pseudo-algorithm
   fantasai: Can we get comments in the pseudo-algorithm?
   howcome: maybe
   howcome: I think my proposal is correct, put a max fuction to make sure
            width doesn't go negative
   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
   howcome: fantasai noted this in the minutes
   howcome: But this prose is not included in the pseudo-algorithm
   Sylvain: Fix the pseudo-algorithm
   Discussion of use cases for column-count
   howcome: btw, my proposal for fixing this should use min() instead of max() ...
   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 for how it should behave; and the behavior of the
            alternative proposals can be gotten in other ways
   Simon: Should we rename it to column-min-width?
   howcome: we'd have to go back to last call
   no strong opinions in favor of renaming
   howcome: Can we update the CR?
   plinss wants to be more verbose and have it column-min-width
   fantasai disagrees
   Brad: If there's only one thing to set the width, it should just be width
   RESOLVED: Publish updated CR of css3-multicol

   dbaron: test suite?
   howcome: I'm working on the test suite
   dbaron: we have 22 reftests for columns
   fantasai: bunch more in pagination
   dbaron: we'd need to go back and check that the tests match the current spec
   howcome: how do we go forward with the tests

Segue: Testing
--------------

   johnjan: I have some ideas
   johnjan: We should take what we learned about CSS2.1 and apply to CSS3
   johnjan: I think first we should map every test to the part of the spec's
            testing
   dbaron, fantasai: We have links to section headings already
   arron: That's not very specific
   fantasai: css3 specs have more fine-grained subsections than CSS2.1
   johnjan, fantasai: ideally would do per-paragraph anchors
   fantasai: And Bert's postprocessor script supports this
   fantasai: but it's hard to have stable anchors per-paragraph
   <dbaron> http://test.csswg.org/suites/css2.1/20110111/xhtml1/toc.xht
   johnjan talks about testing
   keeping track of which sections are tested, not tested,
   how many tests are for each section
   <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 pargraph
             changes the tests have to be updated anyway...

   johnjan: we're not interested in implementation testing, but in
            implementability testing
   dbaron: We need a test suite to enter PR, but that shouldn't be the only
           purpose of the test suite.
   dbaron: I think we should be developing the test suite for interop
   dbaron: We want the test suite to solve real problems for authors, not
           just get us to PR
   dbaron: Authors have problems when impls don't do the same thing
   dbaron: And we want to test things that will have bugs that bother them
   <dbaron> It's not about proving interop... it's about improving interop.
   johnjan: proving compliance and interop are two different
   dbaron: It's not about proving interop, it's about IMproving it
   ...
   johnjan: There's no motivation for making test suites other than going
            to CR
   sylvaing: You could say that you need an implementation report to drop
             your prefixes
   sylvaing: Today, we allow dropping prefixes as soon as we go to CR.
   sylvaing: If we require tests, that gets us tests and it makes sure that
             impls dropping prefixes implemented it correctly
   johnjan: I think testing has to drive the process more

   some questions about logistics
   fantasai: public-css-testsuite and the svn repo are available to all css
             modules, not just 2.1
   fantasai and arronei review the review process
   http://wiki.csswg.org/test
   howcome: Do they have to be reftests?
   Tab: There should be an excuse to why it's not a reftest

   dbaron: Did we adopt the scripted reftest conventions?
   fantasai: Not yet, we'd have to do so
   dbaron explains reftest-wait convention: a reftest with
     <html class="reftest-wait"> tells the harness it needs to wait, so it
     adds a mutation listener to HTML and does the comparison when the
     "reftest-wait" class is removed.
   howcome: do we need scripted tests for multicol?
   dbaron: Yes, changing pagination points
   johnjan: resizing the window

   howcome: Safari?
   Simon: We have 50-60 tests in our test suite
   Simon: But they're not really suitable for test suite tests in their
          current incarnation

   howcome: What about multi-col in vertical text?
   Alex: It should just work :)

   johnjan: what about prefixes?
   Arron: No prefixes in the test suites
   johnjan: So we can't test until we drop prefixes
   dbaron: Could add prefixes with regexp
   fantasai: Current build system has concept of output formats, would be
             easy to build regexp into that

   Arron: Another issue is tracking issues on the testcases
   Arron: Using the mailing list is really really unweildy
   Arron: Can we use bugzilla?
   johnjan: The mailing list is really going to be hard to manage
   dbaron: Bugzilla is too heavyweight
   plinss: we have a design for a system, just need to build it
   johnjan: We need something now
   Arron: May not be perfect solution, but Bugzilla gives us something for now
   fantasai: So I think we should adopt Bugzilla, one bug report per test
             unless you have a really good reason not to.
   RESOLVED: Use Bugzilla for test suite bugs, one bug report per test
             unless there's a good reason not to
   * mollydotcom says yay, that's good news

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

<br/>

Tokyo Workshop
--------------

   <plinss> http://wiki.csswg.org/planning/tokyo-workshop-2011
   Koji: There is a group in Japan supported by Japanese government trying
         to host forum or workshop
   Koji: I'm the liaison to the CSSWG
   Jay: My name is Jay Kishigami
   Jay: I am going to make a presentation for the upcoming Tokyo workshop
   Jay: This is a good opportunity to discuss with Japanese publishers and
        other users of vertical writing.
   Jay: But it's not only in Japan, but also in other countries.
   Jay: Old Korean was written in vertically
   Jay: Newspapers in Korea were in vertical up until 1996 or so
   Jay: And also Chinese write in vertical
   Jay: Chinese, Japanese, and Mongolian all currently write in vertical
   Jay: Maybe this community discuss the real requirements
   Jay: Publishers and software vendors are very interested in ths workshop
   Jay: Maybe some presentation from Asian layout implementers and device
        vendors, authors
   <kojiishi> You can find Korean newspaper archives by date at http://dna.naver.com

   Jay: I just wanted to confirm dates for workshop
   Jay: Before or after
   Jay: I heard that fantasai cannot attend before, but others are better before
   Jay: before is also good if items come up for WG discussion, can be
        discussed at F2F after
   Jay: Is there any objections or comments on the date?
   glazou: How many days do you plan to have the workshop?
   Koji: I don't think we have finalized this yet
   glazou: I think one day is probably enough
   glazou: Since we are meeting W-F for CSSWG F2F
   glazou: So Tuesday is best especially for people travelling from far away
   Bert: How many people should come to the workshop?
   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.
   glazou: We can have both.
   glazou: Most of the WG will be present.
   glazou: We can have panels with questions where WG interact with audience,
           split into tables for lunch

   glazou: The only problem in smaller groups is your last line, the language
   Jay: Atm we have two solutions for the language.
   Jay: one is to have basic language be English
   Jay: But for some people they're not comfortable to speak English
   Jay: So we can have simultaneous language
   glazou: Japanese is probably best for main language, but we need English :)
   Jay: So proposal is May 31st Tuesday from 9 or 10am through the evening,
        with lunch session
   Jay: We can have tables with discussions at the tables
   glazou: That's doable if we have one person per table able to translate
           between English and japanese
   glazou: That's the only trouble we have

   Peter: One other thought about the dates is that we could push our meeting
          back by a day or shorten it by a day
   jdaggett: I think we definitely shouldn't shorten our meeting
   plinss: We could also push back our meeting by a day, T-S
   fantasai and Steve can't make Tuesday
   ?: Tab, can you host on Saturday?
   Tab: difficult, since Google employees won't be there
   jdaggett: We could host on Saturday
   <Bert> (So how big will the ftf be, again 25, or less?)

Scribe: Tab Atkins

   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.
   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.
   Jay: The participants here may be from the publishing area, but will
        include the web designers.
   Jay: Maybe the signage designers would be able to offer useful feedback
        as well
   jdaggett: We're designing CSS here, and the focus is on designing CSS,
             not necessarily on how Japanese text works.
   Jay: The goal of this workshop is understanding how to handle vertical text.

   <mollydotcom> John's concerns are very real, and of course this is an
                 ongoing issue
   <mollydotcom> as the person who acts as developer liaisons, we have to
                 engage designers more
   <mollydotcom> but Japanese text is part of that too - designers designing
                 Japanese sites need the technology
   <mollydotcom> I'm just repeating my old mantra: Engage designers somehow
   <mollydotcom> It's very difficult, not our fault, but it's necessary

   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.
   Koji: I think we tried to make the participant list take into account
         input from the WG, including you.
   <mollydotcom> +1 That's the point, is it not? John. At least as I see it
   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.
   jdaggett: My concern is that people are just going to get up and talk about
             things that they think are important.
   * mollydotcom says isn't that what happens anyway?

   Markus: So you want to frame it as "How can we help", action items that
           the WG can take away to work on.
   jdaggett: Right; we need to think about it in terms of CSS and the web,
             not just about the difficulties of publishing.
   plinss: I think CSS is becoming more and more important in publishing.
   jdaggett: Right, but we need to ensure that it's both about the web and
             publishing.
   Markus: If you explain what is the delta between what you see on the Web
           and what you would want to see
   Markus: I think it's easiest to phrase things as a delta between what
           currently exists and what is lacking that is needed.
   <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?
   Jay: We want to intentionally produce just such a productive and tangible
        result from the discussions.
   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.
   Jay: Though, perhaps the older publishing people won't fully grasp what
        is "CSS".
   Jay: So some interpretation may be required.
   <mollydotcom> it sounds unfocused to me
   <mollydotcom> what is the end goal?
   <mollydotcom> in one sentence

Scribe: 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?
   Steve: Or are we sitting through presentations where japanese people
          explain what they need?
   Steve: I don't have a particular preference, but from the CSS viewpoint
          it seems to make more sense for us to present what we are doing,
          since that's what we are expert in
   Steve: But it would also be relevant to hear what other people think we
          /should/ be doing
   <hyatt> "what they need" is already described really well by the amazing
           http://www.w3.org/TR/jlreq/ document
   <glazou> hyatt: yes that document is amazing
   <hyatt> glazou: that's really what we've been using in webkit to guide our implementation
   <glazou> hyatt: how suprising :-)

   Koji: Is there anyone who can give an overview of what's going on in CSSWG?
   fantasai: you? :)
   <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
   fantasai: Could hve two days, one in Japanese, one with the WG in English
   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
   Koji: Could have first day Japanese learning, second day presenting to WG
   Jay: So could have second day be workshop, with English support, first day
        be preparation for/by/in Japanese
   Jay reads out name of government org that will be co-organizing with W3C

   glazou: When do you think the organizing committee is going to release a
           schedule for the day?
   Jay: Need to coordinate with Japanese government and W3C
   Koji: SVGWG is also interested in participating in this forum
   Steve: They have their F2F the next week
   Steve: I think Chris favored having the workshop beforehand as well
   Steve: He also talked about having a joint SVG-CSS meeting
   Koji: Should be able to get back to everyone within 2-3 weeks
   Steve: Asap, so people can get airline tickets
   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

CSS3 Line Grid
--------------

   plinss: anything to discuss here?
   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
   jdaggett: I'm a little confused why we're talking about this as a separate
             spec
   jdaggett: This was in a previous CSS3 Text draft
   jdaggett: I think it's peculiar to be creating modules here
   fantasai recaps history of CSS3 Text
   jdaggett: Given everything we have on our plate here, I think it's a little
             premature to work on a spec here
   jdaggett: Were there implementers on the CSSWG who wanted to implement this?
   Koji: Apple
   fantasai: We need 2 implementers to take on a module
   Koji: CSS3 Text was born 12-13 yrs ago as International Text Layout spec
         from stuff at Microsoft
   Koji: The Japanese portion of that spec was mostly written by me, brought
         from MS Word features
   Koji: Line grid one of the features Word implemented in 97 and tried to
         bring into IE
   Koji: Nobody has been showing much interest since IE
   Koji: Not sure what happend after, but it was decided to split up
   jdaggett: What needs to happen first is Apple need to say they're
             interested in this
   jdaggett: And then we can assess whether this is something we wan
             to take on
   jdaggett: We have a very full charter
   jdaggett: Seems like something that should be starting after we finish
             CSS3 Text and CSS3 Writing Modes
   jdaggett: Talking about it now seems premature
   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
   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
   Alex: We are glad that somebody else is interested
   Alex: We had a hard time last 12 years in promoting this
   Alex: We should create a spec that a new implementer like us can agree on
   Alex: Not sure what we do if Apple goes to implement line grid without a spec
   jdaggett: If both Apple and Microsoft are interested, then we should have
             them write down what they're interested in implementing
   jdaggett: Let's have a written proposal that describes what they're
             interested in
   Simon: for the record, we weren't aware of this, so we need to talk with
          hyatt and find out more
   Koji: I prioritize writing mode and text higher, but expect to get to line
         grid in a few  months.
   jdaggett: So we can talk about it then
   Alex: What do you propose for start making changes to the spec
   jdaggett: first, I think we should have a written proposal of what we want
             to take on,
   jdaggett: second, group reviews this and decides whether this is something
             we want to take on
   jdaggett: It's largely a matterof editor's time, but also discussions at
             F2F and telecons, so impacts groups time
   Koji: It's not a new spec, it already exists in 2003 CR
   jdaggett: So point to the spec sections
   <fantasai> http://www.w3.org/TR/2003/CR-css3-text-20030514/#document-grid
   jdaggett: Do you want all of this?
   jdaggett: What is the exact set of features from that spec that you are
             talking about?
   Koji: My approach was to write an editor's draft and ask people for review
   jdaggett: Usually people write a rough draft of what they want
   Steve: I think there are two points going around here.
   Steve: One is, we get regularly beat up from W3CM about having too many
          irons in the fire and not finishing anything
   Steve: We did a priority review at the last charter, and concluded this
          was not at all a priority
   Steve: Since then priorities have changed, especially due to EPUB
   Steve: So one issue is what are we giving up to work on this
   Steve: Second is, if we are going to work on this, is how to go about
          doing it.
   Steve: Adobe and Microsoft both put proposals on the table to discuss
   Arron: You mean a proposal other than the current spec?
   Steve: Could just be updated copy of old spec
   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.
   jdaggett: My concern is that you and fantasai are editors of the CSS3 Text
             spec
   jdaggett: And I don't see that as being stable, there's a lot of work
             remaining there.
   jdaggett: My concern is that we shouldn't be talking about priorities
             until we get through whatever has to happen for that
   Koji: So when the time arrives I should copy from 2003 CR and put on my
         own site?
   jdaggett: Just put it on dev.w3.org
   fantasai: I think that was all he was asking permission for.
   Bert: Putting it in the charter is a separate matter, but dev.w3.org
         is available.

Compositing
-----------

   plinss: SVGWG will publish Last Call of their Compositing spec.
   plinss: They plan to set a 4-week LC period, until april 7
   plinss: They are asking us if that's sufficient time
   <plinss> http://dev.w3.org/SVG/modules/compositing/master/
   plinss: Ok, nobody seems to be asking for more time.

CSS2.1 Issues
-------------

   plinss: That's most of what we preplanned out for today. Also have
           the elephant in the room of CSS2.1 issues
   plinss: Daniel and I suggest tackling those
   * Bert would like to see Daniel and Peter tackle an elephant. :-)
   plinss: Plan for rest of day is to work on CSS2.1 issues.
   plinss: If people want to leave, feel free to leave. We are not working
           on anything else today.

   plinss: One quick thing to discuss, over lunch we talked about keeping
           the editorial issues we don't want to deal with now
   plinss: but that we think are valid
   plinss: Several options are making a CSS2.1.1 or CSS2.1
   plinss: or slip them in between PR and REC
   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
   Arron: My concern with the last one is that we accidentally introduce
          a substantive change.
   plinss: Other thoughts?
   <mollydotcom> this is to ensure that we can shelf 2.1 or does it still
                 remain in limbo

   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
   <dbaron> ...and then want to merge them
   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.
   plinss: So what are we going to do?
   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.
   dbaron: Should consider which branch is going to get served off the server,
           if you're going to branch
   <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

   <plinss> http://wiki.csswg.org/spec/css2.1/anton-lc-2010
   plinss: I'm looking for resolution to accept the recommendations on the
           wiki page where Arron and fantasai analyzed Anton's comments.
   arron: Stuff we didn't have a no-change conclusion on has been filed in
          the wiki as issues
   fantasai reviews the wiki doc
   CL3 could add a more explicit reference to other section, but there's
     a link already
   <dbaron> http://dbaron.org/css/test/2011/css21-issue-280 is a testcase
            for issue 280
   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)

Scribe: Tab Atkins

   plinss: First open issue is 179.
   dbaron: Has an action to Bert.
   dbaron: So what do we need to do?
   plinss: Do we need to make this change?
   fantasai: Yes, it's currently wrong.  It's an example, but it's wrong.
   RESOLVED: Accept the edit for 179.

   plinss: Issue 225
   dbaron: I don't understand "the top of the parent box" in this proposal.
   dbaron: In the text he's quoting, the conditions for top and bottom are
           different, and I think they need to be.
   arronei: I think the current text is fine, personally.
   dbaron: This proposal looks like a substantive change.
   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.
   dbaron: What's the parent box?
   arronei: It should be the top border edge of ???
   dbaron: If it has a previous sibling, the top of the parent isn't what
           you want.
   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.
   dbaron: Anton is correct that the current spec is wrong.
   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]
   dbaron: Never mind, I don't see anything that needs changing here.
           Certainly don't see what's wrong with the second sentence.
   plinss: So, do we think the spec is fine?
   dbaron: Yeah, I think so.
   RESOLVED: No change for issue 225.

   plinss: Issue 226
   fantasai: I need to write text.
   plinss: Do we agree that this is a necessary change?
   fantasai: Don't remember.
   <johnjan> http://wiki.csswg.org/spec/css2.1#issue-226
   arronei: let's look at it and see.
   RESOLVED: 226 is editorial, deferred to CSS3.  No change to CSS2.

   plinss: 229.
   dbaron: This is a case where no impls match the spec, I think.
   <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
   <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
   fantasai: The "aaa"s don't move to make room for the "bbbb".
   <johnjan> if the tests are right, looks like everyone is interop, but
             no one is compliant.
   dbaron: If there's a float between two blocks, does the placeholder
           get wrapped?
   fantasai: No, placeholders only get created for tables.
   dbaron: But I thought we needed it for containing block?
   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.
   fantasai: ????
   dbaron: There is some wording about "the float can't be below the
           bottom of the previous block"
   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.
   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.
   Bert: I wrote those rules 15 years ago, and I definitely didn't want
         floats to move up when their containing block moved up.
   Bert: The intention was definitely to check for the lowest thing of
         *everything* that came before.
   Bert: I imagined keeping a running track of what is currently the
         lowest element.
   fantasai: I think most impls do that, but also move it up if you
             have a negative margin.
   dbaron: We do the same thing for floats, we just don't do it for blocks.
           We track the top of the last float.
   dbaron: In rule 4, we already have this condition...
   dbaron: It helps, because we already have the hypothetical that we need.
   dbaron: [something about rule 5, strike the "block or"]
   dbaron: And then in rule 6, you'd only count the linebox containing the
           float, and not lineboxes earlier than that one.
   dbaron: [something about negative margins]
   [unminuted discussion]
   plinss: I think at this point we should lean toward undefined.
   fantasai: We can't undefine the whole floats section!
   fantasai: And fixing this is probably about as much effort as carefully
             undefining just the behavior we're talking about.
   arronei: I'm up for a note.  We have no testcases.
   fantasai: What are you going to do?  Report that we resolved this by
             noting that the spec is in error?
   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).
   * fantasai suspects there might be a web compat behavior
   plinss: If we can do this by simply saying the interaction with negative
           margins is undefined, that's fine too.
   dbaron: I think that is making too much undefined.
   dbaron: We definitely want to limit it to negative vertical margins in
           the containing block prior to that float.
   <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, the position of the float is
              undefined
   plinss: Objections?
   arronei: I'm concerned there may be more interactions, but I'm okay.
   <johnjan> agree with fantasai's proposal.
   <johnjan> that seems to describe interop behavior.
   fantasai revises
   <fantasai> If, within the BFC, there is an in-flow negative margin such
              that the float's position is above the position it would be
              at were all such negative margins set to zero, the position
              of the float is undefined.
   RESOLVED: Accept fantasai's edits for issue 229.

   plinss: Issue 239.
   <johnjan> http://lists.w3.org/Archives/Public/www-style/2010Oct/0750.html
   <dbaron> was 239 the right number?  Issue is currently marked closed.
   <dbaron> johnjan, ^
   <johnjan> checking my list
   <johnjan> 239 is the correct issue. I didn't think we closed on Body
             propogating to HTML based on Alex's comments.
   <johnjan> if we did, then my mistake.

   plinss: Issue 242.
   <dbaron> re-resolved to accept proposal for 241 in case we didn't accept
             it already

   RESOLVED: Defer 273 to future version, editorial.

   plinss: issue 274.
   fantasai: 274 is related to the earlier one we discussed.
   plinss: Did we undefine this one implicitly?
   fantasai: No.
   dbaron: [something about lineboxes next to floats]
   dbaron: Lineboxes are not shortened by a float that occurs after them.
   <dbaron> which we could note can only occur under the undefined behavior
            we just added
   RESOLVED: Accept dbaron's edit for 274.

   plinss: Issue 275
   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.
   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.
   Bert: But do you move the line box, or do you move the word?
   Bert: and have empty line boxes all the way down?
   dbaron: i remember discussing this in a meeting when tantek was on macIE.
   dbaron: I think this was an intentional decision (to allow the gap to be
           a non-integral multiple of line-height)
   dbaron: So the issue is that 9.4.2 says that lineboxes are stacked with
           no vertical separation.
   dbaron: I'll say that 9.5 overrides 9.4.2 and we can just live with it.
   dbaron: Or we can say in 9.4.2 "except as described in 9.5".
   Bert: Kind of ugly, because it can mess up the vertical rhythm.
   TabAtkins: Many things can do that; we shouldn't worry about that until
              we have a spec that can solve it properly.
   plinss: So what's the resolution?  Fix, or leave spec as it is?
   plinss: There are many places where one piece of prose overrides another.
           Let's just leave it.
   <johnjan> leave as is.
   <johnjan> note that 9.5 overrides 9.4.2
   <johnjan> on the list
   Bert: add "(except as specified elsewhere)"
   RESOLVED: accept Bert's proposal for 275.

   plinss: Issue 276
   dbaron: I'm okay with the proposal.
   fantasai: It's in CSS Selectors, though it's not better defined there.
   <johnjan> that's OK, selectors has time to get it right.
   fantasai: I think we should add a note that the precise behavior is
             undefined, and may be defined in a future version.
   <dbaron> johnjan, not really, since it's ahead of 2.1...
   <johnjan> good point...
   RESOLVED: Note that :first-letter, :first-line are underdefined, to resolve
             issue 276.

   plinss: Issue 277.
   arronei: This is a terminology issue.  We should get it right, but it's
            editorial.
   dbaron: Though it may or may *have* confused conversations or DOM APIs... :)
   <dbaron> since CSSOM misuses declaration
   <bradk> A rule set (also called "rule") consists of a selector followed
           by a set of rules (also called "declaration blocks").
   RESOLVED: Defer issue 277 for errata.

   plinss: Issue 278.
   dbaron: This is saying we should exlicitly say "margin box" to be clearer?
           Seems good.
   RESOLVED: Accept edit for 278.

   plinss: Issue 279.
   <johnjan> http://lists.w3.org/Archives/Public/www-style/2010Sep/0130.html
   RESOLVED: Accept edit for 279.

   plinss: Issue 280.
   dbaron: I believe 280 is an error in the spec, where the impls got it
           right and the spec is wrong.
   <dbaron> http://dbaron.org/css/test/2011/css21-issue-280
   dbaron: The question is whether fuchsia starts within or below the purple
            box.
   fantasai: We have full interop.
   dbaron: ...which disagrees with the spec.
   dbaron: I think the problem is that the spec can be taken more literally
           than intended.
   dbaron: The spec says that [omg rule 3].
   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.
   dbaron: Which is this testcase.
   dbaron: The change is to make the spec say "when they overlap in vertical
           position".
   dbaron: But the spec literally says something to the right.
   dbaron: so the implementations implemented what Bert meant to say, and
           Anton has noticed that this is not what was actually said
   dbaron: "next to it" works.
   <dbaron> Bert proposed "next to it"
   RESOLVED: Change "to the right of it" into "next to it".

   glazou: Issue 281.
   <johnjan> no change necessary for 2.1 here.... errata
   fantasai: I think we should fix this.  It's just wrong.
   dbaron: You could change it to "not a position derived from the line-height".
   <dbaron> maybe change "not the 'line-height'" to "not a position derived
            from the 'line-height'"
   fantasai: or just replace the clause with "and has nothing to do with the
             'line-height'"
   RESOLVED: Accept fantasai's edit for 281.
   <johnjan> I can buy that

Meeting closed.

<RRSAgent> http://www.w3.org/2011/03/08-css-minutes.html
Received on Sunday, 13 March 2011 20:19:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:38 GMT