WHATWG on 2023-07-24

09:43	<jgraham>	I mean, we could replace it with something else, but what else is as cross-platform and readily available? Ideally typing `bikeshed spec` would result in a functional build.
09:47	<annevk>	jgraham: that doesn't meet our requirements
09:52	<jgraham>	OK, but "WHATWG specs have a worse dev experience than W3C specs" seems like a problem worth addressing (and I'm sure the people who work on these specs all the time have internalised the workflow and don't notice this problem).
10:02	<annevk>	I'd be happy for someone to address that, though I also don't think that statement really holds
10:03	<annevk>	I've tried contributing to ARIA and some other W3C documents and they're generally a mess with very custom solutions, lots of warnings, linking errors, etc.
10:17	<jgraham>	Well I'm sure there's some variety on the W3C side. But the best case scenario is that you can download any spec and type `bikeshed spec` to get a build and `bikeshed serve` to get a local webserver with auto-rebuild, and afaict the current WHATWG template means that neither of those things can work because you always need to look up extra command line arguments to fill in the `COMMIT-SHA` macro. So it might be that you could just make that macro optional and you'd already be most of the way there (and if it was up to me I'd then inline the deploy steps into the GitHub action, accept that anyone who does any non-trivial spec work is going to end up running bikeshed locally and forget about the `remote` target, and then delete the makefiles entirely to avoid having a complex tool just to more or less wrap three shell commands)
16:14	<TabAtkins>	Why is zero output for fatal errors a problem? Fatal errors in WHATWG specs prevent us from deploying them. Because I prefer Bikeshed being robust to failure as much as possible, so you can run with `-f` and still get something reasonable rather than forcing people to have a fully working build. (That is, the messages are intended to be lint-level as much as possible; it's of course reasonable to require zero linting errors to publish/update.) That implies I want visibility into the build result regardless. It is just also the case, again, that I should be capturing the messages so I know when I'm throwing more or different errors than I previously did. Like I said, this is going to be fixed.
16:17	<TabAtkins>	Well I'm sure there's some variety on the W3C side. But the best case scenario is that you can download any spec and type `bikeshed spec` to get a build and `bikeshed serve` to get a local webserver with auto-rebuild, and afaict the current WHATWG template means that neither of those things can work because you always need to look up extra command line arguments to fill in the `COMMIT-SHA` macro. So it might be that you could just make that macro optional and you'd already be most of the way there (and if it was up to me I'd then inline the deploy steps into the GitHub action, accept that anyone who does any non-trivial spec work is going to end up running bikeshed locally and forget about the `remote` target, and then delete the makefiles entirely to avoid having a complex tool just to more or less wrap three shell commands) Hm, let me raise a whatwg/meta issue, I agree that this can probably be simplified without losing any requirements, but want to make sure I'm not missing anything.
16:39	<TabAtkins>	Okay filed https://github.com/whatwg/meta/issues/286 and https://github.com/whatwg/meta/issues/287
16:39	<TabAtkins>	depending on how those shake out we can talk about dropping `make remote` and removing the makefile entirely
16:40	<bkardell>	annevk: I like what you did with `:dir`