Re^3: Linking to a POD section that is not uniquely named (try it to see)

Replies are listed 'Best First'.
Re^4: Linking to a POD section that is not uniquely named (try it to see) by perlancar (Hermit) on Nov 29, 2018 at 07:39 UTC
Ah, okay. Didn't realize the spec is now in perlpodspec. And the spec indeed mentions the case of multiple/ambiguous section: This specification does not specify what behavior should be in the case of a given document having several things all seeming to produce the same section identifier (e.g., in HTML, several things all producing the same anchorname in ... elements). Where Pod processors can control this behavior, they should use the first such anchor. That is, L<Foo/Bar> refers to the first "Bar" section in Foo. But for some processors/formats this cannot be easily controlled; as with the HTML example, the behavior of multiple ambiguous ... is most easily just left up to browsers to decide. So I guess the simplest thing to do on the part of document writer is to make sure section names are unique.	[reply]

Replies are listed 'Best First'.

Re^4: Linking to a POD section that is not uniquely named (try it to see)
by perlancar (Hermit) on Nov 29, 2018 at 07:39 UTC

Ah, okay. Didn't realize the spec is now in perlpodspec. And the spec indeed mentions the case of multiple/ambiguous section:

This specification does not specify what behavior should be in the case of a given document having several things all seeming to produce the same section identifier (e.g., in HTML, several things all producing the same anchorname in ... elements). Where Pod processors can control this behavior, they should use the first such anchor. That is, L<Foo/Bar> refers to the first "Bar" section in Foo.

But for some processors/formats this cannot be easily controlled; as with the HTML example, the behavior of multiple ambiguous ... is most easily just left up to browsers to decide.

So I guess the simplest thing to do on the part of document writer is to make sure section names are unique.

[reply]