- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 08 Aug 2012 18:29:52 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Publish updated WD of CSS3 Text
- RESOLVED: Accept dbaron's overflow: repeat/regions draft as ED work item
- Status update on CSS3 Conditional Rules: @supports implemented by
Opera and Gecko teams; Opera has submitted tests. Some open issues
on OM section drafted last month -- will be discussed next week
prior to updating WD
- Briefly reviewed run-ins discussion
http://lists.w3.org/Archives/Public/www-style/2012Jul/0450.html
- RESOLVED: auto margins in grid layout behave like they do in flexbox
- Phil summarized the two main proposals for handling unpositioned grid content:
a) Automatically grid items, same way as Flexbox
b) Flow all unpositioned content into an anonymous grid item,
pulling out any grid-positioned elements directly into the grid
- RESOLVED: Errata CSS2.1 to say that 'overflow' on a table element
applies to the table box (not table wrapper box); and
that values other than 'hidden' are treated as 'visible'.
====== Full minutes below ======
Present:
Glenn Adams
Tab Atkins
David Baron
Ryan Betts
Bert Bos
Arron Eicholz
Katie Ellison
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Koji Ishii
John Jansen
Edward O'Connor
Anton Prowse
Florian Rivoal
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2012/08/08-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2012Aug/0249.html
Scribe: fantasai
Administrative
--------------
plinss: Any extra agenda items?
Markus: alignment of grid items w/ margins
fantasai: page-break / break aliasing?
Publishing
----------
plinss: WD of CSS3 Text
Florian: Sounds like a good idea to me
RESOLVED: Publish updated WD of CSS3 Text
Bert: what happened to text-space-collapse?
fantasai: white-space property is still there
Bert: what if you want no space at all?
fantasai: oh, the discard value
florian: We had discard and dropped it, don't remember why
fantasai will note it as an issue
plinss: dbaron's overflow regions/repeat draft
fantasai: Think we should put it up as ED
<dbaron> http://lists.w3.org/Archives/Public/www-style/2012Aug/0181.html
<TabAtkins> http://lists.w3.org/Archives/Public/www-archive/2012Aug/att-0005/Overview.html
RESOLVED: Accept dbaron's overflow regions/repeat draft as official
work item -> ED
Florian: pseudo-elements draft?
fantasai: haven't looked at that yet...
plinss: on agenda for f2f
plinss: Tab and fantasai's Intrinsic Sizing spec
TabAtkins: It's basically Appendix D of Writing Modes
fantasai: Think we need another round of edits, but then ready
fantasai: Let's try to have all EDs move to FPWD next week
Bert: Why is this not in the box module?
TabAtkins: It's extracted from the Writing Modes module
Bert: think box model is more advanced, though more incomplete
sylvaing: Don't think it's a good idea to have a piece that's actively
worked on in the middle of a spec of shaky status
TabAtkins: We'd also like to be able to release these sizing keywords
anton: Sad to see this not in Box Model, but understand the rationale
Anton: Wonder how many small pieces we'll wind up with
Florian: I don't think it's a problem. If this winds up making progress
faster that's good, and we can pull it back into the box module
sylvaing: point of modules is to make progress faster
Bert: results in inconsistencies across modules, though
Bert: e.g. min-width now has multiple definitions
fantasai: This is why we need to discuss things as a WG and get everyone's
attention on all the work that's going on. You'd have similar
problems with a giant spec where only some people paid attention
to some parts.
fantasai: We're building on CSS2.1 definitions, extending them where
necessary. Box Module can then pull these all together and
create a new base to build on.
Florian: If modules make progress faster, we'll have tests faster, and
if the specs are contradictory the tests will be contradictory
too, so we'll notice
plinss: Don't think now is the time to discuss whether or not to
modularize CSS.
CSS3 Conditional Rules
----------------------
plinss: We have one implementation, another coming. Want to make sure
the spec is on track
Florian: Opera has an implementation. Published a bunch of tests. Our
implementation is not public yet; still in code review
Florian: The purely-CSS part of the spec for @supports are pretty good,
pretty implementable, didn't find any issues
Florian: The DOM parts are still need more work
Florian: I think it will take awhile longer to agree on what to do for
serialization and things like that
Florian: from our POV, coming along quite nicely
plinss: Latest ED from July... previous WD last year.
dbaron: We should spend some time on the DOM stuff at the F2F, then
publish a new draft on TR
dbaron: Gecko also has an implementation; in Nightly for a week or two.
Know we pass our tests, not sure we pass Opera's tests
Florian: You fail three. I commented on the blog announcing them that
one was invalid.
Florian: You haven't published your tests, right?
dbaron: We need to sync that over at some point.
Florian: Also some of your tests use -moz-document, these I don't have
Florian: Little glitches here and there, but we have most of each others'
tests. Need to review them
sylvaing: When we talked about vendor prefixes, side-discussion of
prefixing variables/@supports
dbaron: In Gecko, we implemented unprefixed, but it's behind a preference.
On for nightly, will turn off for release depending on status of spec
Florian: We can do the same thing with a compile-time flag
glazou: Betas will have it unprefixed?
Florian: Most likely yes
Florian suggests discussing this again in San Diego with beer
and promises Opera won't ship before then
case-sensitivity of author idents
---------------------------------
fantasai is not prepared, deferred to F2F
Alternate model for run-ins
---------------------------
http://lists.w3.org/Archives/Public/www-style/2012Jul/0450.html
fantasai: [explains state of discussion]
TabAtkins: Much more in favor of this model than the previous one.
sylvaing: Was excited, because first time I understand what run-ins do
* florian +1 to what sylvain says
sylvaing: wiki page with examples of what we want to handle
sylvaing: to help us validate whether this is good, can only say it's readable
TabAtkins: started a page for collecting use cases here
<TabAtkins> http://wiki.csswg.org/spec/box-orphans
Grid Layout
-----------
Topic: Grid Items and Margin Alignment
<pcupp> http://wiki.csswg.org/spec/css3-grid-layout#issues-for-august-8th-2012-telcon
[See Appendix A for full text from the wiki]
pcupp: Treatment of auto margins and how they affect grid items vs.
flex items vs. block-level items
pcupp: There's a section in 9.3 of CSS3 Box spec that describe how we
resolve the equation relating size of box to containing block
pcupp: We want to satisfy this equation
pcupp: There's a question of where do we actually position the item
pcupp: When both margins are auto, and talking about aligning in a
fixed-size grid slot
pcupp: If item was actually larger than grid cell, we create two
negative margins, centering the item
pcupp: seemed to be aligned with CSS3 Box
pcupp quotes from CSS3 Box
pcupp: we dropped that paragraph when we implemented in IE
[the paragraph that prevents start-edge auto margins from being < 0;
issue is basically about safe vs. true alignment
pcupp: I'm wondering if it's correct to drop that paragraph, and whether
it would have been correct to drop in flexbox
TabAtkins: When you're overconstrained, auto margins reset to zero
TabAtkins: Flexbox purposely went with the same behavior because
a) it's consistent with blocks and
b) you can get true centering with the alignment properties
TabAtkins: To be consistent with what we did there, grid should do the
same thing
Rossen: fantasai pointed out earlier in the discussion that this makes
the big difference when you have overflow: scroll
Rossen: you want to be able to see all the content, but can't scroll
past the origin
TabAtkins: True centering can be unsafe, but in some cases it's really
what you want
TabAtkins: Both have their use cases. Since block already does safe
centering with auto margins, that's what Flexbox uses for
safe centering
pcupp: Ok
<dbaron> The thing TabAtkins said about flexbox choosing the opposite
option from block so that authors had the ability to do both
was interesting, and maybe worth minuting...
* scribe can't remember what Tab said, probably the point was:
In Flexbox, auto margins behave like in block layout, and do safe centering,
while alignment properties do true centering, so both are possible.
szilles: If you're doing centering, can you set it so that the scrollbar
allows scrolling to the left?
TabAtkins: That would mean the origin of the document, it would have
to start out partially-scrolled, and browsers have avoided
that as being confusing
TabAtkins: generally can't scroll into negative regions of the document
Anton: talking about top-level element, right?
fantasai: Anything that establishes a scrollbar
Rossen: position of a box is negative, could get into situation of chasing
this negative box with the scrollbar (??)
Rossen: You can come up with situations with, for example if you allow
scrolling past origin, to either left or top, the simplest way
to shoot yourself in the foot is to have an element that extends
to the left on scroll event or have a negative-pos element
Rossen: We know that web authors do negative-positioning a lot to hide element
Rossen: Allowing scrollers to scroll there would be a problem
plinss: Doing that now would be a problem, but don't see a problem for
adding an option
<Bert> (Not scrolling left is a veeeeery old bug in browsers, indeed :-(
There are many pages I can only view with Opera or Lynx, because
they have text to the left of the window, when you leave CSS
turned on.)
Anton: Don't understand why chasing an item is a problem, wouldn't
positioning the other way have the same problem
Rossen: yeah...
fantasai explains 2.1 issue on this: discussed many years ago allowing
access to items in the negative coords of the page, but couldn't do it
because so many pages positioned things to negative million pixels to
hide them; having this affect scrolling would make many pages hard to
navigate.
RESOLVED: auto margins in grid layout behave like they do in flexbox
<TabAtkins> http://dev.w3.org/csswg/css3-flexbox/#auto-margins
Topic: Default Grid Items
pcupp: Right now we establish valid items the same way flexbox does
pcupp: which recently changed to be every element
pcupp: with an anonymous inline around loose text
pcupp: challenge with grid vs. flexbox is you can't position the
anonymous inlines, so a little distinct from Flexbox
pcupp: but might make sense with auto placement
pcupp: An alternative was to wrap everything in the grid in an anonymous
grid item, call that the default grid item
pcupp: grid positioning would then pull items out of the default item
and position them
pcupp: pro of first option is, it's what we've been doing and aligns
with flexbox
pcupp: pro of second approach is that we have some ability to lump loose
text in the grid
pcupp: gives us some ability to explore positioning the loose content
TabAtkins: Advantage of the second case is that you can explicitly
position various bits, and then have the rest flow into a
main content area
TabAtkins: Have to think about it
TabAtkins: Maybe can do with different markup
Bert: If you allow the markup to change, then you can do anything without
having flows
Bert: If you don't transform the source, should be able to lay out
something in terms of a grid even if structure of document is
missing some extra divs or whatever
Bert: won't work in all cases, some cases have to transform, but can get
quite far if you allow things to flow
TabAtkins: A related topic is letting things that aren't direct children
of a grid be positioned into the grid
TabAtkins: This was a feature of Template, and imo necessary to unlock
the potential of grid layout
TabAtkins: If you have that, then this wrapper idea is in line with that
TabAtkins: If you wanted the functionality of "everything that isn't
explicitly grid-positioned is flowed into a default grid item",
you can get it with the "any element can be grid-positioned
into their closest ancestor grid" functionality.
TabAtkins: Rather than make an element A be a grid, and have its
non-positioned contents move into a default grid cell,
put a wrapper around A and make *the wrapper* the grid.
Then, the positioned elements of A move into the grid, and
position A itself where you want. This gives you precisely
the same behavior.
TabAtkins: But since this is a wrapper-based hack and is non-obvious,
I think we should bless this behavior with actual syntax.
szilles wants pictures for next week
CSS2.1
------
anton: overflow on table elements
anton: came to agreement that overflow should apply to table box, not
table wrapper box
anton: but there are some values of overflow property that aren't
supported on tables: auto and scroll
anton: testing confirms what was suspected, that all browsers treat
auto/scroll as visible
anton: Asking if we should spec that as an exception to how overflow
normally works?
Rossen: Makes sense given number of implementations with this behavior.
Rossen: unlikely that this will change
dbaron: I think we're unlikely to change this
anton: I think unless UAs desperately want to change this, then yes,
seems unlikely
Rossen: Do you propose to write the spec text for that?
Rossen: Think that would be great
anton: Do we have other examples of values that are ignored when applied
to different kind of element?
Rossen: overflow propagates to body, so [...]
anton: anyone have a preference on whether this should go into Tables
or Overflow section
anton: Thinking it should go into tables chapter
fantasai: Think it should go into overflow, since it's basically an
applies-to question
arronei: either way, should be a note in other section pointing this out
proposal: overflow applies to table box, not table wrapper box, and
values other than hidden are treated as visible
plinss: existing behavior on browsers?
antonp: yes, aside from opera/webkit weirdness
RESOLVED: proposal accepted
====== Appendix A: Grid Layout Issues Writeups ======
From http://wiki.csswg.org/spec/css3-grid-layout on 8 August 2012
=== Alignment of Grid Items versus Flex Items versus Block-level Boxes ===
Three scenarios where boxes are stretch aligned that we could make agree
in their behavior (or not):
- Resolving the width and left/right margins of block-level boxes that
"stretch" to touch the edges of their containing block
- Resolving the cross size property and cross margins of a flex item
such that its margin box stretches to touch the cross edges of its line
- Resolving the width or height and margins of a grid item such that the
box touches the edges of its grid cell (now calling this grid-area in
most recent ED)
In each of these cases we satisfy the equation:
margin_size1 + border_size1 + padding_size1 + box_size + padding_size2
+ border_size2 + margin_size2 == space afforded to item by parent container
- If box_size is auto then first we adjust it up or down to make the
equation true while respecting any min/max constraints on the
applicable dimension
- If that isn't sufficient we do additional adjustments on margins
- If only one margin was auto we adjust that one to make the equation
true
- If both of the margins were auto we take the additional space
needed to make the equation true and divide it by 2 then assign
it to each margin
- If neither margin is auto (the over-constrained case), we take
the second margin (nearest the ending edge) and adjust it to
make the equation true
When both margins are auto though, and the box is larger than the space
afforded to it by its container, a paragraph of section 9.3 for css3-box
http://www.w3.org/TR/css3-box/#blockwidth says:
If ‘width’ is not ‘auto’ and ‘border-left-width’ + ‘padding-left’ + ‘width’
+ ‘padding-right’ + ‘border-right-width’ + scrollbar width (if any)
(plus any of ‘margin-left’ or ‘margin-right’ that are not ‘auto’)
is larger than the width of the containing block, then any ‘auto’ values
for ‘margin-left’ or ‘margin-right’ are, for the following rules,
treated as zero.
We should drop this paragraph. It causes blocks that are wider than their
parent not to be centered (unlike blocks that are narrower), which looks strange.
The Grid ignores the paragraph above as suggested so that two auto margins
will always result in a centered item whenever width/height is not auto.
I noticed that Flexbox keeps the last sentence per its example 10 in the
latest ED http://dev.w3.org/csswg/css3-flexbox/#auto-margins.
=== Valid Grid Items ===
Options:
- Snap to definition of Flex Items i.e. every child element is a valid
Grid Item and runs of loose text are surrounded in anonymous items
(current ED)
- Make contents of a Grid Element wrapped in a default Grid Item
(which is an anonymous flow) and then pull elements out of that
flow and onto grid by using the grid-* properties
The first option works well with auto-positioning while the second would
require the author to write a (trivial) rule to declare that all elements
are in fact grid items: #grid > * { grid-area: auto; }
The second option could be used position descendants of the grid in
addition to just children, but breaks from the pattern established by
flexbox and would differ from IE's current implementation.
Received on Thursday, 9 August 2012 01:30:38 UTC