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)
Related
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/
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).
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.
Like every web developer, I usually curse the creators of IE6 with foul and untimely deaths at least once a week. Yet my company requires me to keep supporting that most-hated of browsers.
My problem today has been wanting to first use a wildcard in my CSS and then trying to use the "inherit" property instead. Neither of which are supported by IE7-.
I really, REALLY want to have good, well-structured, properly-inheriting CSS (object-oriented CSS, if you like that buzzword) but I have that sinking feeling in the pit of my stomach that sooner or later, it's going to have to be custom-purpose and location-based classes.
This poses the question: given how utterly awful IE is at handling many CSS concepts, is it impossible to adequately support this browser at the same time as having a well-structured CSS document?
Just to clarify: I'm aware that there are plenty of ways (some legitimate, some less so) to get around the bugs and shortcomings found in IE6 and 7. What I'm really asking is "if you want to have a single, well-written stylesheet that inherits correctly, must you choose between that and having a consistent look across all browsers?". Hope that makes sense.
In other words, should I stick to my principles and code a good style sheet or should I accept that IE6 still enjoys a horribly high (20% on last count) market share and bring myself to support it? Or is there some happy medium that allows me to minimise the frankenstein surgery on my HTML and CSS while still achieving some respectable results in IE?
To be fair, you can't blame it all on IE (though Microsoft certainly is by far the worst transgressor). Part of the problem with such large & rapidly-evolving standards is that it's too much of a moving target to be perfectly implemented in a timely fashion. Unfortunately, the release cycles of web browsers do not coincide with the release of new web specifications. So all browser developers can do is try to implement as many features as they can from the latest W3C recommendations, selecting what they think will be the most commonly used features to implement first.
However, things are clearly improving, and it is possible to support IE6/7 and still use proper CSS design. It's just... difficult. Take a look at this comparison of layout engines & CSS support. If you look at the overall trend, you'll see that most browsers (even IE) do tend to comply with established standards in the long-run, it just takes some browsers longer than others to implement a standard after its introduction.
And sometimes it's not that one browser is "less" standards-compliant than another. With new standards the problem is often that different development teams chose to adopt different parts of the new specification. So even though CSS3 is already beginning to be implemented by most browsers, we'll probably have to wait until CSS4 is published before seeing consistent support across all major rendering engines. And if you try to use the latest CSS3 features right now, you'll have a hard time establishing compatibility across all major browsers. But if you're using features introduced in CSS1, it's no problem at all.
Therefore, the only option--aside from using ugly CSS hacks--is to stick with well-established older specifications. Then the problem is no longer trying to conform to web standards while supporting a particular browser. Instead the problem simply becomes trying to resist the urge to use the latest & greatest CSS features.
Aside from that, the only permanent solution I see to this recurring situation is for the W3C to prioritize different parts of newly introduced specifications so that the new features can be implemented in discrete phases synchronized across all the major browsers. So, for instance, grammar rules might be given the highest priority along with a set deadline for its implementation. After that would come the second phase, which could be element & attribute selectors, and so on and so forth.
This would require a tremendous level of cooperation between the W3C and development teams, but it would be worth it. After all, it does users and web developers no good for IE to implement one subset of features from CSS3 while Firefox implements a different subset and the Webkit browsers yet another subset. A "standard" is no good until it's actually standardized across all the major rendering platforms. It's better for each browser to support fewer new features but have them all be the same features, than for them to separately introduce a ton of their own features that aren't universally supported.
Not at all - you can compensate for IE's shortcomings with conditional comments and an IE specific stylesheet, while serving your 'nice' stylesheet to other browsers.
Something else which I find helps is to use a CSS reset. While this isn't going to resolve all of IE's issues, it does give you a good baseline to work from.
The most anoying IE6 feature is it's box model handling. You should stick to margin instead when positioning boxes, and try to use relative font sizes to allow font resizing on IE. The rest of the quirks are well documented.
Using conditional comments is the cleanest way of having both a clean style sheet for well behaving browsers, and still using being beautiful on IE. This is what I use, only needing 1 css file of a few lines to repair my sites look and feel.
The dark path of crossbrowser consistent look & feel are css hacks, but I strongly discourage it's use, specialy now that for some time we'll have to target three different IE (6, 7 & 8)
Normally, if you get the style to work in both FF and Chrome/Safari, IE is only a few corrections away of being correct.
There is a great site Position Is Everything that details how FF, IE and Safari conform to standard CSS. At the site you will find most of the workarounds / cures for IE that will alleviate the need for you to write so much conditional code for your CSS.
You'll also want to check out A List Apart for more on CSS and IE. There are also great articles on tableless layout with CSS, handling the height bug in IE, etc. Good luck - IE 6 really sucks when it comes CSS.
Certainly not. If you ensure that they render the page in "standards" mode as opposed to "quirks" mode many of the common IE CSS issues are resolved. To do this you must provide a valid doctype statement at the top of the page, such as
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
As others have pointed out, another good idea is to start off your stylesheet with a snippet that removes all paddings and margins like so:
*,html {
margin: 0;
padding: 0;
}
Finally, one common problem with CSS based layouts in IE is that clearing of floats doesn't happen when you'd expect. This is to do with a hidden object property in IE called "hasLayout"; only objects that "have layout" will correctly wrap around and enclose floated child objects. It is easy to ensure that your containers "have layout" simply by specifying at least one dimension for them:
height: 1%;
width: 100%;
zoom: 1;
I do not personally use conditional IE stylesheets except for one single thing: to replace PNG backgrounds with GIFs in IE < 7 - there is nothing wrong with using them, I just find it unnescessarily complicates things when you have to define the appearance of the same object in two different places. With the three tips above and a bit of patience you should be able to create CSS based layouts using a single stylesheet that render just as well in IE 6/7 as they do in Mozilla/Webkit.
Happy coding!
IE 6 really does limit what we can do.
It’s the lack of support for advanced selectors (and inherit — IE 7 doesn’t support that either) that gets me. Just having the child selector and attribute selectors would be nice, that’d really cut down the amount of code we have to write and maintain. You can only work around the lack of support for them by duplicating your styles, so you just end up having to code as if they didn’t exist.
Sigh.
Only follow online CSS tutorials that is rendered correctly with IE6 and Chrome (or Webkit). If it looks right in both, it likely looks right in (almost) all browsers.