| 04:24 | <annevk> | HTML5 made sense because HTML4 was the last iteration at the time |
| 04:25 | <annevk> | We did not have the foresight that version less is better |
| 06:46 | <annevk> | foolip: https://github.com/whatwg/dom/issues/410 |
| 08:12 | <tobie> | annevk: hey—think you can give me admin privs on whatwg org, so I can better identify the issue? |
| 08:21 | <annevk> | tobie: write access to the repository is not sufficient? |
| 08:23 | <tobie> | annevk: I dunno. I wanted to check how the teams were structured permission and visibility wise. Maybe you can just share a screenshot. That would work too. |
| 08:23 | <tobie> | annevk: I'm just not sure where this info is located though. |
| 08:23 | <tobie> | My hunch is this is some kind of weird team visibility issue. |
| 08:31 | <annevk> | tobie: there's no settings for teams really |
| 08:32 | <tobie> | https://help.github.com/articles/changing-team-visibility/ |
| 08:32 | <annevk> | tobie: hmm yeah |
| 08:32 | <annevk> | tobie: so "A visible team can be seen and @mentioned by every member of this organization." |
| 08:32 | <annevk> | tobie: it's visible, so... |
| 08:33 | <tobie> | annevk: Right. Let me find out what the deal is with GH apps and mentioning teams. |
| 08:33 | <annevk> | tobie: maybe if pr-preview were an actual GitHub account like whatbot it would work better? |
| 08:34 | <tobie> | annevk: that bit would. But lots of other things would be a lot more complex. It would also be less secure. |
| 08:34 | <annevk> | interesting |
| 08:34 | <annevk> | I guess I don't really know enough about all these things |
| 09:06 | <nox> | gsnedders: https://github.com/w3c/dom/issues/175#issuecomment-381291015 |
| 09:07 | <nox> | TFW circumstances make individuals defend some of the biggest corps in the world, what a time to be alive. :) |
| 09:14 | <foolip> | annevk: looking at document.lorigin removal |
| 09:34 | <annevk> | foolip: let me know if me pinging you for stuff gets too much; the main problem I have is that there's not a lot of people that actually reply |
| 09:34 | <annevk> | foolip: especially for web-platform-tests the whole OWNERS system is rather busted |
| 09:35 | <foolip> | annevk: no worries, you tend to ping me for things I enjoy and care about, which is probably no coincidence :) |
| 09:36 | <foolip> | annevk: I know Document/HTMLDocument is waiting for some reaction from me, too, somewhere in my inbox |
| 09:36 | <annevk> | foolip: I think that one is mostly about making document creation in HTML not suck, since then it'd be rather easy |
| 09:37 | <annevk> | Unfortunately it's a rather intertwingled mess |
| 09:37 | <foolip> | annevk: yeah, I think at this point clearly we should unsplit them, and figuring out all the creation points and maybe picking the prototype in the non-interoperable cases is the remaining work |
| 09:40 | <annevk> | That's the main issue I have with the castle Ian created. That there's actually a fair bit of prose intertwined with algorithms. If it were all algorithms it would've been easier. |
| 09:52 | <tobie> | annevk: curious what a non-busted OWNERS system would look like to you. |
| 09:53 | <annevk> | tobie: remove OWNERS who haven't reviewed after some time |
| 09:53 | <annevk> | tobie: (assuming PRs for stuff they own came in) |
| 09:54 | <annevk> | There's probably some complexity there in how exactly that should work, but the current system where you get a list of 10 people and none of them does anything for months is just painful |
| 09:54 | <annevk> | It makes it so those 10 people probably will forever ignore that entire repository and the person submitting the PR has no idea that nothing will happen |
| 09:55 | <tobie> | annevk: interesting. foolip, that ties in well to some of the things we discussed over mail wrt to issue triaging. |
| 09:56 | <tobie> | foolip: and more generally the migration of wpt to the GH org. |
| 09:57 | <foolip> | tobie: haven't looked at that yet, sorry :) |
| 09:57 | <tobie> | foolip: np. I wasn't trying to passive/aggressively suggest you should. :D |
| 09:58 | <tobie> | foolip: just pointing out that there was an even larger group of problems my suggestion could be a solution to. |
| 10:00 | <jgraham> | TabAtkins: The idea that the CSSWG is doing just fine at the W3C seems kind of like Stockholm Syndrome when you consider that every time we try to improve the testing situation we are told that there are a whole bunch of CSS-only Process-only requirements that add an order of magnitude in complexity |
| 10:08 | <tobie> | jgraham: can you elaborate on how you feel this relates to the W3C process, rather than a workmode the CSSWG would adopt regardless? |
| 10:29 | <jgraham> | tobie: We keep hearing that the requirements around result collection for process transitions mean that the CSSWG needs a bunch of bespoke infrastructure for e.g. running manual tests, overriding the results of reftests, and storing results. Maybe they would have the same requirements without the belief that they are Required By Process, but they would have to invent some other reason |
| 10:34 | <jgraham> | (and also it's apparently not possible for a bunch of senior people at some of the the richest companies in the world to organise resources to actually support those Very Important Requirements) |
| 10:34 | <nox> | jgraham: How come so much CSS stuff relies on manual tests btw? |
| 10:34 | <foolip> | jgraham: A charitable read of the situation is that at some point for some CSS spec, the WG tried to do it really well and noticed all these problems and found solutions. And no other group has made that kind of attempt, instead waiting it out and maybe filing issues like https://github.com/w3c/web-platform-tests/labels/type%3Auntestable |
| 10:36 | <jgraham> | foolip: A more historically motivated view is that CSS2.1 had all kinds of problems getting to Rec. and that experience informed everything since |
| 10:37 | <jgraham> | But my point was not that these things aren't actually required by process |
| 10:38 | <foolip> | jgraham: sure, but they are kinda motivated by the CSS2.1 experience, right? and the process does say *something* about interoperable implementations. |
| 10:38 | <jgraham> | It was the assertion that the W3C Process isn't causing problems for CSS doesn't match my observations |
| 10:39 | <jgraham> | foolip: Right. I mean it seems like other groups manage, so I'm not convinced that the CSSWG read of the Process document is the only valid one. But whether or not they're actually right isn't so relevant as their belief that they are right causing issues |
| 10:40 | <jgraham> | nox: A combination of stuff that is actually hard to test in automation, and stuff that could be automated but isn't |
| 10:43 | <foolip> | jgraham: AFAICT the main effect of wanting to testing things well has been manual tests and some manual test results management, which we can help automate away. Seems like much of the rest of the complexity is because of levels, would you agreee? |
| 10:45 | <jgraham> | foolip: I think that sentence implicitly understates the first part. We can automate some things that require manual tests, but with features like media queries that depend on specific hardware I'm pretty sure there are always going to be features for which manual tests will be written (and then probably run ~once at Process transition time) |
| 10:46 | <jgraham> | I also agree that levels vs living standards is a source of complexity |
| 10:48 | <foolip> | jgraham: Sure, we can only fix maybe 80% of it. Maybe we should support submitting manual results to wpt.fyi? If tested using the same browser+wpt version as an automated run it'd be useful I think. |
| 10:48 | <jgraham> | foolip: I certainly wouldn't object to that |
| 10:52 | <jgraham> | foolip: (that would be another reason to allow multiple chunks of results for a single revision to be uploaded) |
| 10:53 | <jgraham> | foolip: Although whether that will be enough or there will be something about crowdsourcing, I couldn't tell you |
| 10:53 | <foolip> | jgraham: you mean that the css build system currently allows for lots of people to collaborate on a single run? |
| 10:57 | <jgraham> | foolip: Yes |
| 10:58 | <jgraham> | http://test.csswg.org/harness/ |
| 10:59 | <foolip> | jgraham: Well, that's interesting. I guess technically it's like sharding, but how to keep track of remaining work? |
| 10:59 | <foolip> | Oh wait, we're not in #testing :) |
| 11:00 | <jgraham> | foolip: We aren't. Think of it as a useful less in how the sasuage is made for other WHATWG participants :) |
| 11:01 | <jgraham> | foolip: Without a database-based design isn't hard to see how this would work. wpt.fyi seems to have been designed around a different set of requirements with minimal knowledge about the actual tests |
| 11:06 | <foolip> | jgraham: yep. https://github.com/web-platform-tests/results-collection/issues/123 would allow us to list missing tests though. Starts to be a bit more work than just submitting results though |
| 11:08 | <jgraham> | Yeah, of course we can manipulate the generated json files to include everything in the manifest, not just the ones we actually for results for. But you'd need some process that read all the json data to generate a list of missing tests |
| 11:57 | <zcorpan> | Domenic: Do you have any opinion on https://github.com/w3c/fxtf-drafts/issues/275 ? |
| 11:57 | <zcorpan> | Also hello everyone |
| 14:24 | <Domenic> | zcorpan: it does seem a bit more idiomatic, but probably extra work that's not worth it if this is already shipping in a few places |
| 14:24 | <Domenic> | (and hello!) |
| 14:27 | <gsnedders> | jgraham, foolip: sent you email about the testing discussion last week |
| 14:28 | <Domenic> | Also, doing it in the truly idiomatic way, by using this.constructor, which would work on user-defined subclasseses as well, seems rather un-Web IDL-ey. |
| 14:28 | <zcorpan> | Domenic: yeah I agree with the last point |
| 14:30 | <zcorpan> | Domenic: can you comment in the issue? :) |
| 14:30 | <Domenic> | Sure |
| 14:31 | <zcorpan> | thx |
| 14:39 | <jgraham> | gsnedders: Thanks |
| 14:51 | <zcorpan> | Hmmmmmmmmmmm. Is https://html.spec.whatwg.org/#read-html correct in initializing a new Document when the response arrives, in wpt payment-request/allowpaymentrequest/setting-allowpaymentrequest-timing.https.sub.html ? Seems like it will run "set the allow* flags" twice. |
| 14:53 | <nox> | Friends don't send friends to the monopage version of the HTML spec. :P |
| 14:58 | <zcorpan> | https://bugs.chromium.org/p/chromium/issues/detail?id=819800#c6 |
| 14:59 | <zcorpan> | nox: maybe we should have a checkbox to prefer multipage and automatically redirect |
| 14:59 | <nox> | zcorpan: Just wanted to say "Friends don't X friends Y". :) |
| 15:02 | <Ms2ger> | Friends don't let friends' jokes fall flat? |
| 15:02 | <Ms2ger> | zcorpan, since you're taking about Document creation, the default answer would be "no" |
| 15:03 | <jgraham> | Friends don't let friends apartments? |
| 15:04 | <Ms2ger> | Friends don't pun friends |
| 15:07 | <zcorpan> | Ms2ger: I'd be happy to spend a year fixing document creation and navigation |
| 15:08 | <nox> | Ms2ger: I disagree, they do in total impunity. |
| 15:10 | <Ms2ger> | zcorpan, if I ever find someone who'd pay for that, I'll let you know :) |
| 15:11 | <zcorpan> | Ms2ger: thanks :) |
| 15:57 | <jwalden> | to all you haters out there, puns are good |
| 15:57 | <jwalden> | except in the C++ object model |
| 15:58 | <jgraham> | Those just aren't your type of puns? |
| 15:59 | <jwalden> | truth |
| 16:00 | <Ms2ger> | You got jwalden p'nned in a corner there |
| 17:49 | <TabAtkins> | jgraham: Assuming that my statement about CSSWG working must be wrong because of the group doing something annoying in your own wheelhouse makes some pretty strong assumptions about what things *I* care about in terms of how the group works... |
| 17:50 | <TabAtkins> | (While I have no opinion on most of the testing stuff, I'll note that CSS *is* fairly unique in that it *does* have an actual, unavoidable need for a goodly number of manual tests, which most specs don't have as their tech isn't directly interacting with user interaction.) |
| 18:16 | <jgraham> | TabAtkins: You didn't scope your claim about it being "just fine" only in terms of the bits that you personally care about. But sure, if that's your criteria then you're making a statement that's impossible to disagree with (and also uninteresting) |
| 18:16 | <TabAtkins> | lol ok whatever dude |
| 18:17 | <tantek> | This sounds more like a twitter thread |
| 18:18 | <TabAtkins> | It was ^_^ |
| 18:25 | <jgraham> | The testing problems in particular are mostly being externaised, and group members repeatedly state that they're a result of Process. So finding out that people in the group don't care about the problems is unsurprising (because the costs are being externalised) |
| 18:26 | <jgraham> | Anyway you are right that this is not a useful discussion |
| 18:26 | <jgraham> | Sorry |
| 18:34 | <tantek> | jgraham FWIW I am interested in helping improve the situation around testing, tests, test suite in CSS |
| 18:35 | <tantek> | as is gsnedders |
| 18:35 | <tantek> | we've raised issues and discussed a bunch last week at the CSSWG f2f, so it is a priority in so far as group time is being spent on it |
| 18:36 | <tantek> | btw I don't think anyone brought up "Process" as a excuse for any problems |
| 18:36 | <tantek> | more like crappy/abstract/unusable docs/websites |
| 18:39 | <TabAtkins> | tantek: One aspect that can reasonably be interpreted as "Process makes us do it" is our reliance on some level of manual tests; some features *can't be tested* except manually, so if we want to proceed thru Process, we need to write manual tests, which make wpt generally unhappy. |
| 18:40 | <TabAtkins> | I'm unsure what else might fall under that rubric, or might have been read as such due to bad communication in the past. |
| 18:40 | <TabAtkins> | (But "Process makes us do it" is an uncharitable reading anyway; *good testing* makes us do it. The fact that Process requires good testing is a second-level effect.) |
| 18:40 | <tantek> | "Process"? sounds more like engineering discipline like TDD - what's the point of any feature if you can't (or refuse to make) test it |
| 18:41 | <tantek> | ah yes, *good testing* |
| 18:41 | <tantek> | right agreed, Process is just pointing at existing good engineering practice |
| 18:45 | <jgraham> | tantek: The meeting notes expplicitly mention Process transitions as driving requirements |
| 18:45 | <jgraham> | And FWIW other groups with similarly difficult features to test have been more proactive about driving automated solutions |
| 18:46 | <jgraham> | e.g. adding test-only APIs to reduce the surface area of manual tests |
| 18:48 | <jgraham> | (I apparently lost my link to the meeting notes so I can't look up specifics) |
| 18:48 | <tantek> | jgraham: will take your word for it |
| 18:48 | <tantek> | often such mentions of "Process" are shorthand for explaining engineering discipline (not everyone in CSSWG is an engineer) |
| 18:48 | <tantek> | would be interesting to explore CSSOM additions to reduce surface area of manual tests |
| 18:48 | <tantek> | I expect we'd hit a limit at some point, but that's no reason not to try |
| 18:49 | <TabAtkins> | jgraham: Hm, I'd love an example of such a test-only API, any pointers? |
| 18:51 | <jgraham> | https://wicg.github.io/webusb/test/ for example |
| 19:17 | <TabAtkins> | Ooh, thanks, that's useful. |
| 22:55 | <gsnedders> | jgraham: the big problem with Writing Modes I think is the tests are broken under HiDPI, and under UI we have a bunch of issues open but they're hard to test things |
| 22:56 | <gsnedders> | (like cursors using the correct gamma when they're an image) |
| 22:56 | <gsnedders> | which is easy to implement wrong and hard to test in an automated fashion |
| 22:56 | <gsnedders> | like if I'm not mistaken, that's a hard test to write in C++ |
| 23:02 | <tantek> | indeed |
| 23:05 | <gsnedders> | (I could be mistaken and some OS might somehow make it easy) |
| 23:06 | <tantek> | or rather, none that we know of, and if someone does know better, please let us know! |