- From: Aharon (Vladimir) Lanin <aharon@google.com>
- Date: Wed, 8 Aug 2012 21:43:03 -0400
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: "www-style@w3.org" <www-style@w3.org>
- Message-ID: <CA+FsOYaPOOXZ6VcOku6t5Gj8=jBSSA_9VHmRL5Qbrg=ut--=BQ@mail.gmail.com>
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