Everyone is now talking about HTML5, i dont really understand what is the difference between it and the normal .xhtml
could you please solve some of my doubts:
What are the differences?
What are the advantages and disadvantages?
Is HTML5 considered a markup language or an scripting language?
What are the differences?
HTML 5 is just the next version of HTML. It takes HTML 4 and adds more stuff to it (while throwing out a few bits that shouldn't be used and changes the rules on how to parse it (to what browsers have been doing for the last decade anyway)).
What are the advantages and disadvantages?
It lets you do more stuff.
It doesn't have any disadvantages (other than that the new stuff isn't well supported yet).
Is HTML5 considered a markup language or an scripting language?
It is a markup language with a bunch of DOM APIs.
I guess the confusion is that HTML4 and HTML5 don't do much (on their own). You need javascript and css and that is when the party really starts.
When people are talking about HTML5 I guess they are talking about HTML5+ CSS3 + Javascript (compared to HTML4 + CSS2 + Javascript).
For a good example of the adventures you can have in the new world check this out:
http://slides.html5rocks.com/
Remember this isn't using .NET or PHP or any thing, its "just" HTML5 + javascript + css
pro
fancy new options
more elements to better define your content
video without flash
con
not supported by all browsers
Not a lot of good quality docs available (yet)
And it is still a markup language as it has no dynamic elements in it that are scriptable.
basically html5 is just like html, with some extra tags added,
like the canvas element for drawing, the video and audio elements for media playback, some new content specific elements, like article, footer, header, nav, section. it has also better support for local offline storage. and also some new form controls, like calendar, date, time, email, url and search
So actually not much you couldn't do earlier with some JavaScript (or jquery, as some people like to call it now :p), but it's designed to make those (nowadays) common tasks a lot easier
What are the differences?
See HTML5 differences from HTML4
What are the advantages and disadvantages?
That's going to depend to a certain extent on what you're trying to achieve, but it might help to understand the rationale behind the spec. Basically, backwards compatibility is one of the main goals so, if you avoid using any of the new features like video or canvas, there should be no disadvantages over the previous standards.
Is HTML5 considered a markup language or an scripting language?
From the WHATWG FAQ:
HTML5 is a new version of HTML4,
XHTML1, and DOM Level 2 HTML
addressing many of the issues of those
specifications while at the same time
enhancing (X)HTML to more adequately
address Web applications. Besides
defining a markup language that can be
written in both HTML and XML (XHTML)
it also defines many APIs that form
the basis of the Web architecture.
Some of these APIs were known as "DOM
Level 0" and were never documented
before. Yet they are extremely
important for browser vendors to
support existing Web content and for
authors to be able to build Web
applications.
Related
As far as I understand, the only real advantage of HTML5 semantic markup is for search engines and web crawlers to interpret the document better.
Since intranet applications have nothing to do with search engines or web crawlers, what are the advantages of using semantic markup in HTML5?
There is no straightforward example to point out, but the website (even intranet) can be consumed by different user agents (on different devices).
You are probably familiar with Skype (and the iOS Safari) making phone-number-like words clickable. In the future I can easily imagine mobile browsers being smarter to assist the user in completing tasks on the page, like importing a clearly indicated contact to the address book.
Screenreaders for blind people?
While there is not a whole lot of immediate benefit for non-disabled people, it is still good practice. Does your company not have any externally facing sites? If it does, do those people not look at internal page code? Good practices spread just like bad ones.
see also: http://en.wikipedia.org/wiki/Semantic_HTML
Simply said there the only rule you have to follow if you create your html documents is that it is valid html, otherwise you will have the problem that the browser would try to correct your broken syntax which may result in defects of the visual representation of your content.
In modern browsers you can use display to given any element - with some limitations e.g. with input element - the same visual look and behavior then any other element.
So if you ask what are the advantages of using semantic markup in HTML5 you should ask, why to use any of the semantic markup if it is possible to have the same result using css.
The short answer is, no one will stop you if it is your own project where you are responsible to - except the client that probably gives you requirements.
It is similar to asking: Language xyz provides comments and there is a syntax for doc-comments, but why should I use them?.
Using the semantics wisely increases the readability and thus maintainability. You are not required to use every possibility of semantics at all costs.
Using them will help you to get into the code again if you haven't looked at it for a longer time, e.g. to distinguish between the elements that encapsulate logical parts and elements that are used for styling. Especially if you use a template engine to create your code or to search for certain elements in multiple files.
Even if you are now the only one who works on the code it may happen that if the project grows that you need other people to work on the code. Or for the situation, you for some reason are not available, someone else needs to maintain your code, a good markup is essential.
Using the correct markup and additions like WAI-ARIA is not only essential for handicapped people, but also allows the browser to recognize the meaning of elements, allowing to e.g. improve the keyboard navigation. Especially in a productive environment where you need to type much, it is often faster to navigate with keyboard then using a trackpad or a mouse.
HTML5 introduced 22 new markup tags. W3C still recommends we stick to the old tags, because IE exists. I think adding JavaScript for this purpose is over the top. HTML5 also features the less known role, comparable with the ARIA role of XHTML 2. The great advantage of the markup tags is that search engines like Google know which is which. Do search engines also support these?
Hard to tell, but I would say Google understands them in the same way as it understands HTML5 tags. And even support for HTML5 will take some time, since new sites could take too much vantage from old HTML4 sites.
For example a <div role="main">...</div> would be like the main <article>...</article> of your page.
Please keep in mind that it is important to make your document at least ARIA valid. For example, use more than one role="main" in your site is invalid and could be considered as blackhat SEO.
Worth using role where appropriate. Remember that it improves the accessibility of your site.
What is the Document Object Model (DOM)?
I am asking this question because I primarily worked in .NET and I only have limited experience, but I often hear more experienced developers talk about/mention it. I read tutorials online but I am unable to make sense of the whole picture. I know that it is an API!
More specific questions are:
Where is it currently used?
What field(s) of developers use it (ex-.NET developers)?
How relevant is it for all developers in general to understand?
In general terms a DOM is a model for a structured document.
It is a central concept in today's IT and no developer can opt out of DOM. Be it in .net, in HTML, in XML or other domains where it is used.
It applies to all documents (word documents, HTML pages, XML files, etc). In the developer sphere it applies mainly in the HTML and the XML domains with slightly different meanings.
HTML
In the HTML arena, the DOM was introduced to support the revolution called in the late 90ies "dynamic HTML". Before IE4 and Netscape 4.0, HTML documents where not changeable inside the browser (all you had in these remote times to sprite up a web page was "animated GIF" !!!! and HTML was version 3.2).
Therefore dynamically manipulating inside the browser the document sent by the server was a huge revolution and initiated the march towards the attractive web sites we see today.
Javascript had been introduced by Netscape (baptised javascript to surf on the new Java trend, but unrelated) and was supported by both Netscape HTTP servers and Netscape browsers, with Internet Explorer eagerly following the move inside the browser. However When javascript is used to manipulate the content of a document, you need an easy way to designate the part of the document you want to interact with. That's where the DOM comes in. Although HTML 4 is not "well formed", browsers build an internal representation of the page with the "body" element at its top and plenty of html tags below, in a hierarchical organisation (child nodes, parent nodes attributes etc). The DOM is the model underpinning the API that allows to navigate this hierarchy.
Since both Netscape and IE browsers were competing solutions, there was little chance the NS and the IE DOM would converge. The W3C stepped in to allow smaller browser vendors to enter the competition and endeavoured to standardised the DOM. Hence the W3C DOM. All it did was just to introduce another dialect and as everybody knows it took years and two serious competitors to force MS to comply with the standards.
Even though more moderns navigating techniques like JQuery have shorthand notations for the DOM, they internally rely on the DOM.
XML
HTML made obvious the disadvantages of showing leniency towards the "well-formedness" of documents and this ushered a new craze : XML. In the web arena, XML and XSLT were first supported by IE5 and adopted in many more domains than just displaying pages.
To parse XML, in the Java Word mainly, you would develop a SAX parser which is basically a plugin to a SAX engine in which you describe what the engine should do of all the XML events (tags...) it will encounter in the parsed document. Developing a SAX parser is not straightforward but is a low footprint solution.
However you have to develop a specific one for each new document type...
So it was not long before libraries started to appear to parse any document and build an in-memory map of its hierarchy. Because it also had the same concepts of root, parents and children (inherited from SGML through HTML), it was also termed a DOM and the name applies regardless of the library.
Other domains
The concept of DOM is not restricted to or even invented for HTML or XML. A DOM is a general concept applicable to any document, especially those (the vast majority of them do) showing a hierarchical structure in which you need to navigate. You can speak about the DOM of a MS-Word document and there are APIs to navigate these as well.
The DOM is the application programming interface for well-defined HTML and XML structures (per W3C's document). It is used in any place where you interact with the elements of a web page (any element - style, text, attributes, etc). You will hear a lot about the DOM with JavaScript and/or JavaScript libraries, such as jQuery (which, of course, is JavaScript). It is also referenced with Java, ECMAScript, JScript, and VBScript.
If you are programming .NET it is important if you are doing web-based work. If you are doing application programming, it's not as important. The DOM is definitely not a thing of the past - it is used and worked within every day by many developers. With that said, there has been work towards standardization of the DOM across web browsers. (Again, libraries can help hide these differences. This is one reason jQuery is so popular. You don't have to worry about the browser specifics - you just do what you need to do.)
The document I linked to above does a great job of answering all your questions and more. I would highly recommend reading it. If you have more questions, you can also check out the links below:
What is the Document Object Model? (W3C)
Document Object Model (Wikipedia)
I'm really not going to be able to explain it any better than the Wikipedia Article on DOM
But to answer a few of your questions:
Where do we still use it?
Every web browser since the mid-nineties.
Who uses it,
Every web developer since the mid-nineties.
in what technology?
Mostly the web via JavaScript, but pretty much anytime you access XML/HTML programatically you are using some kind of DOM implementation.
How important is it for anyone in .net
carrier? [sic]
Extremely, although you probably use it without even knowing it.
Is this just a thing of the past which
was heavily used but had problems?
If it is then somebody needs to tell John Resig that he has wasted the past 3 years of his life.
When a browser loads an HTML page, its convert it to the Document Object Model (DOM).
The browser's produced HTML DOM, constructs as a tree that consists of all your HTML page element as objects. For example, assuming that you load below HTML page on a browser:
<!DOCTYPE html>
<html>
<head>
<title>website title</title>
</head>
<body>
<p id="js_paragraphId">I'm a paragraph</p>
some website
</body>
</html>
After loading, the browser converts it to:
Some of the ability of scripting languages on HTML DOM consists of:
1- Change all the HTML elements in the page.
2- change all the HTML attributes in the page.
3- Change all the CSS styles on the page.
4- Remove existing HTML elements and attributes.
5- Add new HTML elements and attributes.
6- React to all existing HTML events in the page.
7- create new HTML events on the page.
Let's back to your questions:
1- It currently used in all modern browsers.
2- Front-end developers.
3- All Front-end developers that using scripting languages especially JavaScript.
What is DOM?
The Document Object Model (DOM) is a programming API for HTML and XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. A standard defined by w3 consortium.
Source: http://www.w3.org/TR/WD-DOM/introduction.html
I have just started considering using the HTML 5 api for a Rails/JQuery project, so I can use that great data- attribute to store values.
I am worried though about browser compatibility issues. I have two questions (basic questions):
In order to use HTML 5, do people need to upgrade their browsers? How does that work?
Is there an up-to-the-day chart of what features each browser layout engine supports, more up-to-date than this Wikipedia article on comparing HTML layout engines and this When can I use... HTML 5 page?
Is it going to be an issue with people using IE6 for example? Lots of non-computer saavy people I've talked to who want to get an internet presence themselves use, and the people they talk to use, still, IE6!
If it's not an issue, and you can use HTML 5 on old browsers, how do you? Or what docs should I look at :)? Thanks.
Update: I will post some interesting links as I find them below.
FindMeByIP: "A simple app which reveals your browsers' support for CSS3 and HTML5 features in an easy to read format using Modernizr." - Browser Support for CSS3 and HTML5
It is not useful to consider HTML5 as a single entity, that browsers either ‘support’ or ‘don't support’. HTML5 is:
an attempt to codify widespread existing practice beyond the limits of what the previous W3 HTML and DOM standards had covered, such as IE and Firefox extensions that the other browsers have copied, and long-standing ‘DOM Level 0’ behaviours that everyone took for granted but weren't written into any spec before.
a random selection of new extensions not yet in widespread use, which it is hoped browser manufacturers will support. Some have already succeeded, heading into all new browsers already; some have been spun off into their own specifications (which is much more manageable for everyone), some are controversial, and some no-one cares about at all.
It has been, IMO, an enormous mistake to try to cover these two bases at once. I would have preferred an HTML 3.2-style ‘catch-up’ standard plus many separate extension specifications. But there's nothing can be done about it now.
HTML5 is also:
Not finished. The specification is massive, complicated, incomplete, and likely to change in details (or maybe more than that) before it becomes a proper standard. No-one can say they ‘support HTML5’ yet, because no-one knows yet what ‘HTML5’ is actually going to be.
In practical terms: there are some parts of HTML5 that have long been in use. There are some parts that you can use safely on modern browsers. There are some parts that you can use on new browsers except for IE. There are many parts you can use with fallback workarounds or ‘graceful degradation’. There are some parts you may never be able to use. For now you will have to learn each separately, because there won't be a browser that supports absolutely everything in HTML5 for many, many years. If ever. Add the extra features you like gradually as you go along and they're supported by a greater share of browsers; there will be no ‘big bang’ where everyone updates their browser at once.
As for data- attributes, well, yeah, you can kind of get away with using them, in that most browsers have always allowed any old attributes to go through anyway. This is typical of several HTML5 extensions, the browser doesn't need to explicitly ‘support’ it for it to work.
But since there are other ways of passing data (classes, comments, script blocks, etc.), I'm not wholly convinced it's worth dropping (universally supported, validatable against a fixed standard) HTML4/XHTML1 pages just for that one feature yet.
You might want to check out diveintohtml5.ep.io and modernizr.com.
Modernizr is a small and simple JavaScript library that helps you take advantage of emerging web technologies (CSS3, HTML 5) while still maintaining a fine level of control over older browsers that may not yet support these new technologies.
Here's an interactive chart of html feature support:
http://a.deveria.com/caniuse/
As you can see, there are a lot of browsers that support quite a few of the H5 features.
If you're using jQuery, concerned about interoperability, and the only reason you're investigating HTML5 is to use the data-* attribute set, then I would consider switching back to a better-supported doctype and using jQuery's $().data() method, which allows you to bind arbitrary pieces of data to DOM nodes, similar to how the data- attribute set does.
Example:
<button id="set">Click me!</button>
$('button#set').click(function(){
if($(this).data('name')){
alert('Clickin\' again so soon, ' + $(this).data('name') + '?');
}else{
$(this).data('name', prompt('Hey good lookin\', what\'s your name?', ''));
}
});
Try it out!
My answer might not be the one you would like but I would say - don't. Don't use HTML 5 just yet.
Use Protovis. It uses javascript and HMTL5. No Flash here. More important, Protovis has BSD license. So you can use it in commercial projects. Although D3 is the a newer project that authors of Protovis are working on.
Although this is an old(ish) question, the topic of browser support will always be relevant. There's no right way or wrong way to approach it, but take a look through one of the many browser feature support tables that show you what percentage of users will see a certain feature and then be brutal.
Don't try to please everyone. Don't kill yourself to catch a few percent of the Luddite's who are still using IE7. Next year, substitute that for IE8. Personally, I would be happy to lose 8% in order to spend that time on forward thinking practices rather than catering for those who don't know what an upgrade is.
Maybe your site will cause people to upgrade. These people will come round eventually.
What are the key differences between HTML4 and HTML5 draft?
Please keep the answers related to changed syntax and added/removed html elements.
HTML5 has several goals which differentiate it from HTML4.
Consistency in Handling Malformed Documents
The primary one is consistent, defined error handling. As you know, HTML purposely supports 'tag soup', or the ability to write malformed code and have it corrected into a valid document. The problem is that the rules for doing this aren't written down anywhere. When a new browser vendor wants to enter the market, they just have to test malformed documents in various browsers (especially IE) and reverse-engineer their error handling. If they don't, then many pages won't display correctly (estimates place roughly 90% of pages on the net as being at least somewhat malformed).
So, HTML5 is attempting to discover and codify this error handling, so that browser developers can all standardize and greatly reduce the time and money required to display things consistently. As well, long in the future after HTML has died as a document format, historians may still want to read our documents, and having a completely defined parsing algorithm will greatly aid this.
Better Web Application Features
The secondary goal of HTML5 is to develop the ability of the browser to be an application platform, via HTML, CSS, and Javascript. Many elements have been added directly to the language that are currently (in HTML4) Flash or JS-based hacks, such as <canvas>, <video>, and <audio>. Useful things such as Local Storage (a js-accessible browser-built-in key-value database, for storing information beyond what cookies can hold), new input types such as date for which the browser can expose easy user interface (so that we don't have to use our js-based calendar date-pickers), and browser-supported form validation will make developing web applications much simpler for the developers, and make them much faster for the users (since many things will be supported natively, rather than hacked in via javascript).
Improved Element Semantics
There are many other smaller efforts taking place in HTML5, such as better-defined semantic roles for existing elements (<strong> and <em> now actually mean something different, and even <b> and <i> have vague semantics that should work well when parsing legacy documents) and adding new elements with useful semantics - <article>, <section>, <header>, <aside>, and <nav> should replace the majority of <div>s used on a web page, making your pages a bit more semantic, but more importantly, easier to read. No more painful scanning to see just what that random </div> is closing - instead you'll have an obvious </header>, or </article>, making the structure of your document much more intuitive.
From Wikipedia:
New parsing rules oriented towards flexible parsing and compatibility
New elements – section, video, progress, nav, meter, time, aside, canvas
New input attributes – dates and times, email, url
New attributes – ping, charset, async
Global attributes (that can be applied for every element) – id, tabindex, repeat
Deprecated elements dropped – center, font, strike
HTML5 introduces a number of APIs that help in creating Web applications. These can be used together with the new elements introduced for applications:
An API for playing of video and audio which can be used with the new video and audio elements.
An API that enables offline Web applications.
An API that allows a Web application to register itself for certain protocols or media types.
An editing API in combination with a new global contenteditable attribute.
A drag & drop API in combination with a draggable attribute.
An API that exposes the history and allows pages to add to it to prevent breaking the back button.
You'll want to check HTML5 Differences from HTML4: W3C Working Group Note 9 December 2014 for the complete differences. There are many new elements and element attributes. Some elements were removed and others have different semantic value than before.
There are also APIs defined, such as the use of canvas, to help build the next generation of web apps and make sure implementations are standardized.
You might be interested in this list of HTML5 elements and attributes.
Also, please note that it's "HTML 4", not "HTML4". Indeed, for HTML 5, both variants are used, but there is an important difference in meaning. HTML 5 refers to the name of the W3C specification, whereas "HTML5" is the document type of those HTML files with a text/html MIME type that follow this spec.
The same goes for XHTML 5 vs. XHTML5.
Now W3c provides an official difference on their site:
http://www.w3.org/TR/html5-diff/
HTML 5 invites you give add a lot of semantic value to your code. What's more, there are natives solution to embed multimedia content.
The rest is important, but it's more technical sugar that will save you from doing the same stuff with a client programming language.
In short it is much simple compared to html, the long doctype is removed and also center and font tag is removed.
I also answered this difference in my blog :
http://ravisinghblog.in/key-difference-between-html-and-html-5/