Yes, they are duplicates.
By now, each and every question asking "How to parse HTML with X" is a duplicate of some other similar question asking the same. Of course, all of these questions differ in some fine detail. One wants to get all src attributes from an img element. The other wants to get all href attributes from an a element. Yet another one wants to get all td elements in a table with a class attribute of foobar. For someone with no idea about how to do that, those are probably quite different questions. But they are not!
If you abstract the problem, all of these questions are asking the same thing. If you understood how DOM works, you know that it doesnt matter whether it's an a element or an img element or whether you want to fetch href, src or class attributes. That's just implementation details. It's an argument passed to a function. They are all asking how to fetch element X or how to fetch attribute X. Do we really want to answer all questions that differ just in X? Do we have to have one answer for each possible element and attribute in the HTML specs? No!
I'll give you that "Best Methods to parse HTML" is not answering most of these questions directly. But like I have already commented below one of these questions, I cannot be bothered to wade through the hundreds of duplicates to find the one that says td instead of img anymore. Especially when duplicates are flowing in while we speak. For the record, these came in shortly after you started to took offense on the closed question
That is just two more questions that will not get reusable answers but that I would have to look at in that futile quest to find the one duplicate that is a better fit than my generic answer to "Best Methods to parse HTML". Closing those as "too localized" will get the OP nothing. Closing it with "Best methods to parse HTML" at least gives him an entry point for the research s/he was supposed to do right from the start.
Fact is, SO is littered with those questions, just like it is littered with questions asking for the meaning of specific operators or how to format a date. We do not need any more of these. Generic answers like "Best Methods to parse HTML" or "Reference - What does this symbol mean" (for which you have attacked me in the past as well) are the first line of defense against lazy OPs that didnt do research, against shortcomings in the SO search engine and against community members that decide to ignore that we shouldnt answer duplicates.
I agree to not telling people "you cant parse HTML with Regex", because technically you can with PCRE and I very much agree to answers like Regex matching table rows in HTML getting deleted. In fact, I complain lately whenever someone links RegEx match open tags except XHTML self-contained tags because the answer, while legendary, is just wrong. Then again, just because you can parse HTML with Regex doesn't mean you should.
IMO, you are making false assumptions about the nature of these questions and about HT/XML parsers. Those questions are not about pattern matching. They are about retrieving information from structured documents and that is a solved problem. HT/XML parsers do a perfect job for this. They are not overkill. There is no drawbacks using them. There is only benefits. You dont have to know the grammar rules of XML to fetch elements with DOM. All the domain knowledge is captured inside those parsers, so you can concentrate on just getting the job done.
PCRE on the other hand have to be taught the intricacies of the markup first. People at SO undeniably fail at that regularly. Telling them to learn PCRE to match Regex when examples like tchrists HTML chunker clearly show how impractical this is over just using XPath (which was designed exactly for this job) is telling them the wrong thing. You are telling them to reinvent the wheel, when there is perfectly nice and easy to use wheels available.
Also, how is telling people to "do a Regex tutorial" any different that telling them to "Google DOM"? Your very own answer to Regular expression HTML match isnt exactly what I would consider an explanation of that pattern. The OP will likely just copy and paste it into his code. If you want to educate the OP about Regex, at least use
x and explain the pattern completely and do what you demand and link to a tutorial.
Also, I find it questionable to tell the OP he "might want to use a (X)HTML parser" and then give the links you give in that answer and then dv and cv "Best Methods to parse HTML" when it pretty much says that too.
You do not not parse HTML with Regex because you cannot, but because parsing HTML with Regex is hard and impractical. That's what "Best Methods to parse HTML" says. It's not touting the same old "you cant!" horn. It offers sensible advice and choice for a solved problem. And, while not best fit for all questions that get closed with it (which I cannot control btw) it's a good enough fit for most of these poor and lazy questions which it is too hard to find a better fit for.