I'm going to answer this out-of-order, because some stuff at the top, middle and bottom can be answered all at once.
Not opposed to newer methods, just want to see better arguments for newer methods than to say my way is archaic.
I agree that newer isn't always better -- just look at the train wreck of "let's take a trip with Mr. Peabody" known as HTML 5. BUT...
It's a laugh some of this being called "newer" since what I'm advocating -- semantic markup, use of the proper tags for what they are for, and so forth are now over a decade and a half old! Much less that LABEL and FIELDSET were introduced with HTML 4, which is when FORM was added -- Which is to say early 1998...
That's not newer, that's following the rules of language; something a lot of people creating tutorials, books, videos and even professional educators never seemed to learn in the first place.
You want better arguments as to why... that's easy. ACTUALLY using the elements for means MORE than just "what it looks like on the screen in front of you" - not everyone has the same size screen, OS, device capabilities, screen sizes - or are even looking at your page with a screen! That's what semantic markup is about. Search engines don't give a flying purple fish what your page looks like -- screen readers, braille readers, printers, etc don't care. Then there's the new trend of responsive design - using semantic markup means easier hooks for doing things without 'throwing classes at everything'.
Bottom line on that - If you can't be bothered to use the rules of writing HTML when writing HTML, why are you using HTML?
At least though it's not as bad or risky in HMTL as it is in say PHP, where decade out of date practices can leave security holes the size of the USS IOWA.
I starts to border on arrogance after a while.
You're probably getting that feeling from the fact that for people who do this stuff all the time, seeing the same mistakes over and over again year after year just gets really frustrating -- particularly when it's NOT the fault of people like you, but the people and sources you learned from who never did it right in the first place either. Frustration can make you say all sorts of crazy ****.
Naturally, being told "you're doing it all wrong, and been doing so for a decade and a half" can be equally frustrating.
Some of the things you mentioned being taken to task for ... are... well... I have a different perspective on.
I've also been criticized for using GIFs instead of PNGs, despite the fact that PNG transparencies don't work on all browsers, and can't do simple animations.
The transparency thing is a lie... kind of.
Palette transparencies -- they type of transparency GIF does -- works JUST FINE in IE using PNG all the way back to IE 4 in 1996. PNG also compresses (with a good compressor, Photoshop isn't) smaller image files between 17 and 256 colors, so in terms of file size PNG usually wins out over GIF. PNG also wins in that it can do true-color images, and unlike JPEG is lossless.
Meaning the only thing left for GIF is images that can be done in 16 or less colors, or where you want an animation -- and webm is starting to put a real dent in GIF's since it's smaller, true-color, and has finer control over frame rate.
If you can do it with a GIF, you can do it with a PNG, all the way back to IE 4. ALPHA transparency, where you have multiple levels of translucency is the one that didn't work right until IE7.
I've even been criticized for still using HTML symbols like @quot; instead of the UTF equivalents.
XML-tards love to pull that stunt, but news flash for them, HTML isn't XML, neither is XHTML 1.0 -- the named symbols are SAFER than UTF, because then it doesn't matter what encoding the document ends up.
Though I would probably never use "e; (which is what I assume you meant) as I'd just put the quote in the markup -- not a fan of styled quotes or wasting time making entities of them... but for things like © or • -- RIGHT THERE WITH YOU!
So I continue to create pages that can be represented in 7-bit ASCII.
As do I in most cases, so long as all you're working with is English, that's ALL you need.
Hell, officially by the spec the only valid characters in a CSS file is ASCII7... which makes the use of @charset kind of a head scratcher! :/
It's actually something I suggest to people starting out -- avoid stepping outside ASCII7 until you have a firm grasp of what character sets are, how they work, and what a pain in the backside they can be.
And really... <br><br> means something is wrong? Everybody does that.
The only thing wrong with double-breaks is if the text is clearly grammatically a paragraph of flow text. Search engines, screen readers, etc, etc can leverage a paragraph tag to help deliver the content -- it's saying what the text IS, NOT what it looks like. Breaks are for splitting text inside a semantic element, and really provide no 'meaning' to the document structure.
REALLY bad with breaks though is just slapping a bunch of them back to back inside a page instead of using margins or padding... not so much for semantics, but from an efficiency and speed standpoint. Markup isn't cached, CSS in an external stylesheet is.
They do because some browser will do the "right" thing and others won't, and its a simple way to ensure better layout in the majority of cases.
Except it isn't... because you actually have less control thanks to more markup; a bunch of breaks might look fine on one media target, but not another. It's why what things look like has never had any business in the markup no matter what HTML 3.2 became thanks to Microsoft and Netscape's repeated one-upmanship from when they both licensed from Mosaic and started piling on their own proprietary garbage.
but I don't buy the multiple arguments about changing things because the code style is dated.
It's not just that it's dated, it's that it's WRONG and BEEN WRONG as long as people have been doing it.
Take that form -- you have clear labels, use a LABEL tag. That's what the HTML specification has said as long as there has been a FORM tag... WHY? So that user agents can leverage that relationship to make the page easier to use -- from clearly identifying that said text is the label for the INPUT in screen readers, to letting you click on the label to focus the element giving a larger target area for people using something other than a mouse (like a touch interface).
BY THE RULES none of the inline-level tags can be direct children of FORM, you need a DIV or FIELDSET -- and FIELDSET is preferred for that to identify that the inputs contained within are ones the user can interact with.
There is more to a website than what you happen to see on the screen in front of you.
You make the comparison to a '72 Gibson, when a more apt comparison would be a '69 Kay bought out of the Sears Christmas Catalogue in the kids section. (the guitar I had when I was five, before I moved over to woodwinds)
I wear many hats... electronic engineering, product design, software (started back with assembler on an ATARI!), musician, carpentry, modeling, costuming (hence the "hats" reference), and several other endeavors which all have something in common. That is, there is always a "newer" way of doing things. But newer is not always better
Similar here, musician (Sax, Flute, EWI), custom bicycle builder, electronic design, carving, painting, writing -- and you're right, there is always something new to learn, the trick is to learn what's actually BETTER... more so, when things AREN'T new, they're just new to you.
I have no issue migrating more to divs with positioning controlled by CSS, but I do have a problem doing so just to avoid someone's teasing.
Please don't think I'm teasing -- most of what I say I do in earnest; There are reasons for doing this and I outlined most of them above.
judging by the many pages I've seen put out by modern CSS systems like Wordpress and Joomla that don't display right (even on some newer browsers), it tells me again that newer is not always better.
Well, get a load of this. I don't consider those to be 'newer' in terms of how they put things together; Turdpress in particular raises my ire as it is some of the most poorly coded garbage I've ever come across. Using those as examples of "modern CSS" is like using a 1984 Yugo GV or Reliant Robin as an example of automotive excellence.
But at least in the music world, what matters is what you play and the quality of your music and sound... not how old fashioned the electronics or style may be. See my point?
Which is not exactly a great parallel, well, unless you only want your music to be heard live, without amplification, in a small venue that seats maybe 20... with everyone being deaf in one ear; as opposed to a stadium performance with an accompanying live album.
... and that's really the difference between using HTML properly and just vomiting it up any old way completely ignoring the structural rules of the language and what it's tags actually mean and are for!