Please be more specific in what you are trying to accomplish. Unless you help us understand what you need to do, it will be IMPOSSIBLE to help you answer your question.
It's not XML, it's HTML. We already have too many tags as is, why in hell would you want to add more to it?
If by "tags" you mean DOM elements (like div and span), no, you cannot. Neither would there be ANY reason to, so why do you think you need new elements? What are you trying to do?
Actually, xhtml allows exactly that. It's a damned shame MSFT screwed that pooch. The ease of html and the extensibility of xml. Had xhtml gained traction, none of that microformatting silliness would have happened nor would a whole potload of html5 have been dumped on us. See http://gtwebdev.com/workshop/xhtmldoc.xhtml for a simple-minded example. cheers, gary
what is there in that question for not being specific.. i just asked is it possible to define custom tags in html5 ?
Well, the short answer is "no" - but again, the question doesn't really make sense, because there's no REASON (really) to create new "tags" (again, a misnomer) in HTML5 - hence why some of us asked "why would you need to" and "for what purpose". If I'd gotten that question on an interview (if this was for a job), I would've probably gotten up and left, because the interviewer doesn't have a clue. Either that, or the interviewer thinks _I_ don't have a clue, which isn't much better. If I was in a VERY good mood, I might have countered with "no, but why would you even want to? What purpose isn't covered by the existing tags in HTML 5 - give me an example of what you would like to accomplish with this, please". That would probably throw off the interviewer.
One of the entire reasons we use HTML instead of XML or even the SGML on which HMTL was originally based is that the tags have MEANINGS. Headings and rules provide structure, lists and paragraphs identify content, etc, etc... Randomly making up your own tags (or even the new idiotic HTML 5 tags that are redundant to existing ones) completely break this notion. It's like the mouth-breathing halfwits who make claims about ID's and classes providing semantics. User agents (aka browsers) don't know what any of that means, so it's NOT semantic markup. In the same way just making up your own tags randomly provides NO semantics for user-agents to interpret within the limitations of the device it's on. That's HTML's entire reason for existing. The whole concept was to take SGML style formatting and create pre-determined tags that browsers would know what they mean and then best convey that meaning within the limitations of the target device. That's what HTML is for, and that's why "semantic markup" is just a sick euphemism for "using HTML properly". We use said euphemism so as not to upset the halfwits, morons and fools who vomit up HTML any-old-way and/or based on the default appearance of the tags instead of what they MEAN. You make up some random tag, how is a screen reader (a program that reads the page to you), braille reader, or other non-visual non-css UA going to know what the blazes that is? Two tags -- DIV and SPAN -- are reserved WITHOUT a semantic meaning for when you need a container that doesn't fit one of the existing meanings. They are often referred to as "semantically neutral" because of this. Though technically <a> is also semantically neutral as while it makes a link, it does NOT change the meaning of the text inside it. As PoPSiCLe is saying, there are MORE than enough existing tags, to be frank there are so many tags and attributes that few if any people actually bother using any of them properly, so throwing even more tags at it is NOT THE ANSWER. Again see why I consider HTML 5's header, footer, nav, article and section tags to be pointless bull that's mostly redundant to how h1...h6 and hr are supposed to work if developers would get off their lazy sleazeball asses and use them PROPERLY - or if Joe forbid browser makers got off their collective rumps and implemented their functionality properly. ... another reason HTML 5 pisses me off -- browser makers implementing a new specification when they still have decade or more old bugs in their HTML 4 implementations. Right Bugzilla 915? -- but sure, Open source means bugs are fixed faster. You say that like it's a good thing. The uselessly and painfully vague made up fairy tale bullshit and general pissing on accessibility from orbit for anything that can't use stylesheets doomed it from the start. That ANYONE who grasps the point of semantics would support XML as a web format leaves me flabberghasted as it's one of the DUMBEST concepts I've ever heard. "Just go ahead and make up any old tags you like!" -- oh yeah, that's just going to be SO brilliant and easy to maintain, much less work with other people on. It's bad enough when people can't keep tags with meanings straight without giving them full and open leave to just piss all over sites even more. XHTML 1.0 was nice in that it was to XML as HTML was to SGML. It was simply to be a reformulation of HTML to fit an XML namespace, WITHOUT being full on XML and for the sole purpose of allowing it to be parsed by either engine -- It made sense -- the later versions with the extensibility crap? No... Just... **** no. That asshattery couldn't be shot down fast enough IMHO. Take your example, how the **** is a user-agent supposed to know what the blazes your fictional "booktitle", "publisher" and "author" tags honking mean? Also, don't we already have <i>, <b> and <cite> for that based on professional writing standards? A standardized vocabulary is the POINT of HTML. "extensibility" is nothing more than pissing on that from so on-high you'd think the almighty himself just got back from a intergalactic kegger. Though it is ENTIRELY -- much like HTML 5 -- what I'd expect from the folks who still sleaze out presentational markup and never grasped the meanings much less proper use of HTML tags in the first place. More so when one considers that the majority of people crapping out code any old way know next to nothing about the language or writing norms upon which HTML was based.
The UA has no clue what any tag means, nor does it care. It only knows whether it is on its list of known tags and then applies its default presentation. If the tag isn't on the list, the UA ignores it. The semantic value of an element token matters to the human who writes or maintains the html or uses or modifies the DOM. Tag tokens could be nonsense characters, and if the UA didn't ignore it (e.g. an x(ht)ml parser) and the syntax was correct, it would still build a DOM and render however the matching presentation rulesets declared. Sure, you could use the <b> tag, which has contextual semantic value. But it might mean a book title, a journal title, a ship's name, an album title, the first mention of a person in a gossip column and probably a number of other things. On the other hand, the <booktitle> in my little demo is more specific and does not depend on its context. I maintained an intranet for a couple of years, and using xhtml, we could provide small tools for users to parse various pages using whatever criteria they wanted; much simpler than getting a set of db queries for what might be a single use. gary
Assuming there is presentation and not some other way of conveying the meaning -- since "presentation" really doesn't apply to screen readers, braille readers, teletype, etc, etc, etc... and if it's a "known" tag that VISUAL UA's have a "default presentation" for, how is that any different FROM KNOWING WHAT IT MEANS?!? That's what HTML is FOR and why semantic markup exists. It's why tags even HAVE meanings like "this is a grammatical paragraph" or "this is a heading" or even "this heading starts a subsection of the higher order heading preceding it" -- to convey meaning, or more specifically to allow the user-agent to best determine how to convey that meaning within the capabilities of the target device. Saying that UA's done know what tags mean much less shouldn't care is SO ignorant of what HTML is for or WHY IT EVEN EXISTS, I can't believe that statement came from you of all people! You just forfeited my opinion of you and your knowledge with that statement... At that point we might as well semantics, the intent of strict, and the entire reason HTML exists out the window and go back to using tags like CENTER or FONT... or attributes like ALIGN or BORDER. Just letting people make up **** any old way? Oh YEAH, that's SUCH A BRILLIANT PLAN FOR SUCCESS!!! Though it certainly explains the mentality (emphasis on the mental) of how halfwit bloated redundant nonsense like HTML 5 came into existence. ... and is utter and complete gibberish until it exists in a specification, has a meaning applied to it by that specification, so that user agents can have a default behavior (behavior does NOT always mean presentation) associated with it. Letting people make up their own blasted tags? That's one of the most IDIOTIC things I've ever seen in a common document specification -- admittedly, I hold that opinion of XML itself when people use it for anything OTHER than a human legible medium for transfer between system specifications. Hence why whitespace stripping XML is one of the most jacktarded things people can do. It's why when people call XML a "machine readable format" my knife-hand whips up ready to deliver a pimp-slap. Damn there's some REALLY HUFFING STUPID CRAP out there right now.
Did you not look at the source? The html specification is extended there. That's what eXtensible HTML is all about. Behavior? Enlighten me. //edit: Oops, my bad. <A> has behavior which would explain the "HyperText" part of the mark-up language's name. Are you thinking of inline replaced elements? Those would be shaky examples IMV ~g gary
... and that extensibility has no business in a HTML specification. If it were actually XML or SGML, then fine -- that's what those are for. As an accessibility minded means of conveying content? UTTER AND COMPLETE NONSENSE. Just becuase you declare "hey treat these as if they're real" doesn't mean they provide anything resembling semantic meaning to the browser. Title hovers on things like CITE? Accesskey menus? Heading and section navigation? Fieldset navigation separate from field navigation? Content breaking on aural? Admittedly a LOT of the 'behaviors' only crop up on non-visual UA's, and/or the ACTUAL Opera back when it actually meant something instead of the steaming pile of crippleware known as "let's slap the big red O on Chrome any-old-way flipping the bird to our entire fanbase"... or Vivaldi which is trying to capture those formerly loyal Opera fans. OF course that such things were the intent of both original HTML, HTML 2 and 4 Strict yet the majority of big name UA's still haven't even TRIED implementing them isn't helping matters. Getting worse as the latest flavors each of iOS, Andriod and Windows seem to be telling users with accessibility needs to go **** themselves. Take NAV, SECTION and ARTICLE -- are we REALLY supposed to believe the latter from 5 will EVER actually be implemented for use by their meaning given it's been how many years of said tags being "supported"? BULLSHIT. Particularly given that other than Mosaic, classic Opera and TBL's original browser heading navigation is still nonexistent. (hell M$ and Nutscrape went out of their way to rip them out of their Mosaic forks!) Remember, the base spec should be able to stand on it's own WITHOUT any "default appearance" as the default is supposed to ENTIRELY be up to the user-agent within the capabilities of the device. That 90%+ of people out there sleazing out HTML any old way don't seem to grasp that is why the majority of websites are inaccessible broken shoddily written rubbish. Again, "view source" on a site built in turdpress for all the proof you need of that. Now certainly people without accessibility needs or who have never had to work with people who had those needs will be blissfully unaware any of these things even exist, much less how to use them. More the shame. See the shock on people's faces when they see the output from something as simple as hitting ctrl-shift-esc in Opera 3.62 through 12, or pull up "information->document outline" from the web developer toolbar for FF. Or just the shock when a non sighted user starts bitching about the painfully long delays between the content because someone did something ignorant like slap a single IMG tag into a P for no good reason, or fails to provide alt text, or fills up a page with presentational images that have no damned business in the HTML either. It's a shame JAWS is so ridiculously expensive - I think every web developer should be forced to wear a blindfold then use the web with it for a week. It's... uhm.. eye opening? Or just try to use the web with CSS disabled. Technically because of HTML and CSS' relationship the pages should still work. Yeah, good luck with that thanks to developer ignorance and how most people still sleaze out presentational markup even when they are under the delusion they aren't doing so. That's why letting people just make up their own tags willy-nilly is halfwit nonsense, and why for the most part "extensibility" in the spec reeks of the same type of asshattery as "microformats" -- code bloat nonsense that has NOTHING to do with actually helping users navigate the page, and more to do with making the sleazeball content thieves have an easier time of data-scraping a page. (which seems to be the REAL reason <article> was created) ... something I'm used to most site owners asking how to prevent.