[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: use id="xx" instead of <a name="xx"> in html output

From: Per Bothner
Subject: Re: use id="xx" instead of <a name="xx"> in html output
Date: Tue, 9 Feb 2016 12:07:11 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 02/09/2016 10:30 AM, Gavin Smith wrote:
I think <A NAME> is good to use for the target of a hyperlink, even if
it has been deprecated by HTML5, this was always the way to do it in
earlier versions of HTML. The reason to use the the ID attribute would
be for manipulation with JavaScript functions like getElementById.

Using "id" makes sense when it is the name of a sub-tree, like a chapter
or section, since it can be directly associated with an element that
represents the subtree.

Using <a name="xx"> is reasonable when it is the name of a *position*,
as resulting from an @anchor.  Though being able to use getElementById
is an argument for using id for positions as well.  I.e. you can do:

<span class="anchor" id="foo></span>

as equivalent to:

<a name="foo"/>

The main reason to prefer the former is using getElementById.
But I think that is good reason.

I see no need for a two levels of <div>. "Nodes" are an artifact of
the Texinfo source. They don't have an idiomatic meaning in HTML. In
the Info format, they define the target of a cross-reference and also
define a sub-unit of the Info file.

A node does have a meaning in HTML: It is the part of a chapter/section/
whatever that is not a child chapter/section/whatever.  As such it is
useful if you want to simulate --split=node after-the-fact.  Specifically,
you may want to hide everything except the current node.

div[current="false"} { display: hide }
and then you use JavaScript to set the "current attribute to "false"
on all nodes except the current one.

This would imply the wrong structure, since the "header" for a chapter
comes *before* the h2.

I see: you mean the header with the Next:, Prev:, Up:, links?


You are
right, then. If you want to manipulate the document with JavaScript,
making nodes pop in to and out of existence, maybe with menus of
subnodes sliding around as well, then you would need the entire node
in one element.

I don't think having separate <div class="node"> elements are *necessary*,
but I do think it would be easier that way.  We can defer adding those
div elements until somebody actually has a need for them.

This is assuming an entire manual in a single HTML file - JavaScript
to process a manual with one page per node would have different needs,
of course.

Right.  But when cell phones have more memory than workstations used to have,
and the and the entire elisp manual is comparable in size to a few 
images, it's probably easier to just have a single html file.  However, we
don't have to decide that now.

If we defer adding the <div>s for node until we see they needed (which may
make sense), then we get:

<section class="chapter" id="Chapter1">
<header>LINKS for chapter1</header>
<table class="menu">...</table>

<section class="section" id="section11">
<header>LINKS for section11</header>

<section class="section" id="section12">
<header>LINKS for section12</header>

        --Per Bothner
address@hidden   http://per.bothner.com/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]