xref: search externally first, then look for local dfn

[sidvishnoi]

No description provided.

[saschanaz]

Why should the xref data preferred? Is current setup causing some problems?

[marcoscaceres]

I think the issue is not correctly articulated. The actual problem is that data-cite must not prevent matching local definitions.

[saschanaz]

data-cite must not prevent matching local definitions.

You mean must prevent?

[marcoscaceres]

These must all work:

      <section>
        <p><dfn>hi there</dfn></p>
       </section>
      <section data-cite="dom html" id="test">
        <p><a id="link1">event handler</a> try either [dom] or [html]</p>
        <section data-cite="dom">
          <p data-cite="svg">
            <a id="link2">event handler</a>
            - not in [svg] -> fallback to [dom] -> fallback to [dom], [html]
              <a>hi there</a>
          </p>
          <p>
            <a id="link3" data-cite="fetch">event handler</a>
            - try and stop at [fetch] as data-cite is on self
          </p>
        </section>
      </section>

[marcoscaceres]

You mean must prevent?

Nope. Must not.

[marcoscaceres]

This still means match in current document first, the fall back to data-cite.

[saschanaz]

Ah okay, understood.

You mean must prevent?

Nope. Must not.

Does <a id="link3" data-cite="fetch">event handler</a> possibly fallback to local definitions? The issue title seems to say it should but I think it should not...

[marcoscaceres]

Yes, but we may warn. Specs shouldn’t stomp on each other’s definitions - that’s really bad if they do.

[sidvishnoi]

This issue was created out of confusion, so closing.