[CSSWG] Minutes Telecon 2018-05-16 [css-break] [css-flexbox] [css-grid-2] [css-transforms] [cssom-view] [css-align] [css-typed-om]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Fragmentation L3

  - RESOLVED: Accept changes in
      - Change Summary- pulled out break propagation into its own
          section into CSS-break-3 and clarified that:
          - out-of-flows don't propagate their break values up to
              their parents
          - layout modes like Flexbox and Grid have more specific
              propagation rules which override the one in CSS-break-3
          - Flexbox uses order-modified document order in determining
              first/last child

Grid L2

  - RESOLVED: Add a feature that allows max to win over min in Grid
              L2, name tbd. (Issue #1102)

CSS Transforms

  - RESOLVED: SVG attribute reflects current interop, future
              improvements will be in CSS transforms. (Issue #2623)


  - RESOLVED: Add returning a promise to all scroll functions. (Issue

CSS Align

  - TabAtkins introduced issue #1432 (Rules for align/justify-self on
      static position of absolutely-positioned boxes need more detail)
      and the proposal to have align/justify-content be similar to how
      CSS 2.1 behaves for blocks.
      - There were concerns that this does not give you a true center
          for the center value.
      - Additionally it was expressed that this change in alignment
          may cause re-layout which isn't desirable.
      - Continued discussion and additional feedback are welcome on
          the github issue: https://github.com/w3c/csswg-drafts/issues/1432

Typed OM

  - RESOLVED: Allow fr and resolution units in calc functions, add a
              note to Values & Units explaining they don't combine
              with length. (Issue #734)
  - RESOLVED: Add a note to CSS Values & Units that new unit value
              types should be added to calc as they're added to CSS.
              (Issue #734)


Agenda: https://lists.w3.org/Archives/Public/www-style/2018May/0025.html

  Rachel Andrew (IRC Only)
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Garrett Berg
  Dave Cramer
  Alex Critchfield
  Dael Jackson
  Brad Kemper
  Peter Linss
  Anton Prowse
  Liam Quin
  Manuel Rego
  Fran├žois Remy
  Melanie Richards
  Dirk Schulze
  Majid Valipour

  Benjamin De Cock
  Elika Etemad
  Florian Rivoal
  Alan Stearns
  Lea Verou
  Greg Whitworth

Scribe: dael

Fragmentation L3

Fragmentation rules around break propagation are confusingly-written
  github: https://github.com/w3c/csswg-drafts/issues/2614#issuecomment-385836043

  Rossen: Summary: There were some comments made about fragmentation
          rules not being clear, especially with child/parent break
          propagation. Changes added to CSS break were intended to
          address this.
  Rossen: "out-of-flows don't propagate their break values up to their
          parents" makes sense because out of flow items propagate to
          containing block.
  Rossen: 2nd is flex and grid layout have specific propagation rules
          that override CSS 3 break. That was in tune to previous
          since we've extended fragmentation before and assume that
          overrides, but now that's explicit
  Rossen: Last is flexbox....I think also grid...order is modified and
          propagation is based on layout order, not doc order.
  Rossen: These are the changes. Issue was on the agenda to either
          accept or challenge the changes.

  Rossen: From the 3 changes, as I said, 2 are mostly editorial. 1st
          is out of flows don't propagate their break...that can be
          seen as normative.
  Rossen: Opinions? Questions? Reasons not to accept?
  Rossen: I'll take silence as no. Objections to accept changes in
  <dbaron> I think it's probably fine, but I think out-of-flows might
           be a *little* interesting, maybe?

  RESOLVED: Accept changes in

  Rossen: dbaron, you said something in IRC?
  dbaron: I think it's fine.

CSS Grid 2

Allow minmax where max wins over min
  github: https://github.com/w3c/csswg-drafts/issues/1102

  TabAtkins: Someone brought a use case where they want to set up
             columns that are like 20% of the grid but no larger then
             250px. Obvious way doesn't work the way they want because
             min wins over max. If viewport is large the min will win
             and it'll be >250. They want priority to min.
  TabAtkins: Seems reasonable. We chose min win over match because it
             matches CSS. Reasonable to want different order.
             Suggestion is to add some way to achieve that in grid L2.
  <Rossen> what if we call it maxmin
  <Rossen> meaning max wins vs minmax where min wins?
  TabAtkins: We can decide on the functionality addition and not the
             syntax. It's a minor change to layout algorithm. There
             will need to be a check to say if it's this type of
             sizing you can't go above this value.

  Rossen: Support adding. Did we resolve on using maxmin?
  TabAtkins: I don't want maxmin because it suggests max comes first
             in argument. We can figure syntax out later. fantasai and
             I will recommend something.
  Rossen: The feature request makes sense.
  Rossen: Opinions? Reasons not to put this in grid L2?
  Rossen: Objections to adding a feature that allows max to win over
          min in Grid L2?

  RESOLVED: Add a feature that allows max to win over min in Grid L2,
            name tbd.

CSS Transforms

Browsers do not implement transform attribute syntax as described
    by w3c
  github: https://github.com/w3c/csswg-drafts/issues/2623

  krit: This is the transform attribute for SVG name spaced elements.
        Syntax browsers allow is different then specified in
  krit: We have transform attribute that uses SVG syntax. Is some ways
        incompat to CSS syntax. Since there's interop between browsers
        do we accept transform attribute is using SVG syntax or do we
        force browsers to support CSS?
  <krit> https://github.com/w3c/csswg-drafts/issues/2623#issuecomment-388005994
  krit: Tests^
  chrisl: Given there's interop we should go for that.
  chrisl: Given we're chartered to document what works now we have to
          go with situation as it is.
  Rossen: As an impl that just added this, having had to do all the
          work to support both parser and object model version I
          wouldn't rush to modify one or the other. Certainly not CSS
          transforms. Document what's fully interop is very much
          supported by us.
  krit: Might mean we can't support CSS syntax in the future for
        transform attribute, but no indication an implementation would
        pick that up.
  AmeliaBR: Way it's specified is that transform attribute is supposed
            to accept both legacy and new syntax. No one supports new
            CSS syntax. If we match current we say attribute is tied
            only to SVG 1. Separate issue is what browsers support
            doesn't match what has been copied from SVG 1 so still
            need to work to figure out what's interop and then define
            that in grammar. It's not a perfect match.

  krit: Only difference as the tests show is that there's currently a
        requirement to have a comma or a space between numbers. That's
        not followed. Broader issue is do we ever want to support CSS
        transforms syntax? I don't think we can do both.
  krit: Mostly because functions in CSS requiring function name and
        then parenthesis. SVG allows spaces between. There's other
        things like SVG allows lots of separators and CSS is strict.
  chrisl: I think we have to say for historical reasons there's
  krit: What about CSS transforms?
  chrisl: Means you have to use a selector to apply.
  krit: Also propose if you want new syntax you have to use a property.
  chrisl: Agree.
  AmeliaBR: We lock down the attribute, no new features except those
            to match reality
  Rossen: That's our take.

  Rossen: To go back, is there any implications to CSS or where we
          need to give input? I'm not hearing changes or requirements
          to CSS. I would suggest if you want to discuss SVG lock down
          you do that with SVG and decide how to lock attribute. Are
          there specific questions for CSS?
  krit: If the WG would object to that?
  Rossen: Group, do you object to having SVG WG defining what SVG
          attribute should do?
  AmeliaBR: Currently defined in transforms.
  krit: Probably needs to stay.
  Rossen: Take it out?
  chrisl: Don't see need. No one is queuing to change impl so document
          what works
  krit: Question from Rossen is if we spec differences in CSS
        transforms or in SVG
  AmeliaBR: Agree with chrisl keep in same spec.
  krit: Good idea.
  Rossen: I don't have anything against that.

  Rossen: Do we need a resolution? Summary: SVG transform attribute
          will document what's interoperable.
  AmeliaBR: Worth a resolution because that's a major change.
  AmeliaBR: We've currently got it spec the attribute accepts new and
            old syntax.
  Rossen: Okay.
  krit: I'm fine SVG will define details. Resolution that transform
        attribute is locked down to current interop impl is nice.
  Rossen: Other impl opinions?
  krit: Webkit PoV securing status quo is preferred.
  Rossen: Blink or Gecko?
  AmeliaBR: Issue was started by a Gecko contributed. He said he can
            make minor fixes.
  Rossen: dbaron are you guys okay?
  <dbaron> I said it seems fine to me given what Robert said in the
  Rossen: TabAtkins?
  TabAtkins: I believe fine
  Rossen: Sounds like no implementors object.

  liam: Does anyone know what non-web SVG impl do?
  Rossen: Not sure. If any do something else and no major impl can
          support I'm not sure the use case.
  AmeliaBR: As far as I know they stick to SVG 1.
  liam: Thanks.
  Chrisl: It's not a weird syntax, they impl SVG 1.
  liam: That was my expectation. Just checking if anyone looked.

  Rossen: Objections to document the SVG attribute to be as currently
          supported by all implementation, possibly with a note that
          future extensions will be made at CSS level

  RESOLVED: SVG attribute reflects current interop, future
            improvements will be in CSS transforms.


Consider making scroll methods return promises
  github: https://github.com/w3c/csswg-drafts/issues/1562

  TabAtkins: Right now all scrolling methods are void, return
             undefined. When they were instant that was fine. Now that
             there's smooth scrolling it may be worthwhile to have
             something tell you when it's finished. Someone suggested
             that scroll methods return promises.
  TabAtkins: I don't think they would ever fail.
  TabAtkins: Upgrading void methods into promise returning is a
             standard way to do this and should be compat. As long as
             there's no implementor objecting I'd like to add.

  Rossen: Defined behavior for overlapping scroll timelines?
  TabAtkins: Don't know, use case?
  Rossen: You want to impl your own overscroll behavior for a spring
          effect. When your scroll is complete you want to scroll down
          and back. I can see someone doing that. So I start a scroll
          for something fairly long in time and then I'll wait for the
          promise to do the little overscroll. But another scroll in
          the opposite direction happens.
  TabAtkins: If a scroll is started and interrupted it's done and you
             fulfill promise.
  Rossen: So interrupt or complete fulfills.
  TabAtkins: We only reject promises on errors and there's no sense
             the scroll throws an error
  dbaron: You might want data on if interrupt.
  TabAtkins: Agree. Should fulfill, but argument should give data

  majidvp: Can you not read scroll offset with actual offset and it
           means interrupt?
  TabAtkins: No because you're interrupted mid-way. Using that as a
             method an interrupted will be forever pending unless you
             hit it by luck.
  dbaron: I think it's an alternative to data, not to the promise.
  dbaron: That said, I think there are a bunch of scrolling operations
          where you don't know destination offset. You can cause
          scroll by page and you don't know pixel.
  TabAtkins: And scroll into view is at least difficult to calculate
  Rossen: I would want to have something cleaner and richer for hints.
          When you intersect this with scroll snapping and you stop
          for a different reason...if you scroll by and need to scroll
          up more because a scroll snap has a mandatory scroll you'll
          overscroll based on target.
  Rossen: Meta point, I don't think anyone objects use case of promise
          pattern. I think the addition to this is adding some data
          that describes how this was fulfilled.
  TabAtkins: I can see fulfill with an object that's an enum of
             completed or interrupted or something like that.

  AmeliaBR: I suggest looking at web animations spec. Smooth scroll is
            a type of animation and web animation uses lots of
            promises and I could see a use case for chaining things
            like web animation after a complete smooth scroll. Compat
            here is useful.
  TabAtkins: Agree. I didn't know about that but I will take a look at
  majidvp: Another case is a scroll-into-view where we scroll multiple
           scrollers and we need details on when we fulfill. I imagine
           after all scrolls are complete.
  TabAtkins: Yes, if you have 2 nested scrollers inner is a bit and
             outer is a lot so inner completes fast. Makes sense. Good
  <dbaron> https://developer.mozilla.org/en-US/docs/Web/Events/scroll

  Rossen: Is there a reason we wouldn't want this as an event that you
          can subscribe instead of adding promises to all scroll
  TabAtkins: Possibly. But if you only care about a given scroll you
             have to subscribe and then unsubscribe. Also there may be
             another scroll and you might get the wrong one. Event is
             useful, but doesn't do the use case of I want to know
             when this scroll is complete.
  Rossen: Okay. Makes sense.
  Rossen: Sounds like a feature that merits addition of promise.
          Likely details to work out.
  Rossen: Additional comments or objections to add returning a promise
          from all scroll functions?

  RESOLVED: Add returning a promise to all scroll functions.

CSS Align

Rules for align/justify-self on static position of
    absolutely-positioned boxes need more detail
  github: https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-387153116

  TabAtkins: We've made the changes of what we've interpreted from the
             working group's earlier resolutions. Quick intro and if
             there's interest people can look. Not expecting
             resolution. Just an introduction.

  TabAtkins: Size of containing block, sizing rules for static abspos
             are complex. Standard LTR page and you have a standard
             element size is constrained on left by static and on
             right by abspos edge. This is reasonable, it's fine. But
             there's questions about how to interact with alignment of
             staticpos. Current is a different ridiculous thing done
             by each browser.
  dbaron: What existing features did you use to test?
  TabAtkins: One is swapping direction. We think that's good. Using
             align-content which switches where static pos and that's
             where it's different and bad everywhere.
  TabAtkins: Just tested in flex, should be same for grid.
  Rossen: I'm not surprised it's less then interoperable.
  TabAtkins: Main thing, we think browsers with blocks when you toggle
             direction is good. You swap the sides so right is from
             static and left is from abspos container. This is good.
             Align switching from start to end should have same swap
             is what we think.
  TabAtkins: Only not covered is when you center. We think then both
             edges come from static pos element. So the left from ltr
             and right from rtl. It gives you reasonable centering. If
             you want other behavior you can get with left:0 right:0.
             Also seems less intuitive.

  Rossen: One addition, we've discussed this in the past, especially
          when doing grid. Having the static position modify your
          containing block size, or what you use for layout position,
          so that you redefine space for position left and
          right...because layout you first measure content to get
          preferred sizes and then you do arrangement and then you do
          alignment...you should assume alignment doesn't change
          layout though some baselining does.
  Rossen: If we assume alignment doesn't reintroduce layout the
          problem is simple. Need to figure out how much to
          additionally allow alignment adjustment.
  Rossen: One thing we considered is if static pos is a point to where
          the actual static element would have been you then do your
          layout however you'd do it. You size and position as if
          block. Then you use this point and say align the box you
          have created and then additionally aligned about that point
          something else in that box. 30% additionally on the left, or
          align me in the center. So you can reposition without layout
  Rossen: That also means there's additional alignment values we'd
          need, but they can apply in all layout modes.
  Rossen: Food for thought. This is where we ended up after
  TabAtkins: In this case that...you're sticking with alignment can't
             alter. That gives you Firefox behavior. I suggest looking
             at the test case in FF and flip start to end for align
             and you can see why it's not really sensible.
  TabAtkins: The original box size is okay, but as soon as you
             re-align it's a nonsense size. But if you direction
             toggle it's good.
  dbaron: Probably there's other behaviors for Rossen variant.
          Including these properties should mess with static pos at
  TabAtkins: I don't particularly like that. Seems odd that swapping
             direction is different then swapping alignment. Going
             from align-content:start ltr to rtl we like that. We want
             to make it so swapping align seems the same.
  dbaron: But considering this align has weird consequences like
          center isn't halfway between left and right.
  TabAtkins: Yes. But we think the center we proposed is a useful

  Rossen: Question. You mentioned you wanted to introduce this. Not a
          resolution. Pretty sure we need to work more.
  TabAtkins: Yes. Look in details on the thread and we can discuss in
  Rossen: Okay. Anything else you want on this issue?
  TabAtkins: Nope.

  Rossen: There were a few Houdini and FXTF topics that have been
          lingering. I'm happy to prioritize those now.
  TabAtkins: I'd love that.

Typed OM

'fr' units cannot be used in a calc
  github: https://github.com/w3c/css-houdini-drafts/issues/734

  TabAtkins: When typed OM defined math rules it treated fr like any
             other type
  TabAtkins: You can divide a resolution by 2 for example. Anything
             else added confusion. But looking at value spec fr and
             resolution aren't allowed in calc.
  TabAtkins: Seems like not it's a purposeful limitation. I think the
             types were added to V&U after calc. Given you can express
             them in typed om I'd like to be able to express in calc.
             Or go back to typed OM and say no you can't use these.
             That's oddly limiting. Proposal is allow fr units and
             resolution units in calc. They are independent units.

  dbaron: I think we have resolutions to allow more unit algebra in
  TabAtkins: [missed]
  dbaron: Then they're their own type in the unit algebra.
  TabAtkins: Yes. fr doesn't add to length, though. but you can
             combine as long as end result is a reasonable unit.

  Rossen: Sounds reasonable. Other opinions?
  <dbaron> I'm in favor.
  <dbaron> That said, it seems like we might want to be able to add in
           the future...
  AmeliaBR: I'd ask that maybe somewhere there's an informative note
            emphasizing fr can't be added and combined with length and
  TabAtkins: I think that's a note in grid. If not, I'm happy to add
  AmeliaBR: Sounds good.
  Rossen: I think V&U is good for this note.
  Rossen: Anything besides the note. Other ideas or objections?

  RESOLVED: Allow fr and resolution units in calc functions, add a
            note to Values & Units explaining they don't combine with

  TabAtkins: Do we want a standing resolution that any new numeric
             units should add to calc?
  chrisl: I'd rather exceptions on case by case basis.
  TabAtkins: Agree.
  Rossen: Sounds reasonable. It's not like we add numeric units that
  dbaron: Agree new numeric values should be supported by calc.
  Rossen: Separate resolution for CSS Values that adds a note that
          numeric values are supported by default in calc.
  TabAtkins: New unit value types should be added to calc as they're
             added to CSS.
  Rossen: Obj?

  RESOLVED: Add a note to CSS Values & Units that new unit value types
            should be added to calc as they're added to CSS

  Rossen: We're top of hour. Thank you everyone for calling in. We'll
          chat next week.

Received on Thursday, 17 May 2018 05:19:10 UTC