genhtml: stop using obsolete <a name="">

[jelly]

Since HTML5 using a name attribute on an anchor is obsolete, switch to an id which is the modern alternative.

Signed-off-by: Jelle van der Waa jvanderwaa@redhat.com

[jelly]

See for example https://rocketvalidator.com/html-validation/the-name-attribute-is-obsolete-consider-putting-an-id-attribute-on-the-nearest-container-instead

[henry2cox]

Hi - Could you describe the implications of this change? It is obviously easy to do - but will it cause any issues, on any platform? Note that it isn't unusual to find some machines somewhere running 10 year old software..will that break? Conversely, if we DON'T make this change - and continue to use the obsolete syntax - what issues will that cause?

I'm happy to merge this - but I don't know enough about the implications to know whether I can do that safely or not. Thanks Henry

[garrett]

1. People shouldn't be using browsers that are more than a year old. It's wildly insecure. Anyone using a browser that's 15 years old is asking for severe problems.
2. HTML 5, which deprecated name as an anchor attribute and strongly discourages its use, is already > 14 years old. HTML 5 does not support name as an attribute; it is invalid HTML. Browsers provide backwards compatibility, but there are issues, especially with screen readers.
3. HTML 4 supported both name and ID for anchor elements. HTML 4 came out in 1997. That's > 25 years ago.

Therefore, we're talking about browsers that are older than 25 years ago... but everyone should be running browsers much less than 25 months old (which is already way too long ago, all things considered).

Problems with <a name="">:

• It was discontinued 15 years ago.
• It's now invalid HTML.
• Names and IDs are in the same namespace, but from different sources. This causes clashes.
• Using <a name=""> instead of using an id is an accessibility and usability issue.
• Anchors are only supposed to be used with an HREF attribute as of HTML5. (Different browsers may do different things in different cases; it's not clearly specified, as it is a bug in the HTML.)

---

TL;DR: It's pretty clear; this is a good change and long overdue. :+1:

[henry2cox]

Thanks for the explanation...that seems clear. You sold me :-) Only issue is that the code has changed quite a bit - so I can't just apply your patch (there are now 3 places that need to be fixed). I can do that and then close this PR - or you could update the PR based on latest code, and I'll merge.

(Side note: you would be shocked to see how old some stuff at some user sites really is. Not naming names ;-) ) Thank you for your contribution Henry

[xaizek]

2. HTML 5, which deprecated name as an anchor attribute and strongly discourages its use, is already > 14 years old. HTML 5 does not support name as an attribute; it is invalid HTML.

First you say that its use is discouraged, then that it's not supported. The first statement is correct, while the second one is wrong. It's still a valid HTML5 as far as I can tell (one is perfectly permitted to use obsolete/deprecated features, just not recommended to do it).

It was discontinued 15 years ago.

It's been 14 years since initial release while adoption date would be much more appropriate here and is maybe 5 years later (if not more).

there are issues, especially with screen readers.

Then they better be fixed in those screen readers as long as <a name=""> is permitted.

HTML 4 supported both name and ID for anchor elements. HTML 4 came out in 1997. That's > 25 years ago.

Irrelevant, and it had limitations on the set of characters.

So, if this change breaks navigation, it doesn't need to be applied.

(Not that I care about it, just didn't like the argumentation :))

[garrett]

(This is all directed to @xaizek. Everyone else here has been very kind and we're all working together to improve software. :+1:)

(Not that I care about it, just didn't like the argumentation :))

Then why are you arguing?

All my points are correct, backed up with evidence by links (often official links with the spec and MDN, which is de facto reference documentation).

---

not supported

Deprecated means it's no longer supported for the definition of support where it's not the right thing. Sure, browsers still support the not-recommended, old way of doing things, but it has problems so it does not have full support by the spec.

Like many other words, there are so many definitions for "support". My usage of "not supported" meant the same things as deprecated. It was obvious by context.

It's definition not the definition where you pay money to someone to have them answer your questions (also "support") and it's not the one where it doesn't work at all (also "support"; your definition in your comment). It's the one where it's not recommended to use any more ("support" meaning "we don't really support that use anymore", aka: deprecated).

Here's an official dictionary definition: https://www.merriam-webster.com/dictionary/deprecate:

: to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative

(emphasis mine)

---

It's been 14 years since initial release while adoption date would be much more appropriate here and is maybe 5 years later (if not more).

Don't try to gaslight me. I was there, paying attention to HTML 5, doing web work at the time (among other things). I've been doing web development (and contributing to Free Software) since 1996.

HTML5 was adopted before it was released as an official spec. It was a "working draft" for years, and as it was the obvious choice, web browsers started implementing it years prior to its release, and web developers loved it and started using it early. Browsers were so tag soupy at the time, that most of HTML 5 could be parsed by browsers in an HTML 4 (and even XHTML mode, which was a generally bad idea)... so most web developers switched as soon as they could, to some better standardized language. It was a big deal back then.

Then they better be fixed in those screen readers as long as is permitted.

No, you are absolutely wrong. There's no way to always infer intent from <a name="">. This is literally one of the many reasons why using the id attribute became the correct method and why name was not just dropped from from the spec, but why id is strongly suggested while name is not supposed to be used.

Simple example:

<a name="foo"></a>
<h2>Heading</h2>

vs.

<h2 id="foo">Heading</h2>

In the first example, a screen reader and the people who use it, do not have an association between the #foo part of the document and the heading. In the second one, there's a direct association.

You could, for example, add some ARIA to tie the two together, but rule 1 of ARIA is that you shouldn't use it unless you need it. Meaning: You should use normal HTML whenever possible. And if your browser supports ARIA, then your browser has already supported using an id attribute for much, much longer. Therefore, use the id.

Irrelevant, and it had limitations on the set of characters.

It's not irrelevant. The question was about backwards compatibility. This was to point out HTML4 saying that even ancient browsers that nobody have been using for two and a half decades still would work after switching from name to id.

---

Basically, you came here to troll and waste my time and everyone else's time here too with false information, invalid opinions, and pointless pickiness (which wasn't even correct).

People who jump in to troll an already factual conversation are the very definition of "stop energy", which is frankly one of the biggest problems in almost any conversation on the Internet right now, including Free & Open Source Software, where most of us are trying to improve things with "forward motion":

Here's a short blog post defining "stop energy". Read it: http://www.userland.com/whatIsStopEnergy

---

Hypothetically, even if you were right — which you are most definitely not — it still would not change the fact that even ancient browsers support id, name is deprecated, and everyone including lcov should be using ids and not name.

You might want to reconsider providing "forward motion" instead of "stop energy".

@xaizek: It's now your role to not reply. There's nothing more to say, unless you want to share an apology for being wrong and wasting our time. If you do apologize, that would be appreciated. We are all wrong sometimes and make mistakes. No hard feelings.

[xaizek]

Everyone else here has been very kind and we're all working together to improve software.

I feel sorry for you if your definition of "being kind" == "agreeing with you when you're wrong".

Then why are you arguing?

I'm pointing out glaring deficiencies in your argumentation, which is outright wrong.

My usage of "not supported" meant the same things as deprecated. It was obvious by context.

No, you made clear references to the spec and claimed that HTML with <a name= is invalid, which is completely incompatible with "not supported == deprecated". And no, "not suported" is not the same as "deprecated", these are very different things (especially, if any spec is involved).

I was there, paying attention to HTML 5, doing web work at the time (among other things).

I also was there and remember very different things. There were lots of talking and support for trivial changes, but it took many years to actually get HTML5 support.

why name was not just dropped from from the spec,

It was not dropped from the spec, but only marked as deprecated.

In the first example, a screen reader and the people who use it, do not have an association between the #foo part of the document and the heading. In the second one, there's a direct association.

A screen reader like that could infer the association by connecting <a name to the next HTML node in post-order traversal.

This was to point out HTML4 saying that even ancient browsers that nobody have been using for two and a half decades still would work after switching from name to id.

Then why did you need any other points at all then? You should have said this and be done (if that's actually the case).

(lots of crap)

Yes, I do feel sorry for you.

[garrett]

@xaizek: Just stop. You're being a jerky troll. Stop. Please. Spend your time elsewhere, constructively, instead.

[henry2cox]

Hoping to move past religious war and back to improved software…

My read on the current situation is that it is probably a good idea to update the code to remove the deprecated usage. If that breaks something – we will revert. What we need is an update PR with the required changes for the current TOT code. (Or I will just do it myself and close this PR.)

I had a completely different question/request though. Hoping that someone more familiar with HTML can help to fix the problem:

• Background:
  • ‘genhtml –frames’ option causes us to generate a sourceview page with a colorized/clickable PNG image on the left of the source code. This can be quite convenient for finding stuff in moderate sized files.
  • We also have a rather new feature which adds href links from entries in the summary table to the first line in the source code in the corresponding category – for example, from the count of unexercised lines in the fileview summary table to the first unexercised line in the file. (Please see the genhtml man page for the “--show-navigation” option.)
• The problem:
  • I wanted to have similar hrefs from the “directory view” table entries to the corresponding sourceview line – for example, to be able to click on the “unexercised line” count in in the row corresponding to file “foo.c” and be taken to the first unexercised line in the foo.c sourceview. This saves at least one click and one mouse movement – and is pretty commonly done when tracking down and diagnosing coverage issues.
  • This works fine if we do not use frames – but fails if we do use frames. “works fine” means that the href does what I want (for both chrome and firefox, at least). “fails” means that the href does not take me anywhere (like a dead link to nowhere). It fails for both chrome and firefox – but fails slightly differently for each of them.
  • Some doc that I found suggests that this ought to work with frames…but that frames are somewhat orphaned and not well supported by anyone ☹
• The question:
  • Does anyone know how to fix this such that the links will work correctly with frames? Or, is there a better way to achieve a frames-like look and feel, which will also work with href navigation. One restriction is that I think we need to do this with static HTML – no active pages.

Thanks for your help and suggestions… Yes – this problem should probably be moved to a new issue.

Henry

[xaizek]

Just stop. You're being a jerky troll. Stop. Please. Spend your time elsewhere, constructively, instead.

I was merely demonstrating that you're wrong, but you've made it very clear that you'll do anything to keep pretending that you're right.

Hoping to move past religious war and back to improved software…

No religious wars here. "Deprecated" != "removed", no ambiguity. And it's deprecated here (old draft?) and here ("de facto reference documentation"), but is missing from here (new draft?).

I had a completely different question/request though.

No idea how to fix it. Your best bet might be reducing the example that doesn't work to the bare minimum and asking on StackOverflow whether it's possible to make it work. This should be much faster than hoping that some competent web-developer will find the question here by accident.

[garrett]

As pointed out, everything I said was factual and backed up. I cited references, even the dictionary. Overall, I've made my point.

I don't need this harassment here. I'm leaving this thread so hopefully xaizek finally shuts up. (I've blocked whoever it is, but I'm not sure that's enough if we're on the same thread.) None of us needs his inaccurate opinions. The rest of us just want to make software better.

Good luck! Looking forward to the update. :+1:

[xaizek]

To conclude my response to his hysteria: really hope that @garrett will improve his reading and comprehension skills, which are just no good at this point.

[henry2cox]

pushed the originally requested change as part of some other fixes, in 038c2ca22598bf645436806ecb5f16716a29b513 Closing this PR now - and hoping to not create more controversy.

If there is something else that needs to be fixed - please open a new issue or PR...

Thank you for your contribution. Henry