- From: Greg Whitworth via GitHub <sysbot+gh@w3.org>
- Date: Fri, 18 Aug 2017 17:42:47 +0000
- To: public-css-archive@w3.org
> That said, I'm unaware of anyone having done any work on any such tool (@gregwhitworth wrote something that grouped based on links, but didn't do what the build system did and plot that relative to the table of contents of the spec), or anyone willing to pay anyone to work on it. I actually had a version that would map to TOC, but that limited it too far as some links were deeper than that, additionally that's how I discovered the issue with regard to mismatching from what was in the TOC. Also, this is exactly why I brought up the linking of musts/should during the test discussion at the F2F as I don't think simply mapping to the TOC is the best approach. I would like for every test submitted to have a `rel=help` and while you state it doesn't help implementers I'm spending quite a bit of time doing this work and I'd really like them to be there. So it shouldn't be mandatory as I'd prefer tests than no tests, but I would definitely prefer them. Bikeshed already supports wrapping your things with anchors and it will create a unique id for the page, the only thing that I need to add to my tool or bikeshed is a way to tie the practice of spec writing and test pruning together. We did this for normative changes to specs in CR but it would be preferable to have a flag in bikeshed to run and then check the spec for possible test review. @plinss mentioned that this is possible to include in the email once bikeshed has the lookup information to WPT. That's about it IMO regarding tooling, shall we do a oneday hackathon and get this busted out? @tabatkins for visibility in hopes he'll offer his python-foo? -- GitHub Notification of comment by gregwhitworth Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1730#issuecomment-323416947 using your GitHub account
Received on Friday, 18 August 2017 17:42:48 UTC