Re: [w3c/ServiceWorker] DO NOT MERGE: using better link defaults (#995)

> `<a>browsing context</a>` is not working despite setting a link default for it like the error message asks me to

Oh shoot, that's just a terrible error message on my part. The first option should include a `for: /;`, like Anne suggests. Tracking in <https://github.com/tabatkins/bikeshed/issues/851>.

> `<a>DOM manipulation task source</a>` is not working despite HTML exporting that term

Ah, bleh, this is a misfire of Shepherd's auto-detection. Note the value in the db:

```
$ bikeshed refs --text="DOM manipulation task source"
status:    snapshot
for:       []
level:     1
url:       https://html.spec.whatwg.org/multipage/webappapis.html#dom-manipulation-task-source
type:      interface
export:    True
text:      DOM manipulation task source
shortname: html
normative: True
spec:      html
```

It's type "interface", not "dfn". This is because, lacking other information, Shepherd introspects on the ID, and it so happens that the "dom-foo" pattern is used to detect interfaces and other IDL types.  To fix, HTML needs to mark it up with an explicit `data-dfn-type=dfn`.

> `task queues` and `origin`

Both of these are the same thing. I've tried to help you with these before: autolinking attributes filter the possible choices (and lacking an attribute means you don't filter on that aspect), and then locals are always preferred above foreign anchors.

So in both of these cases, without a `for` value on the link, we don't filter by `for` value. A single matching anchor is found locally, so it's chosen automatically; we never see the foreign anchor at all.  This is by design and extremely intentional; without it, it would be very annoying to link to local terms sometimes (if a foreign anchor happens to also match). Having a local anchor for a given term/type almost always means you want to link to that. For the rare cases you want to get around this, you either specify the `for` value or the `spec` value, so the local anchor gets filtered away and we move on to checking foreign anchors.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/995#issuecomment-255904307