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

[CSSWG] Minutes Telecon 2017-12-06 [css-sizing-3] [css-scroll-snap] [css-values] [css-counter-styles] [css-grid] [selectors]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 6 Dec 2017 21:55:47 -0500
Message-ID: <CADhPm3trDc2qihocjCb=pNUtHADVZcnbrfPDzL9nguxaA6Emgg@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 Sizing
----------

  - Everyone was requested to review the major update to fold in width/
      height & box-sizing propdefs. Link:
https://lists.w3.org/Archives/Public/www-style/2017Dec/0008.html

Scroll Snap
-----------

  - RESOLVED: Rename scroll-snap-margin to scroll-margin
  - RESOLVED: Request an updated CR for CSS Scroll Snap

Values & Units
--------------

  - There were two possible solutions to issue #434: Computed value of
      a negative calc unit that doesn't allow negative lengths
      1) Clamp as early as possible based on values.
      2) Clamps as early as possible based on the property.
  - The group was moving toward option #1, but that would lead to not
      preserving calc to which there had been objections in other
      cases.
  - A note will be added to the issue to look back at the reasons for
      previously wanting to preserve calc and see if those reasons
      apply in this case as well.

Counter Styles
--------------

  - RESOLVED: Mark <image> in <symbol> at risk

Grid
----

  - The group did intend the implementation breaking change resolved
      in issue #1921 (Percentage tracks and indefinite sizes). The
      timing of implementing this change will depend on results from
      the usage counter being run as well as implementation complexity
      and browser coordination.
  - RESOLVED: Request publication of new Grid CR.

Selectors
---------

  - The group didn't reach a conclusion on issue #2037 (:link and
      :visited are not mutually exclusive in implementations) however
      there was agreement that the spec text didn't align with most
      implementations and that Edge will likely need to change their
      implementation to align with the spec.

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

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

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Dael Jackson
  Dean Jackson
  Brian Kardell
  Peter Linss
  Xidorn Quan
  Naina Raisinghani
  Manuel Rego
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Victoria Su
  Lea Verou
  Greg Whitworth
  Eric Willigers

Regrets:
  Rachel Andrew
  Angelo Cano
  Tantek Çelik
  Benjamin De Cock
  Tony Graham
  Michael Miller

Scribe: dael

Agenda/Spec Rec Next Steps
==========================

  astearns: Things are still a little lite. Are TabAtkins or fantasai
            on?
  fantasai: I'm here
  astearns: We should start.
  astearns: First thing, any extra items? I do see Rossen commented on
            #1120 so that should go in with grid
  astearns: Any other items?

  astearns: I didn't put spec rec next steps because fantasai and
            Chris sent detailed notes. Anyone else have something to
            bring up?
  florian: Is Chris on the call?
  [silence]
  florian: I just wanted news on CSS UI 3 transition. There has been
           discussion, but I'm not sure on conclusion.
  astearns: Send a query to private list or Chris directly.

CSS Sizing
==========

Major update to fold in width/height & box-sizing propdefs
-----------------------------------------------------------
  link: https://lists.w3.org/Archives/Public/www-style/2017Dec/0008.html

  astearns: I don't think we need to comment, this is a call to please
            review.

Scroll Snap
===========

Should scroll-snap-margin lose it's snap?
-----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1954

  astearns: Since scroll-snap-padding is now scroll-padding, should
            scroll-snap-margin be scroll-margin?
  TabAtkins: fantasai and I are fine with it. Seems good. I don't
             believe there are impl so rename should be free.
  florian: I seemed to remember during TPAC we had a discussion where
           that rename would be useful, not just principle.
  fantasai: Previously we renamed padding because it had effects
            without snap. When we did #1708 for using margin when not
            in snapping mode, it now makes sense.
  florian: okay, yes, I'm all for it.

  dbaron: I'm a little worried the name sounds more like something
          general, but maybe it's okay.
  astearns: Right, margin on scroll port rather then margin on an item
            in scrolling situations? The name could invite that
            confusion.
  TabAtkins: Yes, that's an unfortunate consequence.
  fantasai: Another thing to note is that point of confusion existed
            independent. It's just the choice of using padding and
            margin. And what would a margin be outside a scrollport.
  dbaron: Somebody might expect it to be margin on the stuff inside
          the scrollport.
  fantasai: That's what it is, isn't it?
  florian: What do you mean by stuff?
  dbaron: The gap between...when you hit the edge of the scrollport
          between the edge of the content and the limit of what you
          can scroll to.
  dbaron: That's something today people can't control because that's a
          function of what the scrollable overflow is.
  dbaron: Maybe it's not a big deal.
  florian: I think what you're talking about is more similar to
           padding than margin.
  <fantasai> +1 to florian's reply
  dbaron: I guess we should go ahead with it. Maybe worth another
          issue about possible confusion.

  astearns: Any other concerns?
  astearns: Objections to rename scroll-snap-margin to scroll-margin?

  RESOLVED: Rename scroll-snap-margin to scroll-margin

Publication
-----------

  astearns: And there's a question of if we ask for new CR.
  astearns: Thanks to fantasai we have a test case for the previous
            large change. This resolution will require a few tests to
            be changed.
  fantasai: The ones I just checked in need to be changed so I'll do
            that.

  astearns: Objections to requesting an updated CR for css scroll snap?

  RESOLVED: Request an updated CR for CSS Scroll Snap

Values & Units
==============

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

  astearns: I added some tests with idea we would want to be picking
            either used or computed time. Sounds like proposal is to
            clamp as soon as possible. Correct?
  fantasai: Not quite. To clamp them both...twice effectively.
  fantasai: Some values you can calc through at the beginning and
            others you can't.
  <fantasai> Summary of the issue / proposal :
https://github.com/w3c/csswg-drafts/issues/434#issuecomment-310183908
  dbaron: I think what I suggested is that when the value...when all
          values of property can be computed through at computed value
          you clamp at computed value time. If not you clamp at used
          value time.
  TabAtkins: That is what we're saying.
  fantasai: No it's not.
  fantasai: There's two proposals. One is you clamp at each stage if
            it's possible at that stage for values under consideration
            at that moment; other is you clamp when it's guaranteed to
            be possible for that property in general.
  TabAtkins: The answer is the forward compat one. A prop is used
             value clamping if any property needs used value time to
             tell. It will have an observable effect if we later add
             an item that is used to a clamp. The clamp as early as
             you can has no observable effect when we add new things
             to value space.
  florian: So is there an argument against that?

  astearns: My question is since clamping at used value appears to be
            slightly useful for animations could we only clamp at used
            value time?
  TabAtkins: That might be possible
  fantasai: It's not because font size property needs to compute
            through to ems can be computed.
  TabAtkins: Is that true though...
  ??: I think so.
  TabAtkins: What's wrong with ems computing to a calc.
  fantasai: ems are a length, they resolve to px.
  TabAtkins: That's current. What's wrong with the other way around.
  TabAtkins: It eventually falls through to layout. Only difference is
             what things you can observe at computed value time.
  fantasai: It means you'll carry a calc around that's 50px+100%+2em
            you have to carry that and insert it into a margin that's
            a descendant of a descendant but still have it resolve on
            the parent on the original element on which it was
            declared ... are you crazy?
  TabAtkins: Yeah, that would be the technical consequence. Every
             situation here is bad.
  dbaron: That's bad for impl complexity and performance if you say
          you can never simplify.
  TabAtkins: Sure.

  <fantasai> A) Clamp as early as possible based on values.
  <fantasai> B) Clamps as early as possible based on the property.

  florian: What's wrong with clamp as soon as you can. It sounded good
           to me. It's fine with animations.
  TabAtkins: Someone advocating for that would have to argue for it
             because I don't know.
  astearns: I'm still unclear.
  TabAtkins: florian means what we're suggesting.
  florian: As soon as you can based on values, not based on which
           property it's in.
  dbaron: % will behave differently depending on how they behave for
          prop.
  TabAtkins: We're saying as early in the context of a property. Since
             in the property you can tell if you can know at computed
             and clamp them or you wait until used.

  dbaron: Are there cases...where we distinguish between calc(10%) and
          10% doing something different.
  TabAtkins: I don't think so. In position % don't resolve to a simple
             pixel value, but still a bare % goes to same in or out.
  fantasai: If it's negative. We throw those out at parse time.
  dbaron: If we want to throw out negative it also makes sense to
          simplify away the calc.
  dbaron: If you're at a point where you can fix the negative you
          should compute calc to a single value.
  TabAtkins: That's against our general consensus to maintain calc
             structures somewhat so that authors get to look at a
             regular thing. I've argued against that, but that was
             what the group wanted.
  florian: Channeling glazou: when possible, keeping what the author
           wrote helps with authoring tools.
  dbaron: I don't see how you maintain a calc structure while
          clamping. If you have 50px+2em and you know an em is large,
          do you change the em or do you turn it into 0px?
  TabAtkins: For animation it's 0px.
  dbaron: But we're talking what the computed value is.
  TabAtkins: Well, what the animated value is. It's mostly the
             computed, but sometimes diverges.
  TabAtkins: Big observable thing is in your animated behavior
  dbaron: I guess...you could compute it to calc 0px rather then 0px.
          But it seems weird to deal with clamping but not simply
          expressions.
  astearns: Seems weird to me to have a clamp happen but then give the
            non-clamped expression and the person using it doesn't
            know if it's evaluated as expression or clamped value.
  TabAtkins: I don't have a strong opinion but people have objected to
             removing calc before.
  fantasai: Removing calc should be a separate issue.
  dbaron: It would also be useful to have links to the other decisions.
  TabAtkins: I recall glazou being a proponent of maintaining calc

  astearns: fantasai in IRC had 2 comments [reads]
            A) Clamp as early as possible based on values.
            B) Clamps as early as possible based on the property.
  astearns: My understanding is we're going with option A.
  astearns: Is that correct?
  florian: Yes, I think so.
  astearns: What if we resolve on option A: Clamp as early as possible
            based on values. and I'll open a new issue as to what to
            do with calc when they're clamped.
  dbaron: I'm uncomfortable agreeing to clamp at a time when we're not
          agreeing to simplify calc at the same time.
  florian: Would you object to not simplifying or is there another
           option?
  TabAtkins: I'm fine with simplifying. There were arguments against
             it before.
  dbaron: I think we should table and go back to look at those
          arguments.
  astearns: I'll add a comment that we need to look at why we had been
            deciding to preserve calcs. This being a new situation
            where we're clamping the value I suspect the previous
            arguments about preserving calc-ness will go out the
            window.
  florian: astearns when you make that it's good to mention glazou.
  astearns: I will tag him on it.

  TabAtkins: This is the only thing blocking CR and V&U is quite out
             of date. Can we do a new CR with this unfinished and get
             it up to date?
  astearns: How many other changes are in the changes section?
  <fantasai> https://drafts.csswg.org/css-values-3/issues-cr-2016
  TabAtkins: I'll look. A decent amount. A number of new units
  astearns: And we're in CR?
  fantasai: The new units are in 4.
  TabAtkins: Let me link the changes.
  <TabAtkins> https://drafts.csswg.org/css-values-3/#changes
  astearns: Given we're in CR I don't think we can ask for updated
            before we republish.
  TabAtkins: Then let's close it no change and re-open it because this
             is dumb process preventing us from publishing.
  fantasai: I think we can ask for republish and explain this is a
            minor issue and still open and we'll deal with it.
  astearns: Republishing and knowing we have to do it again is also
            dumb. I'd rather wait.

  florian: Does spec have the thing we're likely to resolve to?
  TabAtkins: let me look
  TabAtkins: Current spec says always clamped at used value which is
             the one thing we agreed to not do.
  [laughs]
  florian: So resolve unless glazou objects?
  astearns: I don't want to rush this through.
  astearns: I'm sorry.
  TabAtkins: I'm just frustrated that we can't publish because
             process. I'd rather publish and publish again in a month
             then have a month of buggy TR draft.
  astearns: I agree on regular WD but CRs are extra work.

Counter Styles
==============

Mark <image> in <symbol> at risk?
---------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1991

  TabAtkins: xidorn pointed out the image value no one has impl and
             he's not interested in impl. I noted it complicates the
             definition of counter in unexplained ways. I'm happy to
             mark as at risk on track to drop.
  astearns: Any objections to Mark <image> in <symbol> at risk?

  RESOLVED: Mark <image> in <symbol> at risk

  fantasai: We just submitted it as a transition.
  <fantasai> https://github.com/w3c/transitions/issues/23

Grid
====

Percentage tracks and indefinite sizes
--------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1921#issuecomment-347993853

  astearns: We decided on a change, but it was pointed out impl have
            interop.
  fantasai: We discussed that at TPAC. We re-resolved to do the thing
            impl don't do. This is the are you sure you meant the
            thing.
  florian: We took impl into account when we decided, yes?
  fantasai: We did.
  TabAtkins: We just want to be able to mark WG is cool with this.
  astearns: I'm looking at tpac discussion and I see Rossen said this
            is fine, not a big deal.
  TabAtkins: He just didn't want to do it alone b/c it's a breaking
             change.
  Rossen: That's true. That's still my point. I'm still okay as long
          as others do the change as well.
  Rossen: We're still cool. Others?
  astearns: webkit or gecko?
  dbaron: It's a question for Mats or dholbert
  astearns: dholbert deferred to Mats.

  astearns: Given we have two impl willing to make the change and no
            obj from the others, shall we reaffirm we want this change?
  astearns: Objections?
  dbaron: Who will change first?
  dbaron: If no one will do that we shouldn't do it.
  fantasai: Rossen it looks like webkit and blink will follow if you
            lead.
  <fantasai> mrego said “We're not planing to change Blink/WebKit
             implementations until other browsers do it”
  Rossen: I won't do it the same way we tried with control characters.
          I will allow the market leader to lead and we will happily
          follow. The change is straight forward, but I don't want to
          introduce interop change.
  Rossen: For technical decision I'm fine. For scheduling and who
          when, we won't be first.
  fantasai: Rego said they won't change until other browsers do it.
            Igalia folks are good about following up so I don't think
            it'll get lost. But it will require MS to go first or at
            least say it's impl and will release on a date as long as
            WB and blink will also trigger.
  Rossen: How about we table scheduling discussion. If it's as easy
          for Rego and Igalia as it is for us, let's stop the
          discussion and we'll discuss timing. As far as spec decision
          is concerned we'll ship first as long as there are
          assurances others will follow.

  rego: We checked how many chases will go through this. We first want
        to gather data on how many websites will break with this
        change.
  Rossen: You want us to change to see breakage?
  rego: No, we added a use counter in chromium to gather data. So we
        want to wait to gather some data before doing anything.
  <gregwhitworth> rego do you mind linking to the use tracker?
  Rossen: Sounds good. Let us know that data and what it shows.
  rego: Sure.

  astearns: So anything more on this issue?
  Rossen: Is take away everyone is still okay pending some data
          collection from Igalia folks?
  astearns: Yes, pending data collection, impl complexity, and timing
            of all engines getting change done.

Resolving 'fr' flexible lengths during intrinsic sizing of grid items
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1120

  astearns: I'm not up on this issue. What was your comment Rossen ?
  Rossen: We are most likely going to have to change. We're okay with
          it, it will be simple. I'd like TabAtkins and fantasai to
          give this a read one more time. If they're still okay with
          current resolution we don't have to re-open. If they find
          additional points we can bring it back. for now I don't see
          a reason to re-open
  fantasai: Our analysis from the comment is there was a clarifaction
            place and an error in terminology. We checked in those
            fixes. We couldn't find any other wanted change then those
            errors. We checked that in and asked Rossen if there's
            anything else. I'm guessing he said no.
  Rossen: Mostly. We can discuss if after you read the comment you
          feel like we need to discuss.
  astearns: Sounds like action is for fantasai to take a look and if
            everything is fine she can mark as commenter satisfied.
  Rossen: Yes.
  astearns: Good fantasai ?
  fantasai: Yeah.

Publication
-----------

  fantasai: Rossen are you okay if we publish cr without the one you
            just found (https://github.com/w3c/csswg-drafts/issues/2085 )?
  Rossen: I really want resolution on this
  fantasai: Can we do it in Jan,? If we don't get it today it doesn't
            get published this year. But we need to publish, grid is
            super out of date, it hasn't published since may.
  fantasai: Unless you want to block on this for publication.
  Rossen: I won't object to publishing for this issue.
  fantasai: Let's resolve to publish CR update. Then we can publish
            again.
  Rossen: Do we not have a call next week?
  fantasai: This is the deadline for CR publication.
  Rossen: I'm fine discussing next week.

  <fantasai> Disposition of comments at
https://drafts.csswg.org/css-grid-1/issues-cr-2016
  astearns: Proposal is publish an updated CR of grid minus this
            issue. fantasai put together tests for all the issues
            since we resolved to require them. So I think we should
            try to publish.
  astearns: Objections to asking for a new CR of grid?

  RESOLVED: Request publication of new Grid CR.

Selectors
=========

:link and :visited are not mutually exclusive in implementations
----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2037

  victoria: We found it weird that edge is doing something different
            then the rest of us.
  victoria: It is technically doing what spec says.
  TabAtkins: I don't think it is.
  TabAtkins: I think I agree with dbaron it should be mutually
             exclusive. I thought it depended on which, it's one or
             the other not a mix.
  TabAtkins: It's not agreeing with how we thought the model worked
             for this.
  <fantasai> oh, wow that's super interesting testcases

  Rossen: I was seeing if fremy is on.
  [trouble hearing fremy]
  <fremy> don't worry
  <fremy> everything is in the issue
  astearns: Given fremy last comment in issue, do we need a spec
            change to more closely define what other browsers do or is
            it just clear edge is doing something weird?
  TabAtkins: I think spec is clear that Edge is weird. They're clearly
             mutually exclusive conditions.
  <fremy> TabAtkins: not true
  <fremy> TabAtkins: you still need to apply :link { padding } for
          instance
  astearns: fremy disagrees
  * fantasai *wishes* that they weren't mutually exclusive, but
             legacy... :(
  <TabAtkins> https://drafts.csswg.org/selectors/#link
  TabAtkins: I think his disagrees that it's an important difference.
  dbaron: I think fremy thing is after selector matching. Because the
          way the property restrictions work for some properties you
          always get the thing as if it's just visit, but for
          something like color you use the styles for has visited.
          That was derived from the legacy where we didn't have
          property restrictions.
  Rossen: fremy is coming to my office so you can hear him.
  [pause to wait for fremy]

  fremy: I think...tbh I think we do agree edge is different and we
         need to change. But I don't think the spec clearly defined
         what should be done. dbaron documents those.
  fremy: I think it would be good to clarify the spec so people get it
         right, especially because there's privacy involved. It's
         clear to me you need to match link values for visited links.
  TabAtkins: The spec says "these two states are mutually exclusive"
             so I don't know how to make it clearer.
  fremy: In practice they're not mutually exclusive.
  fantasai: What fremy says is try because you're doing background
            color for visited at same time as color from link. We
            should think of an easier way to describe this in the
            spec. For some properties visited doesn't apply and link
            applies.
  fremy: They're mutually exlcusive for some not all properties. I
         think that needs to be in the spec
  dbaron: It's a bit dangerous to mix it into the selector. It is a
          layer above selector matching in gecko. If you mix it into
          selector matching you get different results potentially.
  fantasai: I need an example
  <TabAtkins> Yeah, impls don't seem to match the spec, I agree now.

  astearns: We're out of time. There will need to be some changes to
            the spec to clarify and Edge will need to change to match
            the spec
  TabAtkins: No one matches the spec. So something has to be done.
  Rossen: So we agree to do work.
  astearns: So that's where we need to leave this. I apologize that we
            didn't get to :focus-ring and :focus-indicator. We'll
            continue in the issue and try and resolve there.
Received on Thursday, 7 December 2017 02:56:44 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 7 December 2017 02:56:45 UTC