- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 4 Dec 2017 19:28:55 -0500
- 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