[CSSWG] Minutes and Resolutions TPAC F2F 2009-11-02: multicol LC, grid + flexbox + template layout

CSS3 Multicol
-------------

   - Disposition of Comments at http://dev.w3.org/csswg/css3-multicol/last-call.html
   - RESOLVED: advance css3-multicol to CR

Grid, Flexbox, Template Layout
------------------------------

   - Discussed interaction of layout models
   - Discussed triggering fallback based on UA support
   - RESOLVED: remove note about interaction between grid and tables
   - It's not clear how to make progress on these drafts

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

http://www.w3.org/2009/11/02-CSS-irc
http://krijnhoetmer.nl/irc-logs/css/20091103#l-16

CSS3 Multicol
-------------

   howcome: Yes, I want to advance it.
   Peter: So all the comments have been addressed?
   howcome: yes
   fantasai: Do you have a disposition of comments?
   howcome: It's linked from the wiki page.
   <howcome> http://dev.w3.org/csswg/css3-multicol/last-call.html
   ChrisL: What are the uncolored rows?
   howcome: They're not really comments, just questions.
   ChrisL: put that in the grid at the top
   ChrisL: Sylvain, could you send email about whether you're ok with that
           resolution.
   howcome: The other orange... he sent a message saying it was ok.
   fantasai: I disagree with howcome's disagreements.
   howcome: I'm happy to change.
   <dsinger> comment #1: change "coing" to "going"
   Daniel: some green rows have no action
   howcome: didn't result in changes
   Daniel: so put "no changes needed"
   Daniel: Don't use "white".  Use "green".
   ChrisL: Also need CR exit criteria.
   fantasai: We have boilerplate for that.
   howcome: Should I prepare a CR draft then?
   Bert: Yes, everything except the status.
   fantasai: Bert can take care of the status right before publication.
   RESOLVED: Advance css3-multicol to CR
<Zakim> -Hakon_Lie
   <glazou> #howcome { color-replace: white green; }

<break duration="17min" />

Grid, Flexbox, css3-layout
--------------------------

Scribe: fantasai
   Alex: Are there specific issues about these specs being inconsistent,
         overlapping, etc?
   glazou: The issue is that these specs are in limbo for 2 years
   Tab: I added it to see if there is any way to unify the concepts, esp.
        between template, flexbox, and tables
   Tab: These are 3 separate ways of dealing with layout, was wondering
        if we can combine them
   dbaron: Tables have so many backwards-compatibility constraints that
           you probably don't want to do that
   Alex: Flexbox is the first concept of layout that is completely
         independent of the rest of CSS
   Alex: ...
   Alex: There are two exceptions to that: table and flexbox
   Alex: each uses its own algorithm to do layout
   Alex: Which keeps its really simple: only layout concepts of this model apply
   Alex: It's awesome
   Alex: It's cool if this same model applies to something else
   Alex: If it can be added as its own model without added any complexity
         of interference with other features
   Tab: So you prefer the layout modes being completely separate from
        each other?
   Markus: Depends on how you want to apply it
   Markus: Flexbox is great for layout
   Markus: Then use flow layout for the content inside
   Alex: yes, I prefer different models separate
   Alex: We can certainly discuss how this applies to CSS, where mostly
         everything applies to everything in combination
   Alex: This is great for flow content
   Alex: but the there are other systems like Silverlight, WPF, etc.
   Alex: Where most layout models are self-contained and independent
   Alex: Everyone has its own model and it's extensible, you add a model
   Alex: Is it good to go forward to have both system in CSS .. and add
         flexbox and add something else and add something else... I don't
         know
   Alex: I think the existence of flexbox as something separate is good.
         I would be worried if we tried to integrate with regular CSS layout
   Tab: Ok, seems reasonable
   Alex: Flexbox is a parent that has complete control of its descendents (?)
   Alex: The model of the ocntainer overrides the contents
   Alex: Abspos has that kind of gray area
   Tab: That makes sense, esp within the context of flexbox
   Tab: Jumping over to template
   Tab: we have some definite parallels with how tables work
   Tab: Might makes sense to align
   Tab: E.g. apply table border concepts to template slots
   Tab: Do we want to redesign this, or treat them as applying to both
   Peter: things like border-collapse could apply to flexbox too
   Tab: Anytime I use a table, I'm almost always want border-collapsing
   Tab: I think most times for templates I'd want to collapse the borders
   fantasai isn't sure if that's the case, a lot of designs put margins
            around their boxes
   Tab: I think the biggest problem is making sure the drafts have some
        life into them
   Tab: All three are extremely important to me as a web designer
   Tab: Static design right now is workable, but bloats my markup and
        requires many compromises
   Tab: I would make many sites faster and easier if I had layout modes
        like flexbox and template, and even tables now that they're
        implemented widely
   Tab: I want these specs to move and be implemented well so I can use
        them in a few years
   Bert: For the spec writing part of that, I've been thinking it should
         be possible to merge grid and template together
   Bert: flexbox is different, but some can also be used with template
         and grid
   Bert: I was thinking to put them in all in one spec. What to do with
         flexbox display values they are rather separate
   Bert: But the flex property can be applied to other things
   Tab: That makes sense I think. Grid matches really well with template
   Tab: Grid positioning basically does a static template
   Tab: Template just has some extra magic with slot pseudo elements
   fantasai: There are some things you can do with grid that you can't
             do with template
   fantasai: Although template would be better for some of the examples
             Alex had, last time he showed some interesting examples
   (they are minuted in the last F2F minutes)
   Alex describes some things you can do with grid and e.g. multicol
        interactions
   fantasai: Another thing about grid is that it creats a grid that you
             can use to align things
   fantasai: have a snap-to-grid feature
   fantasai: That you could use for flow content
   fantasai: e.g. say this box should fit its content, but should snap
             to the grid
   fantasai: and you adjust the margins to make that happen
   ...
   Bert: I wanted to do abspos the right way.
   Bert: You want to position not by numbers, but say "this is next to that",
         and "this is just as tall as that"
   Bert: I wanted to have that abstraction there.
   <glazou> hum hum http://daniel.glazman.free.fr/weblog/position__new.html
   Bert: you can put any element anywhere, but they align to each other
   Markus: I'm not sure we should merge them
   Markus: They each have their use cases
   Markus: Grid is very much a pixel-perfect wireframe thing
   <smfr> grid: http://www.w3.org/TR/css3-grid/
   Markus: I think if we merge them, we might lose the original use cases
   Markus: I see the benefit of what you say
   <smfr> template layout: http://www.w3.org/TR/css3-layout/
   ...
   Markus: Grid was intended to be a positioning system over whatever
           positioning scheme you use
   ...
   * glazou thinks that we would not have this discussion if CSS was able
            to position an element relatively to any other element, like
            P language did 20 years ago
   Alex: could just as well be the other way, the grid defined as a side-effect
         of something else, e.g. a template
   Alex: Currently it's explicit, but it doesn't have to be
   shepazu: Have you guys talked about a fallback mechanism?
   Alex: I'm not sure it makes sense to do fallback at the property level,
         you'd probably need an entirely separate style sheet
   shepazu: What about for authoring tools?
   glazou: Depends on if you need to preserve ... relation of prose
   glazou: If I used this I wouldn't care about legacy browsers
   shepazu asks when can browsers be relied on to support this stuff
   fantasai: You'd need a media-query-like thing
   fantasai: for something like this
   glazou: This has come up many times before
   shepazu: Yes. Is that a stupid question?
   glazou: No, it's important
   ...
   shepazu: It's come up in dom3 events
   * glazou said it's not the 1st time we want to do one thing if one couple
            (property/value) is parsed and something else if not
   * glazou just for the record http://www.glazman.org/weblog/dotclear/index.php?post/2009/03/04/CssHackz
   * glazou and http://www.glazman.org/weblog/dotclear/index.php?post/2009/03/22/CssHackz-2
   shepazu: Before, hasFeature only worked on a very gross level
   shepazu: e.g. do you support Mouse Events?
   shepazu: if you support 5 events and not 1, then can you say you support them?
   shepazu: It's very hard to say at a group level whether a feature is supported
   shepazu: but if you have granularity, do you support this aspect of grid,
            then it's much easier to get an accurate response from the browser
   Tab: You'd still run into bugs
   Tab: That's something that JS-based feature testing can do
   Tab: Maybe you just defer to JS
   Brad: Then JS has to be turned on
   fantasai, glazou: testing at the property: value level is probably good enough
   fantasai: If you need to detect specific bugs, /then/ use a JS library
   fantasai: but at the property: value level, then it's probably usable
   fantasai: it's unlikely a browser would lie about hat
   Peter: back on target
   Tab: Personally I like the idea of template being built on top of grid
        and aligning a grid onto a box
   Tab: Then you can align other boxes onto that grid (????)
   Tab: But it works the other way for tables ...
   * fantasai is not understanding enough to minute correctly
   Alex: I don't think merging the specs would help to resolve these questions
   Alex: I prefer keeping it separate as a coordinate system
   Alex: doesn't say what you use it for
   Alex: or where it's coming from
   Alex: Just defines a grid
   Alex: make sense and can be implemented
   Alex; they don't have to merge to be able to interact
   Tab: The only problem I have
   Tab: Is if you have e.g. on the body both a template and a type grid
   fantasai: I think you should be able to have multiple grids on a element,
             name them, and be able to align differnet things to different grids
   Markus: Keeping the specs separate also makes implementing easier, faster
   Tab: I think multiple grids is useful and important
   Tab: And should be addressed if we want grid and template to interact nicely
   shepazu: While I appreciate your case, just from a deployment standpoint,
   shepazu: I'd rather see something like this implemented at a simple level
   shepazu: Than talk about how to merge them
   shepazu: It seems to me that grid is solving a lot of cases designers
            care about
   shepazu: slowing it down to add templates doesn't seem like a good idea
   Tab: I want template to be done
   shepazu: I don't know template as well  :)
   Tab: A table defines its grid along its borders.
   Tab: A type grid, you align your table cells along that grid
   Tab: you give the table width and height to that grid
   Tab: In that case you want multiple grids
   Tab: you'll be introducing other grids along the way
   Tab: I think it's useful to do so
   Tab: but you still want to maintain access to your original type grid

   Markus: To move these specs forward.. what are you asking for?
   Markus: Do you have specific feedback on this? Then we can look at your
           comments and address them and move forward
   Markus: or are you asking ... or are you asking just how they itneract
   Tab: Right now there's a note in the spec saying that it interacts with
        other specs
   Tab: And thats the area where I want more attention
   Markus: To move theses things forward, we need to go through the
           process to make that happen
   markus: Here that means working through the issues
   Markus: If there are no issues, then we leave the note and do nothing
   ...
   Tab: The note suggests right now an interaction that I don't think is good
   Alex: The note just says the interaction might not happen, removing
         it doesn't change anything.
   Tab: If grid and table don't interact and there are no plans for it,
        I'd like to keep it that way
   Alex: Maybe someone comes in and implements that.
   Steve: I'm losing track of where this discussion is going
   Steve: I don't see any concrete proposal to discuss
   Tab: I'm getting there
   Chris: I think the discussion start with "shouldn't we merge them
          because they do the same thing" and has gotten to "no they're
          doing different things" and now we should move on
   Tab: If we're going for simplicity, I'd rather there not to be a
        suggestion that tables create a gird
   Tab: I want it either removed, or something stating that it will
       be added later
   motion to remove note
   RESOLVED: remove note about interaction between grid and tables
   Peter: While we're on the topic, can we get better traction on these modules?
   Chris, to MSFT: You could ship your experimental implementation.
   Steve: There are two things missing
   Steve: One is an agreement that people will focus their attention on
          at least one particular one of the mechanisms and make some
          progress there
   Steve: I tend to agree with Tab's comment that there are too many
          mechanisms there
   Steve: There are too many, so people say there are too many, and I
          won't do anything
   Steve: The lack of agreement on one thing everyone will try and do
          is one of the blocks.
   Steve: Second thing is, esp with grid, there are open questions on
          syntax etc.
   Steve: Some things talked about in 2007 that need to get addressed.
   Steve: e.g. backwards intrusions of flaots
   Alex: Grid invites that kind of positioning ...
   Steve: syntax and sizing...
   Steve: Basically there are still open issues on grid
   shepazu: experimental implementations would help
   Bert: There are three prototypes for template
   Bert: Cesar's JS implementation, a JQuery implementation, and
         Andrew's htmllayout implementation
   shepazu: MSFT is interested in grid. Mozilla or Apple?
   shepazu: Is it a matter of priorities, or a matter of not liking the
            technology?
   dbaron: I don't know enough about the tech to answer
   ACTION Alex: remove note from grid wrt table interaction sect 4.something

Received on Thursday, 12 November 2009 23:22:41 UTC