[CSSWG] Minutes Telecon 2017-12-13 [css-values] [selectors-4] [css-flexbox] [css-grid] [css-sizing]

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


Meetings for the rest of 2017
-----------------------------

  - Rossen will send out the proposed agenda for 20 December to garner
      regrets and determine if there are enough people for a call.
  - There will be no call on 27 December.

CSS Values
----------

  - RESOLVED: Resolve to clamp negative calc unit values in context
              and simplify as early as possible and then return the
              clamped calc as a result of the computed style.

Selectors
---------

  - RESOLVED: Change the name :focus-ring to :focus-visible.

Flexbox & Grid
--------------

  - Rossen brought issue #2085 (https://github.com/w3c/csswg-drafts/issues/2085
      | Choose a single option for resolving padding and margin
      percent values of grid/flex items) to the call in order to get
      more visibility and movement toward a solution.
  - There wasn't a decision reached on the call, but rachelandrew will
      make a blog post to garner from the community which behavior is
      preferable.
  - Most people expressed a desire to make sure that the same decision
      is applied to Grid & Flexbox to keep them inline.
  - As a part of this discussion several people have expressed an
      interest in a permanent solution to the aspect ratio hack and
      fantasai, TabAtkins, and gregwhitworth have all been looking
      into writing some spec text.

Sizing
------

  - There were many concerns that the proposal in issue #1865
      (https://github.com/w3c/csswg-drafts/issues/1865 | Intrinsic
      Sizes, Scroll Containers, and Grid/Flex Sizing) would cause
      severe breakage.
  - fantasai will go out and research if it will cause breakage and,
      if the result is that there is no compat risk, there was
      agreement that the proposal would be worthwhile to implement for
      Flex, Grid, and Block.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Dec/0016.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Michael Miller
  Anton Prowse
  Manuel Rego
  Melanie Richards
  Alan Stearns
  Lea Verou
  Greg Whitworth

Regrets:
  Benjamin De Cock
  François Remy
  Florian Rivoal

Scribe: dael

Agenda & Process
================

  Rossen: We should be good to get going.
  Rossen: As usual, are there any extra agenda items or changes?
  glazou: Is the discussion about short hands the deferred?
  Rossen: I was asking which you were referring to.
  glazou: The one about the shorthand impacting border image and that
          it cannot set it.
  Rossen: Do you have a GH?
  glazou: I'm not sure I did. I mentioned it probably 10 days ago.
          Last week because the different time astearns said it was
          this week. No problem if it's not.
  Rossen: I was hoping to see a GH or email that I can point to. It
          would be good to give people a chance to get familiar. Can
          we start with opening an issue in GH and then I don't mind
          adding it to any call. Including this one if you insist.
  <rego> it's on the mailing list
https://lists.w3.org/Archives/Public/www-style/2017Nov/0018.html
  glazou: No, not this call, but I wanted it sorted b/c it's very
          painful for web authors.
  Rossen: Thank you. Any other extra items?
  <glazou> Rossen https://github.com/w3c/csswg-drafts/issues/2108

  Rossen: Should we have a call next week, 20 Dec?
  Rossen: I'm asking because I believe we settled on no call 27 Dec
          and I'm not sure the outlook for 3 Jan
  Rossen: So 27 and 3 most likely not. So instead of discussing in or
          out on the 20th I'll shoot a proposed email very early for
          next week and it would be great to see the number of
          regrets. Based on that we'll decide on if we should have a
          call.

CSS Values
==========

Computed value of a negative calc unit that doesn't allow negative
    lengths
------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/434

  Rossen: This was intro last week. We resolved to clamp as early as
          possible, but not how to return computed values based on
          this clamping. We wanted to hear about it from a few people,
          one of them was glazou.
  Rossen: That's the first topic.
  Rossen: Is TabAtkins or fantasai on?
  <TabAtkins> in.
  fantasai: I'm on, but no computer.

  TabAtkins: glazou didn't respond and I haven't had time to go
             through and dig up previous issues. I'm fine resolving
             now and waiting for complaints later if there are any.
  Rossen: Let me get us on the resolve. Previously we said clamp
          negative clamp as soon as possible.
  astearns: We didn't actually resolve.
  Rossen: Ah, thank you. So we didn't resolve. But there was consensus
          on clamping as early as possible, right?
  TabAtkins: I believe so.
  <glazou> apologies I completely missed the RFI on that issue

  Rossen: Proposal is negative calc units are clamped as early as
          possible
  fantasai: per value or per prop?
  Rossen: I believe per value.
  fantasai: That was key question, per property or per value.
  Rossen: I assumed it was per value and if it was given to the
          property it inherits.
  astearns: Yes, it was definitely per value.
  TabAtkins: mmhmm
  Rossen: Right.

  Rossen: So the consensus was to try and clamp those as early as
          possible. There was not consensus on how to return computed
          values. as calc with negative value inside or return the
          clamped value.
  Rossen: So we could resolve on clamping and leave serialization out.
          TabAtkins or fantasai preference?
  TabAtkins: That's fine with me. The question was if you have a calc
             that's 50px-2em and that's negative at calc time do we
             simplify to calc(0px) rather then keeping the original.
             I'm fine simplifying the internal of the calc to the
             clamped value. I think that's what dbaron wanted.
  <gregwhitworth> so calc(0) rather than 0 or calc(<N> - 2em)
  dbaron: I think clamping and simplification should go together. If
          we're clamp we should also simplify.
  TabAtkins: That happens already, we collapse units together. But if
             we have units that we know will be clamped is the topic.
  dbaron: When you can resolve between px and em and know it's
          negative I think you also simplify to px.
  TabAtkins: I'm fine with that.
  Rossen: And the serialized value is whatever the clamped value?
  TabAtkins: With a calc around it.
  Rossen: Other opinions?
  * glazou is fine with resolution
  Rossen: Objections on resolving to clamp negative calc unit values
          in context as early as possible and then return the clamped
          calc as a result of the computed style.

  RESOLVED: resolve to clamp negative calc unit values in context as
            early as possible and then return the clamped calc as a
            result of the computed style.

  dbaron: We're saying clamp and simplify.
  TabAtkins: Some simplification is speced. This is collapse all units
             together that can be figured out. So we'd collapse em
             with px etc.
  fantasai: You have to do that for inheritence to work.
  TabAtkins: Yeah.
  <TabAtkins> Right now we already simplify calc(1px + 2px).
              Resolution is to also simplify calc(1px + 1in) at
              computed/used value, and things like calc(1px + 1em) at
              the point where that's possible.

  RESOLVED: Resolve to clamp negative calc unit values in context and
            simplify as early as possible and then return the clamped
            calc as a result of the computed style.

Selectors
=========

Rename :focus-ring to :focus-indicator
--------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2036

  bkardell: :focus-ring is what the mozilla folks used on early
            prefixed impl. When we said we'd adopt we carried the
            name, but most documentation use a different name and it's
            frequently not a name. In practice the name was confusing.
            We proposed focus-indicator which matches most doc, but
            there were worried that sounded more like a pseudo element
  TabAtkins: One of the obj from Alice to focus-ring is people think
             it's a pseudo element styling the ring and if that's the
             confusion then focus-indicator just genericized the noun
             since we name the thing shown not the quality of the
             element.
  bkardell: That's a fair other observation. I think focus-visible is
            what people on GH seem to have gathered around and there's
            a standing pull request with that.
  Rossen: So I guess the current runner is focus-visible
  <tantek> I reviewed https://github.com/w3c/csswg-drafts/issues/2036
           and :focus-visible makes sense to me per Tab's arguments
           about noun/thing vs. state of thing
  bkardell: Yes and there's an outstanding PR so we can just accept
            that.
  Rossen: I'm sad focus-pocus isn't it, but focus-visible is good.
  <fantasai> wfm
  TabAtkins: I'm fine with focus-visible
  Rossen: Other opinions?

  RESOLVED: Change the name to :focus-visible.

Flexbox & Grid
==============

Choose a single option for resolving padding and margin percent
    values of grid/flex items
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2085

  Rossen: I'll intro this, but I'm also going to timebox this. We've
          beaten this down in the past quite a bit. We've stated
          differences already openly. I think the current GH captures
          a lot of this.
  Rossen: I want to recapture the topic and I'm speaking as an Edge
          implementor on this.

  Rossen: Base of the problem is that we have a spec that defines 2
          different models of resolving percentage values for margin &
          padding top/bottom.
  Rossen: They are spec for flexbox and grid to either resolve
          percentage against inline direction and that matches with
          block behavior.
  Rossen: Other proposed/defined behavior is keep everything symmetric
          and resolve top & bottom in the same axis as the height and
          width and those resolve in the respective block direction.
  Rossen: I expressed the differences between flex and grid from our
          PoV. In this case I am a proponent of keeping flexbox and
          grid as close as possible. I wouldn't push for that
          principle on this, but I wouldn't be opposed. Flex is mostly
          a single dimensional layout where we distribute empty space
          in block or inline direction.
  Rossen: In the vertical case that's a lot closer to block layout.
  Rossen: Grid has always been 2d layout and we have attempted to keep
          everything as symmetric as possible when we worked on this,
          even internally at MS. That was a key principle. Everything
          is resolvable and symmetric to the extent where things are
          computable.
  Rossen: This has been our behavior since the original grid. Later
          Gecko & FF caught up with grid and flexbox. At this point
          the blink and WK impl caught up with grid and the opposite
          for the inline direction % resolution was proposed/accepted
          b/c of those impl and the strong argument at the time was
          that people were trying to use % padding aspect ratio hack
          for grid items.
  Rossen: And here we are today.
  * fantasai is very strongly opposed to making Grid and Flex differ
             on this point. Otherwise defer to Jen & Rachel.
  <astearns> my understanding (I might be wrong) is that people are
             only complaining about this for Grid, not Flexbox. If
             that's the case I'm less concerned with keeping Grid and
             Flex the same
  <TabAtkins> astearns I would hard-object to having Grid and Flexbox
              act differently, unless there's *strong* web-compat
              reasoning for it.

  Rossen: Thanks to people from Igalia we have data that suggests
          current usage of those properties as % has increased after
          we had a wider release of grid. That, looking a the numbers,
          is at least 2-4x higher.
  <rego> just a clarification, the jump in the metrics is unrelated to
         grid shipping, it was a change in the way to measure use
         counters in Chromium
  <rego> > Note: on 2017-10-26 the underlying metrics were switched
         over to a newer collection system which is more accurate.
         This is also the reason for the abrupt spike around
         2017-10-26.
  Rossen: The reason I'm bringing this up is we're starting to see
          non-interop content. There are broken webpages due to this.
  Rossen: I'll give you an example of this where content looks broken
          on seemingly normal wordpress sites.
  <Rossen> http://www.gpkafunda.com
  Rossen: I'd like L1 of grid and flexbox with just one behavior so
          that we're not introducing more breakage.
  Rossen: That's everything I want to say.
  Rossen: At this point the higher order importance is that we have
          interop on those basic layouts that will be adopted more and
          more.

  Rossen: I'd like to hear from Chrome folks if there are additional
          opinions or data.
  TabAtkins: Nothing that hasn't been said a year ago when we first
             had to introduce the undefinedness of this. We cannot
             change behavior of blocks, it should have been symmetric.
             Only reasonable use of % is the aspect ratio hack. Even
             though it's weird, being consistent with block seems
             easier for authors.
  <tantek> FWIW "consistent with block" on one hand, "consistent with
           positioned elements" is the other.
  TabAtkins: Ultimately I don't care, I want consistency. We're split
             in half. Once 3 browsers converge we can change the spec
             to that. I don't want to change until someone bites the
             bullet and changes behavior.

  <rachelandrew> I'm having trouble with audio (on hotel wifi) but I
                 noted in the issue my thoughts previously

  Rossen: Would FF or Gecko be willing to change to match Chrome?
  dbaron: I don't know off the top of my head.
  dbaron: I'd need to look into history.

  Rossen: Our position is we want interop. We're more willing to
          change now that grid is impl everywhere (which is awesome).
  Rossen: One thing I want to throw out is there was another possible
          solution proposed a couple years ago by myself in NY to
          entertain the idea of a switch to resolve % in one way or
          the other based on the container itself.
  Rossen: It took me a couple of days to make a prototype and make it
          work. That's another potential way forward.
  Rossen: However I said I'd timebox. I don't want to force a decision
          on this call. I really want to see grid L1 and flexbox have
          a single defined behavior on that.

  Rossen: Also, I know rachelandrew is having audio issues, but she
          offered to write a blog post. It would be great to hear what
          the community has to say.
  <fantasai> +1 to blog
  <rachelandrew> I'll write up something in the next couple of days
                 once I'm back in the UK

  Rossen: To close the topic, does anyone else want to say anything?
  tantek: I want to call out what I thought is new is it appears
          there's consensus on developing an actual solution to the
          aspect ratio hack. I see more interest on developing that in
          this issue then I remember previous interest.
  tantek: In the hope of making progress on something with consensus
          I'd like to see the folks with proposals for that use case
          to post them in a separate issue.
  fantasai: TabAtkins and I are planning to spec it for sizing L4 once
            L3 goes to CR.
  tantek: That would be great to see. I just wanted to call that out.
          I don't know if there's other new information.
  Rossen: That's great. gregwhitworth has been working on that from
          our end too so you might want to loop him into that
          discussion.
  tantek: +1 to gregwhitworth
  <TabAtkins> +1 for developing a non-hacky aspect ratio thing
  Rossen: Anything else? If not we can continue after rachelandrew
          blogpost.

Sizing
======

Intrinsic Sizes, Scroll Containers, and Grid/Flex Sizing
--------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1865

  Rossen: fantasai can you take this?
  fantasai: This was the issue about when you have a flex or grid item
            and inside it there's really wide content that has
            scrollbars.
  fantasai: When you put this inside a flex item it triggers the impl
            min size which looks at min-content size. Usually it's on
            the smaller size, but for something like this it could be
            really really big. Bigger then you expect, esp if you have
            scrollbars in there.
  fantasai: But you don't get scrollbars because the ancestor asked
            for the min size.
  fantasai: This is causing a lot of author confusion because some
            ancestor is making it blow up. The work arounds are not
            super obvious.
  fantasai: Suggestion when there is an overflow scroll the
            min-content contribution should be 0.
  fantasai: That would prevent this from happening.
  fantasai: There are some compat restrictions. For now proposal is:
            a) don't do this to a block in the block axis and b) don't
            do it for blocks that have overflow: hidden b/c that's
            often used to create a flex-root
  fantasai: If a box has overflow not visible and not hidden and it's
            a block in the inline axis its min-content contribution
            assumes 0. If it's a flex or gird item we do that for any
            value of overflow that's not visible in both axis.
  fantasai: We believe this would solve most cases. The fix if it's
            too small is to apply a min-width which is a fairly
            understandable fix.
  Rossen: Thanks fantasai.

  dbaron: This sounds like a substantial change to existing behavior.
  fantasai: Yes.
  fantasai: On flex items and grid items probably won't be too
            surprising. Applying to blocks...if you have a scrollable
            block and you're expecting inline size of that block to
            control the size of its ancestor by sizing so it won't
            scroll, then your layout would change.
  fantasai: We can split into two parts, do for grid and flex and can
            we do for block.
  dbaron: If you do it for one but not the other you're changing from
          one concept of min-content size to 2.
  fantasai: Min-content contribution. We already have special behavior
            for flex and grid when overflow is visible. This is
            implying the same thing where we don't consider the
            content for min-content contribution.
  dbaron: Isn't this non-local? It's arbitrarily deep descendants.
  fantasai: No. This is if a particular element is flex or grid and
            has overflow not visible we don't look at its content when
            looking at its own min-content contribution.
  fantasai: We're assuming 0 for the purpose of calc the min-content
            contribution of that item and this will fix the ancestor
            issue.
  dbaron: Only if the descendant is flex or grid.
  fantasai: Yes. That's part 1. Part 2 without would apply to regular
            block would fix it for block. But it's a local effect, to
            fix the action-at-a-distance problem.
  dbaron: Seems like you're saying the compat thing only solves half
          the problem. Given how widely flex and grid are used I'm not
          sure part 1 is even web compat.
  Rossen: Certainly not for flexbox. I'd be more concerned about that
          then grid at the moment, but definitely concerned about
          flexbox.

  dbaron: Any sign that impl are not interop?
  Rossen: I don't believe so. fantasai ?
  fantasai: I don't believe so either.

  fantasai: I think the behavior is more in line with what authors
            expect. When then set it to be scrollable you don't expect
            it to force the ancestor to give enough space for you not
            to scroll. I think this would make flex and grid more
            intuitive to authors.
  dbaron: I don't think we can change without more evidence it's safe.
  fantasai: Fair. I guess we can discuss if we want to change if
            possible, then we can look and see if it's possible. Not
            make the change until there's more data.
  dbaron: My gut is it's not safe and therefore not worth exploring.
          Particularly the half change doesn't seem sensible.
  fantasai: The thing is the only case...for a block element by itself
            inside a container you can size it with %. For block
            elements they're in a flow and they'll take their auto
            size. The effect in that axis...we don't distinguish
            between max and min content in the block axis. If we try
            and apply to a block in a block axis we have to introduce
            this concept and then have the min and max calc
            differently.
  fantasai: You have a set of blocks and they have a min and a max
            size and you have to calc layout twice to get the min size.
  dbaron: I'm not worried about block axis part. I don't agree with
          these concepts existing in the block axis. It's the not
          doing it for block, just for flex and grid, that's the half
          change.
  fantasai: Ideally I'd like to do both, yes.
  Rossen: And the second part is a lot scarier meaning doing both
          would be a lot harder.

  Rossen: This is going to sizing right or flex and grid?
  fantasai: Sizing
  fantasai: In terms of collecting data, that's a project but I'm
            willing to try and work on it b/c this issue is causing a
            lot of problems for authors.
  Rossen: Can you point to some of the confusion?
  fantasai: There's a bunch of websites trying to explain the fix and
            the fix isn't obvious.
  fantasai: There's a pre several items deep that's causing this and
            it's not obvious and it's getting exploded. And the
            explosion is a min-width so even setting a flex-basis it
            won't flex the way you expect.

  Rossen: Do you want a resolution?
  Rossen: More support to work on it? Sample interest?
  fantasai: What I've gotten is we want more data on if it's
            compatible. I'd like to know if the web compat comes back
            as no problem, would people want to make this change? If
            the answer is no there's no point in getting data.
  Rossen: As an Edge impl, the impl itself won't be that difficult so
          if you're probing to see how impl this it, it is fairly
          doable. But I'm fairly concerned with breakage, I'm
          sympathetic to dbaron's case.
  fantasai: And the point is collect data. But if we get data that
            says it's okay, would you accept the change? If you still
            don't like the change we've wasted the time to get data.
            Is it worth it to collect the data?
  Rossen: Okay. If anyone wants to push back on any reason other then
          interop concerns, this is your chance.

  gregwhitworth: While people think, I want to loop back and say we
                 solved a similar problem for tables. I'll link to the
                 minutes. We hit a similar problem where we have this
                 very scenario.
  <gregwhitworth> https://log.csswg.org/irc.w3.org/css/2017-08-03/#e843776
  gregwhitworth: I personally feel there is enough there. I'm not sure
                 if it's worth gathering data. We have compat issues
                 with the inverse.
  fantasai: What you're saying is we had an issue with a direct
            descendants of the table which has scroll does not
            contribute it's min-content. It was 0.
  gregwhitworth: Yeah, it's floored out. The layout is done and then
                 Chrome fills out. In Edge we give it the 100% and
                 then the accept term of service ends up offscreen.
  fantasai: That's an example of us having to make for compat reasons
            the fix being proposed. This proposal is doing that same
            kind of fix more generally.
  fantasai: Same use cases.

  fantasai: Concern for data wasn't if we needed use cases to see if
            there's author want, this was to see if we can do it
            without breaking the web.
  gregwhitworth: To answer the question better, if there's positive
                 use cases showing people want this and you bring back
                 data saying it wouldn't be a problem, I would be
                 shocked if people pushed back.
  Rossen: I also said that impl % resolution for padding was easy for
          us and it wasn't for others. I'm only speaking for Edge.
  fantasai: My understanding is because it's a local effect it's just
            a switch on when computing the min-content not to do some
            extra work. I don't think it's generally difficult to impl.

  Rossen: We're pretty much top of hour. For fantasai to proceed we
          need to hear there are not strong objections. Most people
          are worried about interop. gregwhitworth pointed out some
          issues where people need the opposite for tables which would
          bring more arguments against making it for blocks.
  fantasai: gregwhitworth's argument pointed out people are having
            this behavior for specific tables. It's a point in favor
            of people expecting the proposed.
  Rossen: Okay.

  Rossen: I'm not hearing any objections. fwiw continue with this.
  fantasai: So the conclusion is we expect to accept the proposal if
            fantasai can get data that's it's webcompat.
  Rossen: Yes. I think going to the step of data is worthwhile.
  dbaron: I would hesitate to accept the half proposal, though.
  Rossen: +1 to dbaron
  fantasai: We expect to accept the full proposal if fantasai can get
            data it's web compat.
  Rossen: I'll send the rest of the agenda to get how many regrets for
          next week.
  <dbaron> I think we'd want to know who would the first implementor
           of the change would be, though.

  Rossen: Thanks everyone.
  Rossen: If we don't have a call, I wish everyone an early happy
          holiday, safe travels, and we'll talk next week or next year.

Received on Thursday, 14 December 2017 01:20:23 UTC