When i was learning html5. As i was looking at all the features, i noticed the web browsers don't support all features. Some browsers support things that others don't and vies versa. So my questions is, is html5 stable enough to rely on as for as design goes? Would it be better to code websites with HTML5 in minds but not to use the new features? Please share your thoughts. I personally think we should be coding websites with HTML5 in mind yet keep the features on the back burner or don't incorporate them to the point your design revolves around a feature.
HTML5 is a collection of thousands of features. Some of them are stable, some of them are not. But you really only need to worry about browser-support. If a feature is implemented in all modern browsers, then it is safe regardless of whether it's a HTML5 feature or not.
HTML 5 is a modern version of HTML, it may not work on all browsers but if it is incorporated with new features, then it is better to use HTML 5, it will definitely give better results in terms of performance.
Can you explain that? It only gives out new features that should be supported by Javascript/jQuery so older browsers would support that. Addressing to what you think as a better performance would only be a more prettier markup. Correct me if I'm wrong.
HTML5 is a couple of steps backwards. Maybe if no one would support it, we'd see HTML6 come out as a real improvement over HTML4, not a "let's throw stuff on it and see what sticks" approach.
You mean explain it? Not without losing my account here by making a post that's so long that it won't fit into any database.
I can do that with aplomb and a flourish... and unlike Rukbat if being brutally frank with the truth means getting banned, OH WELL... Also, I think I can fit this in one post. Even the OP's opening sentence rubs me the wrong way as the word 'features' goes hand in hand with the word 'benefits'... and much as John Adams would kneejerk into a rant about the 'benefits' of belonging to Great Britain as a Colony, I respond with the exact same "Benefits? What benefits?" Bloated code, loosened structural rules, pointless redundancies, vendor lock-in? It is a philosophical step BACKWARDS from the simplicity of the the REAL HTML 4 (aka STRICT) -- and nothing more than a continuation of the sloppy practices and browser maker 'pimp my ride' nonsense used by the people who never pulled their heads out of 1997's backside! Basically I'm talking about all the folks who continue to write non-semantic or broken semantics HTML 3.2 and slapped a tranny on it. Now they just slap HTML 5's lip-service around their outdated, bloated idiotic rubbish code -- net improvement zero! Though that's talking STRICTLY in terms of markup. Let's review the POINT of 4 Strict and some of 5's garbage in that regard, shall we? One of the entire concepts of HTML 4 Strict was to remove redundancies and reduce the number of tags to a simple baseline. A lot of people seem to focus only on the tags removed for being presentational, but that's a REALLY short list: CENTER, FONT and BASEFONT. That's it... Some people would list S and STRIKE as being dropped for presentational, but that's wrong -- they were dropped for being redundant to DEL. The MENU and DIR tags were dropped for being redundant to UL. APPLET and IFRAME were dropped and EMBED not accepted into the specification for being redundant to OBJECT. U wasn't even dropped for being presentational, it was dropped becuase underlining non-link elements is confusing from an accessibility/usability standpoint! (and is redundant to the two different emphasis tags, EM and STRONG). OBJECT in particular was a major step forward with IMG allegedly even being on the chopping block for the next HTML before they threw said plans in the trash and went with WhatWG's idiocy instead... Why a step forward? It moved non-text content into a single tag that you could add or remove formats to on the fly -- meaning you were not at the mercy of the browser makers on format support, and that said formats could be run sand-boxed. (and then browser makers dragged their heels on implementing the latter half of that plan for a decade). It could easily have replaced IMG and given us access to superior image formats like JPEG2000 (and it does so if you have Quicktime installed on IE BTW) if Microsoft hadn't dragged it's heels for a decade and a half about removing the fixed border around it! (The same goes for IFRAME's relationship to OBJECT) So along comes HTML 5 and what's the biggest markup feature being pimped by the press? VIDEO and AUDIO -- pointlessly redundant tags that took a industry that was FINALLY settling on a standard (flash), and has only fractured things back to the WORST of the 1990's Realplayer vs. WMV vs. Quicktime wars (that ran in parallel to the browser wars). HOW? Simple: each and every blasted browser maker went out and started pimping their own favorite pet codecs and containers... which is why now to deploy video in addition to a flash fallback, you also have to deploy 4 different codec/container combinations. Oh yes, that's 'progress'. ... and why did this happen? Unrealistic dirty hippy "open sores" advocates ranting and raving about how wonderful the steaming pile of 'also ran' known as Vorbis is, and Apple being total dicks to the people dumb enough to buy their products. It is the pinnacle of vendor lock-in in action. It's all redundant to OBJECT, there is NO legitimate excuse the new scripting controls for AUDIO and VIDEO couldn't be put on OBJECT (oh noes, one IF statement and/or a new pass-through API, not that). The ONLY reasonable explanation for it is promoting vendor lock in. That's just the tip of the iceberg. The new 'structural' tags being a mish-mash of redundancies and outright non-semantic presentational markup! IF, IF you are using headings and horizontal rules properly (the one thing I can say good about 5 is they clarified the description of a HR's job), the SECTION tag serves no legitimate purpose. How can I say that? Simple, a HEADING's job is to indicate the start of a section, and a HR's job is to say where a section change occurs when a heading would be inappropriate/unwanted. As such if you use numbered headings and HR's for what they are for, they are semantically indicating the start and end of sections in the code! (See Opera's heading navigation to see the accessibility created by this in action!). As such, SECTION serves no legitimate purpose, which is why most people are just using it where they were using DIV -- the thing is DIV has no semantic meaning, it's a containing hook, which is WHY it should be the preferred tag for such an element as you may or may not be applying presentation to it depending on which of your layouts is in use. Yes, that's PLURAL, because if you are practicing modern layout strategies, you should have a RESPONSIVE layout which means multiple different appearances. What's a separate column on a big display could be under the main column on a small one... Playing to HTML's primary job of saying what things are, NOT what they look like. Goes back to something I've been saying for almost a decade, if you are choosing your tags based on their default appearance, you're choosing the wrong tags. The new ASIDE tag is a confusing mess since people seem to think it's content that's 'off to a side' -- which is presentation, which again HAS NO MALFING BUSINESS IN YOUR MARKUP!!! If we look up the words definition the ONLY one that makes any sense semantically would be a literary aside - which is when an actor breaks the fourth wall to deliver a soliloquy or monologue to talk directly to the audience while the rest of the cast ignores the characters actions. That is such a rare occurance in non-performance literature using that definition would put ASIDE squarely in the same realm as the rarely if ever used ADDRESS tag. Any other use of it is either ignoring the word's meaning or using it for presentation. NAV is also pointless, since if they would get off their asses and implement numbered headings for what they are for, you would simply skip to the first second level heading as the start of the main content section. It's an extra tag that the ONLY reason I can figure it exists is to justify the practice of slapping an extra DIV container around menu UL's for no good reason... as if UL isn't a perfectly good block-level container in it's own right. Now they've just made a tag to justify sloppy coding habits. ARTICLE is just confusing, or at least that's what it seems like from how people are just slapping it around anything that happens to be a run of text, JUST like how people slap P around non-paragraph elements (like INPUT, LABEL, IMG). From a usability standpoint it seems to serve no legitimate purpose, other than to satiate the wants of data scrapers... the type of people many webmasters come to forums like this one asking how to keep them out! WBR is redundant to whitespace, SOURCE is redundant to PARAM, for some screwed up reason EMBED is accepted into the spec... MARK is blatantly presentational, MENU is back for some oddball form usage I've still not been able to get a clear explanation of (I would have brought it back to use for *SHOCK* menus instead of UL), TIME seems to be another data-scraper oriented idiocy that goes hand in hand with the bloated trash your 'microformats' junkies jones for... A hefty number of the tags are there just to make the script-tards go all gooey in their pants, but serve no legitimate semantic or accessibility purpose that couldn't simply be done on a anchor, SPAN or DIV. They offer NO legitimate advantages over existing tags other than encouraging people to put things in their markup that shouldn't be there in the first place if you are practicing graceful degredation... Why do I say that? Because elements that don't work when JavaScript is disabled -- like COMMAND and PROGRESS -- should be added by the script instead of being static in the markup, so when scripting is unavailable or intentionally blocked you don't have non-functional elements on the page! (admittedly, a concept lost with people walking through the pile known as jquery then smearing it all over their websites carpets when they forget to take their boots off.) Something highlighted by the CANVAS tag, an element that is completely useless without supported JavaScript -- at which point why the blazes does it even need a tag? The only excuse for that is when CANVAS is unsupported (which the script should be detecting ANYWAYS) or scripting is disabled (which makes it redundant to NOSCRIPT!) About the ONLY new tags and attributes I can find legitimate reasons for are the new form handling attributes -- Which IMHO if you need there's something wrong with your forms -- and the BDI/RUBY/RT/RP tags for east asian typography, which to be frank as a English language user means exactly two things to me; and Jack left town, took his **** with him. ... and even some of the form stuff takes a leak on accessibility from so high you'd think the Lord Almighty just got back from an all-night kegger. In particular the placeholder attribute just makes it easier to make forms harder to use, all to stroke the ego's of the "but I can do it in Photoshop" twits who when pressed go "WCAG, what's that?!?" See: http://baymard.com/blog/false-simplicity (thanks go out to Stomme Poes for that link) That's not even the start of it, with the new loosening of structural rules, destroying the meaning of heading orders, dumbass elements like HGROUP that means the WhatWG doesn't even understand numbered headings purpose (likely the same idiots who use a H2 for a tagline after the H1) -- it's is carefully crafted to undo all the progress those of us who embraced strict markup, semantics and separation of presentation from content have made over the past decade. So if none of the new tags and attributes are worth a flying purple fish, what does that leave of value? NOTHING... except the flashy bits of CSS3 and the new scripting that have NOTHING to do with writing markup and can be used just fine with ANY of the older document specifications. I believe that's the entire reason CSS3 and the new scripting are slapped under HTML 5's bannerhead, as without them the Emperor is standing there for all the world to see. Near as I can tell, there are only five legitimate purposes HTML 5 serves: 1) Justify the sleazeball coding practices of the people who write HTML 3.2 like it's 1998 and have spent the past decade and a half with a tranny doctype on it. 2) Allow Book writers to take their outdated '90's works, replace twenty pages and slap a new title on it. 3) Allow professional lecturers to put more buns in seats to flap their gums about topics they aren't qualified to open their mouths about in the first place. 4) Create a new sick buzzword akin to Web 2.0 to exploit the ignorance of the suits who think they can get sound technical advice from the pages of Forbes; which is akin to taking financial advice from Popular Electronics. 5) Allow browser makers to dictate to developers what codecs and containers they should be supporting, promoting vendor lock-in. Which is why I personally have ZERO plans to migrate past XHTML 1.0 Strict for the time being... I literally cannot fathom how ANYONE is DUMB ENOUGH to see merit in anything HTML 5 has to offer... and for me to be the one underestimating the stupidity of my fellow man is, well... if you told anyone who knows me they wouldn't believe you.
HTML 5 is not stable yet.. Check this article to know your browser compatibility with HTML 5 bit.ly/S6mcRR
I do not think it is very stable at the moment. It is still under development. I think we will have it still shaky for quite some time, but it looks promising.
Yes, HTML5/CSS3 and jquary is most recent technologies around the web industries. Its give complete fast loading short hand coding and user friendly development. the perfect coding style will help you get good rank on SEO as well. for the browser isssue.....Now a days most of the latest browsers going to support HTML5/CSS3.
HTML5 gives more flexibility while also enabling websites to be more interactive, powerful and efficient. The best thing about HTML5 is that it is simpler than previous HTML standards, thus giving rise to a cleaner code. 1. Do away with add-ons to play your multimedia. HTML5 allows you to play videos, animations, drawings, and music on the page itself. You do not have to use any add-ons such as Flash and Silverlight, the way that most video sites are doing now.Also; developers can now use JavaScript alone to create diagrams, graphics and animations on any page they create. 2. Geolocation. HTML5 supports geolocation, making location directly available on any compatible browser or application. 3. Offline database. HTML5 also brings with it an SQL-based database that allows those in the client side to store data on their computers. 4. Work your applications offline. With the offline application cache, users can still use and access their applications even when they are not connected to their networks. 5. Great forms. HTML5 allows for better form fields such as better text inputs and better search boxes. It also handles data validation quite well. On top of that, you can create really nice looking forms. 6. Works best for mobile phones. What
HTML5 (or just HTML) will never be "stable". The official specification documents what browsers are doing, and it'll always be behind what different browsers are capable of doing. Instead you should consider each piece/feature on its own.
Obviously, HTML 5 is stable, and It's a newer specification for HTML, which has more features than HTML, and it is much better but isn't as widely supported as plain old HTML.