W3C home > Mailing lists > Public > www-style@w3.org > August 2017

[CSSWG] Minutes Telecon 2017-08-23 [css-flexbox] [css-ui] [css-grid] [css-scoping]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 23 Aug 2017 19:26:19 -0400
Message-ID: <CADhPm3sVJT1jH0otHfitgCyKDEX9iFXgWd1j+o+tRbEr6JMKxg@mail.gmail.com>
To: www-style@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Intrinsic sizing algorithm seems to produce 0 for many common cases
-------------------------------------------------------------------

  - RESOLVED: Change the spec to treat width and height as input for
              the max content size.

Definiteness of flex items' main size depend on flex-basis's
    definiteness
------------------------------------------------------------

  - RESOLVED: Allow percentages to resolve, re-open issue if
              dholbert or others want to re-discuss.

Spec for cursor during selection?
---------------------------------

  - RESOLVED: Add the proposed text from the github issue
              https://github.com/w3c/csswg-drafts/issues/1691
              (Text: "User agents may also ignore the cursor
              property and display a cursor of their choice to
              indicate various states of the UA's user interface,
              such as a busy cursor when the page is not responding,
              or a text cursor when the user is performing text
              selection.")

fit-content() vs 'stretch' alignment
------------------------------------

  - There was initial leaning toward having 'stretch' affect
      fit-content() up to the max size, but several people wanted
      more time to review before resolving.

Clarify that ::before/etc allowed after ::slotted()
---------------------------------------------------

  - RESOLVED: Allow ::before/after after ::slotted() but not opening
              it to general stacking of elements.

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

Agenda: http://lists.w3.org/Archives/Public/www-style/2017Aug/0025.html

Present:
  Rachel Andrew
  Tab Atkins (IRC only for most of the call)
  David Baron
  Bert Bos
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brad Kemper
  Myles Maxfield
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Greg Whitworth

Regrets:
  Rossen Atanassov
  Alan Stearns
  Lea Verou

Scribe: dael


  Bert: Let's get started
  Bert: Extra items. Anything we need to talk about?
  myles: The set of people on the call is small.
  Bert: It is August, but we do normally have more people.
  [discussion about quorum, more people arrive]
  Bert: I don't hear extra topics.

Spec Rec Next Steps
-------------------

  Florian: Question. Based on recent resolution I sent transition
           for MQ4 to CR. I know it's possible to do it myself or
           ask staff contact. I tried to do myself, but I haven't
           heard back. If you know something, let me know. If not
           can you look?
  Bert: It's making its way. It's not often the editor sends the
        request so people are looking at it as odd.
  Florian: We'd done that in the past. I was mandated to do it for
           CSS UI and document it. I forgot to document so I figured
           I'd do it this time and document.
  Bert: It's fine. plh is on holiday and he assigned his role to
        other people who aren't as experienced. They found the
        resolution.
  Florian: As long as it's not lost we're good.

  Bert: I have news: scroll snap is going to publish tomorrow.

  Bert: Anything else?

Intrinsic sizing algorithm seems to produce 0 for many common cases
-------------------------------------------------------------------
  Github topic: https://github.com/w3c/csswg-drafts/issues/1435

  fantasai: There is an issue filed by dholbert pointing out
            max-content of a flex container is only defined by
            max-content size of its content and flex-basis isn't
            taken into account. Empty elements in flex with a basis
            it shrinks to 0.
  fantasai: dholbert pointed out this is unintuitive. We did give it
            a size.
  <fantasai> Options:
https://github.com/w3c/csswg-drafts/issues/1435#issuecomment-321098718
  fantasai: We have options here. No one has a good argument for one
            over another. We need WG or community opinion. We could
            do nothing and leave as-is. We could treat specified
            width or height as a size that needs honor and ignore
            flex-basis. We could do flex-basis and ignore width and
            height. We could take max(flex-basis, width/height) as a
            floor on the max-content size. And this would all be
            inflated by max-content.
  fantasai: If I was going to pick randomly I would say use width
            and height but not flex-basis.
  Bert: Sounds like it's not a serious problem, but I may be
        misreading. Any opinions?

  gregwhitworth: I'd agree with width and height but not flex-basis.
                 My only worry is, I don't expect people to hit this
                 on web but they probably wouldn't know they have
                 empty flex.
  gregwhitworth: Any compat issues?
  rachelandrew: As an author it's not an issue I've seen.
  rachelandrew: I'd probably agree width/height not flex-basis makes
                sense.
  Bert: That's one in support. Other opinions?

  Bert: Other options...flex-basis as well as width/height and take
        the max, they are less desirable. Did we not want to discuss
        those?
  fantasai: flex-basis is a start place for flexing, it's an input.
            Width and height are set. In that case you're setting
            something explicit and everywhere else in CSS we take
            that.
  Bert: Anybody want to argue in favor of flex-basis or max of that
        and width?
  Bert: Maybe we drop those.
  Bert: So only no change or look at width/height.

  Florian: Sounds like a good change, but is anyone rushing to impl?
  fantasai: I'm not sure but dholbert is planning to look at flex
            box.
  gregwhitworth: Looking at the test case we have interop. It's a
                 worthwhile change, we should make it.
  Bert: Okay, they we need buy in from more impl.
  Florian: We have 2 at least. That's a good start.
  Bert: Is TabAtkins on?
  fantasai: He's just IRC.

  <bradk> Is there existing content that depends on current interop
          behavior?

  Bert: I'm hearing some support for looking at width/height but not
        flex-basis which is a change in spec.
  fantasai: Yes.
  Bert: Do we put that up? Change the spec to treat width and height
        as input for the max content size.
  Bert: Who is in favor, who is against?
  Florian: In favor
  <rachelandrew> +1
  Bert: I only hear in favor.

  RESOLVED: Change the spec to treat width and height as input for
            the max content size.

  Bert: fantasai will you write text? or TabAtkins ?
  Bert: Whose action?
  <TabAtkins> We'll take care of it, don't worry
  fantasai: We'll do it, don't worry.
  <TabAtkins> As long as it shows up in the issue

  <dbaron> I guess I'm surprised they weren't already an input to
           the max-content contribution, given that they're an input
           for other layout modes.
  <fantasai> dbaron, yup, that's why dholbert filed the issue :)

Should last-baseline's fallback alignment be safe or unsafe?
------------------------------------------------------------
  Github topic: https://github.com/w3c/csswg-drafts/issues/1611

  fantasai: I didn't post a blog post. I did ask jensimmons and her
            opinion was unsafe. That's as far as I got.
  Bert: You want to continue that action.
  fantasai: Yeah.
  Bert: Keep that open?
  fantasai: Yep.

Definiteness of flex items' main size depend on flex-basis's
    definiteness
------------------------------------------------------------
  Github topic: https://github.com/w3c/csswg-drafts/issues/1679

  Bert: I think gregwhitworth wanted to look at code he had to
        compare.
  gregwhitworth: Is anybody from FF on?
  dbaron: I don't know if I'll be helpful.
  gregwhitworth: I put my information in the notes. I sat with our
                 dev. We could figure out the same thing as
                 dholbert. We haven't impl this aspect. I pushed him
                 to see if this is right approach. dholbert seemed
                 to say he thought it was the right approach.
  gregwhitworth: We do because everything is auto we do layout and
                 then a second pass to resolve percentages. That's
                 what authors also expect. I'm wondering if we
                 should remove the constraining on #2 of 9.8. If you
                 set definite flex-basis and fixed height it does
                 the extra work. I see a lot of authors doing this
                 though it's not what they're expecting.
  fantasai: Bigger argument is we have introp on 2 impl and the
            authors expect that behavior. Spec says something else
            so we should change spec.
  gregwhitworth: And what dholbert posted to the list, we originally
                 said 'hey performance'. It's odd for authors to
                 know that to set flex-basis to 0 is what you need
                 to do for chrome to look like edge and ff.
  gregwhitworth: Let's just remove the constraints of #2 under 9.8
  <fremy> fwiw I discussed this with gregwhitworth yesterday, and I
          totally +1 his request to remove the constraints on #2
  fantasai: Reasonable to me.
  Bert: Me too, but I'm not expert. Other opinions?

  dbaron: I'm not sure how well performance bugs get tied back to
          this. I'm not sure if we would have heard if there were
          performance bugs.
  gregwhitworth: That's a valid argument. I feel like we're going to
                 argue a theory. Now that we have grid we'll be able
                 to have less nested flexes is my guess so I'm not
                 as worried about the circular problem.
  fantasai: In grid percentage always resolved because grid sizing
            creates sizes for the tracks. Conceptually grid algo
            resolves the equivalent code the way FF and Edge do flex
            right now.

  Bert: I'm hearing, fantasai, that there are impl that do and some
        that don't do the layout based sizing?
  gregwhitworth: Chrome and I believe I saw webkit and blink would
                 have to change. As we stated the people on the
                 thread aren't on the call.
  <gsnedders> FF and Edge agree, Chrome and Safari agree (but are
              one impl now again)
  <gsnedders> WebKit's implementation of flex was literally copied
              over from Blink a few months ago
  Bert: Are we confident enough to decide? Do we need more input?

  fantasai: Christian is away for the next couple months. We can ask
            dholbert that we want this resolution and ask for
            approval. From dholbert and whomever people want to tag.
  Bert: Sounds like a good way forward. If we document it in the
        issue is that enough? Do we need to contact personally?
  gregwhitworth: I say we just resolve since we discussed it. We can
                 re-discuss if they want to get on a call.
  Bert: Okay.

  Bert: Wording for proposed resolution?
  gregwhitworth: It's what I said in the issue. Basically re-write
                 #2 of section 9.8 to percentage would resolve.
  fantasai: Allow percentage to resolve, re-open issue if dholbert
            or others want to re-discuss.
  Bert: Okay, that's the proposal. Objections?

  RESOLVED: Allow percentages to resolve, re-open issue if dholbert
            or others want to re-discuss.

Spec for cursor during selection?
---------------------------------
  Github topic: https://github.com/w3c/csswg-drafts/issues/1691

  Florian: We discussed and reaffirmed that we want cursor:auto to
           only do limited switching. All other types of adjustment
           are through UA stylesheet. Chrome is fixing their impl to
           change that and they found another thing they can't do in
           the stylesheet. While user is dragging mouse they change
           cursor to text cursor if it's auto.
  Florian: This is chrome only behavior. Safari changes always, not
           just auto.
  Florian: My feeling is this is sort of out of scope. We already
           said UA can ignore cursor if you're doing something like
           hovering over scrollbars. We originally suggested that
           way the UA does to reflect state of UI is out of scope.
  Florian: My suggestion is changing the cursor to reflect selection
           is an indication of the browsers UI is out of scope. I
           propose an editorial clarification to say that. Is that
           sounding sane?
  Bert: Does to me.

  myles: On mac there's already system behavior. It's valuable to be
         able to match platform.
  <fremy> +1
  Bert: That's support for Florian
  jensimmons: I'd add that I have no see authors desiring the
              ability to control at this level of detail so sounds
              good to me.
  Bert: Anybody else?

  Bert: Proposal is add a note?
  Florian: I'm doing this as a may. Proposal is in issue. [reads:
           "User agents may also ignore the cursor property and
           display a cursor of their choice to indicate various
           states of the UA's user interface, such as a busy cursor
           when the page is not responding, or a text cursor when
           the user is performing text selection."]
  Florian: Resolution would be adopt the wording in the issue.
  Bert: Okay, proposal is add the text as is in the issue.
  Bert: Objections?

  RESOLVED: Add the proposed text from the github issue
            https://github.com/w3c/csswg-drafts/issues/1691

  ACTION Florian add the proposed text in
https://github.com/w3c/csswg-drafts/issues/1691
         to the spec
  <trackbot> Created ACTION-862

Metadata
--------
  Github topic: https://github.com/w3c/csswg-drafts/issues/1730

  Florian: May be better for fuller attendance, but in brief.
  Florian: While submitting tests recently I found a difference
           between what I understand the policy on how to write test
           and what the web platform tests is. I think there's a
           mis-match and how we decided to relax our metadata and
           how the tooling is based.
  Florian: I want to confirm if I'm the only one confused or if
           others have the misunderstanding.
  Florian: I'm not convinced this is useful without more people.

  Bert: We can keep for the next time. Anyone else want to say
        something today?
  Bert: Okay, we'll wait for more people.

fit-content() vs 'stretch' alignment
------------------------------------
  Github topic: https://github.com/w3c/csswg-drafts/issues/1732

  fantasai: rachelandrew and rego found spec issues about 'stretch'
            and fit-content() and 'stretch' will stretch past the
            specified limit and that doesn't make sense.
  <rachelandrew> the interop issue is described here

https://github.com/rachelandrew/gridbugs#14-fit-content-is-stretching
  fantasai: There's 2 options. 1) Only have stretch stretch auto
            tracks but not fit-content. 2) Have stretch work on
            fit-content() up to the limit.
  fantasai: 2 is more complex to impl but may be more expected.
  Bert: I'm having trouble visualizing. Other people understand?
  fantasai: I'm happy to defer if people want more time.
  gregwhitworth: I prefer to wait. I didn't review in depth.
  Bert: How much time?
  gregwhitworth: Just a week. I want to run Rego's comment on impl
                 past our devs.

  fantasai: There's also two options for if we do stretch...do we
            stretch other tracks once these have reached their limit
            or just say nope.
  jensimmons: From author side having a track with fit-content grow
              and shrink would be expected. And I think that once
              the fit-content limit is hit having additional space
              appear get distributed through the rest of the grid
              would also make sense, not have the grid stop growing.
  jensimmons: I don't know the implication for impl. Super quick
              issue reading from rachelandrew's github of grid bugs
              it looks like that's what other authors expect.
              Correct me if I'm wrong rachelandrew
  rachelandrew: I think the author that raised it thought stretching
                was correct, but I found authors assume Chrome is
                correct. They tend to assume the browser they use
                the most is correct so I take it with a pinch of
                salt.

  Bert: So if we come back next week that's enough time to
        investigate?
  jensimmons: Is what I tried to articulate what FF does?
  rachelandrew: FF doesn't stretch. If you align to start you get
                the same with everything. Chrome is stretching.
  jensimmons: It would be nice...Oh there's a demo here.
  jensimmons: I'm fine punting to next week.
  fantasai: If people have opinions or thoughts please add comments
            to the issue.
  <gregwhitworth> Edge doesn't stretch either in the case provided

  Bert: So there are impl difference so at least one will have to
        change.
  Bert: Please add your thoughts to the issue and we'll come back
        next week.

Clarify that ::before/etc allowed after ::slotted()
---------------------------------------------------
  Github topic: https://github.com/w3c/csswg-drafts/issues/1747

  Bert: It's raised by TabAtkins. Anyone else know this topic?
  Bert: I don't think I've seen ::slotted() before.
  gregwhitworth: I think we should wait for TabAtkins. I think their
                 implementation is the furthest along.
  <TabAtkins> I can call now, one sec
  fantasai: I think...issue seems straightforward. There's ::slotted
            pseudo element. They want to attach ::before/after and
            what's the syntax for that. Obvious is TabAtkins
            suggestion. I think we just need confirmation from WG
            this is acceptable.
  Bert: It's only syntax? I thought it was if it was even possible.
  Bert: If it's only syntax this is easier.
  TabAtkins: I'm here now.

  TabAtkins: Simply, is everyone else okay with allowing this
             syntax. ::slotted lets a shadow dom element select
             whatever light dom was. There is a real element being
             pointed to by the pseudo element. So should we allow
             structural pseudos on that element. Should you be able
             to modify before and after from the ::slotted pseudo.
  TabAtkins: It's fine from an impl perspective. afaict it's not
             problem and it's not a problem from spec side. I need
             WG sign off and then a small change to selectors
             grammar to allow it.
  Bert: Now it makes sense to me.

  fantasai: Syntax change makes sense. If you should be allowed to
            access is separate question. Is slotted how light dom
            accesses shadow?
  TabAtkins: No. Other way around. slotted accesses light dom.
  myles: This isn't arbitrary, just these two.
  TabAtkins: ::slotted with ::before and ::after only. We can look
             at further combos later.
  fantasai: We're doing this similar with pseudo classes on pseudo
            elements. Currently only this set is allowed and all
            others are disallowed unless explicitly specified.
  Bert: So ::slotted is a special kind of pseudo element.
  TabAtkins: Yeah. Special part is is refers to a real element in to
             dom that's not accessible by standard combinators.

  Bert: Have you thought about other syntaxes that avoid stacking?
  TabAtkins: We've tried. We talked about the deep combinator taking
             elements. It ends up awkward. In general these to act
             like pseudo elements. They just happen to be back by a
             real element that's not normally accessible.
  Bert: I'm ready to propose allow ::before/after after ::slotted()
        but not opening it to general stacking of elements.
  Bert: Any support or arguments against?

  RESOLVED: Allow ::before/after after ::slotted() but not opening
            it to general stacking of elements.

  Bert: TabAtkins you're making the changes?
  TabAtkins: Yeah.

  Bert: That's the agenda. Other things to discuss?
  Bert: Hearing nothing, thanks everybody!
Received on Wednesday, 23 August 2017 23:27:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 23 August 2017 23:27:16 UTC