Enh. Req: Option to have Table of Contents Tool Create Numeric Id's

[WebsterJoe]

Hi,

In a document that looks like this:

<h1>Main Title</h1>
<h2>Step 1</h2>
<h2>Step 2</h2>
<h2>Step 3</h2>

after generating a Table of Contents the headings are assigned id's that look like this.

<h1>Main Title</h1>
<h2 id="Step">Step 1</h2>
<h2 id="Step1">Step 2</h2>
<h2 id="Step2">Step 3</h2>

Not only is it confusing to have a document where "Step2" identifies a section labeled "Step 3" but things get worse when the section headings change. E.g.

<h1>Main Title</h1>

<h2 id="Step">Task 440</h2>
<h2 id="Step1">Task 450</h2>
<h2 id="Step2">Task 470</h2>

Now we have "Step" identifying headings that do not even use the term "Step".

It would be nice if the Table of Contents tool could assign unique, non-intelligent id's like "id-1", "id-2", "id-3" to headings. Mozilla based editors already take this approach by creating id's of the form "mozTocId260519".

Thx.


(tested on Amaya 11.2)

[ve3ll-2]

In an attempt at user friendliness and configurability, why not offer

an option to allow the user to set the root term  with numbering to start

at 0 rather than a blank --- and a default of step|id|amaya|whatever

that way the user could set a root that is meaningful and non-conflicting to other ids

for example  jwr0, jwr1, jwr2,  for my own johns wonderful  ritings haha

<original message follows>

In a document that looks like this:

<h1>Main Title</h1>

<h2>Step 1</h2>

<h2>Step 2</h2>

<h2>Step 3</h2>

after generating a Table of Contents the headings are assigned id's that

look like this.

<h1>Main Title</h1>

<h2 id="Step">Step 1</h2>

<h2 id="Step1">Step 2</h2>

<h2 id="Step2">Step 3</h2>

Not only is it confusing to have a document where "Step2" identifies a

section labeled "Step 3" but things get worse when the section headings

change. E.g.

<h1>Main Title</h1>

<h2 id="Step">Task 440</h2>

<h2 id="Step1">Task 450</h2>

<h2 id="Step2">Task 470</h2>

Now we have "Step" identifying headings that do not even use the term

"Step".

It would be nice if the Table of Contents tool could assign unique,

non-intelligent id's like "id-1", "id-2", "id-3" to headings. Mozilla based

editors already take this approach by creating id's of the form

"mozTocId260519".

Thx.

(tested on Amaya 11.2)

--

--

John Russell, VE3LL@...

http://home.cogeco.ca/~ve3ll

http://home.cogeco.ca/~trains

http://home.cogeco.ca/~cipher

 

[Vatton]

Hi,

The generation of id attributes is a general mechanism that works also
when you create a single target anchor. Initially Amaya generated a
label that as not relation with the contents of the element like
Mozilla. We changed to generate more intelligent ids because in many
cases an intelligent id is more useful. An id like "mozTocId260519" is
always confusing so you never try to interpret it.

Le lundi 02 novembre 2009 à 23:37 +0000, Joe Webster a écrit :

> Hi,
>
> In a document that looks like this:
>
> <h1>Main Title</h1>
> <h2>Step 1</h2>
> <h2>Step 2</h2>
> <h2>Step 3</h2>
>
> after generating a Table of Contents the headings are assigned id's
> that look like this.
>
> <h1>Main Title</h1>
> <h2 id="Step">Step 1</h2>
> <h2 id="Step1">Step 2</h2>
> <h2 id="Step2">Step 3</h2>
>
> Not only is it confusing to have a document where "Step2" identifies a
> section labeled "Step 3" but things get worse when the section
> headings change. E.g.
>
> <h1>Main Title</h1>
>
> <h2 id="Step">Task 440</h2>
> <h2 id="Step1">Task 450</h2>
> <h2 id="Step2">Task 470</h2>
>
> Now we have "Step" identifying headings that do not even use the term
> "Step".

When the element has an id, it must'nt be changed.

> It would be nice if the Table of Contents tool could assign unique,
> non-intelligent id's like "id-1", "id-2", "id-3" to headings. Mozilla
> based editors already take this approach by creating id's of the form
> "mozTocId260519".

>
> Thx.
>
>
> (tested on Amaya 11.2)
>
>
--
Irene Vatton <Irene.Vatton@...>
INRIA

[WebsterJoe]

Hi,

> Initially Amaya generated a label that as not relation with the contents
> of the element like Mozilla. We changed to generate more intelligent
> ids because in many cases an intelligent id is more useful.

It looks like a classic case where the solution to one perceived problem creates other problems. It typically happens when no single solution is the right answer in all cases. The usual fix is to provide a preference setting that enables either one behaviour or the other.

If some people feel intelligent keys are best and other feel unintelligent keys are best then, instead of choosing sides, why not give users the option to use either?

> When the element has an id, it must'nt be changed.

If that's so then why not raise an error when someone tries to change an element that has an id? Probably because that would be a silly thing to do. People edit headings all the time. That's what editors are for. It's unrealistic to expect heading text to remain static forever after using the Table of Contents feature once.

Alternatively, dropping and recreating headings or wiping out their ids are inconvenient, non-intuitive workarounds that negate the convenience of having a Table of Contents feature in the first place.

[Vatton]

Le mercredi 04 novembre 2009 à 09:39 -0500, Joe Webster a écrit :

> Hi,
>
> > Initially Amaya generated a label that as not relation with the
> contents
> > of the element like Mozilla. We changed to generate more
> intelligent
> > ids because in many cases an intelligent id is more useful.
>
> It looks like a classic case where the solution to one perceived
> problem creates other problems. It typically happens when no single
> solution is the right answer in all cases. The usual fix is to provide
> a preference setting that enables either one behaviour or the other.
>
> If some people feel intelligent keys are best and other feel
> unintelligent keys are best then, instead of choosing sides, why not
> give users the option to use either?

For the table of contents I restored the generation of generic labels.

>
> > When the element has an id, it must'nt be changed.
>
> If that's so then why not raise an error when someone tries to change
> an element that has an id? Probably because that would be a silly
> thing to do. People edit headings all the time. That's what editors
> are for. It's unrealistic to expect heading text to remain static
> forever after using the Table of Contents feature once.
>
> Alternatively, dropping and recreating headings or wiping out their
> ids are inconvenient, non-intuitive workarounds that negate the
> convenience of having a Table of Contents feature in the first place.
>

--
Irene Vatton <Irene.Vatton@...>
INRIA