[CSSWG] Minutes Seattle F2F Tue 2014-01-28 AM II: Reversed Lists, Transforms, Display Module, 9-slice recap

Reversed Lists

   - RESOLVED: keep counter-reset magic for <ol reversed> lists in level 3


   - Discussed Simon Fraser's proposal for 'transform-style: auto' to make
     transform flatting make more sense by default. Details will be posted
     to www-style for discussion.

Display Module

   - RESOLVED: Add fantasai's run-in model to Display Model, with
               clarifications / fixes needed to solve bzbarsky's issues
   - Discussed various clarifications that are needed in the spec.
   - RESOLVED: FPWD Display Module

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

Reversed Lists

   tab: the lists module correctly handles HTML list rendering
   tab: except for the reverse attribute which counts backwards
   tab: if you look at the list module right now the style sheet resets
        the counter to some magic thing so we can't express this
   tab: so do we keep it magic or do we have a way to represent the number
        of children of an element
   <TabAtkins> http://dev.w3.org/csswg/css-lists/#ua-stylesheet
   simonsapin: right now this is a non-normative stylesheet so we could
               consider this magic for now
   dbaron: i think we should address this eventually but this is not a
           priority right now. and the way we do address it should not
           just be some hack like counting the number of children
   dbaron: though it's possible html defines it as...
   simonsapin: html specifies to count the number of <li>
   plinss: and does the display value impact the count?
   fantasai: HTML has a preshint-level rule that sets counter-reset
             on the list element to the number of <li> in the list
   <SimonSapin> http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#attr-ol-reversed

   <dbaron> it sounds like <ol reversed><li><li value="20"><li></ol>
            gives 3, 20, 19, which isn't quite expected...
   <dbaron> I'd rather have had a mechanism that gave 21, 20, 1
   <fantasai> dbaron, that doesn't make any sense to me
   <dbaron> reversed means "works the normal way but counts in the other
   <glazou> it is expected because reversing a list is only setting
            start a counter-increment: -1
   RESOLVED: keep counter-reset magic for <ol reversed> lists in level 3
   <fantasai> dbaron: hm, fair enough. I interpreted it as "count downwards",
              which I suppose matches the attr name less
   <fantasai> dbaron, I think counting downwards is easier to conceptualize
              as counters, though
   <SimonSapin> dbaron, I don’t think any behavior makes sense in that example


   smfr: previously i tried to clarify a couple of areas
   smfr: i would like to revise the current text slightly
   smfr: there would be a small behavior change but current interop is good
   smfr: 1) how preserve-3d works 2) what elements in the document cause
         flattening to happen are the two topics
   <shows testcase>
   two elements with 3d transforms applied to them
   no preserve-3d
   two siblings
   these elements intersect with each other but not their parent
   smfr: today the spec says this is just a painting effect
   smfr: in webkit we do support intersection. i would like this to be the
         right behavior because it simplifies the explanation of preserve-3d
   <next test>
   smfr: in this new model, if you wanted to prevent intersection you would
         need the parent to force flattening with transform-style:flat
   smfr: the next question is when does a transformed element intersect with
         its parent?
   <shows test where preserve-3d is applied to the parent>
   smfr: intersection is where there is little interop
   ACTION smfr Share transform testcases with the group
   <trackbot> Created ACTION-611

   tab: so webkit make the siblings intersect in their own space then flatten
   smfr: the spec currently explains it using '3d rendering context'
         established by preserve-3d
   smfr: it says such elements can intersect with each other based on
         z-depth (not document z-index)
   smfr: so sometimes elements are a 3d rendering context, otherwise
         they're not
   smfr: instead I'd like to say that every element is in a 3d rendering
         context but sometimes it's only one element deep
   smfr: similar to stacking contexts
   dbaron: I thought I understood until we compared to stacking contexts...
   smfr: today you're sometimes in a 3d rendering context, sometimes you're not
   smfr: whereas with css contexts, all elements belong to a stacking context
   dbaron: the default with stacking contexts is to not make a new one;
           it sounds like with 3d rendering contexts the default would
           be to make a new one?
   smfr: I think I'm proposing to change that also
   smfr: now I'm considering that transform-style:flat creates a 3d rendering
   smfr: preserve-3d extends this context through the element

   smfr: I'm proposing to transform-style: auto as an initial value instead
         of the current 'flat'
   smfr: if you have two elements with 3d transforms; parent has preserve-3d.
         its ancestor is flat
   smfr: the spec is ambiguous as to how/whether elements inserted above
         those child elements can cause flattening
   dbaron: the spec says this is containing-block based
   smfr: right. so it wasn't clear whether stacking contexts or containing
         blocks were involved
   smfr: the reason for 'auto' makes the determination of 3d rendering
         context unambiguous
   smfr: some things cause flattening like opacity, filters….if an element
         has a 2d or 3d transforms and transform-style:auto then it should
         be flattened

   dbaron: I'm trying to understand how this works with the various
           z-ordering rules that require various things to interleave
   dbaron: before this only things that established a stacking context
           could be preserve-3d
   dbaron: if you don't establish a stacking context things can interleave
   dbaron: I'm not sure what this means in this new model
   smfr: the spec would have to say that the root has transform-style:flat
   smfr: in the new model, the root creates a 3d rendering context
   smfr: ...
   smfr: transform--style:flat establishes a 3d rendering context; you
         render the 3d transform descendants, including intersections...
   smfr: then you composite those above the untransformed parents...

   dbaron: suppose the root has another child with a z-index
   dbaron: so you flatten all the 3d stuff and render it with infinite
           z-index in that stacking context?
   smfr: I think so
   smfr: when you have neg z-index, it renders behind…in this model,
         3d descendants don't intersect with the plane of what creates
         the 3d rendering context....
   smfr: I don't think there is a way that z-index can trump the 3d
         rendering contexts
   dbaron: I agree

   dbaron: it would be great to have a write-up of this
   smfr: I have one in draft form, with test cases
   dirk: this fixes a lot of issues we currently have in the spec
   dbaron: I think the intersection of this with stacking contexts sounds OK
   dbaron: what this means is that in the default case, if you specify a
           3d transform on one thing in the doc and nothing else, then
           this thing is above everything in the document
   smfr: yes
   dbaron: it seems kind of reasonable. but is it web compatible?
   dbaron: I'd like to hear from our transform experts...
   dbaron: I'm worried about compat but compat is also messy right now
           in this area
   smfr: I think this model helps explain perspective as well i.e. it
         doesn't cross 3d rendering context boundaries
   dirk: I agree we want more people to check out the proposal
   dirk: over email
   dbaron: yes
   smfr: I will send the proposal to www-style

   plinss: I'm a bit about the interaction with z-index...
   plinss: could we rationalize the two models?
   Bert wonders whether flattening is necessary
   dbaron, smfr, dirk: a bunch of things require it
   Bert: it is hard to explain transform-style
   smfr: this will help explain it.
   chris: you'll be able to say it's like stacking contexts!
   ACTION smfr to send update to mailing list
   <trackbot> Created ACTION-612

   smfr: based on feedback I'll update the ED
   smfr, dirk: no other issues to discuss
   <krit> http://dev.w3.org/csswg/css-transforms/#issues-index

Display Module Revisited
Scribe: fantasai

   <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2012Jul/0450.html
   TabAtkins: Wanted to discuss fantasai's run-in model, and whether
              to integrate it into Display module
   TabAtkins summarizes the model
   (see mail above)
   foo <runin>bar</runin>
   creates a block boundary between foo and bar
   TabAtkins: It's a remarkably simple model, and solves every problem
              we've had with run-ins, I believe.
   * liam thinks the mail looks sane and helpful
   fantasai: bz did raise some issues, but solveable by defining things
             more precisely
   dbaron: Any interesting things wrt placeholders inside run-in?
   dbaron: The whether things run in is purely computable at box-tree
           generation time? No layout effect at all?
   TabAtkins: Yes
   TabAtkins: Some box-tree mangling, but no layout
   SteveZ: So inline, but create a new block if needed
   TabAtkins: or merge into next block if needed
   RESOLVED: Add fantasai's run-in model to Display Model, with
             clarifications / fixes needed to solve bzbarsky's issues

   TabAtkins: Also, I would like to publish FPWD

   SimonSapin: Where does run-in fit into this module?
   TabAtkins: It's a display-outside value, like inline-level
   SimonSapin: Doesn't affect display-inside?
   TabAtkins: Not at all

   dbaron asks for clarification on how the shorthand handles omitted values
   ACTION TabAtkins clarify how omitted values are handled for display
                    shorthand (and other shorthands he might've forgotten
                    to handle)
   <trackbot> Created ACTION-613
   SimonSapin: What are longhands for 'display'?
   fantasai: display-inside, display-outside, display-decoration
   TabAtkins: Yes, need to specify that they get reset
   dbaron: display shorthand should be more clear about what happens with
           values listed twice
   dbaron: e.g. flex is both a value for 'display' and also 'display-inside',
           how is it interpreted
   TabAtkins: Yes, I can be much clearer about that

   florian: Does this model make sense for authors and others who don't
            have a deep mental model of how this all works?
   TabAtkins: The main motivation is to separate out display: none, the
              rest is just making things easier

   dbaron: I'm ok with publishing
   RESOLVED: FPWD Display Module

   SimonSapin: display-inside: auto;, says some cases element acts as normal.
               Should also specify what is the computed value
   <TabAtkins> (the computed value is still "auto")

<br type=lunch>

<smfr> hi leaverou!
<leaverou> hi smfr !!
<smfr> leaverou: we were talking about a 9-piece image function yday
<smfr> leaverou: not much support, and a call for use cases
<smfr> leaverou: so if you have use cases, could you share them somehow?
<leaverou> smfr: you mean for 9 slice scaling?
<ChrisL> call for use cases that aren't borders
<smfr> leaverou: right
<leaverou> hmm I think I've come across some, but can't remember them
            off the top of my head right now :/
<smfr> main comment on things like button backgrounds was "why can't you
        use user border image?"
<leaverou> what about masking?
<leaverou> like, if you were able to 9-slice-scale any image, you could
            use it for masking too
<leaverou> which you can't flexibly do with border-image
<smfr> this came up in the context of masking
<smfr> do we remove mask-box in favor of some mythical future image
        slicing function
<leaverou> that doesn't seem very wise when we already have implementations
            of mask-box
<leaverou> we can always have the image slicing function in addition
<TabAtkins> leaverou: Main issue with using it for masking is that you
             need the "outset" ability that border-image has, but that's
             nonsense for normal images.
<TabAtkins> Because normal images don't extend outside of their bounds.

Received on Tuesday, 4 February 2014 09:16:25 UTC