Iss link ma apka answer hai youtu.be/D92_aZdMirs

I've been writing HTML for a long time, and to me, HTML5 was all of the things I hoped HTML would be, or if I could have invented it and tailored it to my liking and understanding, that's kind of what HTML ended up as. So I'm pretty happy with HMTL where it's at.

I remember all of the 'old' ways we used to have to do things, but these days when I want to write HTML I check the Living Spec: html.spec.whatwg.org

It's surprising even when you read about tags you think you know about, to find out from the examples that maybe there's more to some of these tags than it initially appears.

If you read through the Living Spec, and pay attention to the HTML examples they give in there you will get not only a good understanding of what's allowed and not allowed, but you'll capture the 'Spirit of HMTL', the thing that's 'alive' in there and better understand how you can work with HTML.

Things like <div> and <span> are nice to use in cases where you want tags that don't have some of these other behaviours and meanings, they're blank slates ready to be styled and used however you like. HTML also allows you to define custom tag names too, and I've only just begun doing that!

Once you know the tags HTML has (there are just over 100) and how to use them, if you ever find yourself creating a <div> or <span> and giving them a class to treat those tags special, you can create a tag name instead. The rules for creating a tag name are kind of like:

• must start with a lowercase letter
• can include other letters, characters, and periods after this if you want
• must contain a dash -
• can include other letters, characters, and periods after this

So if you were writing things like this:

<div class="video-wrapper"></div>
<span class="jumbo-headline"></span>

You have the freedom and flexibility to invent tag names like this:

<video-wrapper></video-wrapper>
<jumbo-headline></jumbo-headline>

I just started doing this, and I'm using tags like: <custom-element>, <social-buttons>, <facebook-button>, <headline-container>, <video-container>, <intro-line>, <countdown-timer> and stuff like that :D

The question itself is actually flawed, since DIV is still with us and like SPAN has a very specific use and meaning -- or should I say lack of meaning.

Both DIV and SPAN are semantically neutral, they exist for the purpose of the application of style without saying what that style is. As such if you have written your existing HTML properly using the HTML 4 document structure, you can add/remove DIV with impunity without screwing that structure over. The thing is you should not e adding either of those tags until you have expended what can be done with your semantic tags, and/or as a way to group tags so that you can use one class/id to do the job of many; that way you aren't throwing endless pointless "classes for nothing" onto everything. This is why a lot of how people use DIV ends up much akin to Carlin's joke about abortion. Just as "not every ejaculation deserves a name" not every element needs a DIV, or two DIV, or twenty DIV around it!

... and that's where the new HTML 5 tags are a miserable failure. Their alleged meanings, uses, and purposes are in fact redundant to HTML 4 Strict. Worse, they disrupt semantics and logical document structure with rules over how things like SECTION and ARTICLE works.

Half the entire point of HTML 4 Strict was to simplify the specification and remove redundancies. Whilst HTML 5 does make some smart changes inside HEAD and overall in terms of removing more pointless garbage, it also ends up introducing more redundancies.

This is only further exacerbated by ignoring HTML 4 Stricts other reason for existing was the removal of presentation from the markup, something that many of HTML 5's tags -- like ASIDE -- exist for the sole purpose of, making it just as presentational in concept as CENTER or FONT.

Most of this stems from the fact that to be brutally frank, the people at the WhatWG that created HTML 5 didn't know enough about HTML to create its successor. By the admission of many people who worked on it this alleged "specification" was created more to document what people were doing a decade or more ago, instead of telling people how to do it properly. With most people of that time vomiting up HTML 3.2 under the guise of HTML 4 Tranny, is it any shock that HTML 5 flips the bird at everything 4 Strict was trying to accomplish?

You can see this in the stupid ignorant HGROUP tag they created -- that was removed from the spec almost instantly when the W3C shrugged their shoulders, said screw it, and adopted the WhatWG's BS as the new HTML -- where it basically created for the nonsensical pairing of headings, a common practice that is complete semantic gibberish since in most cases that second heading is not starting a new subsection of the page. The correct semantics would be SMALL inside the first heading for the subtext indicating de-emphasis.

But let's go down the list of problems.

1. SECTION. If numbered headings and horizontal rules mean the start of sections and subsections of the page, and do not mean fonts in different weights and sizes or drawing a line across the screen what possible reason do we have for even having a SECTION tag? It's a pointless redundancy that seems to have been created just to satiate the wants and needs of people who slop in endless pointless DIV for nothing; aka the same mindset that resulted in everyone slopping in endless pointless tables for nothing. That is completely screws logical document structure and alternative navigation by resetting you to H1 depth (or not, given the "it's not recommended but" caveat) really just flips the bird at users with accessibility needs.

2. ARTICLE. Given how people just throw this around randomly not even to mark articles, it seems kind of silly... but there is no grammatical / professional writing norm upon which to base ARTICLE for semantics. The main content of the page should suffice as the "article", and any summaries not being complete articles have no business in such a tag. It's pointless.

3. MAIN. If the first H2 or HR on the page is supposed to indicate the start of the main content of the page, as per professional writing norms, what possible purpose does MAIN serve other than a pointless redundancy?

4. ASIDE. If semantics are based on professional writing norms, there is no grammatical or syntactical reason to put things "off to one side". This leaves us with the literary concept of an aside; subtext running parallel to the main text that whilst related is optional. That semantic relationship is not what anyone seems to use it for, nor is it all that common a thing in writing unless you spend your life transcribing Shakespear or writing Ferris Bueller meets Deadpool slashfic. If you think this tag exists just to place some content "aside" or "off to one side" you know not the first blasted thing about semantics, document structure, or even the purpose of HTML since not all UA's or even all layouts will in fact place it to one side. Again, as pointless and stupid as the long dead CENTER tag!

5. HEADER. We have numbered headings. Why did we need another tag?

6. FOOTER. A meaningless distinction not one legitimate UA has any real reason to separate out, nor do they do anything meaningful with it.

7. NAV... its original WhatWG meaning of "The UA can skip this section to get to the MAIN content" is redundant to either the first H2 or even their own flipping MAIN tag. They newer meaning of "this contains links that can be used to create an accessibility menu" not one legitimate UA has implemented, and given the track record of implementing such things -- *like accesskey menus which only one engine (presto) ever did -- don't plan on seeing said tag actually being implemented any time soon.

Which brings us to the real nail in the coffin, the fact that not one legitimate UA is doing anything meaningful with them. In fact, it often seems that the only real reason these tags were created was much akin to the "microformats" rubbish that was all the rage a decade ago, where people were slopping ABBR title="" on everything just to waste bandwidth for normal users... and for what? To make data-scraper's lives easier.

Data scrapers, let's call a spade a spade, not a "gardening tool", and say what they really are, CONTENT THIEVES! Aka a group you usually don't want to make the life easier of!

Which is why pretty much every legitimate UA you would/should care about treats them as nothing more than generic block-level containers. Aka, DIV.

The same can be said for the ARIA role nonsense, more microformat junkie bandwidth wasting trash; labeling everything for non-semantic reasons; often redundantly; in a manner that just makes web development harder and does not one single blasted thing to improve accessibility. At least not compared to what HTML 4 Strict used properly and the content itself can/should be doing.

Again, you'd almost think the people who created HTML 5 and those singing the praises of these tags never actually embraced the concepts of semantics and HTML 4 Strict.

This get even uglier when we get into the tags and attributes that have zero business even existing, got shoved into the specification despite being redundant or bad practices.

Take EMBED, a tag rejected for 4 strict as redundant to OBJECT and being proprietary rubbish. Why the blue blazes is this in HTML 5?!? Or AUDIO and VIDEO which are also redundant to the purpose of OBJECT; non-text media. Did you know the original plan for HTML 4's successor at the W3C involved removing IMG for being redundant to OBJECT? I still support the idea. There isn't a single blasted thing done with IMG, EMBED, VIDEO, or AUDIO that couldn't be implemented on OBJECT. But no, they had to make the specification larger for no legitimate reason.

How about CANVAS? A tag that only exists as a hook for JavaScript... if it only exists for JS use, why the blue blazes does it even have a flipping tag? This would have been a lot more useful if the canvas' instance were/would/could be attached as a background or intermediate render layer to all elements. Mind you, I like CANVAS as a JavaScript feature, but since it's scripting only there is zero reason for it to have its own tag in the HTML specification. At best it too is redundant to OBJECT, at worst it's a "tag for nothing".

The return of MENU is also a confusing mess, given it was deprecated in 4 Strict and would have been a far better way of implementing what NAV is trying to do or at least what people seem to think NAV is for, but no... Instead it's got "something" to do with forms that I still can't get a clear explanation of exactly what that even is. MENU and DIR were deprecated as redundant to UL, leave them that way!

Then there are attributes like TARGET, which were stricken from non-frameset documents for being a miserable failure at accessibility and usability when people derp them into pages as "_blank". You don't go shoving new windows / tabs down the user's gullet breaking conventional navigation. That's why it was deprecated, and why the people who wanted their documents to validate and used JS to implement it completely missed the point, and why bringing it back for HTML 5 is mentally enfeebled nonsense! The user wants a new window/tab they can middle-click or CTRL-click. Don't whip that new tab/window out of your pants and go waving it in people's faces without so much as a "by your leave"! 99.99% of the time I see target="_blank" in a codebase, I automatically assume a mix of ... well, those two words I'm always overusing.

Hence why overall I consider most of the new tags that go into BODY from the HTML 5 spec to be steps backwards to the worst of HTML 3.2 style methodology and mindset. Much like the mentally enfeebled train wreck laundry lists of how not to build websites that are front-end frameworks, it's a step backwards to the browser wars era mentality of pissing on semantics in favor of using presentational markup. No matter how much they throw the words "semantics" at it. Such claims are nothing more than bald faced lies.

Mind you, it's not all rot. MARK is nice, MANIFEST is useful for app dev, the new INPUT types are really nice letting us kick a lot of "JS for nothing" to the curb, the removal of TYPE attributes on tags that shouldn't need them like SCRIPT or LINK when rel="stylesheet", and the greatly shrunk header area helps with bandwidth. Those are the things that make sense; but the rest of it? Not so much.

That's why a lot of developers -- as Dan W. pointed out -- will tell you to write for HTML 4 Strict, then deploy as HTML 5 for the handful of improvements, and the things being shoved down our gullets whether it makes sense or not like AUDIO and VIDEO.

I really think we need another HTML specification that is to HTML 5 as 4 Strict was to 4 Tranny. HTML 5 just feels like "the new transitional" in that in a lot of ways it's leaving the outdated 1990's development mindset in place to corrupt the minds of the current generation. I've been half tempted to sit down and do it myself. I do keep thinking "but who are you to do it?" -- but who was TBL in '87... who were the WhatWG? What makes the W3C the big authority on the subject other than de-facto lack of anyone else?

I prefer writing for HTML4 Strict and publish as HTML5 to take advantage of the concise header and some other tags that have legitimate usefulness. It means that I don't prefer using tags like article, header, footer, section, and aside because, contrary to conventional notions, they are semantically redundant and unnecessary.

I would say that most developers don't bother studying W3C recommendations because they naturally learn on learning mostly from random tutorials and follow their own sets of rules, or they wouldn't embrace things like CSS frameworks and presentational CSS classes so blatantly.

I don't use tags like articles, sections, etc. because all you need to do, when it comes to a fundamental document structure, is to structure your contents with all the right "h" and "hr" tags. "h1" is used only once as the title of the page, and everything follows (h2, h3 under h2, h4 under h3, and so on. It's like an outline with full contents). After that, it is a matter of using "div" tags only where it's necessary to group and style things. But I say, "ONLY where it's needed" because I can also leverage a lot of block-level tags to lay out blocks of things without them some of the time.

"hr" tag is for things like a footer that don't warrant an "h" tag yet still need to be a section of a document. It is NOT about drawing a horizontal line. It is for a semantical meaning. You can render it as a line, or you can hide it with CSS (so it is still there for a screen reader) and wrap it around a div tag to create a little more visually extensive footer.

HTML is for content and its structure, and CSS is for a presentation of the contents in the HTML document. The point of using both is to separate concerns. Your goal should be to write HTML as minimal and clutter-free as possible so you won't have to make any changes in the future when you need to change the appearance of the website. A ton of people will say it is unrealistic, it is not how we work these days, it won't work in a large-scale site, and so on. IGNORE THEM, because I found that the industry is so full of misinformation and the mindset of "newer and shinier, the better" and "Wah wah I dunt wunna luarn, I dunt wunna du hurd wurk" nonsense.

CSS Zen Garden (csszengarden.com) is a bit dated but still a relevant example. It is one of the examples of how separating concerns can be extremely beneficial in the long run. You should take a look and analyze what they are doing with HTML and CSS. You can do what those people did in their time a lot easier now thanks to CSS Grid and Flexbox. So many developers have forgotten the original intent of HTML and CSS presented in the site. We as an industry is now too busy reincarnating HTML3.2 presentational markup mindset with presentational CSS classes littered all over their documents. It's so bad that it makes Word War Z zombies feel like a charming fairy tale. To me, presentational CSS classes are rotten zombies worth shooting down right in their head.