You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@forrest.apache.org by Ferdinand Soethe <sa...@soethe.net> on 2005/02/22 16:03:28 UTC
Problem with named anchors in HTML-pages being removed
During some involuntary testing of treatment of local anchors in
HTML-pages I found a rather unnerving 'feature'.
If a local anchor like
<h2><a name="myanchorID">My visible headline</a></h2>
is processed by Forrests default treatment, the anchor is
'disappeared' and replaced by the following code:
<a name="N10016"></a><a name="My+visible+headline"></a>
<h3 class="boxed">My visible headline</h3>
This is no problem for Forrest internally as it uses its new
self-generated anchors, but it is if you have other pages referencing
this section by using the original anchor name.
And unless your page is really static, you cannot even use the new
anchors to reference this section as the
- numeric anchor will change each time the structure of your page
changes while
- the text based anchor depends on the text of your heading (which
might change as well).
My question: Could transformation not preserve existing anchors in
an html-page and - in case of conflict - adjust its autogenerated
anchors to avoid the conflict.
--
Ferdinand Soethe
Re: Problem with named anchors in HTML-pages being removed
Posted by Ross Gardler <rg...@apache.org>.
Johannes Schaefer wrote:
> This works for forrest document format:
> <section id="my_anchor">
> I don't know for HTML input, though.
It could be a bug in html2document.xsl.
Ross
Re: Problem with named anchors in HTML-pages being removed
Posted by Ferdinand Soethe <sa...@soethe.net>.
Johannes Schaefer wrote:
JS> This works for forrest document format:
JS> <section id="my_anchor">
JS> I don't know for HTML input, though.
JS> Have you tried <h2 id="my_anchor">?
No, I haven't tried this as it would not solve the problem when
integrating legacy html that use the name-Attribute.
--
Ferdinand Soethe
Re: Problem with named anchors in HTML-pages being removed
Posted by Johannes Schaefer <jo...@uidesign.de>.
This works for forrest document format:
<section id="my_anchor">
I don't know for HTML input, though.
Have you tried <h2 id="my_anchor">?
Johannes
Ferdinand Soethe wrote:
> During some involuntary testing of treatment of local anchors in
> HTML-pages I found a rather unnerving 'feature'.
>
> If a local anchor like
>
> <h2><a name="myanchorID">My visible headline</a></h2>
>
> is processed by Forrests default treatment, the anchor is
> 'disappeared' and replaced by the following code:
>
> <a name="N10016"></a><a name="My+visible+headline"></a>
> <h3 class="boxed">My visible headline</h3>
>
> This is no problem for Forrest internally as it uses its new
> self-generated anchors, but it is if you have other pages referencing
> this section by using the original anchor name.
>
> And unless your page is really static, you cannot even use the new
> anchors to reference this section as the
>
> - numeric anchor will change each time the structure of your page
> changes while
>
> - the text based anchor depends on the text of your heading (which
> might change as well).
>
> My question: Could transformation not preserve existing anchors in
> an html-page and - in case of conflict - adjust its autogenerated
> anchors to avoid the conflict.
>
> --
> Ferdinand Soethe
>
>
>
--
User Interface Design GmbH * Teinacher Str. 38 * D-71634
Ludwigsburg
Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99
Geschäftsstelle: User Interface Design GmbH *
Lehrer-Götz-Weg 11 * D-81825 München
www.uidesign.de
Buch "User Interface Tuning" von Joachim Machate & Michael
Burmester
www.user-interface-tuning.de
Besuchen Sie uns auf der Hannover Messe 11.-15. April 2005
Halle 2, Stand C14 auf dem MMI Gemeinschaftsstand
www.uidesign.de/hmi2005
Nächstes TAE-Seminar zu User Interface Design
Ostfildern-Nellingen, 07.-08. April 2005
www.tae.de TAE-Veranstaltung Nr. 31189
Re: Problem with named anchors in HTML-pages being removed
Posted by Ferdinand Soethe <sa...@soethe.net>.
Ross Gardler wrote:
RG> Can you enter a bug on the issue tracker and record any of your findings
RG> there.
OK, will do that tommorrow.
--
Ferdinand Soethe
Re: Problem with named anchors in HTML-pages being removed
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> During some involuntary testing of treatment of local anchors in
> HTML-pages I found a rather unnerving 'feature'.
>
> If a local anchor like
>
> <h2><a name="myanchorID">My visible headline</a></h2>
>
> is processed by Forrests default treatment, the anchor is
> 'disappeared' and replaced by the following code:
>
> <a name="N10016"></a><a name="My+visible+headline"></a>
> <h3 class="boxed">My visible headline</h3>
>
> This is no problem for Forrest internally as it uses its new
> self-generated anchors, but it is if you have other pages referencing
> this section by using the original anchor name.
>
> And unless your page is really static, you cannot even use the new
> anchors to reference this section as the
>
> - numeric anchor will change each time the structure of your page
> changes while
>
> - the text based anchor depends on the text of your heading (which
> might change as well).
The auto generated anchors are for Forrests internal use so it does not
matter that they may change. If you want to manually create link to a
part of your page you should define the anchor name yourself in the
code. Of course, this is exactly your problem, your manually defined
anchors are being dropped.
Everything works fine for xdocs, so it must be a problem with
html2document.xsl. Can you work out where your anchors are being lost.
Try retrieving your page as an xdoc (by requesting
http://localhost:8888/myLegacyHTMLFile.xml). Do you see your anchors in
there? If not then it is confirmed as an html2document.xsl issue.
Can you enter a bug on the issue tracker and record any of your findings
there.
> My question: Could transformation not preserve existing anchors in
> an html-page and - in case of conflict - adjust its autogenerated
> anchors to avoid the conflict.
The avoiding conflict thing would be a good idea, but not a priority
right now as it is unlikely to happen. Please create a feature request
for this. If it becomes a problem then we can solve it.
Ross