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

[CSSWG] Minutes San Fransisco F2F 2017-11-06 Part III: Flexbox, Image Decoding, Line Clamping, Cleaning up OWNERS files, Feedback on testing policy [css-flexbox] [css-overflow]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 4 Dec 2017 19:28:55 -0500
Message-ID: <CADhPm3txYE=BE1_QWzWbCaNzRGXELmdnEbb9=5__ckQpWtDdPA@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.
=========================================


Flexbox
-------

  - dholbert will investigate the Firefox code around sizing images
      and add more details on their implementation to the issue.
      His comment is here:
        https://github.com/w3c/csswg-drafts/issues/1322#issuecomment-342307410

Image Decoding
--------------

  - smfr introduced the group to the proposal to expose an API to
      control background decoding of images:
      https://github.com/whatwg/html/issues/1920

Line Clamping
-------------

  - There were two points of discussion, how to address the existing
      desire to have some of webkit-line-clamp and, if so, how to
      extend that further.
  - The desire is to have a concrete proposal for a webkit-line-clamp
      like property to further discussion.

Cleaning up OWNERS files
------------------------

  - Anyone listed on an OWNER file who won't be reviewing tests was
      asked to do a PR and remove themselves.
  - There was some interest in a bot to notify of unreviewed tests.

Feedback on testing policy
--------------------------

  - The group spent time discussing how the resolution to require
      tests for CR+ spec has been doing in practice.
  - There was a desire to see a bit more nuance in the definition to
      have the tests become required once there is one implementation,
      to exclude editorial changes, and to clearly not require testing
      every possible variation, but to instead be a general test.
  - Additionally, there was a desire to add teeth to the policy where
      changes are not merged into the main until there is a test.
      However, several people were concerned that that requirement
      would cause changes never to be merged in instead of the
      intended addition of tests.

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

Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda

Scribe: iank

Meeting Planning
================

  astearns: Talked with the chair of TTWG, about CSSWG equiv things,
            talking with them on Friday this week.
  <astearns> https://github.com/w3c/ttml2/issues/406
  astearns: Looking for volunteers to go the meeting.
  astearns: Lets go to non-interop of sizing images in flexbox.

Flexbox
=======

Non-interop of sizing images in flexbox
---------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1322

  fantasai: <goes to project>
  fantasai: Testcase in last comment: https://codepen.io/jensimmons/pen/aVmogq
  fantasai: Flex container, and has some content that shrink down to
            their min-content size, if you have too many items they'll
            start to overflow.
  fantasai: Excess space starts to take up, the text starts to break,
            <explains the testcase>
  fantasai: The item with the image starts shrinking.
  fantasai: This FF behavior is kinda nice.
  fantasai: So we want to make FF follow the spec? Or make other
            vendors follow FF implementation?

  dholbert: I wrote most of the flex code in FF, and don't know whats
            going on here.
  gregwhitworth: What is the usecase where folks would want this
                 behavior?
  fantasai: This means that it won't overflow, where other
            implementations would.
  dholbert: <explains image gallery usecase> being able to shrink them
            is kinda nice.
  fantasai: The image doesn't shrink until everything else has wrapped.
  cbiesinger: If you give the image a flex-basis: auto, and others a
              flex-basis of 0, don't you get that behavior?
  fantasai: You wouldn't be able to get them to start out at their
            content sizes?
  fantasai: I don't think we need to resolve now, but interesting to
            think about.
  dholbert: I'll try and figure out whats happening in our impl, and
            report back on the github issue.

  jensimmons: I had a few questions about flexbox, lots of interop
              issues around squishing images, and because of those
              issues, they are really hard for authors to think about.
  astearns: Definitely want interop here, just need to agree what that
            behavior is.
  Rossen: It looks like we have all the impls apart from FF, having
          interop.
  Rossen: Switching to FF, means that we might run into compat.
  fantasai: We were going through interop cases, and most of them were
            obviously needing impl fixes, but this one seemed
            interesting.
  jensimmons: It also seems like we could do what we want, as there
              seems to be such lack of interop around images.
  gregwhitworth: Only about this issue?
  jensimmons: No, more broadly about images as flex items.
  gregwhitworth: Where are the bugs?
  fantasai: Don't have them here. But this one just seemed interesting.

  <gregwhitworth> jensimmons: it would be cool to see the full list of
                  issues for images as flex items

Image Decoding
==============
  Github: https://github.com/whatwg/html/issues/1920
  https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-decode

  smfr: This should be fairly short. WebKit making more of its image
        decoding async, to a separate thread.
  smfr: Browsers do this in different ways, if an image has loaded
        (event), there won't be a flash.
  smfr: Off main thread decoding for animated images, - fairly
        straight forward.
  smfr: Also tried to do this for a large images.
  smfr: A bunch of authors have assumptions about where the decode
        happens.
  smfr: Would like to propose a new APIs to allow us to do background
        image decoding.

  smfr: 2 things we've done so far.
  smfr: Proposed an API for decoding. promise = img.docode();
  smfr: <explains that once promise has resolved, image has decoded>
  smfr: The 2nd thing that we've proposed, a way for authors to tell
        the engine that is ok to decode these images async. (may be a
        flash).
  smfr: A way for authors to opt into async decoding for <img>, but no
        way to do this for CSS images.
  smfr: This might be something like a new image function, or
        additional argument to the image function, etc.
  smfr: Nothing written up yet.
  TabAtkins: We left space for an async tag, in the url() function.
  <group talking about image() function>

  smfr: Google images does a thing where they load a low res image,
        and then replace to a high res image.
  smfr: This is broken in FF, and Edge.
  Thomas Wisniewski: Can authors opt into sync decoding instead?
  smfr: I think we need the attribute to go both ways... might have an
        "auto" which is current browser behavior.
  leaverou: Whats the usecase for authors to control this?
  smfr: Want to display large images, without blocking the large
        images.
  leaverou: Why control for authors.
  smfr: For compat reasons we can do this in more cases, as it
        introduces flashes.
  smfr: Lots of sites to this based on size of page, this case we'd
        always to sync decoding.
  smfr: If an image is going low-high res, you really don't want a
        flash. The user-agent doesn't have enough information to make
        the best decision.
  smfr: It's hard for a UA to tell whether the image is replacing
        something similar to itself (e.g., a low res version) or
        whether it's replacing a blank space or a placeholder.

  leaverou: Is there a way to provide a fallback image?
  TabAtkins: image() function has this.
  various: image() function was about supported formats fallback list
  TabAtkins: We could have it such that the image() function will look
             until it can render something that can be immediately
             rendered, like a color or gradient.
  leaverou: What's a data URL of an SVG considered to be?
  TabAtkins: I don't know.

  dbaron: Isn't there one reason that you need this the fact that
          there is a 'load' event for images, do you need this for CSS
          as there isn't a load event for CSS?
  smfr: Authors do things like load the same image with an img tag,
        then place the same image into CSS.
  smfr: With decode you need to have additional information like the
        size of the image.
  smfr: prefer to have a declarative solution to this problem
  <leaverou> also a remote image that has already been loaded and
             decoded for some other reason should probably be fair
             game too?
  <leaverou> though then you have race conditions
  chrishtr: The promise returned isn't permanent, such that the UA can
            evict it from the cache if needed.
  fremy: There are way for authors to place images on top of each
         other.
  smfr: We saw a bunch of different ways that people did this.
  smfr: We found that there wasn't a way to do this well unless that
        authors told us what they wanted.

  plinss: Is there going to be an event?
  smfr: No, unless we want to fire events for CSS images in general, I
        don't think that we should special case.

Line Clamping
=============
  GitHub: https://github.com/w3c/csswg-drafts/issues/390

  TabAtkins: Ignore the topic of the github issue, basically many
             years ago, hyatt added some hacky code that turned the
             -webkit-box code, to allow it to do line clamping.
  TabAtkins: If you have more ignore them for sizing purposes.
  TabAtkins: The implementation is weird, very weird behavior,
             property etc.
  TabAtkins: We'd like to address this properly.
  TabAtkins: This is the only major part of the -webkit-box code that
             needs to be maintained.
  TabAtkins: What needs to be mapped, preserved for line-clamp, and
             removed.
  TabAtkins: We'd like to start up a spec to handle the line-clamping
             behavior.
  eae: Would like a way to eventually alias this property over.
  eae: And would like to do this in a way that other folks can alias.

  florian: I don't remember the discussion of the spec.
  florian: Expand on what we already have?
  TabAtkins: Yes.

  smfr: Would like to extend this feature a little.
  smfr: Mail client has a feature where it keeps some lines at the
        beginning, keeps some lines at the end, and collapses in the
        middle of the content, with clicky in the middle to expand it
        all back
  smfr: Collapses in the middle of the content.
  smfr: We would like to see this as start, end, middle.

  florian: max-lines as currently specified is a fragmentation thing,
           makes the div into a fragmentainer, that breaks after a
           certain number of lines.
  florian: Drop the rest of the lines.
  florian: Could make it such that you get additional lines.
  smfr: We did consider fragmentation to implement this feature, I
        don't really have opinions on how to do this.
  smfr: It does interact with fragmentation possibly.

  leaverou: Why is this being discussed in terms of max-lines, and not
            max-height?
  florian: Images in between for example, typically people want to
           clamp lines
  florian: and break at a fragmentation point, not slice partway
           through a line
  florian: The generalized this in overflow-4 lets you deal with
           heights...
  florian: And let you decide if the additional div gets dropped.
  leaverou: In most cases I've seen the clipping is visual.
  florian: But you don't want to split a line in the middle?
  leaverou: If an ellipsis isn't displayed, people won't use this.
  florian: Its a separate issue...

  Scribe: eae

  iank: One thing I'd like to stress is that we've seen a lot of
        demand for something simple like clamping the number of
        max-lines. Would like to keep it simple and not expand scope
        too much.
  iank: Clamping both start and end adds complexity as it requires
        layout out all of the text. Have to think about.
  iank: We're looking to remove support for percentage values for
        webkit-line-clamp. Behavior is bizarre and there is
        essentially zero usage.
  <eae> use counter for percentage values:
https://www.chromestatus.com/metrics/feature/timeline/popularity/2139

  fantasai: I agree that we should limit scope. Discussion about
            advanced use cases is great, but I don't want to go
            there right now. Want to understand actual proposal.
  fantasai: As I understand from proposal, calculate the height of
            specified lines and set max-height based on that.
            Is there more to it then that?
  TabAtkins: You don't want the lines to still be there like with
             line-clamp, we want to omit the rest of the lines.
  TabAtkins: Want to suppress display of line boxes after the cut off.
  TabAtkins: Right now they are simply considered to be of zero height
             for sizing but are still there.
  <TabAtkins> https://drafts.csswg.org/css-overflow-4/#issue-6fadc074
  fantasai: So the ellipsis gets inserted?

  florian: The machinery of clamping or cloning or fragmentation is
           invoked implicitly if set max-lines. There is an issue
           saying that one has to explicitly enabling the
           fragmentation support.
  iank: My only concern with that is that invokes a bunch of machinery
        that takes a lot of implementation work. A simple max-lines
        behavior is potentially a lot simpler.
  florian: Concerned that it would require a lot of reinvention.

  Rossen: Want to re-emphasis fantasai's question. In my mind we keep
          going back and forth between two different things:
  Rossen: 1) Fragmentation and stop layout at some boundary. Should
             think of this in css4
  Rossen: 2) Existing pain, what TabAtkins is taking about. We have a
             a lot of requests for webkit-line-clamp support.
  Rossen: My point here again. This is different. If we want to be
          compatible with webkit-line-clamp then the behavior is
          different. Not fragmenting, consumes space differently.
  Rossen: Not that different to implement as long as it doesn't
          involve fragmentation.
  fantasai: Would like to see a concrete proposal.
  TabAtkins: The goal of this was to start up something that at the
             bare minimum addresses the "I want n of something".
  TabAtkins: All reasonable things that I'd like to see addressed.
             Should resolve whether we want to do or not.

  fantasai: line-clamp can be made to support a subset of uses cases
            but if you want support for more complex use cases then
            the problem gets a lot harder.
  fantasai: Should try to tackle the problems one at a time.
  fantasai: I don't want to expand line-clamp, I would rather it
            stayed as some minimally simple property that could be
            used to *build* other things. Not design it to be expanded
            to do all the other things.
  TabAtkins: I would like to explore the space. Replace
             webkit-line-clamp first and then, maybe, extend it later.

  florian: Responding to ian/rossen. When I was talking about invoking
           the machinery not walking about ..., to deal with
           fragmentation. I think we sort of have to, if not then we'd
           have to resolve what to do about text shadow, intruding
           floats etc. Would rather refer to the fragmentation spec.
  florian: Would also be compatible with the rest of the spec in the
           future.
  florian: css overflow invokes css break, max-lines already speced
           there.
  <fantasai> https://www.w3.org/TR/css-break-3/#possible-breaks

Cleaning up OWNERS files
========================
  Scribe: TabAtkins

  gregwhitworth: I got put on a review for Syntax (which should never
                 occur, I don't know it)
  gregwhitworth: That exposed a problem - I submitted some tests,
                 those people should be in owners.
  gregwhitworth: When I add a flexbox test, 9 or 10 owners are added,
                 but geoffrey ends up always reviewing them.
  gregwhitworth: So if we could go thru and review the OWNERS files
                 and make sure it's actually the QA owners.
  gregwhitworth: Whoever is actually going to be the person that will
                 review a given spec.
  astearns: I think >1 person is good, but yeah, if you're on an
            OWNERS file and not willing to review, is it just a PR to
            remove yourself?
  gregwhitworth: Yeah, just asking everyone to do it for themselves.
                 ^_^
  astearns: And adding yourself to OWNERS where appropriate.

  gsnedders: There has historically been some habit of using that like
             a cc flag, rather than a test-owners thing.
  foolip: This ties into triage - we can mess with OWNERS files, but
          we also need to notice when people in those files aren't
          doing reviews.
  foolip: Also helps us discover where we need to add people.

  foolip: What do people who are submitting tests want? Immediate
          review, I guess, but how do you deal with spec issues when
          things go unnoticed for a while?
  florian: For spec issues we eventually had to do a DoC, so we go
           thru and make sure nothing was dropped.
  florian: That helps with specs that are worked on, even if slowly.
           But it doesn't help specs that aren't worked on.
  foolip: So that's like every quarter or so?
  [laughter]
  florian: Usually much slower. Sometimes every few years.

  foolip: So any prefs on how this should work? A bot emailing the
          list when things go unnoticed?
  florian: If we sent something every *year* when things were
           reviewed, it would be a massive improvement. 2 days would
           be crazy fast.
  gregwhitworth: Related: if you've ever committed to a spec, go to
                 w-p-t repo and check the OWNERS files. If you're not
                 actually relevant for that spec, remove yourself.
  dbaron: Or if you notice yourself getting reviews for something you
          feel like you shouldn't be reviewing.

Feedback on testing policy
==========================

  zcorpan: I made a PR in September to add a testing policy for the
           CSSWG for specs in CR.
  zcorpan: + CSSOM and CSSOM-view
  zcorpan: I wanted to get feedback from the WG on how this has been
           going - if policy is working, what benefits, what might
           need changing.

  Chris: In other groups that do this, editors do PRs and then the WG
         approves and merges.
  Chris: In there, adding a test in is really easy.
  Chris: In our group we don't do that, editors push to master. That
         makes this hard.
  Chris: *Some* editors seem to be doing tests and specs together,
         it's useful.

  florian: I've tried to be more systematic about writing tests with
           changes, and linking to the tests from the changes.
  florian: What I haven't noticed is a significant difference in
           reviewer activity; I was worried it would be the
           bottleneck, and it still is.
  florian: We haven't been doing this long enough for my anecdotes to
           become data, but it doesn't seem improved from the past.
  Chris: The spec-readiness things that go out every week, I've been
         guilty of using that to push people on reviewing things.
  <zcorpan> (issues with "Needs Testcase" label
            https://github.com/w3c/csswg-drafts/issues?utf8=✓&q=label%3A"Needs%20Testcase%20(WPT)"%20
)

  gregwhitworth: I'm gonna be a pain - I agree with florian from last
                 discussion. I desire a world where everything modern
                 - I run flex, grid, vars, etc - I'm running daily our
                 build system, and if it turns red I know we regressed
                 or the spec changed.
  gregwhitworth: This is very important, I can't keep track of
                 everything.
  gregwhitworth: I'd like to start giving teeth to this.
  gregwhitworth: I don't think we'll ever get to the interop goals us
                 browsers want without tests added for every change.
  foolip: What teeth would you like to add?
  gregwhitworth: There's words that it's CR.
  gregwhitworth: I feel like it should be more universal.
  gregwhitworth: Every other WG MS is in has this policy - every spec
                 change has tests along with it. We're the only WG
                 that doesn't.
  gregwhitworth: Just spent a lot of time reviewing flexbox tests,
                 finding a lot of old redundant tests, a huge waste of
                 time.

  <tantek> I would be ok with WD + impls
  <tantek> = require test case to make normative change
  <tantek> not just WD
  florian: Even tho this is somewhat informal, this group sometimes
           does internal incubation, and forcing tests then seems
           counter-intuitive.
  florian: Once we reach the point we're no longer brainstorming,
           actually refining...

  foolip: Most other groups don't have a CR req, it's just a matter of
          "if it makes sense at this point, let's do that".
  foolip: That's a problem for immature stuff.
  foolip: So the criteria I propose is: anything with one or more impl
          has tests.
  <tantek> +1
  foolip: Means you can punt on testing until someone tries to
          implement.
  foolip: And first implementor is in a good position to write tests.
          Shouldn't always be editor's task; it's not that in the
          WHATWG.
  dbaron: Same - when you have impls.

  dbaron: Also it's very dangerous to write tests without impls.
  dbaron: You write a whole bunch of tests, try to execute spec in
          your head, and it turns out that people are worse at that
          than software.
  dbaron: So you end up with lots of tests that are wrong in subtle
          ways.
  <tantek> +1
  <bkardell> +1

  dbaron: We also have a general problem of losing track of things
          like spec changes, edits, and figuring out the state of
          things.
  dbaron: Part of that is that we tend to resolve to change things,
          and then nothing happens.
  dbaron: I feel like we should try to use GH issues more for this.
  dbaron: If we have a thing we agree to do and it's not done yet, we
          should be tracking it in GH as an open issue.
  <tantek> resolutions for normative changes MUST be in a github issue
  <foolip> for people reading the logs,
https://github.com/foolip/testing-in-standards/blob/master/lifecycle.md
           is my whole thinking about when it makes sense to start
           caring about testing.
  florian: Aren't we already doing that?
  dbaron: I feel like we're not.
  dbaron: This includes us agreeing to some resolution, and there
          isn't an issue for it.
  TabAtkins: After F2F, make sure everything is in an issue or tracked
             otherwise
  dbaron: Even in a meeting - should have an issue as soon as we
          discuss something.

  astearns: Going back a bit, question of teeth.
  astearns: Whether we should apply this rule to CR+, or bring it back
            to things with impls.
  astearns: What are the teeth?
  astearns: We haven't been consistent about it even with CR+
  TabAtkins: For anything in testing stage, only do edits via
             PR-merging.
  TabAtkins: Only push to master for incubation-stage stuff.
  <tantek> for normative changes
  <tantek> editorial should not require that
  astearns: Agree
  <TabAtkins> agree with tantek
  <tantek> also important to drop or update existing tests that are
           affected!

  florian: If we agree to enforce it that way, we need to be careful
           about how to process the giant backlog, and if fantasai and
           tab create 25 PRs per week, still problem with processing
           them.
  florian: So going from "a bunch of specs not tested" to "most of the
           spec is in hanging PRs" isn't an improvement.
  fantasai: That's my point - "why don't you block edits on writing
            tests", I think it's better to publish things where they
            can see them, instead of seeing a diff.
  fantasai: Some things will only require one test, others will need
            200. I don't want to be on the hook for all of those.
  astearns: That's not the request - SOME tests, not a full test-suite.
  florian: Not full test suite, just full tests *for the feature being
           tested*.
  astearns: I'm saying just "at least one".
  fantasai: Like, if I change an orthogonal flow thing, I need to
            write like 500 tests.
  fantasai: That's an extreme example.
  fantasai: but 30+ test isn't uncommon

  florian: Regardless of the rules we set up, we won't solve this
           until some companies set up a budget to pay for QA.
  florian: If we don't get that, we'll rely on the goodwill of people
           like me, and that doesn't scale.

  zcorpan: PR model in the whatwg - every change has a PR, someone
           needs to review, someone needs a testcase.
  zcorpan: Without that, the PR is left open, we never commit to
           master.
  zcorpan: Sounds like there's some issue with the workmode - edits
           get made, we forget about testcases, or resolution are made
           and we forget about edits, that sort of thing.
  zcorpan: So what workmode do we need to not lose track of things.
  fantasai: I think GH is helping a ton with that, to the extent that
            things are in GH.
  fantasai: Resolutions get in there from gh-bot
  fantasai: And we have a needs-testcase flag.

  zcorpan: Responding to fantasai's point, about changes with a big
           testcase burden.
  zcorpan: The policy in CONTRIBUTING.md is that in such cases,
           instead of writing the tests, you file an issue with wpt
           explaining that this change needs testcases.
  zcorpan: Or something is blocking writing the testcases.
  zcorpan: So documenting that testcases are missing, and why.
  florian: So this sounds like a variant of our needs-testcases flag;
           not sure which is better if nobody looks at them?
  zcorpan: If it's straightforward but a lot of work, then
           needs-testcases in CSSWG seems like it's sufficient.
  zcorpan: But sometimes there's tooling missing to write it at all,
           in wpt, so that needs a separate fallback.
  zcorpan: So then we need an issue in wpt, saying that the current
           tooling makes it impossible to write a case for.

  gregwhitworth: I agree with the once-one-impl thing.
  gregwhitworth: I know internally we're focusing more on testing.
  gregwhitworth: I think it's worthwhile, as much as we'd all love to
                 solve every problem in spec form, we all depend on
                 interop.
  gregwhitworth: Doesn't matter if we all implement some new thing if
                 it doesn't work properly in every browser.
  gregwhitworth: So go with PR, say it doesn't land without at least
                 one test.
  gregwhitworth: And with gh issues, often there are already
                 testcases, just informal, need to be wrapped up in
                 testharness
  gregwhitworth: I don't think it's a monumental task to get this
                 working.
  gregwhitworth: And when we go implement it, we'll create more
                 testcases, and implement that.
  fantasai: Yeah, one or two testcases is way more manageable than
            "please fully test this change in all permutations".
  gregwhitworth: I'd love when we go to CR we already have a testcase
                 working.
  gregwhitworth: To hammer home the point - I'd like to get some
                 resolution that's beyond CR.
  gregwhitworth: I think we need teeth or else nothing will happen.
  * fantasai would like to just get more specs in to CR that are
             supposed to be in CR

  gsnedders: I have 2 viewpoints.
  gsnedders: I don't think there's any point in testsuites before
             impl, same as others.
  gsnedders: But when there is an impl, the vendors who impl'd will
             have written tests, to land the feature.
  gsnedders: So inherently there's already a testsuite.
  florian: It might not be shared, or shareable.
  gsnedders: Tho now we have 2-way sync from Gecko and Blink, so
             hopefully more and more tests are in wpt from the get-go.
  gsnedders: The other thing is getting tests per edit.
  gsnedders: So presumably, when someone impls the edit, there's a
             test for it.
  TabAtkins: We don't want to hold up PRs until someone impls
             something.

  fantasai: Yeah, anything that forces us to hold a PR for more than
            2 weeks is a failure.
  fantasai: In CSS2, we had that errata list, and if you wanted to impl
            something you had to check the spec and the errata.
  fantasai: This got super unwieldy, so we eventually merged all the
            changes in to create CSS2.1.
  fantasai: I don't want to get into that same state, except way worse
            because instead of an errata list you have a disorganized
            pile of diffs in GH PRs.
  fantasai: If we're withholding edits from being published for
            too long, that's a failure state.

  gsnedders: When it comes blocking things on PRs, the experience from
             the other groups that have done this is that we don't end
             up blocking on PRs.
  florian: How?
  gsnedders: Someone comes along and actually looks at it.
  gsnedders: Sometimes someone wanted to impl it, so they want the PR
             landed. Sometimes because someone is watching and
             reviewing the changes.
  gsnedders: Generally there's far less problem getting review.
  dbaron: The point of changing the process is to change how people
          spend their time.
  dbaron: I think if we're changing the process to make people spend
          more time writing tests, people will spend more time writing
          tests.
  florian: And we might distinguish between "everybody" and "tab and
           fantasai". If we don't want tab and fantasai to spend less
           time writing specs, we need more people to write tests.
  florian: Their plate is already more than full being the catch-all
           editors. That's why I suggested someone funding the QA work.

  foolip: I don't think it's a matter of decreasing throughput.
  foolip: Ultimately everything needs to be implemented.
  foolip: It's a matter of closing the feedback cycle, so the thing
          being written is closer to time of test being written and
          time of implementation.
  foolip: So getting impls more involved in writing tests and keeping
          track of changes to the spec.
  foolip: It would be a failure if it ends up with the editor writing
          all the tests.
  florian: My earlier point here - either we decrease tab and
          fantasai's throughput, or we move test burden.
  foolip: In Blink, soon to actually ship something we'll require it
          to have wpt. So that's a forcing function.
  foolip: Can't go on indefinitely without it being on a Chromium
          engineer's plate to get the work done.
  fantasai: So that bug - made edits, made a PR, then engineer is
            leave of absence for months, then team does a perf push,
            then a YEAR LATER someone finally impls it... the PR has
            been there for a year.
  fantasai: The spec needs to be reliably up-to-date with what we
            decided.
  <jensimmons> +1. We can’t have secret spec updates living in pull
               requests, invisible to people.

  dbaron: If you make a spec change and *nobody* tries to implement it
          for a year, we'll just wait and change it again anyway.
  fantasai: But if it's in PR, and I need to change something about it,
            I can't see those edits.
  fantasai: I can't deal with a pile of PRs like that.
  fantasai: If we wait for impls to make the change, it'll always be
            months.
  <dbaron> I don't think the implementors have to be the ones who make
           the test change
  <fantasai> dbaron, right, which brings us back to the editor has to
             make the test change
  <fantasai> basically I'm saying foolip's idea that implementors will
             take up the responsibility to write tests for all spec
             changes is unworkable

  <jensimmons> as a person who’s worked in git code repos for years,
               with teams, you cannot leave things lying around in
               pull requests. That’s a terrible way to work.
  <gsnedders> jensimmons: the experience in other groups hasn't been
              things lying around in PRs; if this WG can't get things
              reviewed that implies something is going wrong within
              this WG
  <jensimmons> gsnedders: but that is the experience of *this* working
               group
  <gsnedders> jensimmons: yes, indeed; the question is why are
              participants, most of whom work for vendors, act
              differently to their colleagues in other WGs
  <jensimmons> this is has been sitting here for 2 months:
               https://github.com/w3c/web-platform-tests/pull/7364
  <gsnedders> jensimmons: and this is something we see relatively
              rarely for other testsuites, which implies for whatever
              reason the layout developers behave differently to e.g.
              the DOM developers, and it's not clear why
  <jensimmons> gsnedders: struggling with getting people to write
               tests is *insanely* common in the industry of people
               who make websites. It’s not the CSSWG.
  <gsnedders> jensimmons: yes, that's true; but it's not an issue we
              see around most of WPT

  twisniewski: I was gonna suggest we start with something simple,
               like have gh hooks that say when there's open requests
               in the spec. Someone will be annoyed and poke people.
  twisniewski: And there's a push for people to go fix it up.

  Chris: Echoing fantasai, it's hard to review spec changes and tests
         with a bunch of diffs.
  Chris: When I was doing the fonts 3 review, I put them in the w3c
         repo just so people could see them execute.
  plh: We have a mechanism for that in wpt.
  <plh> --> http://w3c-test.org/submissions/ pull requests for WPT

  astearns: I suggest we take out of this discussion to tighten up
            what we resolved on.
  astearns: Already resolved on tests for CR+
  astearns: I suggest we try out the PR for CR-level specs model.
  astearns: With the caveat that we want to see how we deal with those
            PRs, so they don't just pile up.
  florian: We'll still have stuff piling up.
  florian: Nobody's been reviewing tests, even tho I'm blocked.
  astearns: I don't see a way of solving that issue before break.
  florian: I don't have a solution without money.
  gregwhitworth: Or down the through-put.

  fantasai: So say we're like "you need tests for the PR, but nobody
            else will do it, therefore editors have to write the
            tests".
  fantasai: So 50% of my time goes to tests or whatever.
  fantasai: Then people complain "why isn't this in the spec, I want
            to ship it yesterday"
  TabAtkins: The earlier failure mode was "no impl happens for a long
             while, so no urgency on the test, and the PR hangs". Here
             you're positing someone wanting to implement. They'll
             produce a test, then.
  <tantek> thank you astearns

<br dur=20min>
Received on Tuesday, 5 December 2017 00:29:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 5 December 2017 00:29:52 UTC