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

[CSSWG] Minutes Telecon 2017-08-30 [css-values]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 31 Aug 2017 08:27:12 -0400
Message-ID: <CADhPm3t6F0RGzPsz=sG4JoCyPk6XEX+FJ+kzHyjHjkF_Q_H4tw@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.

Test Metadata

  - Florian raised some confusion he had regarding how to move tests
      when what they're testing changed level in the spec.
  - WPT needs the path name not to change so that references stay
      accurate, however CSSWG needs to have something that says what
      a test is for in order to move specs to REC and these two
      needs are conflicting.
  - There is a requirement within the CSSWG folder to have the
      rel=help populated which is providing the necessary data, but
      this requirement isn't applied to anything outside that folder.
  - The group re-committed to continue requiring rel=help within the
      CSS folder in order to keep the test harness and associated
      programs working.
  - Path not being changeable also create problems since right now
      everything in wpt is versioned.
  - There was a desire to move into unversioned folders to ensure
      the path is consistent even if a feature moves to a different
      version of a spec, but this kind of move needs coordination so
      gsnedders will look into what is the preferred approach.

Consider policy to ask for web-platform-tests

  - The group approved of zcorpan's suggested text
      (https://github.com/w3c/csswg-drafts/pull/1767 ) and agreed it
      should be worded as a must and applied to all CR specs and any
      specs close to CR where the author feels comfortable requiring

Should viewport units still depend on scrollbar width for

  - Though the original instinct was to remove this requirement as
      there's only one implementation, there were strong opinions as
      to why this behavior is valuable and solves an else wise
      unsolvable use case.
  - There's still a need for implementer feedback in order to have a
      second implementation of this feature.


Agenda: https://lists.w3.org/Archives/Public/www-style/2017Aug/0043.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Robert Flack
  Tony Graham
  Dael Jackson
  Brian Kardell
  Tomoya Kimura
  Peter Linss
  Myles Maxfield
  Simon Pieters
  Anton Prowse
  François Remy
  Melanie Richards
  Florian Rivoal
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth

  Vlad Levantovsky
  Chris Lilley
  Jen Simmons
  Lea Verou

Scribe: dael

Spec Rec Next Steps

  astearns: Let's start. Is there anything extra to add to the
  astearns: Next would be spec rec, but I haven't done anything to
            figure out where things are. Is there anything people
            would like to volunteer?
  Florian: Is Bert or Chris on? I think Chris is off.
  Florian: Okay. I had asked for MQ4 CR transition. Got a reply it's
           okay, but someone needs to do it.
  astearns: I will ping them for a status.
  astearns: Anything else on rec track items?

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

  astearns: You were putting tests in that had the rel=help metadata?
  Florian: I was moving tests from UI3 to UI4 and I fixed the rel
           and fixed the file path because my memory of when we
           agreed to merge repos rel was agreed to be optional
           because same info was in path.
  Florian: I naively updated the path and was told not to do that.
           Now I understand they prefer when rel is there and the
           path doesn't change.
  Florian: They want rel=help and the path to be accurate, but
           higher preference is path to not change. The preferred
           way to do this is un-versioned spec in the path. I
           thought the path must encode location and it's only a
  Florian: Currently our tooling relies on rel=help, but I thought
           we were eventually supposed to update tooling.
  astearns: Also when we imported CSS test to web platform we didn't
            follow the spec name folder, it's all in CSS.
  Florian: And leveled spec names.
  astearns: Right. So I think the point where we fully use path as
            encoding for the test is when we start adding tests for
            new spec outside of css directory.
  Florian: I think there is already a few.
  Florian: Key point for me is to understand if it's just me who
           misunderstood or if it's the whole group. We can't
           programatically rely on the path or rel=help being there.
  Florian: If it's just me, fine.
  plinss: Clarification. Our tooling depends on rel=help. wpt was
          planned to have path as encoding and beyond the spec
          having sub folders. Some structure. There was a plan to
          augment our tool to fallback to path, but that's on hold
          until path name is reliable.
  <zcorpan> Currently top-level css directories: css-backgrounds
            css-cascade css-font-display css-font-loading css-fonts
            css-paint-api css-scoping css-timing css-typed-om
            cssom-view cssom
  Florian: And there's no plan for that. Spec names unversioned are
           sorta expected to be reliable, but unversioned not and
           section level will be more of the same. When a piece of
           spec moves there's resistance to changing the path.
  astearns: And other outside tooling relying on that means we can
            never rely on path. We need a requirement to have the
            rel=help links.
  Florian: But that goes against moving outside css directory.
  plinss: No. The css directory was there because that was easy for
          the transition. Our tooling doesn't care about the path at
          all if there's a rel=help link.
  Florian: But a wpt will not make rel=help mandatory.
  gsnedders: It's mandatory in css subdirectory.
  Florian: Right.
  Florian: But we're not mandating the subdirectory.

  fantasai: Do we want to transition outside css directory?
  plinss: There are already some. There are some people moved out,
          there were some outside already. I don't really care where
          they are.
  Florian: I kinda came into that...on the one end I think we
           strongly require this and they strongly require this to
           be option and we apparently had not agreed.
  astearns: I don't think we decided rel=help is mandatory to check
            in tests. We don't want a fail if it's not there, but we
            strongly prefer it. As tests get run we're going to add
            rel=help meta data to those.
  fantasai: We decided to make rel=help optional because it would be
            replaced by file path. If that's not the case having it
            optional makes no sense. We need to know what's being
  Florian: What I was told is that moving things along the rec track
           was a non-goal for the wpt. Though it's better to have
           meta data it still works as a test and it's better to
           have this than no tests.
  fantasai: We agreed to have our tests in their repo, but we
            shouldn't drop our goals.
  astearns: While our tooling isn't going to use anything in the
            path, we are still able to rely on top level css folder
            or top levels that correspond to our tests to see it is
            css and if it's lacking rel it can be fixed.
  astearns: I'd prefer we keep it optional in that nothing will stop
            someone from checking is a test but still strongly
            preferring it so that we have the practice of checking
            in the rel=help
  <dbaron> I agree with the position -- having regression tests is
           useful even if they're not used for advancing on the REC
  <fantasai> dbaron, sure, but I expect it's going to be used as an
             excuse for people to be sloppy and putting more work on
  <fantasai> dbaron, it's way easier for the test writer to
             associate at test with a spec than for us to go back
             and do so retroactively
  <fantasai> dbaron, also people should COMMENT THEIR CODE, and that
             includes tests, and the WPT folks insisting that tests
             be uncommented regression dumps while also believing
             that function declarations should have some kind of
             commenting is hypocritical
  <fantasai> dbaron, tests are maintained code, too
  <dbaron> fantasai, There are also regression tests where it's not
           clear what the specs say, but we actually do have interop
           and should keep it.
  <fantasai> dbaron, sure, and those should be filed as bugs against
             the specs, preferably with a link to the test in
             question so that we can update it as necessary

  gsnedders: If I can summarize, two parts. 1 there was some plan to
             add a per directory file to preserve the mapping to
             specs even if things got moved around. The other thing
             was I thought there was some agreement to move away to
             the tooling people were using for impl tests and wpts
  plinss: We have to rely on the tooling we have until there's a
          tool that meets our needs.
  Florian: And I don't think there's a perception that we require
           our meta data b/c w3c, but because it makes our lives
           easier. I've been told we're just imagining requirements
           from w3c when they're not.
  plinss: We've never done our testing infrastructure b/c a w3c
          mandate. They only mandate we have tests. How we do that
          is up to us.
  astearns: fwiw there was someone complaining on whatwg irc about
            an undocumented test.

  fantasai: This is a general problem. There are people that think
            web platform is a regression dump, but there are other
            people that have to go back and maintain that code.
            We're those people. We have to look at the code.
  astearns: I don't have a good idea of how many tests we have in
            wpt that are css tests and lack rel metadata. Does
  gsnedders: In principle everything in css subdirectory does. It's
             a question of how many are outside.
  astearns: And how many have meta data.
  gsnedders: Few outside the subdirectory have it, I think. This is
             my impression, I don't have numbers.
  astearns: Does the current tooling require rel to check in to css
  gsnedders: It does.
  astearns: So it won't spread in css subdirectory. And maybe we can
            turn it on elsewhere.
  Florian: But there's a plan to move out of subdirectory.
  astearns: As we spread out we can spread the requirements to the
            directories with our tests.
  Florian: gsnedders do you think it's welcome?
  gsnedders: I guess not.
  gregwhitworth: What's the difference between sub level and top
                 level that's not ours?
  gsnedders: The status quo is we have this one top level with a
             bunch of different requirements to everything else. I
             think it's the only one that has any different actual
             check in level req.
  Florian: Based on the discussions I've had the rest outside csswg
           is for the web community and if they want to write tests
           they shouldn't have to follow our unusual rules.

  <fantasai> How are people supposed to cooperate on test coverage
             if everyone's writing tests in their own little corner
             and not looking at what else is in the repo? Part of
             the point here is not to duplicate work by having each
             implementer write its own version of the same exact
  <dbaron> OK, I guess I'm fine with requiring rel=help

  astearns: I would guess the policy for a top level should be
            dictated by the owners. The cssom tests are outside the
            directory. So zcorpan are the tests there using rel
            links? And would you welcome having that req for those
  zcorpan: They are currently outside CSS. I believe they mostly
           have meta data.
  zcorpan: Exception is prob there are test using like .window.js
  zcorpan: I usually at least make sure the path [missed]
  astearns: That's part of your review to make sure the rel links
            are there?
  <zcorpan> I don't know how many of the tests have metadata, but
            the tests were in css before so presumably most have
  astearns: Okay.

  gsnedders: I think some of the cssom tests were already in wpt
             before the merge.
  gsnedders: Therefore those might not have the meta data. That's
             why they live outside css.
  <zcorpan> When I write tests I try to make sure either there's a
            rel-help or that the directory structure matches which
            spec is tested.
  <zcorpan> https://github.com/w3c/web-platform-tests/blob/master/html/README.md
            is the policy for html/
  fantasai: I think it's fine if cssom since they're different. If
            we have a separate top level for every spec we'd have
            some test outside css subdirectory and some within so it
            makes it hard to find things. Also that's a lot of
            subdirectories so people finding what they're looking
            for is hard.
  astearns: I agree it's messy for some in and some out, but it's
            the current reality. We could not add more to it but
            adding new tests in css. It sounds to me like we want to
            continue to require rel meta data links on all tests
            inside css directory going forward. Doesn't seem like we
            can change that and it's helpful to have.
  astearns: We can look into requiring the rel link in other folders
            for tests outside css folder.

  <fantasai> There are less than 200 non-CSSOM tests outside the css.
  <zcorpan> (I think for Chromium there's no problem with moving
            tests, the tooling should figure that out. Might be
            different for other vendors.)
  <gsnedders> fantasai: including almost all of Houdini, IIRC
  <gsnedders> zcorpan: (expectation data hardcodes the path)

  Florian: Questions. 1) if it annoys people when files move we
           should stop that so when we get close to rec and an at
           risk feature moves moving them is not liked. unversioned
           folders solves that. Should we start doing that? If yes,
  astearns: Any thoughts on moving to non-versioned folders?
  fantasai: I'm okay with that.
  Florian: If we do it in one shot and warn people it might be okay
  <zcorpan> gsnedders: (I was informed that the downstream updater
            figures out expectations for moved tests.)
  gsnedders: There's some consensus it's okay to do these things in
             big moves to get rid of cases where css uses policies
             not used by the rest of the repo.
  Florian: That's pref? moving css/cssfoo3 or move everything to css/
           foo all at once?
  gsnedders: There's a part of me in favor of keeping status quo
             until we have different tooling and them move to top
             level at once.
  fantasai: If we want to move to having the path encode data we
            should do that at same time. But if we drop versions we
            can't do subscriptions reliably because they'll change
            level to level. Some will be same, some won't.
  fantasai: I think it'll be tricky to have unversioned module
            directories but also do what to have per section sub
            directories. We can do one or the other but not both.
  Florian: I think we might want subdirectories per topic, but if we
           can't move the shouldn't be fine grained.
  fantasai: Agree. We should just have per module directories on
            level. It would be a good idea to move the tests outside
            css subdirectory in and then maintain that for all
            tests. If we put them top level it'll be 60 top level
            and be hard for people to find all css tests.
  fantasai: I think it makes the repo more usable if we don't have
            all 60+ modules scattered across the top level.

  astearns: gsnedders can I give you an action to look at moving to
            unversioned folders in one go to avoid file movements in
            the further? Within the css subdirectory?
  gsnedders: I guess
  Florian: Until we have the answer, should we start making
           unversioned subdirectory to avoid making it worse for new
  astearns: I think it makes sense for new tests
  fantasai: If we're going to move a bunch people will have to deal.
            If we don't move we'll have to move those things back.
  astearns: Perhaps new test suite if you have to make a new folder,
            make it unversioned.

  Florian: Question 2) If we move out of css subdirectory for
           purpose of no longer following css rules, what do we lost
           beyond rel=help?
  gsnedders: I can't remember all. There's the check for unique
             files names within test suite. We have rel=help.
             There's another I can't remember
  Florian: These are things we only care about b/c build tool relies
           on them. Correct?
  gsnedders: Yes. All CSS only events are there to keep the build
             system working.
  <zcorpan> css/ also can't use .window.js, .worker.js, .any.js,
            since they can't encode rel=help
  <zcorpan> though adding ability to encode a spec link in those
            seems possible
  <gsnedders> zcorpan: also that doesn't work in the build system,
              because they don't use wptserve
  plinss: Beyond that the build system org tests into per spec
          suites and generates other versions of tests. Other
          tooling relies on that output like test harness and spec
          annotations. Also if we ever want anything to say what
          tests a spec change may break. So I keep hearing we might
          move, but if we lose the meta data we lose these extra
  Florian: This idea is that other people get by without this and
           why can't we. I don't know why we should change.
  plinss: We care about taking specs to rec. It's a non goal of wpt
          so do not expect support for that goal.
  astearns: Other people also require a test when you change a spec.

  <fantasai> gsnedders, if we're looking into reorganizing the tests
             within css/, we should also look into moving those <200
             non-cssom tests into css/; otherwise more people will
             try to copy that pattern and we'll end up with
             duplicate locations

Consider policy to ask for web-platform-tests
  github: https://github.com/w3c/csswg-drafts/issues/1755

  astearns: zcorpan would like to require tests for cssom and cssom
            view changes even though those specs aren't in cr. I
            think that's consistent with what we resolved in Paris.
            Requiring this for tests not yet in cr also makes sense
            and it's up tot he spec author to make that
  astearns: zcorpan is that accurate?
  <zcorpan> Yep.
  <zcorpan> So how this works in whatwg and other places is that a
            spec PR is blocked on having tests, and the two PRs are
            merged at the same time
  astearns: I am in favor of having spec authors require tests for
            changes they make at their discretion in addition to
            having rossen and I hold people to that standard for CR+
  Florian: I'm a little confused. I thought zcorpan wanted to check
           in a file that explained that. It's not the author
           requiring himself to do that, but for 3rd party
  Florian: It's things added by everyone to that spec. poss merged
           by editor
  astearns: I think zcorpan should add something saying it's
            required for CR specs and also for other specs at some
            level of stability.
  Florian: I think his wording was a should and it was reused from
           other places. zcorpan are you okay with more specific
           wording or do you want to keep the generic one?
  <zcorpan> I would be happy either way, whatever works best for the
  astearns: I think I would prefer having the more specific wording
            so that I have something to point to when I start being
            hard about this requirement.
  astearns: Any objections to having more specific wording in test
            repo documentation?
  <Rossen> +1
  <Florian> astearns: +1
  <zcorpan> sounds good
  * fantasai suggests astearns doesn't start being hard about the
             requirement until the next publication of css-flexbox
             and css-grid, or else they will not get updated on /TR
             for at least another 5 months
  astearns: I'll ask zcorpan to check those changes in.

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

  astearns: I'm not sure what's left. Can anyone summarize?
  * tantek reads
  <tantek> looks like we discussed it last week
  TabAtkins: No one removed the agenda+
  <tantek> because: <dael> jensimmons: I'm fine punting to next week.

Should viewport units still depend on scrollbar width for
  github: https://github.com/w3c/csswg-drafts/issues/1766

  astearns: We're waiting on impl feedback?
  TabAtkins: Yes, I'm getting ?? to comment.

  dbaron: I raised this b/c gecko was the only engine that impl when
          we decided this years ago. It's apparently harder to do on
          stylo. I think it's reasonable on their part.
  myles: If all browsers except Mozilla ones don't support and Moz
         wants to remove it seems clear
  TabAtkins: Without this feature there's a lot of cases where
             viewport is broken. There are plenty that do, but I
             suspect people are avoiding these things. You cannot
             get 100vw to be the size of the screen. There's usually
             a scrollbar and 100vw is too big.
  myles: The description says it's only on scroll not auto.
  TabAtkins: We decided viewport should be resolved at computed. For
             overflow auto we decided to ignore scrollbar, but w
             wanted to pay attention when it's there.
             overflow:scroll causes a scrollbar so we set it to take
             scrollbar into account in that case.
  myles: Overflow:Scroll on root is not common case.
  TabAtkins: I agree. But when your scrollbar appears your items to
             100vw will overflow horizontal and cause a scrollbar.
             The way we decided to let that be solved you can set
             overflow scroll on it explicitly so it fits. Without
             this viewport units are just broken. The only time they
             add to the viewport is when you have no scrollbar which
             is uncommon.
  fremy: You still need to know size of scrollbar. It's not a static
  Rossen: We're talking about unit value. I'm with TabAtkins. If in
          the case of overflow:scroll when scrollbar takes space away
          from viewable viewport current spec mandates the correct
          behavior from user PoV. viewport should resolve to
  Rossen: Changing spec for interop and going against what makes
          sense isn't best.
  Florian: If we don't drop the thing should we extend it to handle
           the scrollbar-gutter property? Even if it's auto?
  TabAtkins: Prob should. Assuming whatever element applies to root
             scroller. If that works and we define how that would
  * fantasai agrees with TabAtkins
  Rossen: I would argue against that. The element causing the
          scrollbar could be defined in vh unit which causes
          scrollbar and introduces a dependency. In the case of
          overflow scroll on the viewport we only need to add
          computed value and resolve overflow for the root. From
          there on decide what the value will be.
  fantasai: No one is suggesting auto for scrollbar. There's a
            scrollbar-gutter property that adds extra space.
  Rossen: I was reading the minutes from Florian about perhaps
          extending to auto.
  <fantasai> Florian was asking about scrollbar-gutter property
  <Florian> https://drafts.csswg.org/css-overflow-4/#scollbar-gutter-property
  TabAtkins: It's only when you have a predictable value to auto.
  Florian: Even though you get that you get a predictable size with
           space reserved but not scrollbar so maybe that shouldn't
           count. I don't know.

  Rossen: Let's assume simple l to r. Whatever an element with
          abspos top 0 right 0 wherever that positions to should be
          extent of vh.
  TabAtkins: No because then by default auto changes value of vw
             unit and that defeats the computed value time purpose.
  Rossen: No in the case of the gutter we're talking about the prop
          reserving space for gutter.
  TabAtkins: If gutter is predictable yet.
  Rossen: That's what I'm talking about. So if abspos items are
          positioned to gutter this should be extent of vh as well?
  Florian: I don't think we explicitly define it may fall out of the
           wording, but I don't think that was conscious decision.
  Florian: I don't think we decided on that.
  astearns: Is that enough on the gutter sidebar?
  Florian: I think we need to come back, but not for this call.

  astearns: I want to go back to the discussion before gutters
            where...I agree that vw should take the scrollbar into
            account where it exists. But the one piece of impl
            feedback on that is it's really annoying to have to
            layout arbitrary things when you gain a scrollbar. Would
            it make sense to define auto same as scroll case for vw?
            It's always taking into case possible scrollbar?
  TabAtkins: If you have overflow: hidden on root vw doesn't stretch
             all the way across the screen.
  Florian: Just auto.
  TabAtkins: No, still hidden. Just changing auto doesn't fix dbaron
             problem. He didn't want size of vw change based on
             somebody updating [missed]
  TabAtkins: Change at all is the worry. Main response is this is no
             different when m unit. You change the font and
             everything below has to change. Only more complicated
             is that sometimes body can set viewport. So you can
             effect one element up.
  TabAtkins: Aside from that one element jump which is very rare and
             not important for purpose of tree expense this is
             identical to setting font size.
  TabAtkins: You don't need layout this is computed value time
  <dbaron> I think there were actually 2 issues.
  <Rossen> dbaron, can you pls summarize?
  <dbaron> One was that dynamic changes to 'overflow' are hard, but
           that the other is that in Gecko, we need to depend on
           layout to find out what the scrollbar width is.

  dbaron: Second thing that made it hard in gecko, it's not ready.
  dbaron: [missed]
  dbaron: I'm not even sure it worked reliably. I think it worked
          most of the time because usually we constructed scrollbars
  TabAtkins: Is that b/c scrollbar width is controllable in FF?
  dbaron: It depends on too many OS dependent things and that code
          exists in scrollbar layout.
  TabAtkins: So maybe just moving the code up and piping the data
             down into layout instead.
  dbaron: It's possible that the number of things to test is 2 or 3,
          but that's not the way it was written.
  <Rossen> wouldn't webkit-scrollbar {width} have the same effect?

  astearns: We're at time. I'm hearing the desire to keep spec
            behavior as-is, but we'll need other impl to make the
            changes. We should continue impl feedback in the issue.
            We're out of time today, we'll talk next week.

  <TabAtkins> Rossen: A controllable scrollbar width does cause
              problems for this, yes. I'd be fine with a vw that
              only responds to the "default" width of the scrollbar.
              It actually *is* easy to make a global --var that's
              equal to 1% of the viewport width minus whatever you
              manually set the scrollbar to. (Not the case with the
              UA-defined scrollbar width, I think.)
Received on Thursday, 31 August 2017 12:28:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:01 UTC