I have an application developed in VS2005 and html4. First of all my question is, is there any tool that will do migration from html4 to html5.
My plan is first select HTML5 from dropdown available in VS2012 then just change the doctype definition from master page to <!DOCTYPE html> and fix all the warning like replace cell padding with padding and etc.
Does these steps are sufficient in order to convert an application in to HTTML5?
Are these steps are sufficient in order to convert an application in to HTML5?
In short, yes, that's pretty much it.
HTML5 is explicitly designed to be backward compatible with HTML4; there is very little that you should need to change apart from the doctype.
There are a few things to be aware of, which might need changing:
A few older HTML tags have been deprecated in HTML5. You can't use things like <blink>, <marquee> or other awful things like that. Hopefully you weren't using them anyway though?
Also some attributes have been deprecated, mostly in favour of using CSS instead. So if you're using width or height or color attributes in your HTML tags, you should replace them with CSS. The same also applies to the <font> tag; use CSS to define your fonts and font sizes instead.
There are various new tags in HTML5 which you may want to use. These are tags like <section> and <footer>, which are designed to make your site's code more readable for search engines. But you don't have to use them; they are entirely optional. Note that IE8 and earlier don't support them unless you use a JavaScript hack, so if you need to support IE8, it may be best not to use these tags. You can still use the HTML5 doctype in IE8 though.
You might find it useful to read the official documentation from the W3C that details the differences between HTML4 and HTML5. Read it here: http://www.w3.org/TR/html5-diff/
Related
I have two issues I have ignored so far, but I will really appreciate some light shed onto them.
First: how can I solve differences between Safari, Chrome and Firefox and the various tags that their engines render differently? Should I just write down the right attribute for each in the same css rule? Is there no better way?
Is there a way to separate the CSS sheets for these browsers as I am doing for IE? Is this recommended?
Second: What about CSS3 attributes? Should I just write them again in the same rule after the CSS2 attributes?
Will this cause problems validating the CSS with WC3?
Welcome :)
If you start without the prefixes, you should write the code, generally, with all the semantically appropriate tags, first.
Then, you can decide what your goals are.
If you want W3C compliant CSS files, then you'd need to strip out the vendor specific prefixes by default. This would then allow the latest browsers to pick up the standardised CSS properties if they support them.
This will target less of your market than you might wish, so then you should ask if progressive enhancement is a possibility. If you can reasonably enhance the visuals by using css applied after the page has loaded, such as applying styles with jQuery, MooTools or Prototype libraries AND these libraries are already serving a purpose in your website, then you could apply additional styles with those libraries (and possibly use them in conjunction with Modernizr to determine which elements you may want to additionally support.
However, it's likely that a browser will skip a property it doesn't understand and will render the ones that it does, so I'd suggest that if you code it to W3C Standards first and then add in your additional vendor prefixes 'before' the final (correct) one, then you'll likely have satisfied reasonable measures to be compliant and meet design needs.
Edit:
There is a little bit of confusion between validation results from:
http://validator.w3.org/
and writing valid code related to vendor prefixes to get CSS effects cross-browser:
List of CSS vendor prefixes?
for working on some cross-browser CSS, you might find http://csspie.com, for IE compatibility with some CSS3 properties, useful along with http://www.colorzilla.com/gradient-editor/ for cross-browser gradients and http://cssplease.com for code that gives you alternative vendor prefixes, including different versions of IE support for many different properties.
In terms of validation, here's what W3C says about it: (see comments here: W3 VALID cross browser css gradient,) and official docs here: http://www.w3.org/TR/css3-syntax/#vendor-specific
If you code according to the specifications first and test your code out against that and then add in your vendor prefixes to get the same effects on the browsers you want to support (see progressive enhancement: What is Progressive Enhancement?) then you can be more confident that your code is supporting the appropriate standards, adding value to those with more advanced browsers and still useful for those without additional features (see also WAI III compliance, 508 compliance and others if you want to write a more inclusive site).
Caveat: Web Apps may not always be inclusive or follow these guidelines depending on who the audience is.
If you are using jquery on the site you may want to look into PrefixFree. It's a script that adds the vendor prefixes for you, so for example your put border-radius:6px; in yor css and it reads the browser and adds the appropriate vendor prefix for you via js. I like it cause it keeps my css docs more readable.
Is there any practical benefit of using <header> over <div id="header">?
and writing css for header {} over #header {}
I know one downside is , I will have to punish IE users with a Javascript if use <header> otherwise it will not take style.
I know it's HTML5 but is there any advantage of using it until non HTML5 supported browsers are still in use.
IE6, IE7, IE8 and some old mobile browsers do not understand these new tags.
Edit:
It's OK to use a JS Canvas library to do something awesome in all browsers but to use a Javascript just to use some tags in IE wil decrease performance without a big reason.
Besides the fact that it gives more meaning to the markup , when working with css you can more easily select the required items without resorting to id's or class.That reduces the amount of markup you are required to write , it makes mantaining the site alot easier and help other developers understand your code better if needed.
I don't know for a fact, but I think it almost certain that using semantically better markup (e.g. <header>) will help search engine crawlers construct a better image of your website.
There is probably no other practical benefit of going HTML5, and even the above is not exactly tangible. So in practice I don't really believe you can argue that going HTML 5 (and doing the extra work needed to make your page compatible with earlier IE versions) is going to be a good investment.
On the other hand, if you don't care about obsolete browsers then there's really no drawback.
Well, from my point of view, it gives further meaning to the markup. At least in a more structured way. Say, for instance that you have to parse automatically your page (if it wasn't yours), you would know that the header will always be a and it doesn't depend on the CSS class used.
Gives better structure to your page as Carles points out - this is especially helpful when it comes to search engines - they'll be able to crawl all your website a lot more effectively. You can use javascript to get IE to recognise HTML5 elements (simply put it inside an if statement).
Questions
On average, has the usage of HTML5
semantic tags increased compared to
the usage of CSS layers (div)?
Also, is there a good difference between them and does it optimize the code for better speed and maintainability?
Differences in character length is not much
and <div id="footer"> is
compatible in older browser without
using Modernizr or other
Javascript solutions to emulate
support of HTML5 in non supported
browsers.
Therefore, if I only use semantic
tags of HTML5, and not using any
advance functionality of HTML5 like
audio, video, etc. am I missing
something?
Examples
HTML
<footer> and <div id="footer">
CSS
#footer {} and Footer {}
From what I've seen and experienced, HTML5 tags like and are mainly provided for SEO so that search engines can (one day?) possibly use those sections and other tags properly.
Like you said, most of the tags are semantic and provide no real functional benefit- in fact, most break rendering in older browsers. I ran into an issue with these new tags when I tried dynamically loading HTML5 content with jQuery and the HTML5Shiv.js/Modernizr.js. I was unable to properly render the elements that were dynamically loaded in older browsers such as IE8 and IE7.
At this point, I'd recommend sticking with divs, as they're more widely used and provide better cross-browser functionality.
My two cents.
On average, has the usage of HTML5 semantic tags increased compared to the usage of CSS layers (div)?
You are conflating two different ideas here. CSS can be applied to new elements just as easily as it can to old ones. The use of CSS is independent of use of semantics.
Also, is there a good difference between them and does it optimize the code for better speed and maintainability?
Speed? Certainly not.
Maintainability? Well, they reduce div soup, so in theory, yes.
The advantage comes from having more semantics in the document, so tools can extract relevant parts of documents, skip over sections, etc.
Differences in character length is not much and is compatible in older browser without using Modernizr or other Javascript solutions to emulate support of HTML5 in non supported browsers. Therefore, if I only use semantic tags of HTML5, and not using any advance functionality of HTML5 like audio, video, etc. am I missing something?
Err… you're missing audio and video. (Whether that matters for your site is another story)
Best practices?
How does this differ from HTML4 or XHTML1?
There's a lot of discussion going on over here: http://html5doctor.com/html-5-reset-stylesheet/
I'm wondering what other resources/discussion exists.
The comments on that post are crazy. You're certainly not going to find a more thorough discussion.
I think you should delete unnecessary rules and deprecated tags from whatever reset you've been using and keep truckin. Paul Irish (jQuery core contributor, co-creator of Modernizr and now Googler) has a comment in the article you link to that has all the HTML5 specific CSS leveling you're likely to need:
article, aside, dialog, figure, footer, header, hgroup, nav, section { display:block; zoom:1; }
Google's using a simpler version in their base.css on HTML5Rocks.com:
section, article, header, footer { display: block; }
You'll still need to use Remy Sharp's simple, bare-bones HTML5 Shiv or Modernizr to run a JavaScript loop to enable styling of new HTML5 elements in IE. HTML5 Shiv just creates the elements to allow styling, Modernizr is a much more full-featured HTML5 and CSS3 detection/styling solution. There's another great post on HTML5 Doctor worth a look, How to use HTML5 in your client work right now from March 2010, co-written by Remy and Richard 8 months after the reset article. They mention using Modernizr "to detect Web Forms 2.0 and other HTML5-type support."
Also, Dion (from Ajaxian and now Palm) tweeted about css3pie that will render visual elements like border-radius, box-shadow, and gradients in IE. Can't vouch for it myself.
(I had more links in here but had to remove all but one b/c my rep. is < 10, if there's something you can't find. reply and I'll post it.)
HTML5 is still not widely supported. As such, I don't think you will find an HTML5 specific reset stylesheet yet. My recommendation would be to take Eric Meyer's and add the tags for HTML5. (e.g. nav, header, footer, etc)
I just use my variation of Eric Meyer's reset, with my own preferences. For HTML5 compatibility, I add the new elements in as needed.
One thing in particular is that new elements are unstyled by default, so you need to provide your own defaults. This is especially important for block elements like section, aside, and article. You need to ensure you specify display:block for those elements.
I modified Eric Meyers reset late last year for HTML5. Use it for every project, and it works great: CSS Reset Refreshed
It sets the new HTML5 block elements to display accordingly. This is not done in any mainstream browser today, and you will run into problems if you do not set this.
It also "resets" HTML5 element styles. Technically, the resetting is not yet needed as browsers do not natively style HTML5 elements, but your site will be future proofed for when they do.
There's a lot to it. You can't take one persons css rest as gospel. I recently made a custom reset sheet by revising parts of boilerplate, YUI, my preference and some other ppls methods.
It's more down to preference & practicality. In terms of differentiating html5 css standards from xhtml & html4, don't bother compare you should aim to use html5 doc-types for all your new work unless your project specifically requires xhtml by request.
I have designed many web-templates. But (except my first one) I've never used browser detection scripts to load corresponding CSS.
I am not sure whether it is a good technique, or just an alternative way (to struggle with a single CSS to satisfy all the browsers)?
It depends on how complex your layout is.
On the whole, there are a set of "problem features" with some browsers, such as the browser not following the border-box model and assigning margin, border and padding values incorrectly.
Many designs aren't affected by the problems and look very similar in all browsers, but if you have a part of your design that has a touch point on one of the issues, it is probably better to extract the "fixes" into a separate stylesheet, rather than pollute your standard CSS with hacks.
You should find that you have
1 Stylesheet for "standards compliant browsers"
and
1 Stylesheet to cater for any issues with the others
If you have more than this, you're creating trouble for yourself and are juat adding to the number of http requests for the page.
Most commonly people use conditional comments in Internet Explorer to load a separate stylesheet for just IE, and a default one for all the others.
More info on MSDN
The best option is to use a css which is compatible for each (major) browser.
So the question is; do you really need browser-specific-css?
If you really need it; you can use:
<!--[if IE 7]> <link rel="stylesheet" ....> <![endif]-->
From my experience I would always try to avoid to really fall into the specific-browser-CSS-trap. Try using CSS-reset-methods and from a fresh start build for a defined set of current browsers. I would rather try to make little changes to the designed layout to get it working as so much time can be saved by that (if it's possible in the project or the designer is cooperative).
Another aspect where it would make sense is an approach like the one Andy Clarke talks about in his nice book (Website http://www.transcendingcss.com/). Use latest tags and all options that make your code and CSS simpler, shorter, more semantic - even if it results in explicitely different look and feels for, e.g. Firefox and IE.