W3C home > Mailing lists > Public > www-style@w3.org > August 2012

[CSSWG] Minutes and Resolutions 2012-08-08

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 08 Aug 2012 18:29:52 -0700
Message-ID: <50231290.204@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - 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
   - 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 ======

   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


   plinss: Any extra agenda items?
   Markus: alignment of grid items w/ margins
   fantasai: page-break / break aliasing?


   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

   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
   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


   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
         - 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 ===

     - 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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:20 UTC