- From: Chris Lilley <chris@w3.org>
- Date: Fri, 13 Jan 2023 23:36:40 +0200
- To: spec-prod@w3.org
Thanks Tab, this is great news! On 2023-01-13 03:07, Tab Atkins Jr. wrote: > Hey all, this has been coming for a long time, but I just cut a > release of Bikeshed to make it rely on WebRef for definitions > (maintained by the W3C, and also used by ReSpec) rather than Shepherd > (maintained by Peter Linss). This adds 200-300 more specs to the > linking database, and should now automatically add new W3C > publications to the db (rather than requiring a manual addition for > every new spec). > > The major consequence for *you* is that, since there are so many new > specs and new definitions, it's likely you'll run into new linking > errors, where an autolink that previously only had one possible target > now has multiple. Mostly, this should be dealt with just by specifying > your autolink more precisely; this sort of change happens regularly, > just usually a little at a time rather than a big bump all at once. If > you link to something multiple times, use a <pre class=link-defaults> > entry to fix it across your entire spec (see > <https://tabatkins.github.io/bikeshed/#link-defaults>). > > However, there may be some conflicting definitions that should > definitely default to one spec or another. I've caught a number of > them and built them into Bikeshed, but if you run into more (like some > common HTML term suddenly clashing with a specialty spec defining the > same thing), just let me know with a GitHub issue. > > Another note - the ECMAScript spec is in WebRef and wasn't in > Shepherd. I know this was a common cause for large <pre class=anchors> > blocks copy-pasted between specs. Go ahead and remove all those > entries from your specs; things should link correctly now. > > ~TJ > -- Chris Lilley @svgeesus Technical Director @ W3C W3C Strategy Team, Core Web Design W3C Architecture & Technology Team, Core Web & Media
Received on Friday, 13 January 2023 21:36:46 UTC