Lightning flashed, thunder crashed and "Sean M. Burke" <[EMAIL PROTECTED]> whisp
ered:
| apparently envisages a distinction between the two, such that they are no
| longer mutually exclusive!
| (At least as I understand things, they /are/ mutually exclusive currently:
| a link is either to L<name/item> or L<name/"section">.)
There are many instances in the standard docs where we've had to change
things because of this. There is no good reason that they should be
mutually exclusive.
| So does L<name/"sec":"foos"> mean a link to the link-tag in the "sec"
| section, ignoring any other "foos" things in the document? I don't think
| those semantics are feasable in HTML, and I think of hypertextification as
| basically the whole point of the L<...> construct (since otherwise you
| could just have plaintext saying: "See Foo::Bar's section on Baz"). And
| making a hypertext construct that's hard to make into HTML is very bad idea.
Yes, L<name/"sec":"foo"> would mean the item "foo" in the "sec" section. I
don't see a problem with HTML in this respect. We just need to make
pod2html be smart enough to create <A NAME="#sec-foo"> or some such. It
could also make <A NAME="#-foo"> so that L<name/:"foo"> would work.
| Also, if I read it right, your proposal is incompatible with existing POD;
| it would reject like L<perlvar/Predefined Names> and L<perlvar/$^F>. And,
| for incompatibility in the other direction, I think that current POD
| parsers would misread L<foo|"name":"section"> as making the text foo a link
| to a man page called name":"section [sic!].
Yes, it is incompatible with the current situation. However, the current
situation is irrevocably broken and needs fixed. The translaters (and
hopefully the docs) would need to be fixed at the same time the new syntax
was used. It would be possible, I think, to make the translaters smart
enough to figure out how to work around the problems.
| But I like compatibility; and my suggestion is basically a clarification of
| existing practice (i.e., clarifying that section-link-targets and
| item-link-targes might as well be the same thing), and my further
| suggestion for deprecation (above) is just to shoo people away from
| pointlessly ambiguous constructs.
I like compatibility as well. I also like politics, committees, and
standards but only so long as they don't interfere with fixing problems and
getting jobs done. Sometimes we have to break things to fix them.
-spp
