genhtml: stop using obsolete <a name=""> #161
Conversation
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>
|
Hi - 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. |
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
TL;DR: It's pretty clear; this is a good change and long overdue. 👍 |
|
Thanks for the explanation...that seems clear. (Side note: you would be shocked to see how old some stuff at some user sites really is. Not naming names ;-) ) |
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'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).
Then they better be fixed in those screen readers as long as
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 :)) |
|
(This is all directed to @xaizek. Everyone else here has been very kind and we're all working together to improve software. 👍)
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).
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:
(emphasis mine)
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.
No, you are absolutely wrong. There's no way to always infer intent from 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 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
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 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: Hypothetically, even if you were right — which you are most definitely not — it still would not change the fact that even ancient browsers support 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. |
I feel sorry for you if your definition of "being kind" == "agreeing with you when you're wrong".
I'm pointing out glaring deficiencies in your argumentation, which is outright wrong.
No, you made clear references to the spec and claimed that HTML with
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.
It was not dropped from the spec, but only marked as deprecated.
A screen reader like that could infer the association by connecting
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).
Yes, I do feel sorry for you. |
|
@xaizek: Just stop. You're being a jerky troll. Stop. Please. Spend your time elsewhere, constructively, instead. |
|
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
|
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.
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?).
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. |
|
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. 👍 |
|
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. |
|
pushed the originally requested change as part of some other fixes, in 038c2ca If there is something else that needs to be fixed - please open a new issue or PR... Thank you for your contribution. |
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