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

Re: [CSSWG] Minutes and Resolutions 2012-08-08

From: Aharon (Vladimir) Lanin <aharon@google.com>
Date: Wed, 8 Aug 2012 21:43:03 -0400
Message-ID: <CA+FsOYaPOOXZ6VcOku6t5Gj8=jBSSA_9VHmRL5Qbrg=ut--=BQ@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "www-style@w3.org" <www-style@w3.org>
There is a dependency between Text and Writing Modes (whether unicode-bidi
isolates create a bidi paragraph). They should be published together.
 On Aug 8, 2012 9:32 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote:

> 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<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<http://www.w3.org/2012/08/08-css-irc>
> Agenda: http://lists.w3.org/Archives/**Public/www-style/2012Aug/0249.**
> html <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 <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<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<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<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<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<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<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<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<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:43:35 UTC

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