[CSSWG] Minutes and Resolutions 2012-06-20

   - RESOLVED: Proposed edits to CSS2.1 accepted pending dbaron's review
               and acceptance:
   - RESOLVED: order affects painting order
   - Discussed handling of replaced elements as flex items; fantasai
     to summarize discussion for resolution next week
   - Discussed how to handle background-attachment: fixed; in transformed
     elements; vendors to investigate their implementations
   - RESOLVED: add recto/verso values to (page-)break-before/after in css3-break

====== Full minutes below ======


   Rossen Atanassov
   David Baron (late)
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Koji Ishii
   John Jansen
   Brad Kemper
   Peter Linss
   Divya Manian
   Alex Mogilevsky
   Anton Prowse
   Florian Rivoal
   Dirk Schulze

<RRSAgent> logging to http://www.w3.org/2012/06/20-css-irc
Scribe: fantasai


   plinss: additions to agenda?
   smfr: transforms and fixed backgrounds
   florian: at bottom of agenda, leftovers from f2f, some have been
            addressed and should be removed
   fantasai: an issue on counter style case-sensitivity


   plinss: everyone had an action item to review this
   antonp: So, this is an issue about introducing a new term "formatting
           context" which will cover things like BFC but also be used to
           cover things like "flexbox FC" and "table FC"
   <glazou> #antonp { speech-rate: slower; }
   antonp: It came up in the Flexbox spec, because its children are not
           formatted as blocks
   antonp: Realized it would be useful to have a term simply "formatting
   * sylvaing once again, antonp makes me question whether digital really
              is faster than analog
   antonp: would solve problem in specs currently, e.g. for overflow it
           should apply to a wider class of items than just block formatting
   antonp: similar issue with containing block
   antonp: answer here is an element that establishes a formatting context,
           not just a block formatting context
   antonp: this also speaks to some bugs we have on 2.1
   antonp: related to the fact that currently we have problems with
           definitions of overflow and containing block because they do
           forget to handle tables
   antonp: These edits would fix those bugs and give us a nice editorial
           hook for future specs
   florian: after reading what was written and listening to what was said,
            I think the logic makes sense
   florian: I don't feel comfortable enough that I know enough details
            to be sure this all works
   florian: I therefore hesitate to vote for it
   fantasai: I think these edits are correct (I wrote some of them).
             Would like to hear from dbaron too though
   arronei: I think these changes are fine, but wondering why we're editing
            2.1 here
   arronei: 2.1 isn't completely clear here, but it's not obviously wrong
   arronei: why not just start a CSS3 spec
   fantasai: Our current specs depend on 2.1 right now, not on non-existent
             or early-draft specs
   plinss: I'm also concerned about editing 2.1, but also see the problem
           with not having equivalent text in level 3
   proposal - resolve pending dbaron's approval
   Rossen: Is this going to have any changes to the behavior of tables?
           Or is it just editorial?
   antonp: When there was a lot of rewriting of blocks and boxes and things,
           there were some thing that were broken as part of that
   antonp: e.g. overflow used to apply to tables, but doesn't as a result
           of that
   antonp: basically the edit there is taking the spec back to what it was
           supposed to be saying
   antonp: we can fix those two bugs by being very explicit, and just say
           exactly which boxes are affected
   antonp: but the primary motivation for using this term is that CSS3 specs
           need to use it
   antonp: since it's useful to 2.1 and 3, better to make these edits
   Rossen: just concerned about introducing any implementation changes to 2.1
   sylvaing: the question is, do we need to change testcases. If yes, then
             we need to take a closer look at this
   sylvaing: If there are testcases, should be part of the proposal
   antonp: I believe there are testcases, part of the reason these bugs were
           filed was because they didn't match the testcases
   <sylvaing> bringing the spec in line with the test suite is fine imo
   RESOLVED: Proposal accepted pending dbaron's review and acceptance


   fantasai: First issue is, does the order property have an effect on the
             z-order/ painting order
   fantasai: do you follow document order when painting, or do you follow
             the order-modified order
   alexmog: also tab-order
   fantasai: that's a separate question
   fantasai: tab-order and speech order affect a11y. Probably order shouldn't
             affect speech order; part of the point is to affect the visual
             order without affecting the logical order used for linear
   smfr: From implementation perspective, would prefer if flex order didn't
         affect painting order
   alexmog: I think these are related, if we make tab-order change, then
            z-order should also change
   alexmog: from accessibility pov, whole point of changing order is that
            you don't change your tree, you only change little bit in cells,
            it looks like the order is different
   alexmog: tab dialogs, one item's bring to front
   alexmog: you still read stuff in original source order
   smfr: if you have flex order affect painting order, the author puts in
         z-index, what happens?
   smfr: what stacking context are you using to paint the flex items
   smfr: can items interleave with flex items
   fantasai: z-index still works as usual
   fantasai: but if z-index has same number or auto, you use document order
   fantasai: question is, does 'order' affect the document order fallback
             for painting, or do you just you straight-up document order
   alexmog: the last time we discussed this, a couple years ago, we concluded
            at that point that reordering is a major enough change that
            everything looks as if it really was in a different order, and
            it makes sense to actually render in this new order
   alexmog: nobody could come up with use cases where it's important to
            preserve source order for painting
   alexmog: if there is any overlap of items, if it is ever intentional,
            painting order that matches order in flexbox would make sense
   fantasai: IIRC, webkit prefers painting order to be affected; for Mozilla,
             we can go either way, but I think simplifies our implementation
   alexmog: IE reorders by order, and it does simplify implementation
   smfr: if webkit impl is ok with it, then fine with me
   antonp: [...]
   antonp: if you make 3-column layout, you probably want each column to be
           stacking context anyway, would use z-index anyway
   florian: I think I'm hearing most people wanting painting order following
   plinss: Yes, though I'm hearing some concerns about tab-order
   fantasai would like to tackle that as a separate issue, since it affects
            other things
   Rossen: do we have a similar thing for grid?
   alexmog: Discussed in grid, in grid there is no order, everything is
            explicitly placed into its slot
   alexmog: no sequence in grid, so not applicable there
   alexmog: if at some point order is universally applicable, then it should
            be treated same way wherever it's applicable
   plinss: proposal is for order to affect painting order. Any objections?
   RESOLVED: order affects painting order

   fantasai: Current spec text goes with Proposal A, based on Hamburg
   fantasai: proposal A can be recast in terms of proposal B at a later point
   alexmog: I would prefer to revert to the old wording
   alexmog: Someone said it's a problem with replaced elements vs. non-replaced
            elements having different styling during loading
   alexmog: whatever browser does this cannot pass Acid2
   florian: for me that's not the motivation
   florian: we're doing this because these elements have the wrong display
   florian: for other things the user can change the display type to whatever
            they want
   florian: Proposal B lets you opt out
   fantasai clarifies that Alex is asking for previous WD's behavior, not A vs B
   dbaron: what happens if an element is replaced due to CSS3 'content'
   alexmog: the same (follow the rules for whether 'width' and 'height' apply)
   florian: I like proposal B best
   florian: I would not like to be stuck with Proposal A forever
   florian: what Alex is saying sounds suboptimal to me but is acceptable
   alexmog: I can live with any of those, just seems inconsistent that
            replaced inline elements have special behavior that's already
            defined an known
   alexmog: and object fallback depends on those

   fantasai: One complication here is that Mozilla falls back to inline
             when <img> elements don't load, but some other browsers treat
             them as inline-block
   fantasai: whereas I believe some other impls don't
   fantasai: so you'll get different results
   some questions on what is the correct behavior
   <dbaron> I don't see anything in html5 saying img should be anything
            other than display:inline when there's no resource
   <dbaron> same for canvas
   antonp: I think it make sense for these elements to have special behavior
   plinss: have 3 proposals on table, not hearing consensus
   florian: To me Proposal A is only acceptable because we can later switch
            to B
   florian: To me it doesn't make sense to have A in the list because what
            I want is B
   fantasai: I think I'd like to summarize the situation and resolve when
             Tab's back
   fantasai: Anything else to add to summary?
   florian: Does anyone disagree that B is better than A
   antonp: I think A should be followed by B, but not sure it should be
   florian: concerned that we might be stuck with A if it takes too long
            to do B
   fantasai: don't think we'll get stuck with A, B just has A implemented
             as ua.css rules
   fantasai: Have a bigger problem that might get stuck with flex items
             returning 'display: block' and can't change to returning
             'display: flex-item'
   alexmog: if A or B, would rather do B

   alexmog: yet another thing to do would be to treat any element that is
            a direct child of flexbox as a flex items
   alexmog: from all use cases we have, anonymous text in flexbox is not
            a use case
   alexmog: just do something to not lose content when it's there
   alexmog: could just have any element, e.g. <b> or <i>, be a flex item
   alexmog: you'd get weird results if you have formatted text in a flexbox,
            but that's not a use case
   ACTION: fantasai summarize discussion

Background Attachment and Transforms

   <plinss> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17521
   <smfr> http://www.w3.org/TR/css3-transforms/
   smfr: In CSS transforms spec there's a sentence that says
   smfr: [quotes spec]
   smfr: and there's a note that this behaves like a porthole -- you see
         the background through the porthole
   smfr: this kindof makes sense for 2D transforms, but for 3D it's
         extremely hard to implement
   smfr: Making that element behave like a porthole where you see an
         untransformed background
   <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17521
   smfr: one possible amendment to the spec would be to say that
         background-attached: fixed affected by transform is treated
         like scroll
   fantasai: Would it make sense to have the fixed background be transformed
             with the rest of the element? Rather than just ignoring fixedness
   florian: would make sense, why would you do that as an author?
   smfr: Your suggestion is tricky because how you render that background
         before applying that transformed
   smfr: so, you render the element as if screen-aligned, then transform
   smfr: not sure what left/top offset you'd use
   smfr: when you scroll page you'll have this shifting of that background
   krit: background should transform with the element
   smfr: dbaron gave us some history, that bg-attach fixed was only intended
         for the root element.
   smfr: sortof crept into applying to other elements
   smfr: any other implementers with feedback? IE?
   <dbaron> I'm sure Gecko does something, but I don't know what, and it's
            hard to work out what's hard off the top of my head.
   arronei: Not sure, have to look that up and check
   florian: I don't know for Opera
   smfr: maybe get action items from other vendors to investigate
   florian: from our POV, probably too early to tell
   sylvaing: pretty sure we don't do porthole thing, but I'll check what we do
   krit: are there test files?
   ACTION: smfr make a testcase
   <trackbot> Created ACTION-477
   ACTION: florian ask Opera wrt background-attachment:fixed and transforms
   <trackbot> Created ACTION-478
   ACTION: dbaron check Gecko wrt background-attachment:fixed and transforms
   <trackbot> Created ACTION-479
   ACTION: sylvaing check wrt background-attachment:fixed and transforms
   <trackbot> Created ACTION-480
   plinss: should also give some thought to what the right thing to do is
   bradk: Sounds like if the bg was large enough, and coordinates ok,
          could have portal effect look good
   deferred to next week

page-break: recto/verso

   fantasai summarizes
   glazou: These will be easy to understand in Europe
   plinss: these are industry standard terms going back ages
   florian: sounds good to me
   RESOLVED: add recto/verso values to (page-)break-before/after
             in css3-break

Meeting closed.

Received on Wednesday, 20 June 2012 21:00:28 UTC