[Top][All Lists]

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

Re: id attributes for header elements

From: Patrice Dumas
Subject: Re: id attributes for header elements
Date: Sun, 26 Dec 2021 19:29:48 +0100

On Sun, Dec 26, 2021 at 10:08:50AM -0800, Per Bothner wrote:
> On 12/26/21 09:30, Patrice Dumas wrote:
> > On Sat, Dec 25, 2021 at 02:10:29PM -0800, Per Bothner wrote:
> > > Two requests:
> > > (1) Don't generates the implicit id="Electron-1" when it immediately 
> > > follows
> > > an explicit id="Electron".
> > 
> > I do not think that it is a good idea, the @anchor anchor and id should
> > stay different from the @node, or section @-command id and anchor.  It
> > is better to keep it, but it would probably be even better to have a
> > class to make it possible to select @anchor generated anchors.
> Maybe - is there a use-case for this?

Not sure, but it seems to me to be clearly the intent of the @anchor
@-command.  And we add some information to the HTML output to match the
Texinfo even when there is no known use-case.

> > > (2) Add the id attribute to the <h4> element rather than generate an 
> > > empty <span> node.
> > 
> > I did something along those lines, but not when there is a header, in
> > order to keep the anchor before the header, as it was agreed, long ago
> > that having the anchor before the header was better for navigation.
> I don't remember, and I don't see how it could be better for navigation..

It was some time ago, at least some people expected the link to point to
the start of the header, and not to the heading command.

> I don't see any particular use for being able to distinguish referenes
> generated by @anchor from others.

For users to use CSS/javascript or whatever.  Currently it is not
possible to distinguish those.  We already did that for some elements,
such as the h* with adding classes with @-command names.

> However, since @anchor can be anywhere (including the middle of paragraphs),
> there is an argument from simplicity and consistency for just using an empty 
> <span>.
> Though note that best practices for (hard-written) HTML would be to place
> the id to a semantically meaning element.

For a Texinfo @anchor, the meaningfull element, in my opinion, is an
element representing the @anchor itself.

> Regardless, the implicit id that is generated for a heading command belongs
> on the header element.  I.e. for
> @anchor{Electron}
> @subheading Electron
> we should at least do:
> <span id="Electron"></span><h4 id="Electron-1" 
> class="subheading">Electron</h4>
> Since id="Electron-1" is directly generated by the @subheading, it makes sense
> to put the id attribute be on the generated h4 element.

In my view, the @anchor{Electron} is not associated to the @subheading (except
for being before).  The @subheading has its own id as an heading not
associated to a Texinfo element.  The @anchor has its own id too as it
is not associated to the @subheading.

In a case like

@node My node
@section Section

note that there is no id output especially for the sectionning command,
it is the id of the "element" (also called a tree unit) that encompasses
a unit of Texinfo.  In general it corresponds to a @node + sectioning
@-command + associated content.  


reply via email to

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