- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 12 Nov 2009 15:21:57 -0800
- To: www-style@w3.org
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