W3C home > Mailing lists > Public > www-style@w3.org > May 2018

[CSSWG] Minutes Telecon 2018-05-30 [css-grid] [css-images] [css-values] [selectors4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 30 May 2018 20:35:23 -0400
Message-ID: <CADhPm3tSJvMFS9dqB4QyVvT14YJEe-c=UzPon4ctQajegv=r8A@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.

CSS Grid

  - RESOLVED: Accept proposed edits in
              to amend grid algorithm.
  - RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/2697
             (add align-content content distribution for this specific
             case (all rows have definite max size) to the row
             estimation heuristics for step 1).
  - RESOLVED: Close this issue, won't fix. (Issue #2270)
      - The group felt it was too early to create a shorthand and that
          more time was needed to figure out which of the many ways to
          set equally sized columns/rows should be represented in a
  - RESOLVED: Accept this change but keep the issue open and don't do
              edits until there's an implementation commitment. (Issue

CSS Images

  - RESOLVED: Always expand gradient syntax in serialization. (Issue

Values & Units

  - The changes to allow unit algebra in calc() have been put in the
      spec and anyone interested was asked to review.
      Spec: https://drafts.csswg.org/css-values-4/#calc-type-checking
      Issue: https://github.com/w3c/csswg-drafts/issues/545

Selectors 4

  - RESOLVED: Make specificity of :not() :has() and :matches() not
              depend on matching. (Issue #1027)


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

  Rachel Andrew
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Garrett Berg
  Tantek Çelik
  Emilio Cobos Álvarez
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Chris Lilley
  Myles Maxfield
  Thierry Michel
  Liam Quin
  Melanie Richards
  Dirk Schulze
  Jen Simmons
  Alan Stearns
  Lea Verou
  Eric Willigers

  Rossen Atanassov
  Dave Cramer
  Michael Miller
  Manuel Rego
  Florian Rivoal
  Jeff Xu

Scribe: dael

Agenda Setting

  astearns: Let's get started
  astearns: Is there any changes to the agenda to make?
  <TabAtkins> The one change I sent to the thread?
  <leaverou> https://github.com/w3c/csswg-drafts/issues/2714
  leaverou: I was wondering if we could add ^ to the agenda?
  leaverou: It's gradient serialization so hopefully fast.
  astearns: Let's try and do that after grid.

  astearns: TabAtkins you mentioned a change I think I made.
  astearns: TabAtkins was that adding editors?
  TabAtkins: The change I requested isn't in the agenda.
  astearns: Change you wanted?
  TabAtkins: Adding editors.
  astearns: It's first

Adding editors to specs

  astearns: Fergal Daly is going to be editor for shadowparts. Chris
            Harrelson will be compositing and geometry
  astearns: They both joined.
  TabAtkins: Approved for adding Fergal Daly for shadowparts. The work
             Chris will do is much needed.
  astearns: So that's mainly informative.
  astearns: Their first task will be adding themselves as editor.
            TabAtkins I expect you'll help.
  TabAtkins: Yes.

CSS Grid

Applying 'justify-content' content distribution is in the wrong place
    in the overall grid sizing algo
  github: https://github.com/w3c/csswg-drafts/issues/2557

  <fantasai> https://github.com/w3c/csswg-drafts/issues/2557#issuecomment-385571268
  fantasai: Summary is here ^
  fantasai: When we size the grid we do all the sizing account for
            items etc. and at end align the track or justify them.
            Problem is that sometimes this increases size of gap so
            spanning item has more space.
  fantasai: Mats said we should integrate alignment into sizing algo
            more close so that you have alignment effects on sizing
            accounted for when doing sizing.
  fantasai: Seems like everyone agrees this is a good idea so bringing
            to WG for approval.
  fantasai: Questions?

  astearns: Comment you linked to has...does it have both 1.5 and 2.5
            that are in further discussion?
  fantasai: 1.5 is second sentence in 1.
  astearns: And 2.5 is second sentence in 2?
  fantasai: Yes and so on down.
  astearns: Other comments to add?
  astearns: Objections to accepting

  RESOLVED: Accept proposed edits in
            to amend grid algorithm

Applying 'align-content' content distribution to row estimation in
    step 1 in Grid Sizing algo
  github: https://github.com/w3c/csswg-drafts/issues/2697

  fantasai: Follow-up we have a heuristic to get rough sizes and we
            need to also change the heuristic
  fantasai: Technically different issue.
  fantasai: I think this is a matter of getting it correct.

  astearns: Additional comments?
  astearns: Objections to accepting
            or do people need time?

  RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/2697

Shortcut syntax for repeat(M, 1fr)
  github: https://github.com/w3c/csswg-drafts/issues/2270

  leaverou: I found that I was using grid template columns and rows
            numbered by accident and realized that's not how you make
            equal columns and I was wondering if we can add shortcut
            syntax so the error becomes correct because I suspect
            other people would write this.
  leaverou: TabAtkins raised point that because we allow unitless
            lengths grid-template:0 has a meaning. It doesn't mean
            it's not possible, but it's confusing in that case.
  leaverou: People have discussed a new unit, I don't remember names,
            but people discussed units or functions like efr. I'm not
            a huge fan because I wanted to prevent this error and
            other syntax would get people to make errors. But I guess
            a shortcut for this is still a net gain.

  fantasai: My main concerns where that there's lots of sizing
            functions you can have and I'm not sure fr is what you
            always want.
  leaverou: My point was a shortcut to spec equal width columns. It
            can be a shortcut to whatever you think it should be. You
            know grid better then me.
  TabAtkins: The point isn't one better, but it's that there isn't a
             single obvious choice. It's hard to justify one with a
             blessing of a shorthand.
  jensimmons: I'd hesitate to put a thumb on the scale for which
              syntax should be used by giving one approach a special
              short hand. I feel industry needs a couple years to come
              up with a bazillion ways to do things.
  astearns: I wonder if we should let it sit, see if preprocessors
            come up with a shorthand of their own we can adopt.
  rachelandrew: Agree. I don't see huge confusion. I see people that
                love shorthands, but I don't see this as a mistake. I
                see a lot of not working grid and this hasn't come up.
  jensimmons: I see people trying to systematize and it's early for
              that. They don't understand power of grid and what a fr
              is. I think there's a long way to go before we create a
              system of shortcut.
  astearns: Is there anything we can do about the mistake case?
  fantasai: I think we leave as invalid. We could revisit a shorthand
            in the future but I think for now it's not the right time.

  fantasai: Related: one frustration raised in thread is way fr units
            are calc and people are frustrated you can't use direct
            because auto min is often wrong. We need to fix those
            cases. They have to set a 0 min. That's #1865. We need to
            do something about it.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/1865

  astearns: leaverou are you okay closing this for now and taking some
            of this over to 1865?
  leaverou: Yep, fine. I was fine since TabAtkins pointed out grammar
  astearns: We'll leave it there and not do anything for the moment.
            We'll see what people do with fr and make shorthands.

  RESOLVED: Close this issue, won't fix.

gCS() of grid-row-start/etc properties should return used values?
  github: https://github.com/w3c/csswg-drafts/issues/2681

  TabAtkins: Someone brought up question of, it would be useful to
             know what row and column a grid element ended up in for
  TabAtkins: The requests are all solvable if we solve this. In
             particular if you do auto placement. Clearest way to do
             this is make sure used values are actual lines the
             properties end up with. Changing gCS() to return used
  TabAtkins: This is a change for all impl, they all return computed.
             It is more consistent with all other grid properties.
             Solves a useful use case without us having to add an API.
             With luck compat is low and huge benefit, but I want to
             get WG opinion.

  astearns: Used value is a line number index?
  TabAtkins: Yes
  <fantasai> +1 to the change, per TabAtkins’ rationale

  emilio: Do implementations preserve that info after layout? not sure
          they do
  TabAtkins: Don't know, but they have it at some point.

  dbaron: Not a fan of interesting things in gCS(). I see used value
          as legacy not to repeat. Slight pref for separate API but
          not strong
  <gsnedders> I am +1 of dbaron's point here
  TabAtkins: Separate API one thing is a bit awkward to compute. He
             wanted to know how large implicit grid is. I'm okay with
             either way. Thought pile into gCS is easier, but okay
             with both.

  astearns: There are other things in grid returning used?
  TabAtkins: grid-template properties give used values
  TabAtkins: That's because it's how Microsoft and Chrome did it
  fantasai: Microsoft asked to keep because it was compat for them. We
            put in spec so Chrome & Firefox did it.

  fantasai: I think a special API for grid to get interesting things
            is good. It will take a while to figure out what it should
            look like and where it goes and do we want layout mode
            APIs for other modes. It's a big project. Modifying gCS()
            gets us most of what we want. Information you're otherwise
            losing doesn't seem like it's that valuable. You can't get
            used values at all.
  fantasai: Since we're already returning used for other things if we
            switch we let people build the APIs they need to explore
            the grid.
  fantasai: In general I prefer less exceptions but in this case I
            think the usefulness and the time it would take to go the
            other route I think it points that we should change gCS()
  astearns: Summary: because it would take too long to do it right we
            should do it wrong
  TabAtkins: Not exactly wrong.
  fantasai: If gCS() wasn't already a mix of used and computed I would
            say don't do that. It is a mix and it's largely legacy
            driven we may was well go with utility.
  frremy: I think I agree with proposal. It's useful and not complex
          to do. Makes sense.

  astearns: Houdini APIs when you ask computed you'll get computed?
  TabAtkins: Yes.
  fantasai: And that's true in all cases where we return.

  dbaron: If you're making a change incompatible with all impl you
          need to have someone commit to try it soon rather then
          sticking it in and hoping someone will implement in a few
          years. We don't want dependencies on that decision.
  TabAtkins: Valid, yes.
  <tantek> right, who is willing to provide an intent to implement
  frremy: I'm not technically worried. Right now you get auto. If
          you're trying to do something with that you'll get a right
          value. I don't think it's a compat problem. I agree we
          should impl sooner rather then later.
  astearns: Are you volunteering?
  frremy: Don't know about that. But don't think it's complex. We
          should do it.
  astears: Any volunteers?
  TabAtkins: I'll ask Igalia folks and bring it back.

  astearns: dbaron has a point that longer it sits in spec moldering
            the worse it'll be.
  astearns: We can wait on resolving until a commitment. We can
            resolve and revisit in a month and if not move to impl
  TabAtkins: Resolve to do the change, not change spec until commits,
             and add edits in a month if someone adds
  <AmeliaBR> There probably needs to be at least a resolution that
             implementers can point to in their bug trackers.
  astearns: prop: Accept this change but keep the issue open and don't
            do edits until there's an impl commitment
  astearns: Objections?

  RESOLVED: Accept this change but keep the issue open and don't do
            edits until there's an implementation commitment.

  astearns: AmeliaBR has a point it would be great if people could put
            an issue in your own bug tracker
  emilio: I looked at other grid properties. it's kind of slow but it
          works. I'll file and CC him. If no strong opinion I can impl.
  TabAtkins: Since gCS requires compute up front that is an argument
             for separate API. Then we can lazy compute
  dbaron: It doesn't require computing everything up front because
          it's a live object
  emilio: Right. You only compute when do getPropertyValue call
  TabAtkins: Right, nevermind.
  astearns: Should we reverse resolution?
  TabAtkins: No.
  <fantasai> We should add an issue note in the draft tho

CSS Images

Clarify how gradients should be serialized in presence of the
    double-position color syntax
  github: https://github.com/w3c/csswg-drafts/issues/2714

  leaverou: A few weeks ago we cleared the 2 position color stop for
            shipping. Right now chrome serializes any gradient with 2
            colors stops with same color Chrome uses this syntax.
            Worried will break code.
  leaverou: Options either gradient read back as it's specified or
            canonicalize gradients. If 2 color stops have same color
            they're compressed. Or never canonicalize and always use
            the expanded syntax
  leaverou: No strong opinion. Worried about canonicalizing existing
            not spec this way. It could break parsing code. I would
            vote for another. Probably return expanded syntax in all
            cases. No strong opinion.

  <AmeliaBR> I'd also lean towards serializing with the older/explicit
             syntax, instead of the newer one. The new syntax is just
             sugar for declarations.
  dbaron: I think 2 principles on how to define serialization. 1 is
          that you want to try and serialize to shorter form. That's
          weaker in this case. Other is a syntax that's evolved over
          time you want to serialize to older.
  dbaron: I think the older form principle should win over shorter.
          That still leaves remember how it was spec or always expand
          syntax. No strong opinion between those.

  TabAtkins: How long ago did we ship always collapse?
  emilio: Hasn't yet.
  leaverou: Intent to ship was a few days ago. It's Chrome 69.
  emilio: It needs the three LGTM's to ship. Needs to be resolved on
  <leaverou> Correction: That's conic-gradients that will ship in 69.
             The 2 position syntax may ship later.
  TabAtkins: I was hoping we had shipped with no compat. Then I vote
             always expanded because keeping track of syntax is an
             extra bit on every stop that's not otherwise needed.
  frremy: Always expand seems better.
  leaverou: Agree.
  emilio: Seems good to me. Forget everything at parse time.
  TabAtkins: I assume that currently we're forgetting at parse time
             then eagerly collapsing and then going back and we can
             delete that bit and make it simplier
  astearns: Objections to always expand gradient syntax?

  RESOLVED: Always expand gradient syntax in serialization.

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

  fantasai: We discussed this last week or the week before.
  TabAtkins: 2 weeks.
  fantasai: Issue was defining impact of various align. I think
            discussion had some confusion about I don't want sizing to
            depend on alignment.
  fantasai: To clarify we have the sizing of an abspos item depends on
            direction property of static pos containing block.
  fantasai: Suggesting to look at justify-content property instead on
            that containing block so author can control behavior
            without effecting bidi. No change in element looked at,
            just what element.
  fantasai: One case not covered is there's a center value in
            justify-content and we had to define a value for center.
  fantasai: To revisit the behavior if you have a static pos you use
            as the containing block size you use the start edge of the
            static pos containing block and end of abspos containing
  fantasai: That depends on direction
  fantasai: TabAtkins and I decided that since we can get the behavior
            for both then for centering both should key off the static
            containing block for both sides.
  fantasai: That's a summary.

  astearns: I see Rossen was involved 2 weeks ago, but he's not on
            this week.
  frremy: I don't have the right context to talk. We should probably
          wait for Rossen to be back
  astearns: fantasai and TabAtkins was Rossen adding useful things or
  fantasai: dbaron and Rossen had definite opinions. He was
  astearns: You okay waiting until he's back?
  fantasai: Sure.
  astearns: We'll postpone again.

Values & Unites

Allow division of same types in calc()
  github: https://github.com/w3c/csswg-drafts/issues/545

  astearns: Looks like there's a change for this.
  TabAtkins: I think all that's left is...I wanted review by WG.
  TabAtkins: I added the resolution from months ago to allow unit
             algebra in calc(). dbaron gave me review which I hadn't
             seen yet. I'll resolve those. Any other comments or
             concerns please let me know. It's in the spec

  frremy: I'm wondering how you decided the final unit value of a
          calc. You probably have to back track. I think we have to
          change how we do this. Seems fine by me, but it requires
          keeping track of more things
  TabAtkins: Yep, how to determine type it resolves to is in the spec
             and you need the algorithm to do Typed OM. I leaned on
             Typed OM as much as possible because I think I got it
  chris: This is the correct thing to do. It's compatible with typed
         OM we should do this.

  astearns: This edits is a result of a resolution?
  TabAtkins: Yes. We've had multiple resolutions to do this. dbaron
             found one in 2014. This is just a review request.
  astearns: Sounds like dbaron looked. chris and frremy are okay. I
            think we're good. Anyone else wanting to look please do.

  <TabAtkins> frremy: https://drafts.csswg.org/css-values/#calc-type-checking
              for details on how to resolve the type (final resolution
              step is below the <dl>, but relies on the machinery
              defined above it)

Selectors 4

reconsider specificity rule for :matches()
  github: https://github.com/w3c/csswg-drafts/issues/1027

  dbaron: I originally filed this, but don't have a strong opinion on
          decision. Spec needs to be clear on which.
  <fantasai> List of options for considerations -
  TabAtkins: Other people have argued one direction: :matches() can
             introduce some thorny issues on selector inheritence.
             :matches() specificity is as specific as the most
             specific branch. More than one :matches() with
             combinators in the branches...you get...you get a
             combinatorial explosion. You get 100s or 1000s of
             selectors without going deep
  TabAtkins: Naive calc() is expensive for memory and unbounded costs.
  TabAtkins: Suggestion was don't bother with that. Resolve it the
             same as :not() and :has() where its specificity of the
             most specific branch. So if you put an ID or a tag it'll
             be that. That's straight forward and matches other
             similar pseudo classes.
  <dbaron> wait, :not() and :has() do that?
  TabAtkins: Only problem is that pre-processors doing :matches()
             ahead can only do it with expanding. @extend in SASS will
             result in a specificity change. It's not a backwards
             commpat issue but may be a problem with people or SASS
             trying to switch to doing the new stuff.

  astearns: [reads dbaron comment]
  TabAtkins: I believe it's correct.
  fantasai: :not() takes specificity of most specific argument that
            didn't match.
  TabAtkins: :not() takes a full selector list
  TabAtkins: There's a note. "is replaced by specificity of most
             specific element" Also says it has the exact behavior of
             :not(:matches(argument)), which is a lie. That's not true
             according to spec.
  ericwilligers: Pointed out a few lies in my comment on the issue.
  TabAtkins: If you look at section 16 :matches() and :has() uses the
             branch that matches and :not() uses the most specific
             regardless of matching.

  frremy: I have another proposal, we don't allow combinators inside
  fantasai: We had that for a while. Original :matches() had
            everything. Implementors said too complex, we took it out,
            impl then said they want it. So I think we have
            implementations that handle complex selectors
  fantasai: [some confusion about combinators vs commas]
  frremy: Commas is the whole point of :match() I said combinators
  TabAtkins: Combinators are the difficulty
  frremy: :matches() without combinators is easy.
  TabAtkins: Without combinators, just making it compound, doesn't
             simplify. Still have branches. Look at HTML on list
             bullets. It's a big list. If you do a simple :matches()
             rule you still have combinatorial branching.
  emilio: Removing combinators makes it simpler.
  <TabAtkins> `:matches(a, #foo) :matches(a, #foo) :matches(a, #foo)`
              <= naively expands to 8 choices anyway
  <TabAtkins> `:matches(a, #foo, .bar) :matches(a, #foo, .bar) :matches
              (a, #foo, .bar)` <= naively expands to *27* choices
  <TabAtkins> `:matches(.a .b .c, .d .e .f)` expands even faster, of
              course - expands to over a dozen combination, don't
              wanna compute the actual number right now because it's
  dbaron: Thing that's still hard is if you leave commas and you can
          have multiple matches and have you have backtrack to find
          the right one. As you walk up ancestors you might match the
          first on the element and a match for the second with ID but
          have to try ID ID path
  frremy: Oh, I see.

  emilio: Making specificity a property of the selector is nice, I
  TabAtkins: I see the difficulty and I'm happy to simplify it
  frremy: I think proposal is in the right direction. Easier to impl
          if only compute specificity of the selector as a selector. I
          can see why people would be confused, but I think it's
  ericwilligers: Same for :not() and make it most specific if it
                 matches or not?
  frremy: Yes
  dbaron: I'd be more concerned with this proposal if I thought
          specificity was more useful, but I think most people fight
          with it.

  astearns: I'm hearing at least 3 things.
  astearns: 1) places where current spec lies. Need resolutions on
  TabAtkins: Won't be a lie once we resolve.
  astearns: 2) Removing combinators in :matches()
  TabAtkins: I'd like to keep that separate and reject it.
  astearns: 3) What we're doing for :matches() and :not(). Is there
  dbaron: Consensus to make specificity is only a function of the
          selector and not the element.
  astearns: Specificity on :not() and :matches() depends on selector
            and not any possible matching.
  TabAtkins: Should do for :has() as well.
  astearns: Do not consider matching when determining specificity of
            :not() :matches() and :has()
  <TabAtkins> proposed resolution: :matches() and :has() should only
              consider their selector arguments (using most specific
              argument) rather than which branch matched, like :not()
              currently does.

  ericwilligers: Doesn't know why :has() needs specificity
  TabAtkins: You can't right now, but in theory an impl could allow it.
  astearns: Having a non-testable assertion is annoyi.ng
  fantasai: Of course has needs specificity.
  TabAtkins: You can only use it in JS so specificity doesn't do
  fantasai: but if we ever use it in stylesheet
  TabAtkins: Current spec has an assertion, we should make it
  astearns: Objections to making specificity of :not() :has() and
            :matches() not depend on matching

  RESOLVED: Make specificity of :not() :has() and :matches() not
            depend on matching.

  astearns: Thanks everyone for calling in and we'll talk next week
Received on Thursday, 31 May 2018 00:36:21 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:07 UTC