[CSSWG] Minutes Santa Clara F2F 2014-10-28 Part II: Selectors 4, Fragmentation, Transforms

Selectors 4

  - RESOLVED: unprefix :dir and :lang
  - The current goal with selectors 4 is to separate the unstable
      bits out and put them in level 5 so that the spec can make its
      way through CR.


  - The remaining issue of how to handle containers with no break
      opportunity was agreed to be no data loss for all container
  - RESOLVED: Publish a new WD of Fragmentation and give 6 weeks for
      feedback before CR


  - smfr's proposal for a new "3D rendering context" concept and
      Robert O'Callahan's counter-proposal were discussed with a
      focus on the 'preserve-3D' property and how much memory would
      need to be allocated for smfr's proposal.
  - A point of particular concern was what the author's expectation
      is for when 2D and 3D elements would intersect when the 3D
      item is rotated.
  - There was discussion of inheriting transform-style.
  - Those interested in Transforms will look over smfr's results and
      discuss further.


  Scribe: dael

Selectors 4

  dbaron: I stuck this on the agenda because I want to get to some
          things. At some point we should stop adding features and
          advance it?
  fantasai: I think I want to trim it to the things that will go to
            CR when I have time. Make a cut and put everything else
            in level 5. But that was my goal last year, so I don't
            know if it will happen this year.

  fantasai: I would be happy to take a resolution that :dir should
            be unprefixed.
  glazou: So to do that, does the WG think it's stable enough to do
          it and second are all implementors okay?
  glazou: So objections to it being stable?
  fantasai: :dir and :lang are quite stable, the syntax is obvious,
            and it's well-defined and already implemented.

  SimonSapin: Do you think the complex language matching is ready?
  fantasai: We're just pointing to it. I think Microsoft implements
  glazou: There were bugs in browser implementations about :lang
          where one rendering language wasn't parsing more than one
  glazou: It was a bit back. Make sure it was fixed.
  glazou: Second question, implementors, you okay with unprefixed

  RESOLVED: unprefix :dir and :lang

  florian: Do we have a test suite?
  fantasai: I think Mozilla does.
  florian: It would be good to share so people who were prefixed get
           it right.
  <ArronEi> There are very few test cases
  <ArronEi> I will put the selectors 4 on my list
  <ArronEi> ... for more cases

  glazou: Anything else on Selectors 4? Test suite? Very few cases,
          can we have more?
  fantasai: Mozilla implemented so I'm sure they have a bunch of
            test cases. I'm not sure where.

  dino: Has there ever been a proposal for an OM API to be able to
        set a pseudo-class on something? Like if you want to set the
        initial-letter on a div.
  TabAtkins: That's a pseudo-element.
  glazou: So astearns and I suggested an API a way to create
          programmatical psuedo-elements. I'm not sure it got
          consensus, but I think it should happen.

  florian: On this topic it doesn't look like the test stash from
           Opera will help. I went through the repo and they're
           barely there.
  glazou: It would be good to have more tests.

  glazou: Anything else on Selectors 4 dbaron ?
  dbaron: That's it. We have a bunch of JS scripts that would need
          to be rewritten, but they're straightforward.


  <astearns> issue in this section:
  Rossen: fantasai and I spent time cleaning up. We think we figured
          out the outstanding issues and cleaning up the language.
  fantasai: There's one issue open, let me pull it up.
  dbaron: What's the next level?
  fantasai: I think we need to republish as a WD, ask for review, go
            to CR

Unfragmentable Objects

  fantasai: We say that if you have something you can't fragment,
            you can fragment anywhere.
  fantasai: For example with inline blocks, there's no break
            opportunity possible within a line box
  fantasai: You have an inline block on a line box, it happens to be
            1 1/2 pages. You can't fit it on one page. We have
            language that says if you're printing and have a thing
            that doesn't have breaks and will not fit, you can break
            whereever you want so the content doesn't disappear.
  fantasai: The issue was, do we want this for other fragmentainers
            such as Regions and multi-column?
  fantasai: The default is no data loss for printing. For regions
            and multi-column you might be able to scroll to see it
            another way, but it's probably easier from
            implementations to only have one way to fragment so we
            were thinking for this level we should be consistent.

  fantasai: That was our proposal for closing this. Is there a
            different perspective?
  dbaron: I'm fine with it, though I don't think slightly different
          printing rules is that big a deal.
  astearns: We need something saying what happens with other
            fragmentainers and the printing models is a good
            starting default. If we need something else we can add.
  florian: Given that the proposal is do what you need to to make it
           fit, we can check again later.
  florian: It gives room to play around.
  fantasai: So we'll close as apply to all fragmentainers. I think
            that's all the fragmentation issues. Anything else let
            us know. We'd like a resolution to publish a new WD with
            6 weeks for review and then publish CR
  RESOLVED: Since unfragmentable elements must be sliced to avoid
            dataloss when printing, this behavior applies to all
            types of framentatation.

Feature Set

  dbaron: What's in the draft for new features?
  <dbaron> ... as opposed to just specifying things better?
  fantasai: We added the break-before and break-after property. We
            have new values for forced break: always and any. We have
            added the recto/verso values.
  fantasai: 'always' forces a break through all the levels, so if you
            have a region in a pagination etc you break through all
            the things.
  fantasai: We also have some values for regions spec things in
            addition to column and page spec. They're going to be at
            risk because it depends on where the regions spec goes.
            I think that's it for new features.

Floats and Fragmentation

  Bert: A float is a fragmentainer?
  fantasai: It's not.
  fantasai: Unless it's a region.
  Bert: Yeah. I was wondering if it's a useful case to include
  fantasai: Technically a line box is a fragmentainer, but we put it
            out of scope.
  Bert: I can imagine someone doing a three column layout and
        wanting a break mid-float.
  astearns: Unless there's somewhere else for the content to go.
  Rossen: You can make a region inside a float.
  Rossen: If you have a region inside your float, sure you can have
          three floats and call your content through there. Then
          you'd be fragment context in a region in a float.
  Bert: So I can page break in a void, but I can't use page-break
        for any inside a float. So it would break over two pages,
        but I don't have full control as to where. I can suppress a
        break, but not force a break.
  Bert: Seems asymmetric. I can do that with a region, I assume, but
        not a float.
  Bert: Sounded like the extra keyword of any would do it.
  Bert: I have to think more about that. I'm wondering why float
        isn't a fragmentainer.
  fantasai: Because it doesn't cause fragmentionation. A
            fragmentainer is a page, column, or region
  Rossen: It's what happens inside, not outside.
  Bert: A page break can occur mid-float.
  Rossen: It's the content inside a float
  fantasai: If you force a page-break inside a float, the
            fragmentainer what's important is the page, not the
            float. You can do a page-break inside a float. We define
            how that works, but the page isn't a fragmentainer, it's
            a containing block.
  Bert: The float has a flow.
  Rossen: Just like a table cell.
  fantasai: It doesn't make it a fragementainer, just a containing

  Bert: It would still be useful to indicate where in the float I
        want to break it.
  fantasai: Use page-break.
  florian: You don't want floats to break across a page. That's not
           what we're doing, you can't split the float in half
           without splitting the page in half. Floats don't break
           without being in the page.
  Bert: If you break before always, any content after the float is
        on the current page.
  fantasai: The effect of the page-break is only on the parallel
  Bert: So it is for a float. So fragmentainer isn't the word I was
        looking for.
  Bert: OKay. That's what I wanted.
  fantasai: Alright.

Publication Plan

  Rossen: Publish a WD of fragmentation and give 6 weeks for
          feedback before CR?
  <bkardell> +1
  glazou: Objections?

  RESOLVED: Publish a new WD of Fragmentation and give 6 weeks for
            feedback before CR

  glazou: I have to leave for the AC meeting.
  plinss: Transforms next?


  smfr: I recently updated the ED of transforms to contain new text
        for the description rendering of 3D transforms
  smfr: This section on transform rendering is rewritten.
  smfr: The first part is 2D transforms which we're clear on. 3D is
        the new part.
  smfr: Initially it talks about perspective. 6.1.2 describes how 3D
        transform elements are rendered, how they interweave and
        intersect with non-transformed elements. This was unclear
        before so this is making it good enough to implement.

  florian: Was it unclear or unintentionally ambiguous?
  smfr: Unclear. I added a 3D rendering context. Analogous to CSS
        stacking. It's a set of elements inside of which the 3
        transformed elements are altered and can intersect, but are
        then flattened into a plane, just as stacking is flattened
  smfr: The way I spec'ed it here I mirrored the behavior of
        stacking context in that an element with z-index of -1 will
        go behind the content and other descendants.
  smfr: Let me show you pictures. This is on the wiki and I have a
        link from transforms as the first issue.
  <smfr> https://wiki.csswg.org/spec/intersection-of-transformed-and-untransformed-elements
  smfr: If you look at the blue box and compare to pale blue box,
        you'll see it's behind and that's the CSS2.1 order
  smfr: Now an element with a negative z-translate will go behind
        and a positive will go in front.
  smfr: This is the rendering the spec property where the order is
        the backgrounds and borders order. Where the z = 0 plane
        it's the standard rendering. On top of that is the positive
        translated content.
  smfr: This is the ideal behavior that the spec describes.

  smfr: A consequence is it's possible to intersect translated with
        the untranslated element.
  smfr: One of the issues is that this spec requires UA to basically
        render the root at two planes so it can do intersections.
  smfr: The problem is it could force UAs to allocate twice as much
        memory for some elements, so I have some concerns, but it is
        basically the ideal behavior.
  smfr: On the ML Robert O'Callahan proposed an alternative where
        translate z-1 is on top and if you rotate it wouldn't
        intersect. It's a bit more special case, but would allow
        browsers not to allocate twice as much memory.
  smfr: One consequence is what happens...let me go back to the spec
  smfr: The issue we described is issue 3.
  smfr: There's more subtle ones about UA implementation details and
        if you intersect z=0 planes sometimes.

  smfr: krit asked if this is flattening. In the spec we have 3
        values for the transform-style property.
  smfr: There's a new 'auto' which is the default. It means ignore
        this for the purpose of computing 3D
  smfr: 'flat' is make it flattening and it's a 3D rendering context
  smfr: 'preserve-3D' is the special one where We allow descendants
        to live in the same 3D space.
  smfr: So the default is auto which lets them live in the same
        space and maybe intersect.
  smfr: There's things that required flattening, like clipping,
        opacity. But default transform and perspective also cause
        flattening. With transforms people want to build a 3D
        hierarchy. If an element has a transform the author can
        override the flattening.
  smfr: The role of transform-style is controlling if transforms in
        perspective cause flattening. The root flattens by default
        which is simple.
  smfr: The previous had wording as to if elements belongs to 3D
        context, now it says every element belongs, like stacking.

  smfr: The main issue to discuss is the one I showed you because
        that influences...before I can write test cases
  smfr: Robert proposed the second.
  krit: What's the reasoning?
  smfr: Be efficient for UA.
  vollick: So it's possible to have a bunch of 3D sorting at the
           same time.
  smfr: You do it in the 3D rendering context you belong to. It has
        access to 3D rendering context. That happens no matter which

  smfr: One impact of Robert's model is position:fixed won't
        intersect 3D transformed items. So a position:fixed would be
        like it's in the z=0 frame. I think that's a downside of
        this model.
  smfr: It would be possible to have a combination, it's not
        impossible, it just is in some configurations.

  MaRakow: Can you talk about how the new values would be used. If I
           have an item with preserve-3D?
  smfr: That was a mis-nomer. Preserve prevents flatting, not
        creates it. They would probably set preserve-3D to flat,
        though that would likely be the default. It's only used if
        you want to override the default.
  MaRakow: So every element would have auto except the root of the
  smfr: Preserve-3D would only be used on transformed elements that
        want to live in the same 3D space.
  MaRakow: I'm trying to figure out how it's different from
  smfr: It's been suggested transform should inherit. I didn't do
        that because it would cause flattening in places we don't.
  MaRakow: What's an example?
  smfr: webkit if you have a perspective element and then a div, in
        most cases transform respects perspective.
  MaRakow: Is the middle div already transform-style: flat?
  smfr: It's more like auto.
  smfr: I think we may be willing to make it inherited. It
        simplifies it.
  MaRakow: That seems like a more existing concept as opposed to the
           children behavior.

  MaRakow: Going back to z-index, I think the negative z-index would
           be a pain point.
  smfr: So you favor Robert's behavior?
  krit: There's interoperability for that.
  smfr: It has weaknesses. If it had a 2D transform it wouldn't
        interweave with a 3D. The spec would have to have special
        language saying it pops to the front. We would have to
        actively prevent interweaving.
  MaRakow: The 3D rendering context is gone?
  smfr: It's there, but morphed into an example.
  MaRakow: Because they're in the same 3D rendering context you have
           to have the 3D?
  smfr: In this example everything is in the same context. I guess
        the natural is by mirroring the left, but the one on the
        right is Robert's, where anything with 3D pops to the front.
        I think it's weird because anything that's 2D isn't part of
        that set of depth
  plinss: Also if you're 3D into the z-plane you'd expect it to be
          behind. I accept it's easier to implement, but is it
          rational? Does it give the expected behavior?

  MaRakow: What seems odd to me is the scenario between the text and
           background where it's splitting.
  smfr: But you have to implement that.
  MaRakow: I wouldn't say we enjoy that.

  florian: TabAtkins, any thoughts from google?
  vollick: I have a preference to the proposal from smfr.
  krit: That proposal is more what users would expect if they
        understand z-index.
  smfr: We may have to do implementation experiments and come back.

  krit: So does he object to your model?
  smfr: He agreed with my comment where it would force implementors
        to output more memory.
  smfr: Maybe implementations can be smart and know if they won't
  smfr: I guess with animations it's hard.

  MaRakow: Does this do that much if everything is in the same 3D
           rendering context?
  smfr: It's hard to know compatibility risk because implementations
        are different. For webkit I intend to only do this for un-
        prefixed, but other browsers don't have that luxury.
  krit: We created a lot of tests to observe behavior and for many
        tests, each browser was completely different. Current
        behaviors can't align.
  MaRakow: Previous design was such that it required you to declare
           here's where the content is. I'm hesitant to give that
           aspect up because it makes it easier to think of 3D and
           makes it more backage.
  smfr: It's easy in the current but existing content might have
        issues. Making transform-style inherit might solve those.
  MaRakow: In the new model you might have to wrap in a container
  smfr: The perspective property calls it flatting too so you end up
        with three contexts. I don't think compatibility risk is too
  MaRakow: I'd like to explore inheritance more.
  smfr: Okay.

  smfr: Other feedback?
  Bert: It's complex. I've given tutorials, but perspective is weird.
        What I never succeed at explaining is transform-style. You
        try it and it doesn't work the expected way.
  smfr: That's because existing implementation isn't consistent. The
        new spec is more specific and the scope is limited.
  Bert: Why do I need it?
  smfr: Hierarchies of elements with 3D elements. You often do
        siblings and you don't need transform style. If you want a
        descendant of a face of a cube to have its own transform you
        need it.
  smfr: If you think of it like CSS Stacking, a transform is like
        z-index: 0 - it causes flattening, but you can override with
  Bert: So if you take a cube and then make it rotate, the cube
  smfr: You'd want preserve-3D on the container. There's subtlety,
        it's about making an element not flatten. It allows its
        descendants to share the 3D space it lives in.
  smfr: There's a lot of content about preserve-3D for perspective,
        but you only need it on descendants.
  smfr: You don't need preserve-3D on the root of a 3d scene.

  plinss: If I have a minor component and I want it to participate
          and it has a random ancestor, I need to set the preserve
          on the ancestor, not the child. I get technically why, but
          as an author you may want the other way around.
  smfr: We have the opacity property that forces stacking because
        the way it's spec'ed. You enter the descendants opaquely.
        Preserve-3D is render with the opacity and then combine. We
        don't have that for opacity, but that's the equivalent.
  plinss: That's the way it should have worked, but the other way is
  MaRakow: From the author perspective, I think they're used to it
           being 2D and when you're in 3D you're asking to flatten
           at a certain point.

  smfr: In the new approach, sibling transforms will intersect. I
        think it's the correct behavior. It's a change, but I found
        it hard to write text to formalize the other behavior.
  MaRakow: I think that's true for members of the same scene from an
           author perspective. I think it makes sense for those to
  MaRakow: What's weirder is the cases where they intend to isolate
           and it happens to be that it's near other content that
           they thought of as 2D, but now it intersects.
  smfr: So you're concerned about intersection with?
  MaRakow: I think the author doesn't think of the non-3D section
           being part of the transform.
  smfr: So you'd prefer the second?
  MaRakow: I think they should be capable of intersecting, but
           that's not the default expectation.

  smfr: I think the choice between the two of if you get depth
        sorting by default, the pro is it's more like z-index and
        more consistent of a default, but it's more resource
        requiring and may have unexpected intersections. Also 2D
        transforms don't interact in the same way as 3D.
  smfr: In our implementation some descendant with something special
        will start intersecting and we'll have to turn it off in a
        funny way.
  MaRakow: I don't have a strong opinion, but if the feedback is
           "I'm not sure which", I think we should avoid the
  smfr: I think the feedback will go away.

  smfr: Other comments?
  krit: In this case you spec on the container itself. I think I
        would expect it to intersect the text by default.
  plinss: It seems like a reasonable default. I think you should let
          the author opt, but it makes sense.
  smfr: I think flippers and stuff will still work as expected.

  krit: You're unsure if an author thinks it's better to have
  MaRakow: I think the main thing is as an author I don't expect
           everything in my page to participate in 3D.
  krit: In this case?
  MaRakow: I'm not sure. I have to go figure out.
  smfr: We've seen people put perspective on the body, but mostly
        they want a 3D scene.
  MaRakow: It's hard to think about it in terms of test cases
           because I'm not sure about more active applications. Have
           you guys implemented this?
  smfr: I've done part. The transform-style: auto value, but not the
  MaRakow: Did you get feedback?
  smfr: Great.

  plinss: So are you looking for a resolution?
  smfr: Looking for implementor and author feedback.
  krit: MaRakow, do you want to look at it again?
  MaRakow: Sure. I'd like to see what your results are.

  plinss: More transforms?
  plinss: Everything else folks wanted in the afternoon.
  plinss: What about animations?
  Rossen: sylvaing wanted that.
  smfr: I think we wanted to do that at 3pm.
  fantasai: Text?

Received on Friday, 2 January 2015 14:53:21 UTC